Best practices for BPM, SOA and EDA

While visiting ODTUG Kaleidoscope 2009 in Monterey and talking to fellow BPM, SOA and EDA adepts I got this idea about creating a best practices and lessons learned blog series. This first blog is dedicated to best practices in the BPM and SOA-space based on cases from a presentation by Lonneke Dikmans. Subsequent blogs will dive into best practices and lessons learned for a specific product, methodology or technology.

Case I: Introducing BPM. Mistake: Organizational impact underestimated. Explanation: Successful delivery of BPM project, business heavily involved. Never used because they realized after delivery that changes in both the organization and the software were needed. Best practice 1. BPM and SOA are about business, IT and humans. Observe how people work, don’t just ask them.

Case II: Notifications. Mistake: Dependencies between processes modeled directly in the processes itself. Explanation: Process flow sometimes is influenced by other processes. This was modeled into every process: this makes processes tightly coupled to each other and hard to change. It resulted in deadlocks. Best practice 2. Use events to notify running processes. Best practice 3. Monitor & avoid exceptions.

Case III: New technology. Mistake: Use BPEL as a general purpose language. Explanation: BPEL is a domain specific language; it was designed to orchestrate (web) services. Someone coming from a homogeneous -for example PL/SQL environment- in their back office, could decide to rewrite everything in BPEL, even the service implementations. The progress of such a project is very slow, and doing things that used to be easy becomes very hard. Best practice 4. BPEL is a Domain Specific Language (DSL); use BPEL for orchestration only. Best practice 5. Use an Enterprise Service Bus (ESB) to expose services to consumers including BPEL. Best practice 6. Use Java for service implementation. Best practice 7. Use PL/SQL for persistent data manipulation and data integrity rules. Best practice 8. Use rules when you need customization, inference or when business rules are volatile.

Case IV: Quality of Service. Success: involve administrators early. Explanation: Someone designed their first SOA project with quality of service in mind. In production all the non-functional demands were met. Best practice 9: Design architecture for Quality of Service from the start … but only what you really need! Not everyone needs clustering, fail-over, high-availability, and so on.

Case V: Domains. Success: combine a top down with a bottom up approach. Explanation: By defining 6 business domains and one supporting domain, the service taxonomy and event definitions were easier to keep track of. Also defining an owner for some of the services and design guidelines for services that cross domains become possible. Best practice 10. Use domains and layers to facilitate making a taxonomy of services and defining design guidelines.

Conclusion. Think big, start small. Meet in the middle requires aligning Business, IT and People. Architects can be intermediaries. Sharing knowledge and experience is necessary.

The next blog in this series will dive into Web Services best practices.

ODTUG Kaleidoscope 2009

ODTUG Kaleidoscope 2009 is almost coming to an end at the time of this writing. After some chilly days the sun started to shine in Monterey and turned this great event into an even better one. As mentioned almost every day, ODTUG is one of the few conferences that has grown compared to last year. This was my first visit to ODTUG. I actually thought it would be as big as Open World :-) But it’s about a hundred times smaller. And actually that’s cool; much more intimate. Here you really get the chance to speak to product managers, interact with peers, and meet lots of new and interesting people!

So what were the highlights?

SOA and BPM Symposium on Sunday. For the first time there was a separate symposium and track dedicated to SOA and BPM. It was put together by ACE Directors Lonneke Dikmans, Lucas Jellema and Mike van Alst. Although the APEX and database tracks attracted more audience, we had a very interesting and interactive day with a mix of newcomers and SOA-adepts. The day was split into a business and technology part. Breakout sessions were mixed with great presentations by Demed L’Her, Geoffroy de Lamalle, and Clemens Utschig. Read about the results -SOA and BPM approaches- on Oracle Wiki.

Fusion Apps demo. The first official demo of the upcoming Fusion Apps. It looked really smooth! It’s build on top of the new Oracle Fusion Middleware 11g stack (WebCenter, ADF, SOA Suite). Lot’s of social networking capabilities and interaction. Expect to see more of this. Some technology stats: approximately 11,000 task flows, between 5 and 6 thousand tables, tens of thousands of ADF BC View Objects, and so on.

Oracle ACE dinner. Great dinner followed by a bonfire and s’mores on the beach!

Presentations in the SOA and BPM track. Lots of interesting presentations here. I was an ambassador for Lonneke’s presentation and did a presentation myself on SOA in a database-centric environment. Also great presentations by Roman Dobrik on BPEL development patterns, Chris Judson on canonical data models, Mauricio Naranjo on a government SOA project in Latin America, Samrat Ray on SCA in SOA Suite 11g, Mark Simpson on tools for business processes, and Lucas Jellema on SOA in an Oracle classic stronghold.

Meeting fellow geeks. You want to meet people that drive cars with license plates like “BPEL” or “WEB 2 OH”? Find them at ODTUG!

Great conference! Thanks to everyone and looking forward to meet everyone again at Oracle Open World 2009!

Passive adapters in Oracle ESB that won’t be activated

Configuring SOA Suite 10g for high availability (HA) isn’t the most easy thing to do. Several administrators I spoke with and worked with in projects brought this up. I really hope that FMW 11g -besides all the new functionality, enhancements and support for new standards such as SCA- also makes things like HA easier to configure.

One particular issue we recently ran into in one of our projects has to do with the use of non-concurrent adapters in Oracle ESB when upgrading our clustered environment from 10.1.3.3 to 10.1.3.4. Non-concurrent (or singleton) adapters are adapters that cannot run in an active-active configuration since the underlying infrastructure does not provide a good locking mechanism. Examples are file and FTP adapters. JMS and database adapters on the other hand support concurrency. For non-concurrent adapters you have to ensure that there is only one adapter instance active at runtime. Otherwise you could have two active file adapters both reading the same file, starting two ESB flows instead of one. Futhermore, you want to have fail-over. If the ESB RT (runtime) node on which the active file adapter is running (or adapter itself) fails, the passive adapter on another ESB RT node should be activated. In earlier SOA Suite 10g releases you had to install and configure a separate ESB RT for this (ESB Singleton) and deploy non-concurrent adapters to this separate node. Real overkill. Fortunately, in later versions you could deploy non-concurrent adapters to the existing ESB RT’s and configure these adapters in an active-passive configuration by setting the clusterGroupId property. The jGroups protocol is then used so that only one instance of all adapters that have the same clusterGroupId value will be activated.

When we upgraded to SOA Suite 10.1.3.4 none of our file adapters in the acceptance environment was activated anymore! After some investigation it seemed that ESB 10.1.3.4 uses its own jGroups configuration instead of the jGroups configuration as specified in the global jgroups-protocol.xml file (as was the case for ESB 10.1.3.3). That isn’t a problem by default. However, in our case both our test and acceptance environment are clustered and both run in the same network. The internal jGroups configuration of both test and acceptance by default probably use the same ip and subnet addresses. Meaning all adapters of all ESB projects in the same network with the same clusterGroupId are all put in the same active-passive configuration. For ESB project “A” only one file adapter instance for test was active, the same file adapters for ESB project “A” for acceptance were all in passive mode. Luckily you can specify the useJgroupConfigFile property for an ESB endpoint and set it to true to enforce using the jgroups-protocol.xml configuration file; as was the case in ESB 10.1.3.3. Then configure a different ip and subnet address combination for test and acceptance. That way the non-concurrent adapters in the same ESB projects but in different environments are separated when they have the same clusterGroupId. Another workaround would be to include the environment name in the clusterGroupId value, e.g. MY_ESB_TEST_ID and MY_ESB_ACCEPTANCE_ID.

Web Services article on OTN

Oracle recently released Oracle Enterprise Pack for Eclipse (OEPE) 11g. OEPE is a certified set of Eclipse plug-ins that is designed to help develop, deploy, and debug applications for Oracle WebLogic Server. I wrote an article on OEPE’s Web Service capabilities, and more specifically its support for the JAX-WS and JAXB standards. The article includes a step-by-step tutorial, explains different approaches to Web Service development, and concludes with several best practices. You can find the article on Oracle Technology Network (OTN).

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.

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 :-)

Custom adapter article on OTN

A while ago someone asked me if you could create your own adapter and use it from Oracle SOA Suite. More specifically if you could create an inbound e-mail adapter (not available out-of-the-box in SOA Suite) that polls for new mail messages and use it as activation agent for starting a BPEL process or ESB flow.


I knew this was possible -at least the possibility was documented- and searched for a how-to. I couldn’t find one explaining all steps involved. However, I did find lots of questions on the OTN forums asking how to achieve this. I thought it would be nice to write an article about it after I got it working. It’s published on OTN.


The article includes a step-by-step tutorial for building the adapter and plugging it into Oracle SOA Suite components such as BPEL PM and ESB. The article also briefly discusses adapter support, offerings, and convergence in future Oracle Fusion Middleware releases that incorporate former BEA products.


Drop me a line if you’re interested in an example for using a outbound adapter instead of an inbound one. I’ll see if I can add such an example in the future.