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:]
> Sent: Friday, October 31, 2003 7:41 AM
> To: 'Frank Leymann'
> Cc:
> 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:]
> > Sent: Freitag, 31. Oktober 2003 11:35
> > To:
> > 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'" <>
> > cc:
> > 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:]
> > Sent: Thursday, October 30, 2003 4:50 PM
> > To: Harvey Reed
> > Cc:
> > 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:]
> > Sent: Thursday, October 30, 2003 11:54 AM
> > To:
> > Cc:
> > 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.
