[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 2- requirements for a sub function solution
Maybe I don't understand this issue at all, please help me out: 1. I think we are talking about sub-processes in the context of reuse, and I think your email reiterated that. 2. The two obvious choices for reuse are: (a) inline textual reuse, which some people have suggested tools can help; (b) another BPEL process 3. Why don't I think there is an in between ground? Because if you want to do useful work in the sub-process, that implies a coordinated shift of state, a.k.a. subject to transactional control, which drags in all the handlers. Then you are just a short hop from a full BPEL process. Please show me how useful (transactional) work can be done, with reusability, that isn't one of the above 2 choices. For me, this issue isn't so much about philosophy of programming languages (although that is an interesting area, and I was co-author of a programming language while at Motorola); the issue is instead a practical one of how to accomplish useful work in a sub-process. ++Harvey -----Original Message----- From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] Sent: Friday, November 07, 2003 12:34 PM To: Harvey Reed Cc: wsbpel@lists.oasis-open.org Subject: Re: [wsbpel] Issue - 2- requirements for a sub function solution Harvey, Harvey Reed wrote: >Which brings us full circle to a much earlier question: Can this >convenience of sub-process be implemented by a tool that has "libraries" to >choose from? Then its not a question for BPEL. > >If we want BPEL to provide something the high level choice is clear: > >1. A simple way to do local data processing (no invoking with all that >implies) > >2. A full blown process with compensation/fault handling, etc > > >I don't think there is much in between. > We may have an issue with concepts/terminology here. We are discussing compositional models for processes; sub-processes are a traditional, tried-and-true approach. We are also discussing service composition, which is a primary characteristic of BPEL. Aren't these logically two separate forms of composition? Must be necessarily embrace a single mechanism to perform both types of composition? >If this is right, then we have three >choices: (a) let a tool do it in libraries; (b) have some local data >processing subroutine (with some semi-painful parm passing); (c) just make >another BPEL process if you want to encapsulate something that has invokes. > To (c) we should note that painful <assign> activities are needed to pack and unpack such requests and responses (I believe Yaron characterised them as "gnarly"). As an alternative, I would add Edwin's point that a sophisticated deployment/run-time system could recognise sub-process "invokes" and avoid the full cost of serializing the logical messages. This has the advantage of not affecting the language (and language doesn't get in the way of such innovations). > >++harvey > > Cheers, -Ron
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]