Monday, April 20, 2009

Publishing process information using sensors and AQ

Sensors in Oracle BPEL PM provide a nice mechanism to publish in-flight process data in a fire-and-forget fashion. The information that is published (sensor data) is separated from the communication mechanism (sensor action) which is a good thing: it promotes separation of concerns. JMS and BAM are supported communication mechanisms to publish sensor data, native Oracle AQ is not. It is however possible to use JMS over AQ instead of in-memory or file-based JMS for transactional and persisted message delivery and integration with database components. I’ve described the involved steps to publish sensor data from BPEL PM to AQ-backed JMS and subscribe to these events from ESB since it is bit of a configuration-nightmare. These steps apply to SOA Suite 10.1.3.4:


  • Create a new AQ queue or topic (multi-consumer queue) in the database; e.g. MyQueue. These AQ destinations are typically created in the schema “JMSUSER”. Make sure its payload is of type JMS text (SYS.AQ$_JMS_TEXT_MESSAGE) and not XMLType. If not already there, configure a connection pool and data source in OC4J that refers to the database schema that owns the AQ destinations.
  • Create a Database Persistence provider in OC4J. In Enterprise Manager go to oc4j_soa –> Administration –> Database Persistence and click “Deploy”. You could e.g. use JMSUserRP as Resource Provider name and JMSUserRA as Resource Adapter name. Point to the data source as described in the previous step.
  • Create a Resource Adapter connection factory for the newly created Resource Adapter by navigating to oc4j_soa –> Applications –> Default. Select the module from the Resource Adapter list that you’ve just created. Create a new Connection Factory and new Administered Object. Use the queue interfaces -e.g. javax.jms.XAQueueConnectionFactory- in case you publish to an AQ queue, and the topic interfaces if you use a multi-consumer AQ queue -e.g. oracle.j2ee.ra.jms.generic.AdminObjectQueueImpl. Examples of JNDI names are JMSUserRA/XAQCF for the connection factory and JMSUserRA/Queue for the administered object.
  • Define a sensor and sensor action in BPEL PM. Either choose “JMS Queue” or “JMS Topic” as “Publish Type” in the sensor action. Enter the connection factory JNDI name from the previous step as JMS Connection Factory, e.g. JMSUserRA/XAQCF and the JNDI location of the AQ queue or topic. The last value should be like: [JNDI name of the "Administered Object"]/[either "Queues" or "Topics" depending on the AQ type]/[Name of the AQ queue or topic]; for example JMSUserRA/Queue/Queues/MyQueue.


Now, you can create an ESB project that subscribes to the published sensor events and actually does something useful with it.


  • Create an inbound JMS adapter in a new ESB project. Enter the Resource Adapter connection factory -e.g. JMSUserRA/XAQCF- as JNDI name in the first step and select the correct AQ destination from the browse list in the next step.

And voila you’re done.

There are two sides to this. First of all -not the most important one however- is the technical implementation and configuration details as described above.

Secondly it provides a nice pattern. You can use sensors to publish relevant in-flight process data from running instances. This promotes decoupling since BPEL PM does not (need to) know who is interested in the sensor data. It might be that nobody is interested in it. Secondly, you can use ESB’s fan-out and content-based routing patterns and connectivity features to route process data to all interested components, possibly filtering and transforming its data.

Thursday, April 2, 2009

Behind the scenes of OBUG, literally!

This week I attended the OBUG Benelux Connect 2009 user conference. OBUG stands for the Oracle BeNeLux (Belgium, Netherlands, and Luxembourg) User Group. The conference was held at the Metropolis Cinema Complex in Antwerp. One of the sessions I planned to attend was the “Report from the R&D Lab – Analyzing the upcoming 11g Release of Fusion Middleware” session by Lonneke Dikmans and Lucas Jellema. The presentation was held on behalf of WAAI, a collaboration of four Dutch companies in which Lucas, Lonneke, and I participate. Goal of the WAAI collaboration is to share, bundle, and expand knowledge on the upcoming Fusion Middleware 11g release. In this presentation, the initial findings and research of WAAI would be made available to the audience, including real world examples and demonstrations. At least, that was the plan...

From Kuassi Mensah from Oracle -who had an earlier presentation on Database Web Services and SOA- we heard that you couldn’t hook up your laptop. That meant no demo’s! And nobody had informed the speakers about this! Even stranger since Javapolis is held at the same venue and tons of demo’s are given there each year. While Lonneke, Lucas, and I chatted about this we got the idea that I could do the demo backstage while they did the presentation. We asked the Metropolis crew, who was more than willing to help out. Thanks a lot for that guys!

Time was running out while Lonneke and Lucas showed me what to demo and virtual machines, SOA composites, schema’s, and other stuff quickly moved from one laptop to another. Lonneke and Lucas stayed remarkably calm given the situation. Just a few minutes before the presentation we crawled through a secret hatch in the back of the cinema. While I “installed” myself right next to the digital projectors, professional sound systems, buttons, wires, and tons of popcorn Lonneke and Lucas went back to do the presentation. Guided by their instructions during the presentation -while we couldn’t see each other- we still managed to show Fusion Middleware 11g stuff to the audience :-) It turned out to be a great presentation after all, despite the organization or lack of it. Also quite educational when it comes to the inner workings of cinemas and good for the friday afternoon talks with colleagues :-)