Extending the use of Service Enabled Interfaces for dealing with Business Events

Typically Business Services are considered to be invoked in a synchronous request-response mode. Business Applications are supposedly called into action by human actors who leverage user interfaces. On the other hand, Business Processes are typically assumed to be triggered by Business Events.

However, it is possible to extend the use of Business Services and/or Business Applications to deal with Business Events. This enables the reuse of existing business logic and business rules in order to deal with new buisness interactions which are introduced into the ecosystem without needing to undertake a large service implementation effort.

For the purpose of this discussion Business Services, Business Processes and Business Applications will collectively be named as Event Response Interfaces. Business Events can be routed to the receipient Event Respsonse Interfaces by an ESB or a Message Hub. Business Events may also be sent to a Complex Event Processing Engine for aggregating, filtering or de-duping business events prior to routing them to the apporpriate Event Response Interfaces. Having said that, how does one extend existing Service Enabled Interfaces to trigger them asynchronously?

Architecturally, adding a Message Listener that in turn calls the Service Interface (such as seen in a Service Activator JEE pattern) or leveraging a Service Mediator (such as an ESB or a Message Hub) can allow Business Events to invoke Business Services or Business Applications outside of their regular request-response mode of interaction. The use of this simple architectural strategy allows Business Events to be processed by existing well tested Business Services or Business Applications.

One additional point to keep in mind in extending the interaction context from synchronous mode to that of an asynchronous mode is with regards to dealing with business exceptions, faults and business responses. In a synchrounous communication mode both of these are returned to the invoker of the business service or the business application. In an asynchrounous mode there is a disjointed execution context where in the invoker is not blocking on the call and waiting for execution control to be returned. The execution path may or may not be re-established.

To deal with this asynchrounous communication model the service response and faults may either be logged in a common repository or may be returned back to the invoker by the service mediator. The service mediator may re-establish the execution path with the invoker. The service mediator such as the ESB may refer to the Registry to find the originator or may leverage the correlation identifier and originator address in the payload (a provision made by the WS-Addressing spec. via the use of wsa:From metadata element).

Regardless of which architecture component is used i.e. an ESB, a message hub or a message listerner that intercepts the Event Response Interface the result is the reuse of the service behavior. In addition to reusing the business service applying this simple service extension technique also enables leveraging existing investments in infrastructure components such as the ESB or message hub thus helping achieve business agility.

Please provide me with feedback as to whether or not you have leveraged existing IT service assets to introduce new communications pathways.

surekha -

Invitation to joing the Strategic Use of IT (SUIT) Group

The SOA Practitioners first time got together in August 2005 to share out best practices, key learnings, organizations and governance approaches to Services-Oriented Architecture. Even though SOA is the current hype, the SOA Practitioners believe that the basic principles of this architecture approach will last with the primary objective being the Strategic Use of Information Technology (SUIT). In order to facilitate collaboration between the various teams we have established an Linked In group and leveraging Google Apps to facilitate collaboration among the practitioners.

All Business and IT Practitioners are invited to join the SUIT Group on LinkedIn. Joining this group will allow you to find and contact other SUIT members on LinkedIn as well collaborate using the Google Apps and Sites (Wiki). The goal of this group is to help members:

• Network with other SUIT Practitioners
  
• Share out best practices, key learning, bounce ideas, etc.
  
• Collaborate using Google Apps & Sites

Click here for details on how to join this group.

Business Architecture Dialogue

I will be participating in SOA-Consortium conference being held in Washington DC from March 12-13. One of the main topic I will be focusing on is "Business Architecture". As a result of EA 2010 working group, we have identified Business Architecture as an important aspect of Enterprise Architecture. One of the problems is that there is no clear understanding of what the BA is and how an enterprise should go about creating one.

Surekha Durvasula and myself will be leading a discussion panel to get particpants to talk about their understanding or lack of understanding of BA. Being in Washington, I am sure the dialogue will involve public sector's take on this topic. It will be interesting to see how some of these concepts translate in a public sector settings.

Will let you know how it turned out.

Ashok