Wednesday, August 22, 2007

SOA - Service Aggregation - ESB vs Process Orchestration

One question that is invariably coming up during discussions with technical architects during design of a service aggregation is whether an ESB should be resorted to for aggregating the services or whether a Process Orchestration BPEL engine should be used. I decided to list together the similarities and differences between the 2 approaches.

Summary of Comparision


Process Orchestration Server Approach ESB Approach
Mostly used for synchronous interactions, between services. Asynchronous interactions can be modelled in this approach, but this would normally involve using correlation sets and may increase the complexity and effort. For example using BPEL constructs like invoke and receive.

One fallout of using synchronous interactions is the reduced scalability and failover. If your requirements are high scalability and excellent failover capabilities then using this approach may be limiting
Mostly used for asynchronous interactions between services. Synchronous interactions can be modelled in this approach but require more effort. For example a message going from service 1 to an ESB endpoint, can get transformed into an ESB normalized format and finally routed to another service 2.By avoiding JMS Queues, using direct routing and using late acknowledgement a pseudo-synchronous behaviour can be achieved.

Asynchronous interactions allow for high scalability, excellent failover mechanisms. Using JMS instead of SOAP/HTTP and messaging providers, reliability can also be greatly increased
Choice of protocols for service interactions is quiet limited, mostly to SOAP/HTTP, SOAP/JMS, plain JMS. Most process servers also support some kind of JVM based mechanism for invoking another service's "methods" example POJO method invocation support, SCA/JBI component interface invocation support, etc Most successful ESB products, support larger number of protocols for service interactions. In fact this can be a point of consideration while evaluating an ESB
Support for adapters for interfacing with FTP or SMTP servers, file systems, vendor applications like SAP or radically different systems like main frames is poor to non existent for most process servers Support for adapters for interfacing with FTP or SMTP servers, file systems, vendor applications like SAP or radically different systems like main frames is excellent for most ESBs
Flow of execution control is intermitently "held" by the process orchestration server, this makes it easier to put in centralized exception handling and transactionality. Exception handling support at the process level is present through standard BPEL constructs like those for compensation handlers and fault handlers.While considering SOAP based web services orchestration, transactionality support can be provided through upcoming standards like WS-Transaction or is currently provided as a vendor specific add-on feature. In strictly event based architecture ESBs there is no central execution context, which means like in an event based system the exceptions have to be handled by specific services processing the message at the point of time. There cannot be a centralized exception handling mechanism.But exception based routing can be a easily achieved.
However in vendor provide ESBs which have a message flow context similar to a process context which can be used to exercise central control over exception handling and transactionality. Having such a message flow context may reduce scalability.
The entire business flow configuration or process definition is standards based BPEL or BPEL with extensions and as such is more portable across process server implementations The entire message flow configuration is not standard based. Each ESB vendor has proprietary ways of storing this configuration. This makes the configurations non-portable across ESBs. No popular proposal exists as yet for standardizing the ESB flow configurations.
Transformations are possible but through the use of the central process context to store process instance level variables and suitable assignment statements between complex types. Transformations are possible using ESB flow context. Mostly explicit support for XSL based declarative transformations is present in all commercial ESBs