Dynamic BPEL

I have had some interesting conversations over the last few weeks about dynamically creating and exercuting BPEL processes.  Most recently this was a conversation with
Dr Taha Osman of
Nottingham Trent University around using semantic web concepts and ontologies to dynamically match services and create composite BPEL services on the fly to realise that matching.  During these and other discussions I have learnt a lot about when dynamic services can be useful and what some of the challenges are.

One of the first things I learnt is that dynamic BPEL means different things to different people.

Dynamic Service Location

My first thought about dynamic BPEL was to treat service endpoints (partner links) as variables and bind to them at run time.  The
Oracle BPEL Cookbook has an example of how to do this.  The basic idea is that the partner link describes the interface of the service only and the actual physical endpoint is bound at runtime based on potentially dynamic information.  This is all covered in
part 3 "Making BPEL Processes Dynamic" by Sean Carey.

Dynamic Service Compilation

In my view the next level up to provide a mechanism for business users to construct their own processes.  This can be done by putting a friendly front end onto a set of BPEL templates and then generating the code to match the business process on the fly.  This is what the BPEL designer does for developers and it is possible to do this for business users by providing them with higher level business abstractions in a GUI tool.

An example of this approach can be found in
part 7 "Building BPEL Process on the Fly" of the BPEL cookbook by Jerry Thomas.

This still requires a human to build the process, just using higher level abstractions.  The next level up again increases the dynamism still further.

Dynamic Service Generation

Imagine a world where web services are not only described by WSDL to define their syntactic interfaces, but they also have associated with them semantic information identifying the problem domain within which they reside and the functionality and attributes they work with from an ontology describing that domain.  Welcome to the world of
the semantic web.

In such an environment we can envision systems that dynamically select services that provides the functions they need and then generate dynamically the process descriptions (BPEL) needed to invoke those services in the right sequence, correctly matching attributes and parameters, doing appropriate transformations to maintain consistency across different units of measure.

This is precisely the sort of problem that my friend Taha is trying to attack.  The problems are boundless.  We spent a few hours discussing it before a guest lecture I gave at the university.  The more we discussed it the more problems and challenges along the way I saw.  Taha was undaunted, he saw each problem as an exciting new field of research.

Another Level of Indirection

David Wheeler, chief programmer for the EDSAC project famously observed that "any problem in computer science can be solved by another layer of indirection".  We have gone up from flipping switches, to writing binary, to assembler, to macros languages, to high level languages, to database management systems, to automated process excecution environments all the time moving closer to telling the computer the problem rather than telling the computer how to solve the problem.

Looks like there is still further to go.  Enjoy the ride.