Just enough XML to survive

At a recent meeting to review Cape Clear’s training material we discussed the need to provide a brief introduction to XML itself just in case some of the attendees are new to the technology. This introduction should be very brief as we need to quickly move on to all the good stuff like Service Oriented Architecture. So the challenge is this: “If you only had fifteen minutes to teach someone about XML, what would you do?”.

This video presentation contains my answer to the challenge. If you had never heard of XML before, it will get you started with XML, XML Schema, SOAP and WSDL.

Have a look at the video and let me know what would you do differently? If you had another 15 minutes, what other topics would you cover? If I get some good feedback I might even create a sequel.

Business Analysts and Developers working in harmony

The idea of taking process diagrams drawn by business analysts and directly generating executable business processes is some that has always appealed to us at Cape Clear. So when I did some work recently with Yi Geo from eClarus in order to show their Business Process Modeling Notation (BPMN) tools working with our BPEL engine, I was keen to see such a scenario in action.

I set Yi Geo a challenge to start with a blank sheet and draw a simple process diagram which then becomes an executable business process running in Cape Clear Server. This he did, not once, but twice – you can see the results on our developer web site: Two new tutorials one a simple hello world scenario to get you started and of course the now almost mandatory loan approval scenario.

Yi’s white paper on the subject describes some of the issues involved when mapping BPMN to BPEL which makes for some interesting background reading and this is backed up by the tutorials which show the software in action.

Now, I'm not suggesting that developers are no longer needed – the tutorials have been structured to show the tasks performed by the business analyst and those performed by the developer – the difference is they are now working on the same artefact – the business process diagram.

It shouldn’t happen to a WS-Addressing header

I was recently asked to consider a scenario where a document is received by the ESB and must then be processed by a number of web services in turn. Naturally, the first reaction is to use WS-BPEL to orchestrate the calls to each of the web services. However, I did want to also consider what the alternatives would be.

I like the concept that the document travels from one service to another. Each service passes it on to the next service, perhaps with some modification. Instead of services that consume request messages, we have a document travelling through the ESB, eventually reaching its final destination.

The first step was to create some Web services with the appropriate interfaces. They need to take the document as input and return it again as output. I used document/literal style WSDL, so the request and response messages are the same format. For the final destination I have a service that accepts the document and doesn’t generate a response.

Now all that is required is a means to route the messages between the services. WS-Addressing provides the answer here. The wsa:ReplyTo header allows me to specify that the first service should send its reply to the second service. Remember, I’ve designed the WSDL so that response messages are the same format as request messages, so the second service is happy to process the message.

Routing the response from the second service on to the third one relies on the use of wsa:ReferenceProperties. WS-Addressing specifies that the contents of the ReferenceProperties in a End Point Reference will be copied into the SOAP headers of the message. Creating a nested series of wsa:ReplyTo headers within the ReferenceProperties of the original request message means that each service will route the document to the next service in the chain. Click on the image to the right to see the full request message.

This use case might stretch the original intention of WS-Addressing a little. However, it does achieve the desired message routing capability using nothing more than the existing WS-Addressing processing rules. Here’s a zip containing a set of projects that you can deploy into the Cape Clear 7 beta so you can try it for yourself. You'll find a copy of the sample request message in the TaskOne project. Just send it to the TaskOne service using the Web Service Tester.

Design Pattern or Dirty Hack? You decide.