Re: [ebxml-bp] Fw: [wsbpel] Issue - 126 - Event Handlers with local partnerLinks & Correlation Sets

["David RR Webber" <david@drrw.info>]

Dale,

I'm multi-tasking too much today - I was not clear in
answering your questions.

Bottom line - I'm very comfortable with what we are doing
here - and we are not about to fall into the hole that
BPEL is obviously enjoying being in.

Whatever BPEL is doing - we clearly are marching to
a very different drum.

No issues there.

Cheers, DW.

----- Original Message ----- 
From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
To: "David RR Webber" <david@drrw.info>; "BPSS ebXML"
<ebxml-bp@lists.oasis-open.org>
Sent: Friday, June 18, 2004 12:03 PM
Subject: RE: [ebxml-bp] Fw: [wsbpel] Issue - 126 - Event Handlers with local
partnerLinks & Correlation Sets


David,

I have no idea what your point is here.

Are you suggesting that

1. BPEL has something(s) "wrong" with it that we are in danger of
following?
2. John and your concerns are helping BPSS to avoid repeating those
mistakes?

If so, you will need to elaborate. I would prefer that we not get
involved
in spec. wars here because, as I see it, there are quite different
scopes,
requirements, alignment constraints, and software support tasks in BPSS
than in other BP specifications. Let's worry about making BPSS a 2.0
level ebXML specification.


BPEL has a quite different focus and scope, one aspect of which is that
it is an "execution language" OASIS BPSS explicitly ruled that out of
scope.

Some of us have been wondering whether a construct like "beginsWhen" is
dragging us into the area of an execution language.

So, your concern with "beginsWhen" is in fact an attempt to become more
like BPEL in scope IMO.

If you think that is a bad thing, as you apparently do, IMO you need to
either:

a. explain why "beginsWhen" and "external events" (to b2b choreography
and possibly even state alignment) are not dragging us into the internal
business process execution language area (that is, out of scope areas)
or
b. argue that we need to change our scope to include aspects of an
execution language.

If I have misrepresented you, I apologize in advance. But that would
only confirm my opening remark.

Dale


-----Original Message-----
From: David RR Webber [mailto:david@drrw.info]
Sent: Thursday, June 17, 2004 11:29 AM
To: BPSS ebXML
Subject: [ebxml-bp] Fw: [wsbpel] Issue - 126 - Event Handlers with local
partnerLinks & Correlation Sets


John and mine comments brought into clear focus.

Compare and contrast a BPSS interaction to
this dialogue from the BPEL world!!!

I need say nothing else here ; -)

DW

----- Original Message ----- 
From: "Yaron Y. Goland" <ygoland@bea.com>
To: "Dieter Koenig1" <dieterkoenig@de.ibm.com>
Cc: "Prasad Yendluri" <pyendluri@webmethods.com>;
<wsbpel@lists.oasis-open.org>
Sent: Thursday, June 17, 2004 2:02 PM
Subject: Re: [wsbpel] Issue - 126 - Event Handlers with local
partnerLinks & Correlation Sets


> If I understand the proposal correctly then it would make the
> following scenario nearly impossible to support.
>
> scope
>     partnerLinks
>        partnerLink name="A"
>     eventHandlers
>        onEvent partnerLink="A"
>           do stuff...
>     ...
>
> In this code partnerLink A is not initialized anywhere. However, if a
> message arrives that matches the onEvent element then it will be
> 'caught' by the onEvent handler and a local copy of partnerLink A will

> be created and partnerRole on the local copy of partnerLink A will be
> initialized to point at who ever sent the message.
>
> Now lets say that the desired semantics are that when the first event
> arrives the partnerLink's partnerRole initialized to point at the
> sender and then future events will ONLY be accepted from that specific

> sender in the future.
>
> That's mostly impossible if a local copy of partnerLink A is created
> because the initialization upon receiving the message will only apply
> to the local copy of A and any other instance of the event handler
> will not see it.
>
> But in the current proposal to resolve 126 a local copy is only
> created if the programmer explicitly asks for it by including a local
> partnerLink declaration as a child of the onEvent element.
>
> In other words, the current proposal gives the programmer a choice.
> They can either use a common partnerLink whose state is visible to all

> instances of the event handler or they can use a local partnerLink
> whose state is only visible to a single instance. Both choices are
> required in order to support the two scenarios defined in
> <http://lists.oasis-open.org/archives/wsbpel/200406/msg00046.html>.
>
> Yaron