60 likes | 63 Vues
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.
E N D
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.