The South East Asia SOA Weblog

SOA standards have long been maturing and as of the last few years we now have a fairly complete suite of interoperable standards to work with in the web services world other than a few minor vendor nuances. One of these standards is the WS-Eventing standard (http://www.w3.org/Submission/WS-Eventing/) which leverages other key SOA standards such as SOAP 1.1 SOAP 1.2 and WSDL 1.1 among others.

Building an applications integration framework is still a steep challenge as SOA standards, tools and frameworks have not yet matured to the same extent as the preceding generation of integration solutions loosely falling under the EAI (Enterprise Applications Integration Banner). That being said there is still hope.

The WS-Eventing standard provides the SOA platform with key messaging capabilities similar to the way that JMS and other messaging frameworks provided those capabilities for the previous generation of EAI style integration components. The basic principles of WS-Eventing are in fact very similar to JMS but of course operate at application level and inter-operate nicely with other SOA standards. As with the other SOA protocols, the transport for WS-Eventing may be implemented across multiple underlying technologies such as HTTP and JMS. In my opinion this is one of the innate strengths of the web services stack as it allows applications to route messages at application level across multi-vendor environments thus freeing the application from vendor specific integration.

In this article I will outline the basics of the required components. In later articles I will provide detailed guidance regarding how to create an application-to-application integration infrastructure using WS-Eventing and SOA web services.

Application Integration Componentry: When implementing applications integration there are a few necessary types of component that normally comprise a strong architecture:

The Common Bus or Hub
The Application Adapter
The Common Schematic View
The Application Schematic View
Message Transformers

The common Bus or Hub: normally incorporates facilities such as transport, security, routing, common schema definition, common transformation, logging and other features. The modern SOA incarnation of this is of course the ESB. The quintessential difference between the modern ESB and previous message brokers and hubs is that it supports the use of key SOA web services standards and is built to accommodate the needs of a service oriented architecture.

The Application Adapter: is usually delivered as a pre-built component and possibly an API which provides developers a way of integrating data and transactions vertically to applications. Typically the applications adapter provides two major interfaces, the inbound interface and the outbound interface. The inbound interface handles any messages (transactions & data) bound for the application. The outbound interface “senses” any changes in the data within an application and publishes outgoing messages to the bus or hub to notify other applications that an application event has occurred. Typically it is the role of the adapter to transform the format of outbound messages from the application schematic view to the common schematic view and inbound messages from the common schematic view to the application schematic view. A good example of such a standard is/was JCA. Many JCA adapters exist today and many of the current generatio9n of applications adapters also support SOAP based interfaces. The great weakness in most of today’s applications adapters is lack of support for WS-Eventing which relegates the use of such adapters to northbound integration with older technology and over-complicates matters.

Presently the suites of SOA standards do not provide a standard for applications adapters in the same way that J2EE provided JCA.

The Common Schematic View: is usually defined within the context of the central bus or hub and provides a schema to which all applications adapters should conform when sending and receiving messages. Typically this schema is implemented with XML documents. Older implementations use XML DTD but most modern implementations use XML XSD.

The Application Schematic View: is defined within the context of an application. It provides a transformed schema that supports the way in which data should be represented within specific applications. Like the common schematic view this is usually defined with XSD.

Message Transformers: provide the components and logic to transform messages from one format to another. With XML messages this is typically accomplished using XSLT. Of course the broad requirements of integration usually also dictate that non-XML messages be handled therefore message transformers may exist to handle transformation to and from any specific formats (usually to and from the XML representation or from one XML representation to another). An example of a message format that is becoming popular is REST (representation state transfer) which uses an internal schema based on JSON data types. An emerging common application requirement is transformation between JSON and XML.

The Current SOA Technology Situation…

The current situation is that no standards exist that cover all of the aforementioned components and address the end to end framework required for implementing EAI-style integration using SOA technology. That being said, WS_Eventing does provide a very neat transport mechanism for outbound applications adapters to publish events to and ESB. Our favorite ESB right now is WSO2 ESB which provides a full implementation of the WS-Eventing specification with the ability to route, transform and manage subscriptions in a durable manner. We are in the process of developing a framework and API that delivers applications adapters and transformations that leverages WS-Eventing.

Watch this space…
Over the coming weeks we will be releasing an application adapter framework based on WS-Eventing that can be used with any ESB or server infrastructure that supports WS-Eventing and SOAP. Watch this space.