Implementing information as a service

A topic that I've been interested in for some time is the concept of Information as a Service. My Software Services colleague Bobby Woolf[*] has just discussed this idea this on his blog. In summary, you can implement services in your SOA that provide an interface to your data, rather than accessing it directly using, for example, JDBC calls - separating your application from the format and location of that data. I thought I'd add my own spin on this by providing a real-world example, and hopefully demonstrate how easy it can be to implement this kind of model.

Background: four months ago I was working on a project where we had been asked to create a portal interface to a proprietary, legacy backend system. We were implementing SOA, so chose to use WebSphere Message Broker as the Advanced ESB product to build a service facade over the backend system. When a portlet running in WebSphere Portal needed to invoke one of the backend APIs (say, GetCustomerDetails or ReportFault), it would send a JMS message to the ESB. The broker would then reformat the incoming XML message into something more palatable to the backend, initiate a sockets connection to the iSeries system from a JavaCompute node, perform the call, and then return some XML to the invoking portlet over JMS.

(of course, we could have put HTTP nodes on the ends of the message flows instead of JMS queues, and generated WSDL, but for various reasons we chose not to do so on this occasion)

So far, so good. The other thing that we needed to do was to get some information from a backend database. Naturally, we could have done this using JDBC calls from the portlet. Instead, we chose to implement an interface that was consistent with the one that we were using to access the backend system - namely, a service exposed over JMS.

One line of ESQL in the Broker (similar to the following) created an output message that was consistent with the format of the responses from the backend.

SET OutputRoot.XML.Response.Services.Service[] =
(SELECT T.SVCCODE AS Code, T.SVCDESC AS Description FROM Database.SERVICES as T);

What this code does is query the SERVICES table in a database and return the SVCCODE and SVCDESC columns as an array, which is used to populate an XML structure - we end up with a set of Service elements in our Response message.



When we later needed to query a second database table as part of the same operation, we were able to use the broker to do this - it merged the two sets of data, and returned a single JMS message containing the response. All in a single line of code.

This example only shows a read operation - but we could implement create, update or delete just as easily, and touch multiple datasources if we chose to do so.

So, what were the key advantages of implementing the Information as a Service pattern here?

1. Very simple to code in broker - I'd even use the word, "trivial".


2. No mixing of APIs on the portal side; JMS (or SOAP/HTTP) only, no JDBC.


3. XML data returned to the portal is ready for use by the same XML parser used to get data out of the responses from the backend, in the same format as it came from other services.


4. The ESB can insulate the presentation layer from database changes... if the database schema changes then it can still return messages that look the same if required.


5. Other services can call the data service if required, so the scope and implementation of the data calls are not limited to the portal.

Incidentally, just to clarify, since it seems to be something of a misconception (in this review, for instance) - you do not have to use ESQL in order to access a database using WMB. We offer Java and Mapping nodes which have similar capabilities. In this case, I wanted to illustrate just how straightforward it can be to build an XML message from a database query using ESQL (it uses less space in my blog!).

[*] I've met Bobby only once, briefly, after a session at a conference about 15 months ago. You can tell he's a guru because he's blessed with a blog at IBM developerWorks. Plenty of interesting stuff to read over there.