Setting up Oracle service registry 11.1.1

db options screen shot

Last time  I attended the Oracle day in Athens, Greece, I was impressed by a presales consultant stating that the real difficulties of SOA projects arise not in the first project, but in the second. That is when there is already a prebuilt foundation of services, on which one needs to base the  new applications of the second project. This is the time to prove whether the initial design is worth of the effort, time and money spent.You have guessed  it right, it is all about agility, adaptability to business, or IT changes, and service reuse!
In this new post the installation traits of  Oracle service registry 11.1.1 will be mentioned. No need to clarify the purpose of existence of a service registry within the scope of SOA in this post. You might consult the current SOA governance literature, take for instance chapter 9 of: http://nickaiva.blogspot.com/2010/12/comments-on-ws-bpel-20-for-soa.html as an introduction. I quote some text: "In addition to reuse, a service registry can also be helpful when we need to migrate services from one server to the other. This can happen because of various reasons,
but one of the most common reasons is the migration between the development, test, and production environments. A service registry is also helpful when we need to version services and manage changes. With a service registry, we can also develop more loosely coupled composite applications, because we do not need to hard-code the service URLs. Rather, the application will resolve URLs at run time."
Let's now proceed with the setup. The first  installation attempts failed with rather cryptic error messages. Well, another personality trait which is very important to programmers and pretty scarce to find, is not being too lazy to type a helpful error message, when exceptions occur. So, the technical data follow:

OS is windows 7 64bit, not officially tested by Oracle at present

DB version is 11.1.0.6.0 64bit

Java version 1.6.0_20 64bit

JDBC driver at C:\app\Nick\product\11.1.0\db_1\jdbc\lib\ojdbc6.jar

---

The log output follows:

Expanding C:\Users\Nick\Downloads\ofm_osr_generic_11.1.1.2.0_disk1_1of1\oracle-service-registry-11.1.1.jar to C:\Oracle\Middleware\registry111 ...
Building scripts ...
Platform is Windows
Preparing 'admin' account ...
Preparing account_list ...
Preparing permission_list ...
Preparing approval management ...
Creating standalone configuration ...

Java returned: 1
Installation failed. If accessible, see "C:\Oracle\Middleware\registry111\log\install.log".
To correct installation parameters and resume installation click Recovery.

---

Next come the contents of C:\Oracle\Middleware\registry111\log\install.log:
#
#Tue Dec 28 15:42:49 EET 2010
db.system.name.condition=oracle
install.server.operator.name=Oracle
oracle.database.admin.password=***
oracle.database.datafile=uddinode.dbf
oracle.server.host=hera
oracle.database.admin.user=system
install.server.smtp.port=25
oracle.database.password.confirmation=***
install.http.connector=8081
alldb.create.datasource.name=jdbc/registryDS
install.server.smtp.password.confirmation=***
install.server.admin.mail=nickaiva@
install.os.is.win.andcondition=true
create.desktop.icons=no
porting.standalone.http.port=8080
oracle.database.tablespace=uddinode
install.server.smtp.default.sender.name=
install.server.smtp.password=***
porting.https.use=yes
alldb.install.registry.name=Oracle Service Registry
account.backend.type.condition=database
install.server.smtp.title=
install.server.admin.name=admin
alldb.create.datasource.weblogic=no
security.ssl.password=***
alldb.install.demo.data=no
install.server.admin.password.confirmation=***
security.ssl.username=uddiadmin
dist.version=11.1.1
install.server.smtp.default.sender.email=
porting.standalone.https.port=8443
alldb.create.datasource=yes
alldb.jdbc.custom.uribox=no
install.type.condition=standalone
install.server.smtp.host=[ SMTP server hostname ]
alldb.install.demo.data.settings=
create.menu.items=yes
alldb.create.drop.condition=createComplete
oracle.database.name=orcl
install.directory=C\:\\Oracle\\Middleware
registry111
install.server.admin.password=***
oracle.server.port=1521
db.showall.condition=false
alldb.jdbc.custom.urifield=
alldb.jdbc.drivers.paths=C\:\\app\\Nick\\product\\11.1.0\\db_1\\jdbc\\lib
ojdbc6.jar
porting.hostname=hera
security.ssl.password.confirmation=***
porting.type.condition=jetty
install.server.smtp.account.name=
oracle.database.user=uddiuser
install.windows.menu=Oracle Service Registry 11.1.1
oracle.database.password=***
[echo] Expanding C:\Users\Nick\Downloads\ofm_osr_generic_11.1.1.2.0_disk1_1of1\oracle-service-registry-11.1.1.jar to C:\Oracle\Middleware\registry111 ...
[echo] Building scripts ...
[echo] Platform is Windows
[echo] Preparing 'admin' account ...
[echo] Preparing account_list ...
[echo] Preparing permission_list ...
[echo] Preparing approval management ...
[echo] Creating standalone configuration ...

[java] BUILD FAILED
[java] C:\Oracle\Middleware\registry111\etc\setup\database.xml:737: The following error occurred while executing this line:
[java] C:\Oracle\Middleware\registry111\etc\setup\database.xml:339: The following error occurred while executing this line:
[java] C:\Oracle\Middleware\registry111\etc\setup\database.xml:422: The following error occurred while executing this line:
[java] C:\Oracle\Middleware\registry111\etc\setup\database.xml:207: The following error occurred while executing this line:
[java] C:\Oracle\Middleware\registry111\etc\db\oracle\installOracleDB.xml:99: The following error occurred while executing this line:
[java] C:\Oracle\Middleware\registry111\etc\db\oracle\installOracleDB.xml:166: Java returned: 1

[java] Total time: 4 seconds
Java returned: 1
Installation failed. If accessible, see "C:\Oracle\Middleware\registry111\log\install.log".
To correct installation parameters and resume installation click Recovery.

---

However many times one tries, with the options selected as shown in the db options screen shot, the installation fails due to some build error of the db scripts. Although the installation appears to have failed, the db uddiuser schema has been actually created. On the contrary, some people report that one is better off to create the schema on his own, as you can see in the references. Thus, when one runs installation the next time, having selected an existing db schema "Connect to schema" option, all appears to go well. Well, not everything! If one uses jetty instead of weblogic server, the create data source option does not apply. Therefore, one needs to uncheck the selection, in order to avoid receiving a "Cannot obtain new connection" exception.
The morale of the story is quite obvious, if related to the introduction of the current post: the first time is just the basis, the second time is what matters most. Happy new year to you all!


Further references:
http://www.javamonamour.org/2010/05/trouble-installing-oracle-service.html
OSR - Oracle Service Registry won't create database datasource

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

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/