Sunday, September 19, 2004


Technical Tom shows how we may consider BPEL as a Domain Specific Language. (Update: I have now found a pbblog posting on the same subject from April.) Tom offers an example in which a simple business interaction (withdrawing cash from an ATM) is driven by user-side BPEL rather than supply-side BPEL.

Let's suppose Tom is using a sophisticated smartcard with sufficient memory, processing power and security. It would be theoretically possible to build a smartcard that could run its own BPEL script and send SOAP messages to the ATM. Alternatively, the smartcard could publish its preferred BPEL script, which would then be executed by a BPEL engine inside the ATM. A third option (without smartcard) is that Tom has previously visited the bank's website and edited his own BPEL script, which is now stored on the bank's server.

Meanwhile, the bank has its own business process, together with a fairly strict set of business rules. The actual outcome of the interaction between Tom's smartcard and the bank's ATM needs to be acceptable to both Tom and his bank. If both Tom's process and the bank's process are expressed as BPEL scripts - let's call them BPEL(Tom) and BPEL (Bank) - then we are putting the two scripts together, in other words composing them. Presumably Tom's smartcard will monitor the correctness of this composition in terms of BPEL(Tom).

Of course, the two scripts may be incompatible. BPEL(Tom) may issue some instruction, but BPEL(Bank) may not offer this option at this time. If the two scripts are incompatible, then the composition should of course fail.

Let's suppose that some customers want to withdraw cash regardless of the account balance and accept any charges from a negative balance, while other customers want cash withdrawals to be limited to the available funds in the account. Simply in terms of responding to the variety of demand, it would seem to be a good thing for the bank to offer customers the possibility of tailoring such transactions. In principle, each customer should be free to have as complex a process as he needs, subject to certain reasonable constraints.

So how does the bank enable optimum flexibility for its customers, while maintaining the integrity of its own business process and rules? The challenge on the supply side is to create a platform or environment in which customers can express specific demands, in a way that the supply side can respond to properly. We can think of this as a kind of domain specific language, although not quite in the sense this term is being used elsewhere (including Technical Tom's usage).

1 comment:

Runs with scissors said...

Thanks for including my blog in your post. I'd like to clarify that the post I made on Tom's Tech Blog is only a lead in to a much bigger story I'd like to help write. Basically what I envision is a reference framework for constructing composable domain specific languages. These cDSL’s should be comparatively high-level languages suitable for the average person to use. Not quite natural language processing, but approaching that realm. Maybe a better way to describe it would be the development of a language and grammar as a platform upon which domain specific dialects can evolve.