The Oracle documentation state that both approach top-down and bottom-up can be used to design SOA composite application. http://docs.oracle.com/cd/E12839_01/integration.1111/e10224/fod_intro2.htm
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: http://docs.oracle.com/cd/E17904_01/doc.1111/e17364/bestpractices.htm#BABCGHEH
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…