SOA: Decoupling the database adapter service from the BPEL process

BPEL process

In this article a common source code reuse problem will be brought to the SOA level, using a small demonstration example based on the SOA 11g Handbook chapter 7 source code. Please bear in mind that in order to fully comprehend the content of this post, one needs as a prerequisite, knowledge of xsd and web services wsdl files. The JDeveloper 11g IDE will be used as in the book, but NetBeans could well be another alternative for your SOA development,  which also supports the 64 bit java JDK, or Eclipse Helios,which is preferred by many big organizations, such as the current European Commission IT projects. So try them all to decide on your own whichever suits you best!


Consider for instance a standard JEE web application which requires access to a database. Using the hard coded jdbc connection string to provide the connection details, requires editing the source code, compiling , testing and redeploying, when a new database is provided or the application needs to become distributed. On the other hand, using a jdbc data source, permits the reuse of the code only with modifying the relevant deployment descriptors by the web administrator.  This analogy exists also in the example SOA application, which requires database access , and will be presented next.

composite.xml

The sample medical examination booking application is about querying a database table based on the   the patient identifier (ID), or the patient names in order to query another table and retrieve its hospital record; as shown in the picture of the BPEL process. The initial BPEL process with direct calls to the Database Adapter Services RetrievePatientIdentifier and RetrievePatientRecord is not presented. The XSD and WSDL created for the Database Adapter Services were tied directly into the BPEL process, which means tight coupling. The text of the SOA 11g handbook only guides to the first step of decoupling one DB adapter. Now, as you can see in the composite.xml image, only one   mediator (purple) exists to decouple the DB from the bpel process, the other DB adapter is rather hastily, directly connected to the   bpel process.
This semi decoupled situation is actually presented as an anti-paradigm or anti-pattern. That is, an example case, that you should avoid by all means, since you must abandon the simple drag and drop operations, you now need to manually edit the xml files to solve the problem of fully decoupling. The  steps necessary to decouple the second db adapter follow in brief. The final bpel process we are to implement  and the final composite.xml is shown:

final form of BPEL process

final form of composite

If you 'd rather not delve into the manually editing details, you can consider the following steps as optional, skip them and jump to the next horizontal line to read the two last paragraphs. This is a very long post after all!

---

Well, if you insist on going beyond drag and drop operations, here is a way of doing it:
First, start  by creating the XSD definitions for the PatientDataService.xsd:

 <schema targetNamespace="http://stmatthews.hospital.com/patient/PatientDataService"
        xmlns:hospital="http://stmatthews.hospital.com/patient/PatientDataService"
        xmlns="http://www.w3.org/2001/XMLSchema">
  <element name="PatientDataServiceProcessRequest"
           type="hospital:patientIdType" />
  <element name="PatientDataServiceProcessResponse"
           type="hospital:patientType"/>

  <!--Add on the 2 following elements  for decoupling-->
 <element name="PatientRecord"
           type="hospital:patientType"/>
  <element name="PatientIdentifier"
           type="hospital:patientIdType"/>
  ...

Based on those, it is easy to create the Mediator and its WSDL as shown.

Next, you need to edit the PatientRecordProvider.wsdl file, so that you don't get this screen shot when you wire the mediator to the db adapter, to the bpel process and later insert the new assign and   the invoke activities:

old type is now wrong

<?xml version= '1.0' encoding= 'UTF-8' ?>
<wsdl:definitions
     name="PatientRecordProvider"
     targetNamespace="http://stmatthews.hospital.com/patient/PatientDataService"
     xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
     xmlns:inp1="http://stmatthews.hospital.com/patient/PatientDataService"
     xmlns:tns="http://stmatthews.hospital.com/patient/PatientDataService"
     xmlns:out1="http://stmatthews.hospital.com/patient/PatientDataService"
    >
    <wsdl:types>
      <schema xmlns="http://www.w3.org/2001/XMLSchema" >
        <import namespace="http://stmatthews.hospital.com/patient/PatientDataService" schemaLocation="xsd/PatientDataService.xsd" />
      </schema>
      <schema xmlns="http://www.w3.org/2001/XMLSchema" >
        <import namespace="http://stmatthews.hospital.com/patient/PatientDataService" schemaLocation="xsd/PatientDataService.xsd" />
      </schema>
    </wsdl:types>
<!--replace RequestMessage with patientRecordRequestMessage
    and refresh the variables in the assign and invoke windows
    to get the patientIdentifier appear instead of the older patientQualifier -->
    <wsdl:message name="patientRecordRequestMessage">
        <wsdl:part name="request" element="inp1:PatientIdentifier"/>
    </wsdl:message>
    <wsdl:message name="replyMessage">
        <wsdl:part name="reply" element="inp1:PatientRecord"/>
    </wsdl:message>
    <wsdl:portType name="patientDataServices_ptt">
        <wsdl:operation name="getPatientRecord">
            <wsdl:input message="inp1:patientRecordRequestMessage"/>
            <wsdl:output message="inp1:replyMessage"/>
        </wsdl:operation>
    </wsdl:portType>
</wsdl:definitions>

Next you declare the new patientRecordRequestMessage type to be used, so:

Thus, you now get to this screen shot instead of the old, wrong one, which shows the patientIdentifier (ID):

The process goes on, you delete the old wire, the old invoke and assign activities, insert new as shown in the final form of the bpel picture, and edit their properties to define the parameters correctly, to avoid such failing build messages:
...
     [scac] FATAL_ERROR: in PatientDataService.bpel(168): wrong messageType
     [scac] messageType "{http://stmatthews.hospital.com/patient/PatientDataService}requestMessage" of variable "Invoke_PatientRecordProvider_getPatientRecord_InputVariable" does not match the expected     messageType "{http://stmatthews.hospital.com/patient/PatientDataService}patientRecordRequestMessage" in <invoke>
     [scac] Make sure the correct variable is used in invoke

BUILD FAILED

that is, if you follow the screen shots:

new invoke properties

Create the mediator xsl files:

Delete the old transform, insert a new one and edit as shown:

Create the xsl mappings:

You end with deployment and testing  the composite, as shown:

---

The question surely arises: is it really worth bothering to edit  all those xml files, is it not error prone? I quote: "The Mediator has several functions that all help promote decoupling and agility. It maps from the canonical data structure to the potentially very specific schema for the adapter service, possibly including any value conversions that may be required. When the Database Adapter Service is replaced by a different service implementation, hence with new WSDL and XSD definitions, the BPEL process is unaffected, because the Mediator shields it from these changes. When the data is for some reason distributed over multiple databases, and based on some patient property we have to determine which of those databases to access, the Mediator will take care of this content-based routing. In addition, the Mediator can handle problems with availability of the database service, retrying calls or taking alternative steps. Moreover, the Mediator may present what is a synchronous service through an asynchronous interface, which allows a client such as a BPEL process to continue with other, parallel activities or to be dehydrated altogether to free up resources after the call is made, instead of blocking the thread waiting for the reply, which could take fairly long."
Finally, the gist of this post is:  BPEL processes should never call to adapter services directly. There should always be a Mediator in between. Sooner or later the need to decouple will arise, if you design correctly straight from the beginning, you won't waste your time and effort. So, next time you are about to wire a database adapter, think twice!

Further references

http://oracle-fusion-blogs.com/oracle-fusion-osb-mediator/