|
If we
are to have an extensibility story then we really need the ability to specify
extensions as mandatory or optional. This would be especially useful for
re-usable code where the code may have 'special' commands if you are running on
a newer or enhanced system and fallback commands if you are running on an older
system. Since many companies are forced to run many versions of the same
software it is quite reasonable that they will find themselves needing to
provide re-usable code that can successfully run across multiple versions. This
is where optionality becomes interesting.
Optionality is also interesting for cases where the code includes
performance enhancement tips only understood by some systems. In that case if
you are running on those systems its nice to have the tips but if you aren't
there is no reason the code shouldn't work.
Yaron
Ugo,
You make a very
good point; BPEL extensions are only the business of BPEL engines. This does
bring up an interesting topic: should the BPEL process designer, who uses
extension elements, be allowed to designate them as "required" or "optional",
in much the same fashion as WSDL 2 extension elements? Just a
thought.
-Ron
Ugo Corda wrote:
I am thinking of cases where a BPEL extension translates into modified/enhanced behavior of the deployed process. As a potential user of that process, I would like to know in advance whether that extension is supported before I actually interact with the process.
Ugo
-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Wednesday, December 24, 2003 10:04 AM
To: Ugo Corda; 'Assaf Arkin'; 'Satish Thatte'
Cc: 'Sid Askary'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation
Handler
Why would someone who wants to interop with me need to know
that my executable BPEL is using the patented Furby extension
attributes?
They only need to know what's in the WSDL and the abstract BPEL.
The only entity that should care that my BPEL uses the
patented Furby extension attributes is the BPEL engine and it
only needs to know so it can be told if it can safely ignore
the attributes or if it must fail the BPEL if it can't process them.
-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Tuesday, December 23, 2003 10:15 AM
To: ygoland@bea.com; Assaf Arkin; Satish Thatte
Cc: Sid Askary; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation
Handler
Ideally we would add the ability to make policy statements
inside of the
BPEL's definition to provide information about any
non-backwards compatible
extensions made to the BPEL. A BPEL engine, during
pre-processing, would
read in the policy statements, see if there was any it
didn't support and if
there were any then reject the BPEL.
I would rather attach policy statements to the WSDL that
defines the BPEL interface. That way you can figure out
whether you want to use that particular BPEL process without
even having to read the process. And it would better aligned
with WSDL's direction on policies.
Ugo
-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Tuesday, December 23, 2003 10:01 AM
To: 'Assaf Arkin'; 'Satish Thatte'
Cc: 'Sid Askary'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Resolution to issue 10 - Implicit
compensation
Handler
I think the current mechanism specified in the spec is about
as complex as
we can expect most users to handle. Any additional complexity
will benefit a
relatively small group of people at the cost of confusing
everyone else.
I can, however, imagine certain communities having a well
defined and
compelling need for a different kind of default compensation
handler. This
kind of focused extensibility problem is something I expect
to be very
common in BPEL.
Ideally we would add the ability to make policy statements
inside of the
BPEL's definition to provide information about any
non-backwards compatible
extensions made to the BPEL. A BPEL engine, during
pre-processing, would
read in the policy statements, see if there was any it didn't
support and if
there were any then reject the BPEL.
The scenario is that some community really needs a different
kind of default
compensation handler. So they decide to add an attribute to
scopes defining
what type of default compensation handler to use for that
scope. The only
problem is that if their extended BPEL is handed to an
existing BPEL engine
the existing BPEL engine will ignore the attribute and
execute the BPEL
using the standard compensation handler, which is not the
expected behavior.
To prevent this a policy statement is added as a child of
the process
element stating "Do not run this BPEL unless you support the
XYZ default
compensation handler extension". An existing BPEL engine
would see the
policy statement, realize it doesn't support that statement
and so reject
the BPEL.
This kind of well defined extensibility mechanism allows BPEL
to grow in a
backwards/forwards compatible way.
Yaron
-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Friday, December 12, 2003 2:39 PM
To: Satish Thatte
Cc: ygoland@bea.com; Sid Askary; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Resolution to issue 10 - Implicit
compensation
Handler
Satish Thatte wrote:
Yes, this is one way in which one could extend the custom
capability to
match the capability required by what I proposed. I am
reluctant to add
this complication though.
Anyway you look at it, to achieve the same flexibility as
a default
compensation algorithm would require extra footwork to track,
determine
and operate based on the order of completion. Considering the
complexity, most process definitions will gravitate
towards using
default compensation. Any enhancement to default
compensation is a
significant improvement of the language and so I would
consider it
independently of whether or not we can achieve the same
thing using
custom compenstion handlers.
At the moment, like you, I do not believe that we need
to add more
capabilities to address custom compensations. I'm fine with the
compensate activity being able to either perform default
compensation or
naming direct children of the enclosing scope.
Assaf
-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Friday, December 12, 2003 12:38 PM
To: Satish Thatte
Cc: ygoland@bea.com; Sid Askary; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Resolution to issue 10 - Implicit
compensation
Handler
The current specification requires each scope, upon it's
successful
completion, to install a compensation handler within the
enclosing
scope. That could be a compensation handler that was
explicitly defined,
or a default compensation handler (implicit). But a
compensation handler
is always installed in the enclosing scope by the
completing scope.
The new proposal changes that behavior. It requires
each scope to
support an invocation of its compensation handler by the
enclosing
scope, and that could be an explicit or a default
compensation handler.
However, when a scope completes, it installs its
compensation handler in
the enclosing scope only if one is explicitly defined. If
the scope does
not define a compensation handler, it installs the
compensation handlers
of its child scopes within its enclosing scope.
To achieve the same behavior with custom handlers, the
custom handlers
must be able to invoke any compensation handler
installed in their
scope, and not just those coming from direct children.
It therefore
needs an understanding of when a compensation handler is
installed in
the scope, vs assuming that each child scope installs a
compensation
handler upon successful completion.
Assaf
Satish Thatte wrote:
Sid and Yaron,
My main concern with my own proposal is the fact that
the default
behavior cannot be achieved with custom handlers, which is
a fault in
my
proposal. Someone (cannot recall who) brought that up
during the face
to face and it gave me pause. Need to think about that
some more. In
the mean while let us wait for Peter's comments.
Satish
-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com]
Sent: Thursday, December 11, 2003 3:42 PM
To: 'Sid Askary'; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Resolution to issue 10 - Implicit
compensation
Handler
+1
-----Original Message-----
From: Sid Askary [mailto:saskary@nuperus.com]
Sent: Tuesday, December 09, 2003 1:46 PM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Resolution to issue 10 - Implicit
compensation Handler
Satish,
As I said, I think your solution (the reverse temporal order)
is a good one. I think I have a simple compromise: that we
add a sentence to the effect that
" Note: Sole reliance on implicit compensation handlers as a
programming construct or as a means of defining default
system behavior is not recommended."
This may address both the "programmatic" (Yaron's) and
default behavior (my own) assumptions.
Not sure about Peter's concern.
- Sid.
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/le
ave_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_workg
r
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/l
eave_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/le
ave_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/le
ave_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/le
ave_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.
|