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

["Yaron Goland" <ygoland@bea.com>]

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_workgroup.
php.

<<attachment: winmail.dat>>