Unified Support for Events

This time I would like to mention a few words about another phase of our project - Unified support for events on the Synapse ESB.

This will probably be one of a few postings which will describe this matter. This particular posting simply is intended to lay down some initial background to this concept and introduce a few key terms. It will not be describing the process of unified support, but rather the different types of requests handled by Synapse which results in event formulation.

Some of the different types supported are;

• XMPP Pub/sub
• Atom Feeds
• JMS Topics
• WS-Eventing

Looking at these in a bit more detail;

• XMPP -
  If you usually do a considerable amount of chatting over the internet, chances are you have used this technology at least once... it is the backbone of some popular systems such as Google Talk. XMPP is essentially an XML-based protocol which enables real-time and extensible Instant Messaging feature core (e.g. it is the base of Jabber IM as well as Presence Technology.

• Atom -
  The Atom format was developed as an alternative to RSS. It is a data format used for providing users with frequently updated content.
  
  
• JMS Topics -
  API is a Java Message Oriented Middleware API for sending messages between two or more clients.
  
  
• WS-Eventing -
  a protocol that allows Web services to subscribe to or accept subscriptions for event notification messages.
  

Our goal therefore in brief is giving Synapse the ability to interpret as well as handle these different types of events in unified manner. More on this soon...:-)

Message Mediation

Moving a bit interior....................

This is one of a keys to drive our project to it's successiveness and effectiveness.Hence have the underlying concept of message mediation as a prerequisite to SCI-Flex.

Message mediation is one of the new capabilities of some components like synapse. Mediation is a programmable extension to the messaging capabilities of services that can simplify connecting systems, other services, applications, or components that use messaging. Mediation is used to process in-flight (I just mean the messages on the fly) messages. The types of processing mediation can perform include:

• Modifying or transforming a message.


• Routing messages (or cloned messages) to other or additional destinations.


• Allowing or disallowing a message to be delivered based on some conditional logic in the mediation.
  
  Why use mediations?
  

There are a number of considerations when deciding if mediations are the right solution for your task. It is already possible to write a message-driven bean (MDB) to transform messages between different formats, so why choose mediation?

The most obvious reason for using mediations is that they preserve message identities. If your MDB resends the message after you had manipulated its body, you are actually sending a new message. As a result, the message ID of the new message would be different than that of the original message. This would cause problems if you tried to correlate sent and received messages. Other message properties, such as the expiry or message timestamp will be reset or overwritten when the new message is sent.

Another reason for choosing a mediation over a message-driven bean is that mediations are not tied to a specific messaging technology

However, the mediation programming model provides a Service Data Object (SDO) interface to all messages and a common API for accessing properties and metadata.

Below I have attached a figure for further understanding of how mediation would take place. Here the mediation handler is invoked and passed message context when a incoming message needs mediation

In summary, mediation should be used when you need to transparently modify or route messages. And since the same mediation can operate on Web services or JMS messages, there are more opportunities for reuse.

Why SOA and CEP

The reason to why we chose SOA and CEP integration grew based on a discussion on writing a CEP system using an Apache license. When thinking of what could be done with the new CEP project, we saw the possibility of extending existing SOA frameworks to be capable of making the most of this new CEP system.

After having a fair amount of reading over the internet, we discovered that it was not only us who were interested in the fact but many other individuals, research teams, companies etc who have paid a reasonable amount of attention on this topic that has gradually gained popularity in early 2008. This gave us enough motivation to discover the potential of converting a simple thought into a project that would benefit many.

Our aim is to make it possible for someone who wishes to make use of a CEP system in a distributed SOA environment, without having to worry much about low-level configuring and interfacing. Unlike many developers who are involved with SOA frameworks, most users are accustomed to simply make use of a pre-built framework and integrate some code of business logic which will route information to/from an SOA network. Thus, a typical SOA user will not be looking forward to extend a framework to support a CEP system, but rather look for another that already has that feature.

Based on this requirement, we are targeting to make life easy for a user who is looking forward to make good use of a CEP system, Esper, in a SOA environment hosted through the popular Apache Synapse Enterprise Service Bus.