[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
I agree with Ivana. A subfunction is not a subprocess. A subfunction exists exclusively within the context of a single process and lives and dies in that process's context, it has no independent existence of its own. > -----Original Message----- > From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com] > Sent: Friday, October 31, 2003 7:41 AM > To: 'Frank Leymann' > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Issue - 2- requirements for a sub function > solution > > > Frank, > > The initial wording of this issue defines subprocesses as > outsourced pieces of BPEL codes that can be reused within a > process or across multiple processes. In addition, we may > consider that these outsourced pieces can be defined locally > within a single bpel process and reused only within that > process, or defined as a top-level bpel process and reused > across multiple bpel processes. Subprocesses should be > executed in the context in which they are defined and not in > the context where the calling action is defined/executed. > Therefore, subprocesses must also have input/output > parameters in order to "pass" some information between the > context in which the calling action is executed (the current > context) and the subprocess. So, subprocesses certainly > combine properties of bpel scopes and bpel processes. > > Taking all that into account one conclusion could be that a > sub-process could be easily modeled as another bpel process > with a triggering action referencing either a > request-response or one-way wsdl operation. However, this > would make sense only for sub-processes defined outside the > calling process. But, as you emphasized, Web services are > loosely coupled and I my view this is exactly the problem. > Sub-processes are, by definition, tightly coupled with > calling processes. By tightly coupling I mean: > (1) if calling process is terminated the sub-process must be > terminated as well (at least in case of synchronous call) > (2) if sub-process fails and cannot recover from the failure, > the fault must be propagated to the calling process > (3) the calling process should be able to call the > compensation activity of the sub-process > > I am open to your and Satish's suggestions that we should try > to keep the BPEL model simple and "stay in the realm of Web > services". However, I do not believe that a "notion of > "subprocesses" at the policy level enriching service > definitions" could alone resolve the problem. I am wondering > where requirements #1 and #3 will be specified. Shouldn't > they be part of the BPEL process model? > > Kind regards, > > Ivana > > > -----Original Message----- > > From: Frank Leymann [mailto:LEY1@de.ibm.com] > > Sent: Freitag, 31. Oktober 2003 11:35 > > To: wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Issue - 2- requirements for a sub function > > solution > > > > > > > > We have to define very crisp what a "subprocess" is. We are > > all aware that > > there are many variants of this term. The spectrum reaches from > > > > - a granule of reuse for (BPEL) modellers > > > > over > > > > - a BPEL-snippet at the next lower level within a hierachy of > > BPEL-snippets > > tightly coupled to its "including" snippet at runtime > > > > to > > > > - an entity that shows some BPEL-like processing behavior > and that is > > loosely coupled to a BPEL process > > > > Listing and defining these variants is an endeavor in > itself as we all > > know. > > > > BPEL is a language for specifying business processes in the > > Web service > > space. I guess, it is important to emphasize this. It is > > important because > > Web services are typically loosely coupled. One important > > aspect of this > > "loose coupling" is dynamics in the sense of being able to > decide for > > different service providers (on a per process instance base, > > e.g.). One > > service provider can be used instead of another as long both > > satisfy the > > requirements of the requestor. In BPEL today, these > requirements are > > formulated in terms of WSDL interfaces. What we are > > discussing in the mail > > exchange on this subject is that "a service" that act as a > > subprocess must > > satisfy additional requirements like, for example, being infected by > > transactional context of the invoker, being dependent on the > > requestor in > > terms of termination etc etc. These kinds of additional > > requirements is > > what "policies" are intended for. Thus, I recommend to > > define our notion > > of "subprocess" at the policy level enriching service definitions. > > > > In doing so, we will clearly stay in the realm of Web services. > > Especially, we will comply with the "composability" > > directions the various > > standard proposals took by relying on other general purpose > proposals. > > > > Regards, > > Frank > > > > > > > > > > > > > > > > To: "'Ron Ten-Hove'" <Ronald.Ten-Hove@Sun.COM> > > cc: wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Issue - 2- requirements for a sub function > > solution > > > > > > Ron, > > > > Personally I am eager to leave the 'readability' issue to > > stand on its own > > merit as a separate, orthogonal issue J > > > > I think one of the key degrees of freedom/constraint is the > > intersection > > of: > > > > - 'deployability' as a separate BPEL process > > - 'ability' to act similar to a scope > > > > with the notion of 'easy to use as a function'. You might > > have mentioned > > this in one of your earlier replies. Well truth be told, > > there is nothing > > easy about transactions and compensations. If we want the unit of > > reusability to be that of a scope, then let's lose the idea > > that it's as > > simple as a function call in a functional language. > > > > If we agree with the above opinion (that is, suspend disbelief > > temporarily), then we can focus on how to make separately deployed > > "sub-process-like" BPEL work. > > > > What would the characteristics be? Potentially: > > - structured like a scope > > - one entry point (like a function) > > - "called" similar to starting another scope > > within the same > > BPEL instance > > - which implies that correlation is automatic > > and at the > > invocation-layer, not the full blown correlation set, > > which implies > > us saying something about implementation > > - when the sub-BPEL returns, it has to stick > > around until > > the entire calling BPEL exits, to allow for proper > compensation > > - when the calling BPEL exits, it has to > > remember to tell > > the called sub-BPEL that it can exit too > > - etc > > > > Please let me know we are still on the same page. If we are, > > then there is > > more to come J > > > > Cheers, > > ++harvey > > > > > > -----Original Message----- > > From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] > > Sent: Thursday, October 30, 2003 4:50 PM > > To: Harvey Reed > > Cc: wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] Issue - 2- requirements for a > sub function > > solution > > > > Harvey, > > > > Without putting words in Yaron's mouth, I'd say > > that is a good > > distillation of Yaron's proposal. I would only modify > > item 4, to add > > that invocation of sub-functions (or whatever name you > > want to give > > to the reusable item) should be easily understood by a > > human reader. > > I (personally) think that should be a primary consideration. > > > > What are your thoughts on these ideas? > > > > -Ron > > > > Harvey Reed wrote: > > > > Interesting. I want to make sure I am still following the main > > thread. Are we saying that: > > > > 1. We want to have reusable BPEL > > 2. Since the unit of reusability needs to > also follow > > conventions of compensation, reusability is along > > the lines of > > "scope" > > 3. We want to be able to deploy these > reusable scopes > > anywhere (no restrictions?) > > 4. "invoking" these scopes should be as > easy as with > > regular scopes (no complex mapping of state, like > > with assign) > > > > Close? > > ++harvey > > > > -----Original Message----- > > From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] > > Sent: Thursday, October 30, 2003 11:54 AM > > To: ygoland@bea.com > > Cc: wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] Issue - 2- requirements for a sub > > function solution > > > > Yaron, > > > > The first time I read the BPEL4WS 1.0 spec, > one of my > > strongest reactions was "where are the > > subprocesses?" Over a > > year later, one revision of the spec, and countless > > re-readings, and my initial reaction is unchanged. > > > > Modelling subprocesses as separate web > services is an > > unsatisfactory substitute. This creates > > unreadable processes, > > with, as you observed today, really messy > > <assign> activities > > used to pack and unpack requests and responses. > > Not only are > > the assignments ugly, cluttering the process, but > > the dedicated > > BPEL reader will be faced with > > 1. Discovering that an <invoke> isn't "real" > > (involving a proper partner) -- there is no > > clear way to > > distinguish such service invocations from > > subprocesses, > > except by tricks like naming conventions. > > 2. Decoding the initial <assign> to > > figure out what > > the input parameters are for the subprocess. > > 3. Decoding the trailing <assign> to > > figure out what > > the output parameters are for the subprocess. > > This doesn't sound like the best of modelling > > approaches, and > > certainly makes run-time implementations more > > difficult. Can we > > do better? > > > > Assuming that we can agree that > > sub-functions, as you have > > defined them, can be used as a simple form of > > sub-process, then > > we may be able to converge on a satisfactory solution. > > > > The rest of my comments are in-line: > > > > Yaron Goland wrote: > > Here is my view on what the requirements are for > > a solution to > > Issue 2. > > > > Terminology: > > > > Host - This is the process that called the sub-function. > > > > Requirements: > > > > Integration into host fault/compensation model - The > > sub-function MUST be > > able to throw faults that will propagate to the > > host. The host > > MUST be able > > to call compensation handlers defined in the > sub-function. > > I would add that sub-functions must integrate > > into the host's > > serializable scopes, when shared variables are passed by > > reference to the sub-function. > > > > Functional Programming - One of the key concepts > > of functional > > programming > > is the idea of isolation. Functions in functional > > programming > > systems are > > expected to be able to run in their own context > > and to only > > have contact > > with the host context through explicit value > passing. The > > sub-function > > solution MUST enable for isolation. > > > > Human Usable - It MUST be reasonably easy for a > > programmer to > > read/write > > sub-function definitions and calls without > > requiring the aid of > > a tool. > > I believe we established this as a requirement > > for BPEL very > > early on, in the debate over whether <sequence> > > was necessary. > > > > By Reference - Messages seem only to get larger with > > multi-megabyte XML > > messages now commonly seen. Therefore when > > passing data into a > > sub-function > > it is critical that it be possible to hand over > > the data by > > reference so > > that the data does not have to be copied on its > > way in or out. > > While passing by reference has good, pragmatic > > foundations in > > managing the impact of those ever-growing XML > payloads, I > > believe another line of argument would support > > the need for > > clear, controllable parameter passing to the > > subfunction, such > > that the process author can clearly control and > > understand how > > data are passed to and from the sub-function. > > > > Use in Expressions - It MUST be possible to call > > a sub-function > > anywhere one > > could call a XPATH or other type of general/query/date > > expression and have > > the sub-function return the desired value. > > That is an interesting idea. Such sub-functions > > would need to > > have restricted "signatures" to map to XPath > > functions; also, > > isn't XPath supposed to always be side-effect > > free? That would > > imply that all input variables of the > sub-function must be > > read-only; a single output variable would be > > nominated as the > > function result. > > > > Import - A mechanism is needed to allow > > sub-functions to be > > defined in stand > > alone files which can then be referenced by > multiple BPEL > > processes. > > Agreed. > > > > -Ron > > > > > > > > > > > > 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/le > > ave_workgroup.php. > > > > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]