Category: SOA

The Challenge of SOAD

A major challenge establishing service orient architectures (SOA) and applications is how to design the right services in order to make them reusable and sustainable. A lot of questions have to be answered. For instance:

What are the service candidates?
What is the right service granularity?
Is it better to use a top-down or bottom-up approach?
etc, etc, …

Apart from technical issues answering these kind of questions is very important for the quality of the resulting applications. Albeit the traditional OOAD approaches are helpful, SOA requires a different perspective on the subject. This perspective is party technical an partly business related as existing business processes have to be taken into account.

The article Elements of Service-Oriented Analysis and Design provides a good introduction into the subject.

Experience shows that it is a good approach to have mixed teams with experienced people from the technical and the business departments.
SOAD is neither a merely technical nor a merely business related task. It’s both. That’s the challenge.

Biztalk 2006 at a Glance

I’m currently working at Microsoft TechEd in Amsterdam. My focus is on Business Process Management and Biztalk technology. At the conference I have the opportunity to see and try most of the new Biztalk Server 2006 features. From what I’ve seen so far the next release will not introduce any major changes, but will bring a lot of improvements. Below I’ve listed some information concerning these new features.

1. Zoom
A feature that was really missing is simple zoom functionality in the visual designers of Biztalk, e.g. the orchestration designer. With Biztalk 2006 it’s possible to zoom every model in the designer. That allows to visualize large business processes inside of visual studio.

2. Backwards compatibility
Biztalk Server 2006 is backwards compatible with the 2004 version. That means binding files and other artifacts can be used without or little modification.

2. Admin console
The admin console has been greatly improved. It’s a MMC snap-in and now more like a central point of administration which allows to get status and health information very easily.

3. Deployment
All Biztalk artifacts (bindings, rules, assemblies) can be bundled to applications. These applications can be deployed in it’s entirety. They can be exported as msi files. Such a file can be imported later on a different machine an started with a simple click.

4. BAM Portal
The new BAM portal allows to get access to key performance indicators via web frontend. This tool is really useful for analysts. One can create alerts which send e.g. emails if a particular threshold was reached. In conjunction with the admin console it allows to monitor applications on business- and technical levels as well. The input data for BAM can now also be created by Visio.

5. Routing of failed messages
Extended filter expressions allow to subscribe to failed messages and to process them accordingly. This gives much better control over runtime related problems.

Services and Components

A lot of discussions about Services vs. Components are currently taking place in the blog sphere.
The debate is especially difficult because terms like Component, Service or Widget have a lot of different meanings dependent of whom you ask.
Apart from that I think the phrase Services vs. Components is a bit misleading because this leads to an either-or kind of thinking which is not really helpful.

So please let me add a another kind of definition which uses a more historical approach:

In the very beginning we had Functions. These functions offered raw functionality which was not very organized and therefore often lead to messy code.

Later Objects were invented which gave us the opportunity to model concepts of the real world in our code. Much better but still messy because of tightly bound object systems and white box inheritance and reuse.

In order to solve this Components introduced the notion of explicit interfaces and encouraged black box reuse. Much better but still not open because of platform affinity or complexity, e.g. COM-components, Java-Beans, Corba-Servants.

Now Services add the platform neutral protocols which provide reachability from any platform that supports these protocols.

The main difference between components and services is not the design granularity, although it apparently doesn’t make much sense to create fine grained services. The main difference is openness and reachability.

Conclusion:
A service is a component which is reachable from any platform by using standard protocols.

If you have other definitions which elucidate the subject, please let me know.