SOA Components

What do you really need in an SOA technology stack? To answer that question, let's first have a look as to what SOA really is. SOA is an architectural style, based on service orientation. Ok, so what's architecture? If you Google that term, you'll find 1 gazillion different definitions. I like to look upon architecture as the structure a company gives to its vision. It addresses all the choices (trade-offs) an organization has to make regarding its structure, the way it is organized, how it addresses customers, suppliers, partners and personnel, how and where resources are used (one of them being IT) ... and a lot more. So it's not even about IT, even though a lot of people think so.

If you start working with architecture and especially SOA, sooner or later you will apply it to IT as well. From that point of view, let's see what components you need. Service orientation, as it name says, is based on the use of (business) services.

Let's start at the bottom: services usually make use of data, which will be stored in a database (usually). Next, services exchange data thru messages, so you need something to transport your messages. As different services use different messages (alas!), you will also need a component to transform messages from one format to another. Finally you will need a platform to support a user interface to which the service can be exposed, even though this really is outside the SOA stack. So, basically what you need for an SOA platform is:
- database
- routing & transformation (ie a 'bus')
- UI platform

However, there's more to it. Life isn't that simple anymore. One of the strengths of an SOA is the ability to combine services into a new service: orchestration. So we want to add an orchestration engine to the stack. What else do we need/want? Well, building an SOA is one thing, managing one is another. As you can imagine, the number of services might get large very soon. So you will need at least two additional components: a sort of repository where you can register your services and a management tool that shows you how your services are doing.

Are we done yet? Nope! Managing services is more then just taking care of availability, we also have to take care of security. Who is allowed to use what service? To maintain the reusability of a service, we want a non-intrusive form of security, as a separate layer.

Ok, let's step back and see what we have now:
- database
- routing & transformation (ie a 'bus')
- UI platform
- orchestration engine
- service repository and registry
- management tools
- non-intrusive security

To top it all off, I would like to add a rules engine, to be able to reuse business logic in services, orchestrations, UI, routing and transformations.

Luckily you don't need the whole stack when you start out with SOA, especially when you start small and only within your company. But as SOA is especially very good at organizing processes within your company but also between companies, it will grow fast.

Unfortunately there are not many vendors around who can offer you the full stack. For each and every component I've mentioned there are commercial best-of-breeds and Open Source alternatives. However, integrating tools from just a single vendor can be a challenge, and integrating a lot of best-of-breed tools from different vendors and OSS can be a nightmare (and usually is :p). This is one of the reasons I am very enthusiastic about the Oracle SOA Suite, as it delivers a well integrated suite of components. Most of these are even best-of-breeds, especially the Oracle BPEL Process Manager. I think the integration with BEA will make the Oracle stack even more complete and robust.

Also good to see is that there are a number of OSS projects like GlassFish, who are delivering good SOA components. Unfortunately there are not enough standards yet to overcome the integration challenges. Enough work to do!