RE: [wsbpel] Issue 53 - Motion for consideration by the TC

["Haugen Robert" <Robert.Haugen@choreology.com>]

Why couldn't you make exactly the same argument as below about
compensations?

-----Original Message-----
From: Yaron Goland [mailto:ygoland@bea.com] 
Sent: Monday, January 12, 2004 2:29 PM
To: 'Satish Thatte'; Haugen Robert; wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 53 - Motion for consideration by the TC


Given the infinite possibilities inherent in any standard one of the
most important standard design rules is "The spec is done when there is
nothing left to cut."

When deciding what is to be cut a good heuristic is - if you don't
include the feature is there another way of achieving the feature's
goal?

In this case the answer is an unambiguous yes. It is possible, using
BPEL as it exists today, for a BPEL process to interact with any
arbitrary Web Services based distributed transaction framework.

So our debate is not over the availability of a feature so much as the
availability of a simplified interface to that feature.

One should never underestimate the power of simplified interface. After
all, one can plausibly argue that all modern programming languages are
nothing more than a simplified interface over assembly.

The challenge of creating a simplified interface is that one must
simplify. That is, one must intentionally remove options, curtail
choices, etc. in order to create a simple, easy to understand sub-set of
features that programmers can readily access.

So the crux of the arguments being made around issues 53 et al. is over
what sub-set of distributed transaction functionality should be
supported and by implication what sub-set should not be supported.

Given that the Web Service community has essentially no experience with
distributed transactions, in fact the standards to make distributed
transactions possible with Web Services are still under development, any
attempts we make at a simplified interface will be nothing more than
guesses as to which functionality in which combinations will be relevant
to the needs of the Web Services community. In our ignorance we are just
as likely to remove a critical feature as an unnecessary one.

I would therefore respectfully suggest that we need to wait until the
web services community gains experience with distributed transactions
before we presume to determine what simplifications to introduce. As
such I believe it would be appropriate to close issues 53-59 as out of
scope for this release of BPEL.

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Friday, January 09, 2004 9:56 PM
> To: Haugen Robert; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 53 - Motion for consideration by the TC
> 
> 
> Bob,
> 
> My position against addressing this set of issues is
> motivated at least
> as much by a deep reluctance to start designing a rather large new
> dimension of BPEL functionality in the context of the current spec, as
> by any specifics of the argument we are having.  But it would 
> certainly
> be healthy to at least air ideas on all these issues.
> 
> So why not explain what you have in mind for the application data with

> closure signals?
> 
> Satish
>  
> -----Original Message-----
> From: Haugen Robert [mailto:Robert.Haugen@choreology.com]
> Sent: Friday, January 09, 2004 1:01 PM
> To: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 53 - Motion for consideration by the TC
> 
> Satish Thatte wrote:
> > I am not questioning that all business patterns
> > have an orderly closure requirement and can 
> > therefore be "fitted into a simple business 
> > transaction protocol very nicely".  
> > What I am questioning is whether the separation 
> > of the closure part of the protocol from the rest 
> > is valuable, or even viable given the requirement 
> > for passing application data, which you are not questioning.
> 
> I'm just not dealing with the issue of
> application-data-on-protocol-signal yet.
> (If that issue is resolved, will you vote 'yes'?)
> 
> But there will always be a difference between
> the application messages and the protocol signals,
> even if the app messages follow a business pattern
> (as we both agree they should).
> 
> And yes, closure itself has a business value, for example, knowing 
> that you and your counter-party have agreed on the order so you can 
> safely move on to fulfilling it.
> 
> Or knowing that you failed to agree and must move on
> to the next trading partner or method of getting
> what you need to do business.
> 
> It's analogous to Robert's Rules of Order:
> people may say roughly the same as a formal proposal,
> but it won't become a formal decision until
> it goes through the formal protocol.
> 
> Everybody can make up their own formal protocol,
> but why?
> 
> 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_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_workgr
oup.php.