[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 126 - Event Handlers with local partnerLinks & CorrelationSets
The discussion of issue 126 at the F2F meeting yesterday seemed to indicate
that in addition to the issues specific to the use of partner links and
correlation sets on event handlers there is another generic issue affecting
arbitrary processes. It relates to the following problems:
- how and when are partner link roles initiated in an executing process
instance.
- what error conditions derive from lack of initiation.
- whether or how the assigned partner "values" of a partner link should be
"enforced" in the case of incoming messages, by requiring that messages be
received only form a specific partner.
Paco
Prasad Yendluri
<pyendluri@webmet To: ygoland@bea.com
hods.com> cc: Dieter Koenig1 <dieterkoenig@de.ibm.com>, wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 126 - Event Handlers with local partnerLinks &
06/18/2004 01:08 Correlation Sets
PM
Yaron,
I will be at the f2f. We can pick this up during that time. I could use
a level set on this as well.
Regards, Prasad
Yaron Y. Goland wrote:
> There seem to be assumptions in your analysis about how BPEL messaging
> works that are fundamentally different than my own. Without addressing
> those underlying assumptions I don't believe we can have further
> productive discussion on this issue. It has been my general experience
> that e-mail is an unproductive way to try and synchronize on
> fundamental concepts. Therefore I propose that we table this
> discussion for the moment and re-start it during the F2F when we will
> have a much higher bandwidth with which to work.
>
> Please let me know if you will be unable to make the F2F. In that case
> we can arrange a phone call if that would be acceptable to you.
>
> Thanks,
>
> Yaron
>
> Prasad Yendluri wrote:
>
>> Yaron,
>>
>> Please see below..
>>
>> Regards, Prasad
>>
>> Yaron Y. Goland wrote:
>>
>> > 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.
>>
>> I don't think this is possible unless the end-point is hardwired to the
>> partnerLink A itself at the point when messages on that link should only
>> come from a particular end-point. I am not sure if that is possible
>> unless it is statically bound before the process starts. How do you
>> prevent someone sending a message on a port (and operation) if it is
>> valid (authorized) for them to send it?
>>
>> The event is triggered based on the receiving endpoint side of the
>> partnerLink receiving a specific type of message and the partnerLink at
>> that instance reflects the end-points corresponding to both sides of the
>> link.
>>
>> I don't think we have a mechanism to retrieve the end-point address from
>> the BPEL process for the partnerRole and selectively reject the message
>> from a eventHandler; to reject such messages or require that messages
>> comes from only a particular end-point etc.
>>
>> So, IMO this scenario is not possible. What is possible is to create a
>> local copy of the partnerLink in an eventHandler so that the reply can
>> be routed to the correct end-point by the infrastructure (by caching the
>> partnerRole end-point). This is so that multiple (concurrent)
>> activations of the EventHandler from messages received from the same or
>> different partnerRole endpoints can function without conflict.
>>
>> Hence putting onus on the BPEL engine infrastructure to create an
>> implicit copy of the partnerLink in the scope of the eventHandler is the
>> right approach IMHO.
>>
>> > 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
>> >
>> > Dieter Koenig1 wrote:
>> >
>> >> +0.5 :-)
>> >>
>> >> I agree with Prasad's explanation for the first part of the issue:
>> >> > Each EventHandler instance (when it is activated) gets a separate
>> >> > copy of the already declared partnerLink with initialized
>> endpoint
>> >> value
>> >>
>> >> > for the partnerRole, in the scope that is local to the
>> EventHandler
>> >> > instance. If the event gets triggered from message sent from
>> >> different
>> >> > end-points (over the life of the scope that contains the
>> >> EventHandler)
>> >> > or by the same end-point it would not matter.
>> >> In other words, "A private copy of all process data and control
>> behavior
>> >> defined within an event handler is provided to each instance of
>> an event
>> >> handler" applies to partner links as well.
>> >>
>> >> Kind Regards
>> >> DK
>> >>
>> >>
>> >>
>>
>> >> Prasad
>> >> Yendluri
>> >> <pyendluri@webmet
>> >> >>
>> hods.com> To
>> >> >>
>> ygoland@bea.com 16.06.2004
>> >> 23:41 cc
>> >> >>
>> wsbpel@lists.oasis-open.org
>> >>
>> >> Subject
>> >> Re: [wsbpel] Issue - 126 -
>> >> Event Handlers with local
>> >> partnerLinks & Correlation
>> >> Sets
>> >>
>>
>> >> >> Yaron Y. Goland wrote:
>> >>
>> >> > By "@" I assume you mean attribute?
>> >> >
>> >> > So are you suggesting that if the partnerLink named in the
>> attribute
>> >> > has already been declared in an outer scope then we use that
>> >> > partnerLink and otherwise we implicitly declare it?
>> >>
>> >> No. Each EventHandler instance (when it is activated) gets a
>> separate
>> >> copy of the already declared partnerLink with initialized
>> endpoint value
>> >> for the partnerRole, in the scope that is local to the EventHandler
>> >> instance. If the event gets triggered from message sent from
>> different
>> >> end-points (over the life of the scope that contains the
>> EventHandler)
>> >> or by the same end-point it would not matter. It is a clone of the
>> >> global (to the EventHandler scope) partnerLink.
>> >>
>> >> > If so I am worried that such an approach would lead to typos not
>> >> being
>> >> > caught.
>> >>
>> >> No scope for typos. The partnerLink reference in the EventHandler
>> >> (onEvent) must reference an already declared partnerLink that is
>> visible
>> >> to the in the scope of the EventHandler and can be caught via static
>> >> analysis.
>> >>
>> >> > Don't we need an explicit mechanism for the BPEL programmer to
>> say "I
>> >> > INTEND this partnerLink to be local to a single instance of
>> the event
>> >> > handler"? After all, if they don't put in the 'intention' flag
>> and
>> >> the
>> >> > named partnerLink hasn't been declared in an ancestor scope
>> then the
>> >> > system knows that something has gone wrong. Without the flag the
>> >> > system would just assume that the partnerLink was intended to be
>> >> local
>> >> > to the event handler which could be an erroneous assumption.
>> >> >
>> >> > Yaron
>> >> >
>> >> > Prasad Yendluri wrote:
>> >> >
>> >> >> Yaron,
>> >> >>
>> >> >> I agree with both of your use cases (or the need to accommodate
>> >> them). I
>> >> >> am suggesting we resolve this via the implicit local partnerLink
>> >> >> creation approach and leave the partnerLink as an @ in the
>> >> eventHandler
>> >> >> declaration, rather than requiring to create a local partnerLink
>> >> >> explicitly.
>> >> >>
>> >> >> Regards, Prasad
>> >> >>
>> >> >> Yaron Y. Goland wrote:
>> >> >>
>> >> >> > I'm not sure if you are agreeing or disagreeing with my two
>> >> suggested
>> >> >> > scenarios. It sounds like you agree with #1. But what about
>> >> #2? In
>> >> >> > that case you would intentionally not want to use a local
>> >> >> partnerLink.
>> >> >> >
>> >> >> > Just checking,
>> >> >> >
>> >> >> > Yaron
>> >> >> >
>> >> >> > Prasad Yendluri wrote:
>> >> >> >
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> I am not seeing any conflict in creating a local partnerLink
>> >> >> (that is
>> >> >> >> identical), when the eventHandler in its life receives the
>> >> message
>> >> >> >> from the same end-point all the time or from different
>> >> end-points.
>> >> >> >> There is a bit of processing overhead in creating the local
>> >> >> >> partnerLink (implicitly), which is not very high IMO, for
>> the
>> >> >> >> convenience it offers.
>> >> >> >>
>> >> >> >> Regards, Prasad
>> >> >> >>
>> >> >> >> -------- Original Message --------
>> >> >> >> Subject: Re: [wsbpel] Issue - 126 - Event Handlers with
>> >> local
>> >> >> >> partnerLinks & Correlation Sets
>> >> >> >> Date: Tue, 15 Jun 2004 09:19:12 -0700
>> >> >> >> From: Yaron Y. Goland <ygoland@bea.com>
>> >> <mailto:ygoland@bea.com>
>> >> >> >> Reply-To: ygoland@bea.com <mailto:ygoland@bea.com>
>> >> >> >> Organization: BEA
>> >> >> >> To: Prasad Yendluri <pyendluri@webmethods.com>
>> >> >> >> <mailto:pyendluri@webmethods.com>
>> >> >> >> CC: Ugo Corda <UCorda@SeeBeyond.com>
>> >> >> >> <mailto:UCorda@SeeBeyond.com>, wsbpel@lists.oasis-open.org
>> >> >> >> <mailto:wsbpel@lists.oasis-open.org>
>> >> >> >>
>> >> >> >>
>> >> >> >> There are two different scenarios for event handlers. I
>> >> believe we
>> >> >> >> need to support both of them.
>> >> >> >>
>> >> >> >> 1) The event handler uses a new partnerLink for each message
>> >> (thus
>> >> >> >> allowing it to accept any message that matches both
>> operation
>> >> and
>> >> >> >> correlation set)
>> >> >> >>
>> >> >> >> 2) The event handler always uses the same partnerLink
>> >> >> >>
>> >> >> >> My proposed change to BPEL would support both of these
>> >> scenarios.
>> >> >> >>
>> >> >> >> Yaron
>> >> >> >>
>> >> >> >> Prasad Yendluri wrote:
>> >> >> >>
>> >> >> >>>
>> >> >> >>> Ugo Corda wrote:
>> >> >> >>>
>> >> >> >>>> I think the difficulty I am having with your Part A
>> example is
>> >> >> that
>> >> >> >>>> the
>> >> >> >>>> BPEL spec is not very clear about the rules for endpoint
>> >> >> >>>> initialization
>> >> >> >>>> of partnerLinks.
>> >> >> >>>>
>> >> >> >>>> In the specific case of Event Handlers, one interpretation
>> >> >> could be
>> >> >> >>>> that, like in our resolution for issue 36, each Event
>> Handler
>> >> >> instance
>> >> >> >>>> gets a separate copy of the partnerLink with an
>> uninitialized
>> >> >> endpoint
>> >> >> >>>> value. So at Time 2 a new instance of the handler is
>> created
>> >> >> with a
>> >> >> >>>> copy
>> >> >> >>>> of partnerLink having an uninitialized endpoint value,
>> >> which is
>> >> >> >>>> then set
>> >> >> >>>> to point to monitor B.
>> >> >> >>>>
>> >> >> >>> I like this approach better than having to declaring
>> >> >> partnerLinks in
>> >> >> >>> a scope local to the EventHandler, explicitly.
>> >> >> >>> Only thing is, the partnerLink end-point (corresponding the
>> >> >> >>> partnerRole) would be set to the correct value, based on
>> >> >> >>> where the message that triggered the event originated from,
>> >> rather
>> >> >> >>> than being uninitialized and then set (by who?).
>> >> >> >>>
>> >> >> >>> Now the reply will get routed to the correct end-point.
>> >> >> >>>
>> >> >> >>> I guess this would amount to an implicit local partnerLink
>> >> >> >>> declaration with the same name,
>> >> >> >>> at the same time keeping the current syntax where it is
>> >> obvious on
>> >> >> >>> which parterLink the event is expected etc.
>> >> >> >>>
>> >> >> >>> Regards, Prasad
>> >> >> >>>
>> >> >> >>>> Ugo
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>>> -----Original Message-----
>> >> >> >>>>> From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent:
>> >> Monday, June
>> >> >> >>>>> 14, 2004 2:41 PM
>> >> >> >>>>> To: Ugo Corda
>> >> >> >>>>> Cc: wsbpel@lists.oasis-open.org
>> >> >> >>>>> <mailto:wsbpel@lists.oasis-open.org>
>> >> >> >>>>> <mailto:wsbpel@lists.oasis-open.org>
>> >> >> >>>>> Subject: Re: [wsbpel] Issue - 126 - Event Handlers
>> with local
>> >> >> >>>>> partnerLinks & Correlation Sets
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> In the example the partnerLink monitor is uninitialized.
>> >> >> Monitor A
>> >> >> >>>>> then sends a message to the BPEL process. Monitor A's
>> >> message is
>> >> >> >>>>> caught by the BPEL process's event handler. As a
>> >> consequence the
>> >> >> >>>>> Monitor partnerLink partnerRole value (being used for the
>> >> first
>> >> >> >>>>> time in the BPEL process) is initialized to point at
>> >> Monitor A.
>> >> >> >>>>>
>> >> >> >>>>> This then leads to time 2 where monitor B, a separate web
>> >> >> service,
>> >> >> >>>>> also sends a message to the BPEL process. This message
>> >> will match
>> >> >> >>>>> on portType, operation and probably even correlation set
>> >> but it
>> >> >> >>>>> can't be caught by the event handler because the event
>> >> handler
>> >> >> >>>>> receives messages using the partnerLink monitor and
>> that is
>> >> >> >>>>> already initialized to point to monitor A so, by
>> >> definition, it
>> >> >> >>>>> cannot be used to receive a message from monitor B.
>> >> >> >>>>>
>> >> >> >>>>> In BPEL today there is no way to write an event handler
>> >> which can
>> >> >> >>>>> accept messages from multiple different partners so that
>> >> simple
>> >> >> >>>>> scenarios like receiving asynchronous updates from
>> multiple
>> >> >> >>>>> sources are almost impossible to implement.
>> >> >> >>>>>
>> >> >> >>>>> Yaron
>> >> >> >>>>>
>> >> >> >>>>> Ugo Corda wrote:
>> >> >> >>>>> >>>>>
>> >> >> >>>>>> Yaron,
>> >> >> >>>>>> As I am reading your Part A, I don't fully understand
>> what
>> >> >> you mean,
>> >> >> >>>>>> under Time 1, by "partnerLink monitor is initialized to
>> >> point at
>> >> >> >>>>>> Monitor A" (and, as a consequence, I don't understand
>> >> your point
>> >> >> >>>>>> about Time 2 either). Could you please clarify?
>> >> >> >>>>>>
>> >> >> >>>>>> Thank you,
>> >> >> >>>>>> Ugo
>> >> >> >>>>>> >>>>>
>> >> >> >>
>> >> >> >> Yaron Y. Goland wrote:
>> >> >> >>
>> >> >> >>> There are two different scenarios for event handlers. I
>> >> believe we
>> >> >> >>> need to support both of them.
>> >> >> >>>
>> >> >> >>> 1) The event handler uses a new partnerLink for each
>> message
>> >> (thus
>> >> >> >>> allowing it to accept any message that matches both
>> >> operation and
>> >> >> >>> correlation set)
>> >> >> >>>
>> >> >> >>> 2) The event handler always uses the same partnerLink
>> >> >> >>>
>> >> >> >>> My proposed change to BPEL would support both of these
>> >> scenarios.
>> >> >> >>>
>> >> >> >>> Yaron
>> >> >> >>>
>> >> >> >>> Prasad Yendluri wrote:
>> >> >> >>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> Ugo Corda wrote:
>> >> >> >>>>
>> >> >> >>>>> I think the difficulty I am having with your Part A
>> >> example is
>> >> >> >>>>> that the
>> >> >> >>>>> BPEL spec is not very clear about the rules for endpoint
>> >> >> >>>>> initialization
>> >> >> >>>>> of partnerLinks.
>> >> >> >>>>>
>> >> >> >>>>> In the specific case of Event Handlers, one
>> interpretation
>> >> >> could be
>> >> >> >>>>> that, like in our resolution for issue 36, each Event
>> Handler
>> >> >> >>>>> instance
>> >> >> >>>>> gets a separate copy of the partnerLink with an
>> uninitialized
>> >> >> >>>>> endpoint
>> >> >> >>>>> value. So at Time 2 a new instance of the handler is
>> >> created with
>> >> >> >>>>> a copy
>> >> >> >>>>> of partnerLink having an uninitialized endpoint value,
>> >> which is
>> >> >> >>>>> then set
>> >> >> >>>>> to point to monitor B.
>> >> >> >>>>>
>> >> >> >>>> I like this approach better than having to declaring
>> >> partnerLinks
>> >> >> >>>> in a scope local to the EventHandler, explicitly.
>> >> >> >>>> Only thing is, the partnerLink end-point (corresponding
>> the
>> >> >> >>>> partnerRole) would be set to the correct value, based on
>> >> >> >>>> where the message that triggered the event originated
>> from,
>> >> rather
>> >> >> >>>> than being initialized and then set (by who?).
>> >> >> >>>>
>> >> >> >>>> Now the reply will get routed to the correct end-point.
>> >> >> >>>>
>> >> >> >>>> I guess this would amount to an implicit local partnerLink
>> >> >> >>>> declaration with the same name,
>> >> >> >>>> at the same time keeping the current syntax where it is
>> >> obvious on
>> >> >> >>>> which parterLink the event is expected etc.
>> >> >> >>>>
>> >> >> >>>> Regards, Prasad
>> >> >> >>>>
>> >> >> >>>>> Ugo
>> >> >> >>>>>
>> >> >> >>>>> >>>>>
>> >> >> >>>>>> -----Original Message-----
>> >> >> >>>>>> From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent:
>> Monday,
>> >> >> June
>> >> >> >>>>>> 14, 2004 2:41 PM
>> >> >> >>>>>> To: Ugo Corda
>> >> >> >>>>>> Cc: wsbpel@lists.oasis-open.org
>> >> >> >>>>>> <mailto:wsbpel@lists.oasis-open.org>
>> >> >> >>>>>> <mailto:wsbpel@lists.oasis-open.org>
>> >> >> >>>>>> Subject: Re: [wsbpel] Issue - 126 - Event Handlers with
>> >> local
>> >> >> >>>>>> partnerLinks & Correlation Sets
>> >> >> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>>> In the example the partnerLink monitor is uninitialized.
>> >> Monitor
>> >> >> >>>>>> A then sends a message to the BPEL process. Monitor A's
>> >> message
>> >> >> >>>>>> is caught by the BPEL process's event handler. As a
>> >> consequence
>> >> >> >>>>>> the Monitor partnerLink partnerRole value (being used
>> for
>> >> the
>> >> >> >>>>>> first time in the BPEL process) is initialized to
>> point at
>> >> >> >>>>>> Monitor A.
>> >> >> >>>>>>
>> >> >> >>>>>> This then leads to time 2 where monitor B, a separate
>> web
>> >> >> >>>>>> service, also sends a message to the BPEL process. This
>> >> message
>> >> >> >>>>>> will match on portType, operation and probably even
>> >> correlation
>> >> >> >>>>>> set but it can't be caught by the event handler
>> because the
>> >> >> event
>> >> >> >>>>>> handler receives messages using the partnerLink monitor
>> >> and that
>> >> >> >>>>>> is already initialized to point to monitor A so, by
>> >> definition,
>> >> >> >>>>>> it cannot be used to receive a message from monitor B.
>> >> >> >>>>>>
>> >> >> >>>>>> In BPEL today there is no way to write an event handler
>> >> which
>> >> >> can
>> >> >> >>>>>> accept messages from multiple different partners so that
>> >> simple
>> >> >> >>>>>> scenarios like receiving asynchronous updates from
>> multiple
>> >> >> >>>>>> sources are almost impossible to implement.
>> >> >> >>>>>>
>> >> >> >>>>>> Yaron
>> >> >> >>>>>>
>> >> >> >>>>>> Ugo Corda wrote:
>> >> >> >>>>>> >>>>>>
>> >> >> >>>>>>> Yaron,
>> >> >> >>>>>>> As I am reading your Part A, I don't fully understand
>> >> what you
>> >> >> >>>>>>> mean,
>> >> >> >>>>>>> under Time 1, by "partnerLink monitor is initialized to
>> >> >> point at
>> >> >> >>>>>>> Monitor A" (and, as a consequence, I don't
>> >> understand your
>> >> >> >>>>>>> point about Time 2 either). Could you please
>> clarify?
>> >> >> >>>>>>>
>> >> >> >>>>>>> Thank you,
>> >> >> >>>>>>> Ugo
>> >> >> >>>>>>> >>>>>>
>> >> >> >>>>>>
>> >> >> >>>>> >>>>>
>> >> >
>> >> >
>> >>
>> >>
>> >> 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
>>
>> >>
>> >> .
>> >>
>> >>
>> >>
>>
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]