RE: [wsbpel] Issue - 43 - Proposal to Vote

[Frank Leymann <LEY1@de.ibm.com>]

I admit that this is a typical pattern.  But adding this feature to BPEL is
some sort of a slippery slope. Why?   The use case given is one from the
monitoring space.  Furthermore, here is some base technology being worked
on within OASIS (Web Services Notification) that describes a corresponding
infrastructure for registering to events, e.g. "I am alive" messages.  My
understanding is that our overall guideline in creating specs in the space
of Web services is "modularization" and "composability".  In that sense,
the feature proposed seems to be the beginning of a slippery slope.

Regards,
Frank







Please respond to <edwink@collaxa.com>

To:    <ygoland@bea.com>, "'Satish Thatte'" <satisht@microsoft.com>
cc:    "'wsbpeltc'" <wsbpel@lists.oasis-open.org>
Subject:    RE: [wsbpel] Issue - 43 - Proposal to Vote


+1 -Edwin

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Monday, June 21, 2004 10:18 AM
To: Satish Thatte
Cc: wsbpeltc
Subject: Re: [wsbpel] Issue - 43 - Proposal to Vote

In our experience this is an extremely common design pattern. We
routinely find our customers needing to write code whose structure in
BPEL would be expressed as:

scope
    eventHandlers
       onAlarm ...
          send out heartbeat
    sequence
       do processing work

In other words, the process is undertaking some potentially long lived
piece of work and while it is processing that work it needs to let 3rd
parties know that it is still alive and still working on the problem.

By putting the heartbeat as an event it is extremely clear from the code
what the relationship of the heartbeat is to the scoped code. One can
glance at the code and understand 'o.k., so as long as this scope is
alive this heartbeat is going to go out'.

                         Yaron


Satish Thatte wrote:

>
>
> Yaron,
>
> Could you also add your thoughts on why this is a "must have"?  I recall
> a discussion long ago where no one was able to argue convincingly that
> it is a must have.
>
> Satish
>
> -----Original Message-----
> From: Yaron Y. Goland [mailto:ygoland@bea.com]
> Sent: Wednesday, June 16, 2004 2:46 PM
> To: wsbpeltc
> Subject: [wsbpel] Issue - 43 - Proposal to Vote
>
> Proposal: The syntax for onAlarm element be changed to:
>
> <onAlarm for="duration-expr"? until="deadline-expr"?
> repeatEvery="duration-expr"?>
>     activity
> </onAlarm>
>
> Only one of three attributes may appear on an onAlarm. The semantics of
> repeatEvery is that from the time that the event handler is instantiated
>
> until it is un-instantiated an event handler will be created every
> duration-expr period. Like onEvent handlers each onAlarm handler created
>
> as a consequence of a repeatEvery exists independently of all other
> instances.
>
>
> 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.
>
>
> 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.



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
.