This blog is intended to discuss the issues encountered while implementing an SOA solution.

Wednesday, March 14, 2007

First Step: Receive a JMS Message

This blog continues the story from my previous post (The Virtual Enterprise). In this installment I will describe what I had to go through in order for my business process to receive an XML message from a JMS queue (using ActiveMQ as the provider). Recall that I am implementing my business process using Cape Clear.

As a point of clarification, I have yet to receive any formal training in Cape Clear's product and am attempting to implement my business process by referring to documentation and tutorials available on Cape Clear's developer web site (http://developer.capeclear.com/). To Cape Clear's credit, they do have a good amount of documentation available to the public. Just to make it a little tougher, I chose to use Version 7 of their product, which (at the time of my effort) is in beta (some may call me a glutton for punishment).

In Cape Clear's world, everything is a web service communicating using SOAP. Also, as for supported JMS providers, ActiveMQ is not among them. They do support (out of the box) IBM, BEA, and JBoss. As an additional piece of information, my Cape Clear installation is deployed on JBoss (other options include BEA, IBM, Tomcat).

So, here is problem number 1 (or is that challenge number 1). How do I get a JMS XML message (non-SOAP) sitting on an ActiveMQ message queue to kick off a business process (BPEL) deployed to Cape Clear?

Just to be specific, there are actually 2 problems here. First, using ActiveMQ as the JMS provider, and second, handling a non-SOAP message. Looking back (after a little teeth grinding and mental cursing), the solution was "easy".

First, I configured the JBoss server to access an ActiveMQ broker running on another machine. This part was fairly straightforward using the ActiveMQ resource adapter. I followed directions that I found here (modified for my specific versions of the products and to use a remote broker in place of the embedded broker). Once I got this working, the next step was to configure the Cape Clear server to route messages on this ActiveMQ queue to my new BPEL process. This was accomplished by configuring a "transport" on the Cape Clear server. I essentially created a JMS JBossMQ transport, but in place of the standard connection factories and queue names, I used the JNDI names for the ActiveMQ connection factories and queue names that I configured with the ActiveMQ resource adapter. And then, like magic, I was able to receive messages from an ActiveMQ queue.

Now, how do I get the BPEL process to handle a non-SOAP message. Fortunately, as I stated earlier, Cape Clear has a good amount of documentation and tutorials on their site. I was able to find an example of handling non-SOAP XML messages in an Orchestration Web Service (i.e. a BPEL process deployed as a web service). This tutorial was created for version 6 of their product, but works as well on version 7. Essentially what happens is that you define an XSLT transformation to wrap a non-SOAP message in the appropriate SOAP header and body tags to make it a SOAP message. This XSLT is applied prior to invoking the BPEL process by configuring an interceptor for the BPEL process deployed within the Cape Clear server. How much this additional step potentially impacts performance is TBD and will be addressed sometime later in my road to discovery :). I wonder why Cape Clear just doesn't make that a configuration option for a BPEL web service and then perform some sort of optimized operation to receive the non-SOAP message, or skip the SOAP message parsing entirely and just pass the message directly to the BPEL?

Anyway.....there you have it. I can now accept a non-SOAP message from an ActiveMQ queue and invoke my BPEL process deployed to Cape Clear. So simple a monkey could do it ;) ......got any bananas?

It has been a bit since I was working with Cape Clear, but if I remember correctly, you should be able to point to a topic (as opposed to a queue) when defining your JMS connection information. Is SOAP over a topic really a good thing to do? It seems as though you could have numerous responses depending on who is subscribing to the topic.

As for the WSDL, you would need to define the JMS binding and address information as required per your configuration.

Actually I may not be working with CapeClear eventually, but I have an Intalio BPMS that needs to have these "SOAP over JMS" messages pulled into an Intalio Business process. I was trying to figure what component or components I need to write and setup. I am not an SOA expert at this point, so I am not sure if I am asking an intelligent question. The JMS topic in question is on JNET (Justice Network), and we are going to be pulling these SOAP messages. So here I am trying to figure what I need to get these messages into my Intalio business process.I have the following in mind:an ActiveMQ broker, but I am not very clear beyond this at this point.

Sorry for the delay in the response, but things are hectic these days. Anyway, it sounds like you should be able to configure the server as I documented (except using a topic in place of a queue) and then have your business process accept the request and process accordingly. I've only played with the ActiveMQ integration with Cape Clear, so I'm not sure of the support on other platforms. For example, you can't integrate ActiveMQ with Sun CAPS without writing your own adapter (or possibly purchasing one). Good luck and let me know how you progress.