I'll make this short. This post is not a theoretical discussion of what SOA is. This is a practical guide to the core physical components required to build a "traditional" SOA-based ecosystem.
I believe there are three basic components required - a Service Container, a Broker and a Process Engine.
A Service Container is used when implementing business logic to expose as a service.
A Broker is used to connect to legacy business logic through mediation, routing or transformation.
A Process Engine is used to coordinate two or more services into a process and expose that as a composite service.
We put these together in different combinations to build out the specific business processes we need. Needless to say, what we run on these components should be reusable, so their interfaces need to be generic, yet extensible. Good data design is required for this.
4 comments:
You could add a business rule engine, as it is supposed to address different things as a BP engine.
All in all, it fits pretty much into my view to a SOA blueprint architecture.
Tammo,
I see a Rules Engine as a second-class citizen of a SOA environment.
Both Brokers and Process Engines delegate (externalise) some of their logic to a Rules Engine, and they therefore abstract the existence of the Rules Engine from the rest of the ecosystem. So we could consider a Rules Engine to be an implementation detail rather than a first-class SOA component.
Regards,
Ganesh Prasad
Ganesh,
thanks for your reply, that makes the chosen level of abstraction pretty clear, but also shows how difficult it is to find a good fitting granularity. For instance, you could also drop the process engine by declaring it to be an implementation detail for the services run in the service container (in a sense that business processes are again rendered as services, a recursive composition model).
> but also shows how difficult it is to find a good fitting granularity.
That's an insightful comment. It made me think about why I chose this level of granularity. Perhaps at this level, the exposed interfaces of all three chosen components are based on service standards (e.g., SOAP) while their implementation languages are different and unique (Service Container - Java, etc., Broker - some proprietary language like IBM's ESQL, XSLT, etc., Process Engine - BPEL). The Rules Engine does not even have a standard defined interface, hence it gets abstracted out of this level.
Perhaps you will then point out that a "Data Services Server" or "Mashup Server" a la WSO2 should also be shown at this level, but to me, the first is a specialised kind of broker that has adapters to datastores, the second a specialised kind of Process Engine based on a simpler orchestration model.
Regards, and thanks for the thought-provoking questions,
Ganesh Prasad
Post a Comment