OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


The BPEL group has a vast vein of experience to mine in creating a
simplified local compensation framework as customers have been implementing
local compensation handlers on every Web Service product and platform since
the dawn of web services. 

In the case of distributed transactions the BPEL group can call upon no
industry experience with the standard Web Services distributed
transactioning protocols as such protocols do not yet exist.

Therefore the very factors that make local compensations so ripe for a
simplified framework are the same factors that make it inappropriate at this
time to create a simplified framework for distributed transactions. This is
why, IMHO, issues 53-39 should be closed out.

> -----Original Message-----
> From: Haugen Robert [mailto:Robert.Haugen@choreology.com]
> Sent: Monday, January 12, 2004 12:33 PM
> To: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 53 - Motion for consideration by the TC
> 
> 
> 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/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/le
> ave_workgroup.php.
> 
> 

<<attachment: winmail.dat>>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]