Abstract BPEL Candidate Use Case: Modeling for Business Understanding Wednesday, May 23, 2004 Disclaimer: These are the views of Phil Rossomando and not necessarily those of his employer.

Why Modeling is Important for BPEL Customers think in pictures and rarely in code. Code requires a level of investment in time and money that most customers and business modelers are not usually willing to commit. Their focus is and should be on understanding the business and not on the learning a new coding language. For additional understanding business knowledge is chunked into bite sized morsels called business rules. Business people are used to thinking in the form of such rules.

Why Abstract BPEL Is Important to Modeling Business rules written in natural language may themselves be open to interpretation. Abstract BPEL may be used to serialize visual models: While people think in terms of pictures, computers think in terms of code (i.e. bits and bytes). This is another level of abstraction but still a models. Visual models are usually always simplifications of processes. Hence they are usually incomplete. Thus the underlying serialization is usually not directly executable. However, its validity must be verifiable.. It must be an accurate representation of the visual model seen by the customer. Abstract BPEL may be used to share models between tools. For example, round-trip engineering. Visual model – compiled -> Abstract BPEL -> elaborated -> Executable BPEL (interesting here, elaborations may become OCL constraints on the visual model itself.)

Observations Abstract BPEL is a variant of Executable BPEL in the sense that it is a form of PCODE/Pseudo Code for visual model representation. It is more formal than natural language but rather not as elaborate as executable BPEL. From a modeling perspective, it may be possible that Abstract BPEL may itself never be seen by the customer but be generated under the covers so-to-speak. The visual model represents the customer visible portion of the Abstract BPEL.

Observations Continued Going a step further, it would appear that elements within executable BPEL that can be produced automatically through compilation need no representation within Abstract BPEL hence these can be left un-said by either the human coder or the automated tool. On the other hand, things which the Abstract BPEL production engine would like to leave to the elaborator may be called out using opaque. Opaque thus become nothing more than the place holders that are placed by automatic code generators today in those places wherein the coder is expected to add elaboration.

Conclusion Abstract BPEL can become the bridge which moves business concepts from the drawing board to the real world. As such, it may be a key link in a Model Driven Architecture supporting traceability for concept to implementation and back again.