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 |
