[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal for implementing Abstract Process Template case
Dear Colleagues: I have been following the discussion concerning abstract processes. I have read Satish and Rania's Strawman. I have also been following issues 82 and 107. I feel a part of the problem is that to the best of my knowledge, no one has implemented abstract processes. I believe abstract processes are a powerful concept. However I have not seen a clear business case showing how abstract processes solve real life problems. I feel it important to create abstract process prototypes to see if the ideas actually work. I believe the Strawman, and 107 provide sufficient information to experiment. Based on my limited experiences with WS-BPEL; reading the specification and prototyping a toy front-end parser and a toy runtime (still in their infancy), I have come up with the following ideas. Hopefully others can comment and expand on the ideas. I know much of this is speculation, but abstract processes are speculative. That what makes abstract processes interesting and exciting. In the weeks to come, I will try to prototype some of these ideas. ~~~~~~ Problem: Imagine, I have a (BPEL) choreography that automates the negotiation process for the on-line purchase of widgets. My rules are simple: 1)Based on a product in my on-line catalogue, you send me an offer containing the product, the price, and the quantity. 2)In return, I will send, an acceptance, a rejection, or a counter-offer. 3)In turn, you will send me an acceptance, rejection, or counter-offer. 4)If after three rounds, an acceptance has not occurred, the negotiations end in failure with a REJECTION. If in any time an acceptance occurs, I will successfully terminate the negotiations with a Quote. I embody these rules in a BPEL abstract process instance. However I design the BPEL abstract process instance in such a way that third parties can add their own business logic (through use of opaque). I place the abstract process in a public place. Third parties are free to transform the abstract process into a form suitable for their use. As long as third party's executable instances of my abstract BPEL process complies with what my automated negotiation choreography implemented by my BPEL engine expects, things are fine. Otherwise my engine will terminate the choreography with the non-compliant third party implementation. My problem is that most partners who want to trade with me do not have BPEL engines. Some partners cannot afford the engine. Other partners do not want to make the initial investment. Others find it too difficult to transcribe the BPEL abstract process into a form (say a Java or Python programme) that can implement the choreography. Since automating the negotiation process is the best interests of all parties (especially me since I have a BPEL engine), how do I stimulate trade? Solution: Provide the tools and information to allow third parties to turn abstract BPEL processes into some target implementation language that will actually execute the choreography. Part One: The Minimal Abstract BPEL programming idiom. "Less is More" - Mies van der Rohe I propose that the first part of the solution is to figure out how to write an abstract BPEL process instance with just enough constructions to allow one to implement the choreography in question. Or in more technical terms, just enough BPEL to allow a concrete instance to exhibit the proper public behaviour, or in other words, a valid execution trace. I believe a relatively small subset of BPEL can describe the execution traces of most BPEL choreographies. Control flow constructs like "flow" and transaction/information hiding constructs like "scope" are internal behaviour and should not find their way into a minimal abstract BPEL process. Minimal abstract BPEL process are simple. Minimum abstract BPEL is an idiom because it is a programming guideline, not a change to the language, or a solution to every problem using abstract processes. Part II: A Common Intermediate Code: The first goal of Minimal Abstract BPEL processes is describe the public visible behaviour of a BPEL process. The second goal is to allow for easy translation of minimal Abstract BPEL into a high level language. To this end, let us pretend that there is an agreement amongst BPEL vendors to have BPEL implementations to produce intermediate code. To keep things simple, for now let us assume this intermediate representation is restricted just to the constructs needed to represent abstract minimal BPEL. This intermediate code is somewhere between an Abstract Syntax Tree and an intermediate representations based on say, three code addresses in complexity. However this code has one fundamental characteristic: it adheres to all the "MUST" requirements of the BPEL specification. The intermediate representation does not preclude vendors from performing further optimizations on the IR insidetheir implementations. Now the format for this Intermediate Representation is placed in public. Better yet the representation is given an XML syntax. Again note, the intermediate representation exists for the benefit of making translators easier to write. And allowing every Tom,Dick, Harry, and Andrew to write a translator. Rationale: The idea is to make it very easy for individuals and companies to write Abstract BPEL process to Target-language-X translators (one of my first computer books was Kernighan and Plauger's "Software Tools" with their Ratfor example. In the case of C#, Java one can imagine the output being an abstract class representing the choreography in question. Now third parties simply use their tool of choice in filling in business logic. I figure that having this heavily processed intermediate representation could greatly easy the translation process. Now if I publish an abstract BPEL specification that adheres to the coding guidelines, the following can happen. 1) I can publish the Abstract BPEL process. I can also publish the intermediate representation as well. 2) A third party interested implementing Abstract BPEL processes in say, C#, Java, Python, or Perl can write a translator. The theory behind the intermediate code is to make it easier to re-target the final output. Final comment. The output from these translators are very simple choreographies implemented in the target language. These provide few of the benefits one gets implementing choreographies with WS-BPEL and a full blown tool. The overall strategy is to lower the barrier to entry by allowing a proliferation of simple-to-build tools that provide rundamentary but functional choreographies. And to start a network effect and grow the WS-BPEL ecosystem.....
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]