Thank you for visiting! If you liked the site, please add a bookmark, else add a critical comment! Would you like to visit Greece? Traditional Greek flag This real estate site is only available in Greek! The holy mountain

Tuesday 21 December 2010

Comments on WS-BPEL 2.0 for SOA Composite Application with Oracle SOA Suite 11g, by Matjaz B. Juric, Marcel Krizevnik


On the bright side, the text is written in American English, formal, well organized and neat, having the last sentence of each paragraph linking to the following one. Although the title sounds pretty familiar, the content of the book is actually about the newer version of BPEL 2.0. That's what makes this particular book unique, as the time of this writing. I quote: "Oracle SOA Suite 11g PS2 supports BPEL 2.0. However, BPEL 2.0 is only supported at runtime and not in JDeveloper. BPEL 2.0 support in Oracle SOA Suite 11g PS2 is not yet production ready, so by default, BPEL version 1.1 is used. However, we can write BPEL 2.0 code in text mode (graphical mode is currently not supported)." This book will help readers utilize BPM suite for integrating BPEL with BPMN. Readers will be able to explore BPEL 2.0 activities, loops, decisions, flow control, variables, scopes and other constructs that will enable them to develop BPEL processes. The authors dig into advanced BPEL topics, such as fault handlers, event handlers, compensation, concurrent activities, links, correlations, message properties, dynamic partner links, process lifecycle, and more. The text is accompanied by two online appendices about the syntax of the BPEL versions 1.1 and the newer 2.0, the  full source code, in addition to a sample chapter and its table of contents, which can be found here. Furthermore, the authors use UML sequence, activity diagrams to describe the composite applications, which is useful to the analysts and designers and scarce to find in competitive books.
On the dark side, there are a few spelling errors, the first 3 chapters are rather tedious to read, since there is no hands on practice, nor questions and answers for the reader to exercise.  The action starts in chapter 4 and forward on. However, there  is only purely descriptive text, with no full, step by step detailed instructions how to build from scratch the application, or how to setup the SOA suite. In addition, parts of the application source code is given as is, i.e. java classes, without any explanation how it was created, or how to deploy it correctly; For example, EmployeeTravelStatus,  in chapter 4, should perhaps be deployed as a shared library, or a stand alone application? 
All in all, the book is a complete and detailed treatise on BPEL 2.0, presenting its origins, other BPEL servers available in the market such as tibco, exotic themes such as Oracle service registry, Business process architect, and so on. Its project is an application about employees travel requests and booking the cheapest available ticket offered by the airline companies,  etc. The book is no introduction to BPEL, but of fairly advanced level, since drag and drop operations are rarely mentioned, the authors prefer to edit the source BPEL and XML code directly, which can be error prone, especially for beginners. Its source code is full of advanced java classes, so developing web services using java, XML basics, look like  prerequisites.
Further references:
You can visit the book page at the publisher's site

Monday 22 November 2010

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/

Wednesday 27 October 2010

Comments on Oracle SOA Suite 11g Handbook, by Lucas Jellema

On the bright side, the book offers a plethora of web resources, apart from the textbook itself. The online supplements are actually a way of previewing it by studying the material mentioned, before buying the book. The text is well organized with a few spelling errors.  It delves deeply into XML code details, such as creating the xsd files and editing them. The historical review serves well as an introduction, presenting both the evolution of technologies and relevant acronyms, such as SLA, SCA and so on. Moreover, the step by step guidance offered, is most of the times, easy to understand and follow. Furthermore, some parts  of the source code is available online, including the intermediate steps. The chapter about complex event processing is remarkable, however one needs Eclipse Galileo, not Helios, to follow the hands on guidance.
On the dark side, some sections are too long to read. Once you are done with the printed text, the online supplements must follow. Besides, the huge volume of information is often hard to manage, therefore rather messy. Some parts of text are duplicated,  some others missing. For instance, on page 74 it reads: "Details for the configuration of JMS, JDBC, and UMS can be found online in Appendix C." which has been actually until recently missing. In chapter 7  some errors are reported, due to missing steps, or xsl files and a misleading image, but not yet confirmed. In addition, parts of the source code are missing, like the XML file SimplePatient.xsd mentioned on page 109. Moreover, some spelling errors are critical, omitting an 'a' from 'asynchronous', surely changes the meaning! Some crucial xpath expressions have typographical errors as well. Web services presented in the text such as ConsultWithHealthInsurers in chapter 11, are not implemented. Furthermore, in chapter 13, page 448: "The wiki provides configuration details for setting up a local e-mail server with these domains and accounts based on the JavaEmail project" but  no such details actually existed until recently. Such errors, or missing information prevent the reader from completing the practice, build the necessary self confidence and continue. Unfortunately, the source code for chapters 10 and above has not been  available until recently,  due to broken links.The code for chapter 15 is still missing. Although most times  the known bugs of soa suite are mentioned, this is not true for the ADF service data objects examples of chapter 20.
All in all, the text is of average quality, the author has striven to equally balance the theoretical and practical  views of the subject. It offers an introduction to XML, XPath too, some of hands on practice. Hence, the book is definitely among the top choices for the reader who would like an introductory book, but clearly inferior to  the Getting started with SOA 11g, as far as quality and precision of hands on practice is concerned. As far as quantity, the difference in number of pages speaks for itself!