Precisely. We already have an implicit scope asscoiated with
EvenHandlers. The spec currently says:
"The
variable and messageType attributes
constitute the declaration of a variable of that name and type within
an
implicit scope associated with the event handler."
So, I am also suggesting we leverage that...
Regards, Prasad
Assaf Arkin wrote:
The problem, if I understand it correctly, seems to relate to partner
links, messages (variables) and correlation sets.
Wouldn't it be easier to just add scope semantics to event handler, so
upon message receipt it could just generate a new scope and make all
necessary local assignments in that scope?
Assaf
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?
If so I am worried that such an approach would lead to typos not being
caught. 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_workgr
oup.php.
|