Oracle SOA/BPEL top-down or contract-first approach: not as simple to implement as expected …

The Oracle documentation state that both approach top-down and bottom-up can be used to design SOA composite application.

The top-down or contract-first approach forces the designer to focus on messages and contracts (create the data contract in XSD and the behavioral contract in WSDL) as the key concepts in designing a service contract.

However, using this approach, i have been faced to multiples issues especially if you applied the separation of concern with the MDS usage. The MDS datastore allow to centralized and solve the dependencies runtime by storing abstract WSDL artifacts (and others XSD, XSLT, XQuery, …) into the database (XXX_MDS schema).
You can read the Oracle Official Documentation here:

For a big customer in France implementing our Oracle SOA/BPEL solution, we have used the top-down approach to design their BPEL flows. Most of the implemented flows follow the one-way delivery or asynchronous patterns (OnEvent, OnAlarm, Timers, Pick activities…) due to their business needs.

The XSD (stored in MDS) are also used by others developpers to implement their WebService, EJB or SpringContext components. As BPEL use internally JAX-WS for the mapping between Java Classes and XML object, we decided to used the JAX-WS generated classes inside the Java code.

If you understand the under the hood process of BPEL when you use EJB Adapter or Called a Spring Component using SprinContext; then you realize that JDevelopper do some reverse engeenering from the implementation classes (JAR file) and generate WSDL file with the regenerated XSD types.

However, the generated XSD/WSDL file from JDevelopper does not really match the original WSDL file (as we design it from the top-down approach). Here are some differences, i have notice:
– complex defined type containing simple type are simplified
– to be completed

This leads to the duplicated types during BPEL compilation  process (and/or runtime execution),  where the compiler complains about the same type defined both in the generated WSDL file and the XSD stored in the MDS.

Solution for SpringContext and EJB Adpater:  

In the generated WSDL, comments out the types generated by the wizzard, and reference the XSD via the oramds protocol

Solution for WebService Adpater:

This is more complicated as we do not have the control of the generated WSDL file exposed by JAX-WS.  You need to ask the developper’s of the WS to tweak their WS packaging to exposed the same WSDL defined from the top-down approach. In this case, copy the XSD on the classpath of your WS implementation.
For this tedious task, Maven is your friend.

TODO: to be continued with more example…

About Chenda Mok

19 years of hands on experience in software design and development with emphasis on Enterprise Application Integration (EAI), Services Oriented Architecture (SOA) and Identity Management (IDM) solutions. I’m a software engineer, member of the professional service delivery team working for Salesforce. Prior to this, I worked for Oracle as Solution Architect, through SeeBeyond(06/2005), then SUN’s acquisition (04/2009). After my master’s degree in computer science in 1997; I always delivered consulting on architecture, design, implementation on integration’s field. I’m interested in architecture using EAI/SOA/IDM/BPM/Cloud technologies, software development and Java’s related technologies. I may blog about my work/activities at Salesforce, but I do not speak for my employer, past, present or future.
This entry was posted in bpel, SOA Suite. Bookmark the permalink.