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

ESB vs Service Adapters

follow link below for discussion on ESB vs service adapters http://ganesh.ghag.googlepages.com/soa-adaptersvsesbs ganesh ghag

On the way, to SOA

follow this link to discussion aout SOA adoption http://ganesh.ghag.googlepages.com/enterprisearchitectureold-newcomparison

Securing Web Services - Fundamentals

Web Security : Introduction

Web Applications Security can broadly be categorized into following 2 types

1. Transport Level Security eg SSL
2. Message Level Security eg WS-Security

Transport Level Security (TLS) involves securing the transport channel. It may be deemed inadequate on account of following reason: TLS is essentially a point to point security mechanism. If there are proxies involved or message encounters multiple hops on its way to destination, there is no guarantee that the message security will not be compromised

Message Level Security (MLS) involves sending security tokens or authentication / authorization data as part of the message itself. Irrespective of any number of hops or proxies, security evaluation at the destination ensures much more reliable security.MLS is essentially a end to end security mechanism
It invariably adds performance overhead

 

Message Level Security for Web Services

Web Services - Security (WS-Security)

• WS-Security specification describes message level security standard as applicable for Web Services
• WS-Security specifies enhancing SOAP headers to include security information
• WS-Security provides a flexible mechanism for associating security tokens with SOAP messages
• Security tokens can be binary format certificates, XML-based SAML assertions, encrypted data
  

Web Services - Security

Web Services - Security specification, details the addition of xml-based security information to a Web service SOAP message. The following diagram clearly depicts how WS-Security headers and tokens, fit into a standard SOAP message

 

 

 

 

 

 

 

Security Tokens Supported by WS-Security are of the following types

• User Name token
• Binary Security tokens eg X.509, kerberos, tokens
• XML-based tokens eg SAML assertions
• Encrypted Data tokens
• Security token references
  

 

 

Common message-level Security Services provided are as follows

• Message Authentication as provided by certificates (binary security tokens)
• Message Confidentiality as provided by encryption mechanisms specified by XML Encryption Specification
• Message Integrity as provided by signatures specified by XML Signature Specification
• Message Security Credentials propagation
  

Note:
As per the flexibility of the WS-Security specification, the above 3 services can be combined in various ways to build security models with varying strengths and complexities

Skeleton SOAP Message using WS-Security

 

Cryptography and Keys

Asymmetric Keys

The most common scheme involves using a suitable cryptographic algorithm to generate public and private key pair.

1. The private key is provided by the source agent to the destination agent off-hand
2. The public key is used by the source agent, while encrypting the message
3. The private key is used by the destination agent while decrpyting the message

Symmteric Keys 

The most common scheme involves using a suitable cryptographic algorithm to generate a single key which is shared by both the source agent and the destination agent.. The same key is used for encrypting as well as decrypting the message, by source and destination agents, while sending and receiving the message.

Using symmetric keys though less secure has performance benefits. Some security schemes like the popular SSL protocol, use asymmetric keys for intial exchange of authentication information, once the channel is authenticated, subsequent exchange of pure data occurs using symmetric keys for performance reasons.

Digests and Digital Signatures

These are primarily security mechanisms to ensure message integrity, that is, to ensure that the message has not been tampered with, while it was in transit.

In the simplest case, the entire message or a part of the message, is run through a suitable encoding algorithm, to generate a unique hash-code, which is called a digest. This digest is sent along with the message to the destination agent. The destination agent reruns the received message through the encoding algorithm once again to generate the digest. The destination then verifies that the newly generated digest is same as the digest that ships along with the message.

This mechanism can very easily verify message integrity, but is not fool-proof, because, a sneaky message interceptor, could in theory, intercept the message, change it to its purpose and also change the digest, to be consistent with the modified message. To guard against this kind of tampering, additional to using message digests the message or part of its contents is also signed by the sender.

Steps involved in using digitals signature mechanism, are as follows

Source Agent:

• Calculates the digest based on some encoding algorithm, and attached the hashcode to the message
• Uses a private key to produce a digital signature, to sign the message with

Destination Agent:

• Receives message, checks the hashcode / digest value with message to be consistent with the message, using the same encoding algorithm, as used by the source agent
• Also uses a public key, issued by the source agent, to verify the signature.

Any undesirable interceptor, cannot, simulate the digital signature, since it does not have access to the source agent's private key. Thus, message integrity is assured.

Certificates

A certificate primarily contains the following:

1. Identification details of the certificate owner
2. public key as issued by the owner, for use by message receivers

Signed Certificates

Certificate issuing authority further, signs the certificate, using its own private key. This signature can be verified by the receiver, using the public key issued in the certificate. The certificate issuing authority may be  a trusted intermediary and not necessarily the message source agent.

Yours truely published an article at javaworld.com

Article is about Implementing Crosscutting concerns using Spring 2.0 AOP

SOA Pros and Cons

Pros:

• involve business more closely and directly in defining business process
• closer allignment of actual business requirements with software specs
• processes / services more adaptive to changes in business requirements due to extra abstraction of business process composition layer. previously application logic was hardcoded to -business logic/requirements which kept on changing
• re-use of business logic in the form of services at the macro / enterprise level
• integration within enterprise, across enterprise is based on standards for service description, service implementation stack, service registration and lookup, service invocation

Cons:

• issues with services being stateless (at times business logic mandates service should be stateful)
• issues with performance due to technology stacks for implementation and due to statelessness as well
• standards for transactionality, coordination of services within an orchestrated process, are still evolving, currently a service can be assured of transactionality only within itself, there is no standard transactional behaviour support at the level of a process
• service interaction is still popularly based on RPC-like request-reply paradigm, which is not as conducive to loose coupling as are event based interactions with an intermediary like a queue
• not enough importance is given to the removal of hidden coupling introduced between services due to sharing of persistent data