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?