OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Dale,

Sorry - I should have made it clearer - difference between
BPSS approach - where BTA are deterministic and have
guards and single entry point / exit point - and BPEL - that
is non-deterministic and branches wildly through process
flows and signals and events can be thrown in a will.

As the email showed - even the experts working on the
BPEL cannot figure out how these flows can / should
connect - and they are constantly tripping over yet
more exotic scenarios -and therefore issues.

This was exactly the point John and I were seeing - that
by providing controlled BTA mechanisms you never ever
have the confusion and chaos occuring - and wonder of
wonders - so can build the same models and mechanisms
and they work with BPSS - just a heck of a lot faster
and easier to assemble.

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]