Event Driven versus Orchestration

I had an interesting conversation the other day at a client who was very interested in an event driven approach towards integration versus the traditional centralized orchestration model. The discussion identified that within the event driven model, the state of the process would be maintained in the message versus in the singular centralized orchestration (BPEL). Both solutions have their strengths and drawbacks. One of the big drawbacks that was discussed was in monitoring/management. Operations likes to have a centralized, process oriented depiction of what is occurring. The event model we discussed would spread out the process across a wide range of intermediaries and the message would be updated along the way. Not an ideal situation if viewing from this perspective. Whereas, the BPEL Service provides a more centralized view/approach.

An option for Event Driven would be to utilize an auditing interceptor that would provide a centralized view/update of the process execution. Operations could then monitor this service to get the depiction they preferred.

A strength of the BPEL approach was in the composing of task services or business processes. An event approach everyone thought would not be as easy to compose, however the scalability/performance benefits is very intriguing. This discussion will continue and hopefully draw out distinct patterns on when one approach is better than another.

Cape Clear and the bigger picture

Well over a week ago Cape Clear was consumed by the SAAS marketplace. When I first heard the news I scratched my head but as SAAS gains steam, the need to share data via automation becomes more important. The increasing communication of data outside organizations has not decreased but only increased making simplified integration an imperative. Currently I am working with a several clients that are sharing data with business partners to provide a more complete solution. REST and SOAP interfaces are the standard and from experience are easier then the RosettaNet and EDI standards of the past. These standards spent a lot of time identifying a domain, event model, protocol etc that provided an out of the box roadmap for B2B.

These days the protocol and policy's are standardized however the event model and domain are custom to each. Most of the customers I am doing work for are implementing simple B2B models that share core data and simple event models. This is currently comprised of a WSDL on each end with customers invoking each others interface.

How does this tie into SAAS? Well if you are familiar with the first evolution such as Salesforce.com, there was a backlash from large organizations around storing their data offsite with poor APIs to extract and manipulate the data. After several iterations, Salesforce.com has improved their APIs and you see the second generation like Google, Workday and others providing compelling solutions for GIS, ERP etc. These services have taken off not only in small niche like applications but in the Fortune 1000 and Local/State/Federal Government.

What SAAS has exposed is the need for integration never decreases, it just sort of shifts from internal to external or if you look from a SOA perspective, the interoperability is baked in from the start.

The acquisition of Cape Clear is testament to this fact and identifies the need to use standards to simplify adoption.

BPEL Caching / Persistence

I recently attended a vendors presentation on some caching technology whereby Java Objects could be stored in an in-memory DB or caching layer. The architecture appeared to be quite sound in that it utilized a peer to peer network to manage copies of the information for reliability purposes. The demonstration sparked my interest in its application to stateful BPEL as persisting to a database is a costly exercise when executing large amount of transactions. Prior to / Following this I read subsequent articles at www.soamagazine.com which discussed BPEL Reliabilty using such a concept. A reliable in-memory grid caching store was discussed:

The original article:

Article 1


A current article:

Article 2

Application of technologies such as these will provide dramatic impacts to stateful BPEL Services that are more and more being utilized for Service Composition.

Apache CXF and SOAP Headers

Here is a link that helped me with the Apache CXF client capabilities. The requirement was to send a request to a web service which required a SOAP Header expressing authentication information. The WSDL for the Web Service did not express the request in the abstract portion but rather in the binding/concrete portion of the WSDL. Apache CXF generated a class to support the setting of the Authentication Header but no methods to add it to the request. Using Google and a decent portion of scanning/reading, I found that Apache CXF will not generate the appropriate methods to attach a SOAP Header. Java Annotations provided the answer as described at:

tapestryofthoughts.blogspot.com

By adding an annotation @WebParam along with the header=true flag and other appropriate values in the generated <####>SOAP.java as well as instantiating the Authentication Header via the generated class inside the <####>SOAP_Client.java, the client was sending a SOAP Header to the destination service.