Dejavu: Concurrent Programming

Now I am doing SOA projects for a few years, I can still can rely on knowledge that I did on school. In the eighties I did some practices with concurrent programming. Building low-level applications what acts as processes and were handling information to each other.

When we were clearing the study room, I went trough a lot of books to look which can be thrown away. Then I saw the boook that I used during my study:
Looking into the book, it was a deja-vu. I saw that Business processing and the implementation in SOA/ESB/BPEL had much similarities with this book. While this book is rather technical, it also describes the principles about concurrent processing. The information in this book is very useful for implementing SOA application. It helps you to bridge from functional business processing to the technical implementation.

The difficult thing in business processing, is that all processes are running individual and in parallel. Furthermore, the processes are not in sync with each other, most of them are running at different points in time. Then there are processes that a waiting for other process for requesting or receiving information, all of these issue should be taken into account while designing SOA processes.

More info on the book can be found here.

Deploy single instances of XSD files

In most common project based on SOA we are using a lot of XSD file to specify the format of the message. The goal is often to design several common schema's that are used by the various processes in the SOA application (ESB/BPEL/Workflow).

By default, I mean, you just create BPEL or ESB processes, XSD files are generated by default or you import the XSD files in your project. Oracle JDeveloper just copies the XSD files to your local project. For development purposes this is nice, but for production environments (especially for maintenance), it is horrible to maintain all these files. Each project contains the WSDL and XSD files with the import statements:

<import namespace="http://www.vijfhuizen.com/Error"
     schemaLocation="MyErrorMessage.xsd"/>

What you would like is to have one single source in your SOA project that holds all the common schema's.

You can enable this as follows, I suggest two solutions, but I prefer the last.

Let Apache keep the files.
On your Apache server you copy (ftp/scp) all your XSD files to the server. In the Apache configuration (httpd.conf), you create an 'Alias' that points to this directory. When you restart Apache, your could access these files via a normal http request.

Now you can change your XSD pointers to:

<import namespace="http://www.vijfhuizen.com/Error"
schemaLocation="http://www.vijfhuizen.com/commonfiles/MyErrorMessage.xsd"/>

De disadvantgae is that each time a change is made in the common XSD files, you must copy the files to the Apache server, using FTP/scp. This is different than the other SOA components.

Let BPEL keep the files.
You just create a dummy BPEL process, named CommonFiles. Add to this process all your XSD files. Just compile the project and deploy! Thats all.

Now you can change your XSD pointers to:

<import namespace="http://www.vijfhuizen.com/Error"
       schemaLocation="http://www.vijfhuizen.com/orabpel/default/
                  CommonFiles/1.0/CommonFiles/MyErrorMessage.xsd"/>

Advantages: No changes at Apache level, no FTP/scp steps. the XSD files are under control by BPEL, you could use version functionality of BPEL.