[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]
If I were to be mischievous, I would paraphrase another company's CTO (company, person to remain anonymous until they choose to break cover) who stated (evocatively, if no doubt simplistically) that BPEL was syntactic sugar plus long-running transactions. In the same light-hearted vein I would also note that the urge to escape into a spot of user code in a GPL seems to afflict many BPEL implementers (most notoriously in the form of BPEL/J), suggesting that the sugar sometimes tastes like salt. I think that Andrew's thoughts on the possibility of expressing many (some, lots, all?) long-running interactions in GPLs like Java or C#, and the expense and complexity of deploying BPEL engines in all sites, are very interesting. At the same time there is a missing dimension. The real value of BP execution engines, in my view, is not so much that they provide a better or easier programming language, but that they are recoverable execution engines. It is their recoverable state that makes them capable of supporting long-running, interruptable interactions. If I am not mistaken, BPEL is normatively silent on this aspect: it is broadly assumed that a useful BPEL implementation will be recoverable, but I can create one which does not have this useful characteristic. An extension of this point is: can we assume that both the process engine and the services that it invokes and exploits are equally well equipped? Are the services going to be recoverable? Services may be substantially less complex in terms of conversational breadth and concurrency, but still need to be long-running (recoverably stateful). And what about those long-running transactions? Here we have a linguistic construct (nested compensatable scopes) which is a) valuable, because it provides a way of expressing relationships that are arguably harder to capture in a GPL than many other features of BPEL, and b) of questionable value, because it stops short at the very boundary which would make it truly powerful, the process boundary. If BPEL interactions were marked as, or could be deduced to be, taking place within transactional scopes, then the projection of those scopes into the interlocutor (service or processe-as-service) would enable the real work of the interaction to be tied, from initiator to executor, into a long-running transaction, which is a very useful abstraction from the details of distributed coordination. Transactional behaviour would cease to be a private matter, and become part of the externally observable behaviour, and rightly so. Defining the mapping of such projection points to the use of a distributed coordination protocol, and the making it easier to state and imply the consequent obligations upon a service or a process-as-service would add significant value to BPEL. Bringing these two points together: perhaps the hardest problems in supporting reliable long-lived business process executions and interactions are not defining control flow, concurrency and listener-dispatcher behaviour (let alone manipulation of internal process state), but tackling recovery and distributed LRT, at both ends of a conversation, in an economical way. Alastair Alastair Green CTO and Director Choreology Ltd 68 Lombard St London EC3V 9LJ www.choreology.com -----Original Message----- From: andrew.francis@mail.mcgill.ca [mailto:andrew.francis@mail.mcgill.ca] Sent: 24 January 2005 20:45 To: satisht@microsoft.com 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_workgroup.php. Choreology Anti virus scan completed
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]