RE: [wsbpel] Issue - 2- requirements for a sub function solution

[Harvey Reed <hreed@sonicsoftware.com>]

Yes, that is what I was driving the discussion toward. If you want a true
sub-process, there are certain minimum requirements (my email below) and you
ultimately end up with another web service, with all the associated
mechanics.

If people want to have very small "snippets" I suspect that will end up
being handled in modeling tool libraries, which is beyond our scope.

++Harvey



-----Original Message-----
From: Frank Leymann [mailto:LEY1@de.ibm.com] 
Sent: Friday, October 31, 2003 5:35 AM
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/leave_workgroup.
php.