MoreWhite

So what exactly are we trying to do when we define a business process? Are we composing, orchestrating, aggregating or managing web services? Are we defining the business interactions with our partners or an abstract process for our B2B partners? What terms should we use when we’ve got two thousand to choose from?

Not surprisingly, there are as many specifications for defining business processes as there are fancy terms: BPEL, BPML, BPMN, XPDL, BPEL-J, etc. Do any of these have anything in common? Yes, there are all four letters long!

All of the specifications for composing business processes from existing web services are big. And complex. And boring. But can we really blame them? Trying to define any possible interaction among services, plus format it is XML, cannot be simple. Or can it?

The object oriented world has been using programming languages for years, successfully defining all sorts of processes. And, although this may come as a surprise, business ones too. So why do we need another XML specification?

Well, it is great to tweak our process without having to recompile it. And since we are only dealing with XML messages, we don’t need the extensibility provided by programming languages. I agree. But for some strange reason, BPEL and others still try to do programming stuff, like ‘if-then’ decision making in XML. XML is a declarative language. Leave it alone, let programming languages handle logic.

Can we remove the logic from a business process definition? I think yes. First, let us examine what business process specs really do. They declare the interactions between web services. We all know web services use SOAP. Or XML. And all they do is process XML requests and deliver XML responses. Web services are XML message processors. A process defines the flow of messages from one service to another. Any process, even a business process. Sounds simple? It is. Oh, but we forgot about business decision making, content based routing, security, etc, etc. Don’t we need to include that in our specification? But why not include all of these as services themselves? A content-based routing service can decide where to deliver the XML messages it receives; a security service can encode/decode the message it receives, and so on. We simply have a pipeline of XML message processors, each acting as a message filter, with output of one being used as input to another. Sounds familiar? Yes, the Unix-style pipes are back in action.

A pipeline is an XML document itself. We can generate it at runtime, during the execution of our business process. Then send it as a message to the Pipeline Execution Service, to be executed. Sounds powerful, doesn’t it? What entities are needed to define such a process? Services and message paths – a pipeline.

I can here readers screaming stuff like “service have interfaces” and “you need to modify the response of one service to make it an input to another”, and I cannot help but agree with you. But in the wonderful, paradise world of XML, we have the beauty stylist – XSLT. It can transform our messages in any imaginative way, thus allowing us to pipe output of one service as input to another. Note: you can substitute the word ‘service’ for ‘process’ in the previous sentence, and it remains valid. Yes, pipelines may be recursive, naturally support concurrent execution, synchronization, and so on. Even critical regions can be defined using services.

Pipeline processing can be greatly simplified if we use REST-style services. Each service in the pipeline is identified by a URI alone. No need for complex definitions of SOAP endpoints, operations, etc. But I’ll leave the SOAP-REST debate for another post.

Realistically, BPEL is the major language being supported by most vendors. But its lack of expressiveness and flexibility will be a big obstacle before any major clients attempt to define business processes in it. For a long time to come, the familiarity with programming languages will outweigh the benefits of productivity offered by BPEL, mainly due to its unnecessary complexity.