[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Question on Profile Usage Re: [wsbpel] Issue 82 - resolution]
This is an interesting discussion but I have lost track of the thesis/antithesis dialectic here that we are debating to achieve synthesis ;-) > I am starting off with the assumption common to many distributed processing models that an external observer *cannot* see what is inside a BPEL process. The only way BPEL processes can communicate is through message exchanges defined by a protocol. Completely agree. > a question is "what is the minimal amount of BPEL we need to include to define a protocol that provides the proper externally observable behaviour?" I think the subset of BPEL that does this is small.... This remains to be seen. What is your opinion on the utility of event handlers for things like unsolicited "cancel" protocols? What is your opinion on orderly recovery including compensation in the event of business level failures? The question really boils down to: are such failures handled in protocols or out-of-band? > Also, isn't this what "profiles" are about - using abstract BPEL to handle a particular use case - i.e abstract-BPEL-as-template-method-for-translation- into-simple-3GL-languages-for-trading-partners-how- do-not-have-BPEL-engines ;-) Yes profiles can be used for this. I didn't think this is what we were debating. -----Original Message----- From: andrew.francis@mail.mcgill.ca [mailto:andrew.francis@mail.mcgill.ca] Sent: Monday, January 24, 2005 12:45 PM To: Satish Thatte Cc: wsbpel@lists.oasis-open.org Subject: RE: [wsbpel] Question on Profile Usage Re: [wsbpel] Issue 82 - resolution] Hello Satish: > I am now getting lost. You are focusing on the aspect of my post, which is a thought experiment. I feel the main points of my previous post is to show how the abstract BPEL as the "template method" design pattern works. For readers familiar with a high level OOP, they can see how the body of an abstract BPEL process implements an algorithm. In turn, the body of the abstract BPEL process maps onto a public method of an abstract class that cannot (or should not) be overridden. The opaque is akin to a protected method that allows the algorithm to be altered in a very proscribed fashion. "Protected" is used to signal that concrete subclasses must provide the necessary implementation detail. Note in my example, I have not introduced any new keywords into the BPEL. And as I previously described in the original illustration, the abstract BPEL does not care if its concrete implementation is a BPEL process or some intermediate high level language. >Why would one want to translate abstract BPEL to a 3GL >like C# or Java? How is this so different from what a BPEL interpreter written in C# or Java, is performing, internally? And stops one from compiling a BPEL process into native code? >These languages are not designed for expressing >long-running interactions. However Java and C# are pretty good general purpose languages. With the proper class libraries, general purpose languages will be a source of WS-BPEL competition. They may not have all the bells and whistles of WS-BPEL, but for many, this may prove to be a good enough solution...... >Which means that only trivial processes can be >straightforwardly translated to them. What is the >goal? I am interested in determining the idioms concerning the design of abstract processes. I am starting off with the assumption common to many distributed processing models that an external observer *cannot* see what is inside a BPEL process. The only way BPEL processes can communicate is through message exchanges defined by a protocol. In this context, how can one tell a "trivial" process with rundamentary control flow, from a "complex process" that implements scopes/compensation, atomic assigns, and concurrency? Assuming that the goal of my abstract BPEL process is to provide a concrete implementation with just enough BPEL constructs to successfully communicate with my implementation, a question is "what is the minimal amount of BPEL we need to include to define a protocol that provides the proper externally observable behaviour?" I think the subset of BPEL that does this is small.... Small and simple enough that it seems possible to treat the DOM of this minimal abstract BPEL as an AST. In turn one can convert it straight to a high level language than in turn, can be compiled..... Perhaps I am just itching to use the Visitor pattern..... Seriously, I admit this is handling a simple case, assuming that synchronous exchanges are easier than asynchronous exchanges. Besides illustrating that abstract BPEL can be a language neutral specification, this raises questions like: 1) Are there real world cases that these trivial processes solve? For instance I can see scenarios where one has invested in a dedicated BPEL engine. However most of one's trading partners are SMEs (small to medium enterprises) that for whatever reason, do not have BPEL engines. If you don't trade electronically, you lose on your investment and on lost opportunities. Why not have a translator or make available translators that pumps out code skeletons that your partners can use? This allows your partners to engage in a choreography. Eventually the partners will see the merit of having a more sophisticated solution and may migrate to WS-BPEL.... 2) How much engineering effort would it take to create translations of more sophisticated BPEL processes (support asynchrony)? Could we say, adapt cookies to work with correlation sets (I think Edwin Khodabakchian bought this point up once)? Now how many real world cases get covered? 3) Also, isn't this what "profiles" are about - using abstract BPEL to handle a particular use case - i.e abstract-BPEL-as-template-method-for-translation- into-simple-3GL-languages-for-trading-partners-how- do-not-have-BPEL-engines ;-) Cheers, Andrew To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]