 |
| 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/
