W3C home > Mailing lists > Public > public-ws-chor@w3.org > December 2004

RE: [wsbpel] [uddi-spec] WS-BPEL TN scope OK - but how about working with us on a B2B collaboration TN?

From: Chiusano Joseph <chiusano_joseph@bah.com>
Date: Thu, 9 Dec 2004 07:47:54 -0500
Message-ID: <74B14CBC0FEB9D4EB16969F09FA51F450B0E0B@MCLNEXVS08.resource.ds.bah.com>
To: "steve capell" <steve.capell@redwahoo.com>, "Steve Ross-Talbot" <steve@enigmatec.net>
Cc: "Von Riegen, Claus" <claus.von.riegen@sap.com>, <uddi-spec@lists.oasis-open.org>, "James Bryce Clark" <jamie.clark@oasis-open.org>, "Mary McRae" <mary.mcrae@oasis-open.org>, "Trickovic, Ivana" <ivana.trickovic@sap.com>, "WS-Choreography List" <public-ws-chor@w3.org>, "John Evdemon" <jevdemon@microsoft.com>, "Diane Jordan" <drj@us.ibm.com>, "Tony Rogers" <Tony.Rogers@ca.com>, "Luc Clement" <luc.clement@systinet.com>, "wsbpeltc tc" <wsbpel@lists.oasis-open.org>, <amarten@us.ibm.com>

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of steve capell
> Sent: Wednesday, December 08, 2004 6:25 PM
> To: 'Steve Ross-Talbot'
> Cc: 'Von Riegen, Claus'; uddi-spec@lists.oasis-open.org; 
> 'James Bryce Clark'; 'Mary McRae'; 'Trickovic, Ivana'; 
> 'WS-Choreography List'; 'John Evdemon'; 'Diane Jordan'; 'Tony 
> Rogers'; 'Luc Clement'; 'wsbpeltc tc'; amarten@us.ibm.com
> Subject: RE: [wsbpel] [uddi-spec] WS-BPEL TN scope OK - but 
> how about working with us on a B2B collaboration TN?
> 
> 
> Steve,
> 
> Thank you for your comments re WS-CDL.   We see UN/CEFACT UMM as the
> technology neutral reference model that will be the source of 
> collaboration semantics.  BPSS is just one "deployment 
> technology" for a UMM model (albeit one the fits very well!). 
>  However we also recognise that the WS-** collection of 
> specifications will continue to gain traction and so we are
> very keen to support a WS-** deployment for a UMM model.   To 
> that end I
> would be happy to work on a mapping from UMM to WS-CDL - and 
> from there to registry meta-data (but the model to 
> specification mapping has to come first because that's where 
> the semantics are defined..).
> 
> This is where the different between ebXML specifications and 
> WS-** specifications becomes more obvious:  ebXML was a 
> top-down approach from the beginning and so all the 
> specifications map fairly naturally to the reference model.  
> WS-** is more of a bottom-up collection of protocols and, so 
> far as I can see, nobody has yet done a great job of defining 
> some rules about the assembly of a set of WS-** protocols to 
> meet the business requirements of collaboration or 
> transaction models.  It is fairly easy to go from a UMM and 
> CCTS model to BPSS, template CPA, and XSD that (taken
> together) completely define multiparty collaborations 
> including detailed technology bindings -which are then 
> deployable on ebXML MS.  To do the same thing in the WS-** 
> world requires the assembly of lots more specifications - 
> many of which are still in the IBM/MSFT proprietary 
> specification domain.

Actually, some of these have moved into/through the open standards space, and some have "equivalents" (or competitors, please note that I am using very loose terminology here just to convey general meaning) that are already in an open standards track - please see comments below.

> As a minimum it seems to me that I would need to assemble:

> Runtime:
> 	SOAP (with attachments)
> 	WS-Security

Now OASIS Web Services Security

> 	WS-Reliable Messaging

OASIS WS-Reliability just ratified

> 	WS-Addressing

Now a W3C Member submission

> 	WS-Coordintation
> 	WS-Atomic Transaction

Both have an "equivalent" in OASIS WS-CAF

> Meta-Data
> 	WSDL
> 	WS-BPEL (assy or port types to define one role)
> 	WS-CDL (multi-party collaboration)
> 	WS-Policy
> 	WS-Policy Assertions

If we're speaking about only WS-* specifications that are not in an open standards consortium, the list of what one would consider metadata specifications is larger than that.

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World
 
> Maybe WS-CDL can replace WS-Coordintation and WS-Atomic 
> Transaction via a set of transaction patters?  I just don't 
> know enough about WS-CDL yet. :-(
> 
> Anyway, what seems to be missing is a set of "standard" 
> mappings to these protocols from common business models.  For 
> example, how would I deploy the
> 6 UMM transaction patterns using this set of WS-** protocols 
> and what are the semantics of the WS-Policy Assertions (or 
> whatever..) that would define that assembly?
> 
> Do you know of any work in this area?  If not then is the 
> WS-CDL group interested to work on the definition of some 
> naming & design rules and mapping rules that would permit a 
> WS-CDL instance to be consistently generated from a UMM 
> collaboration model?
> 	
> Don't get me wrong, I'm not an ebXML bigot, I just find it 
> much easier to deploy a B2B architecture on ebXML because the 
> rules are mostly already there.  I do believe that WS-** will 
> eventually dominate the technical protocol space but I see no 
> conflict between the UN/CEFACT eBusiness Architecture and the 
> WS-** protocols - just that nobody has done the mapping work yet.  
> 
> Regards,
> 
> Steve
> 	
> 
> -----Original Message-----
> From: Steve Ross-Talbot [mailto:steve@enigmatec.net]
> Sent: Thursday, 9 December 2004 8:15 AM
> To: steve capell
> Cc: 'Von Riegen, Claus'; <uddi-spec@lists.oasis-open.org>; 
> 'James Bryce Clark'; 'Mary McRae'; 'Trickovic, Ivana'; 
> WS-Choreography List; John Evdemon; Diane Jordan; 'Tony 
> Rogers'; 'Luc Clement'; wsbpeltc tc; <amarten@us.ibm.com>
> Subject: Re: [wsbpel] [uddi-spec] WS-BPEL TN scope OK - but 
> how about working with us on a B2B collaboration TN?
> 
> Dear Steve,
> 
> I would, as I have done at various times, suggest looking at WS-CDL.  
> WS-CDL is designed to model collaborative processes and has 
> been done so from it's inception. Today WS-CDL is nearing 
> last call in W3C and has been well received by many financial 
> service institutions who are looking to WS-CDl as a way of 
> encoding business protocols that are collaborative, 
> multi-party and peer-to-peer - the very things that WS-CDL is 
> designed to deal with. We have also benefited greatly from 
> the involvement of esteemed academics within the group such 
> as Prof Robin Milner, Dr Kohei Honda dn Dr Nobuko Yoshida who 
> are all leading exponents of behavioral typing systems that 
> underpin the WS-CDL.
> 
> The marriage of WS-CDL with UDDI as a means of ensuring 
> conformance (to a behavioral contract) is something that has 
> proven very attractive as an overall message to users. This 
> is one reason why I think it makes sense for you and others 
> to take a very close look at WS-CDL when it does go to last 
> call in the very near future. Your comments will be most welcome.
> 
> Best Regards
> 
> Steve Ross-Talbot
> Chair W3C Web Services
> co-Chair W3C Web Services Choreography
> 
> C: +44 7855 268 848
> H: +44 1273 491841
> www.enigmatec.net
> 
> private email: steverosstalbot@yahoo.co.uk
> 
> On 8 Dec 2004, at 21:00, steve capell wrote:
> 
> > Ivana,
> >
> >  
> >
> > Thank you for your response.  I am pleased to see that SAP has 
> > considered the use case B2B use case - and I do understand your 
> > concerns about the ability of abstract BPEL to model B2B 
> collaborative 
> > processes.  In that context I agree with the scope of your 
> BPEL TN and 
> > am happy to remove my objection.
> >
> >  
> >
> > However I would like to mention that we are actively 
> engaged with the  
> > Australian government in modelling B2B processes in order 
> to develop a  
> > national standard. The deployment framework does include 
> the use of a  
> > services registry (UDDI or ebXML).  Therefore our need 
> still remains  
> > and I would like to ask SAP and/or anyone else on the TC 
> whether they  
> > would be interested to work with us on a registry 
> meta-model for B2B  
> > collaborative processes (based on UN/CEFACT UMM).  At 
> present we have  
> > done some work on mapping UMM to BPSS and CPA and from 
> there to UDDI.   
> > The UDDI meta-model does include explicit enumeration of 
> multi-party  
> > collaborations, roles within those collaborations, binary 
> contracts,  
> > and bindings.  We would be willing to contribute this work 
> to form the  
> > basis of a TN on the subject and would be happy to work 
> with SAP on  
> > developing the material further.
> >
> >  
> >
> > Regards,
> >
> >  
> >
> > Steve
> >
> >  
> >
> >
> > From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com]
> >  Sent: Wednesday, 8 December 2004 2:33 AM
> > To: steve capell; Luc Clement; drj@us.ibm.com; 
> jevdemon@microsoft.com;  
> > Von Riegen, Claus; amarten@us.ibm.com
> > Cc: uddi-spec@lists.oasis-open.org; 
> wsbpel@lists.oasis-open.org; James  
> > Bryce Clark; Mary McRae; Tony Rogers
> > Subject: AW: [wsbpel] [uddi-spec] some comments on "Using 
> BPEL4WS in a  
> > UDDI registry" Technical Note
> >
> >  
> >
> > Steve,
> >
> >  
> >
> > The use case you mentioned below is interesting and it has been  
> > considered. It is not supported in the technical note 
> because modeling  
> > multi-party B2B processes (collaborative processes) using BPEL4WS  
> > abstract processes is limited to modeling the behavior of each of  
> > participants separately and only binary relationships 
> between them.  
> > This limitation must be addressed outside of the UDDI TC 
> and work on  
> > this technical note. From our point of view, the primary 
> purpose of  
> > BPEL4WS abstract processes is to extend the WSDL service 
> definition  
> > with the behavioral aspects - to specify observable 
> behavior of Web  
> > services.
> >
> >   
> >
> > As you also pointed out, the concept of role and 
> relationships between  
> > roles within a scenario are critical features for modeling  
> > collaborative processes. BPEL4WS provides only a limited view on  
> > collaborative processes specifying all binary relationships 
> between  
> > involved parties. Roles defined within bpel partner link types are  
> > fine granular roles. A role within a collaborative process 
> might be  
> > refined into 2 or more bpel roles. Another point is that it is  
> > unlikely that roles will be globally unique. A role has 
> meaning only  
> > within a context (= scenario/collaborative process), so 
> that context  
> > needs to be published in UDDI as well. There is a need for 
> explicit  
> > notion of collaborative processes - it is a container for 
> all roles  
> > involved in a conversation.
> >
> >   
> >
> > These are the reasons why we decided to restrict the scope of the  
> > first version of the technical note. The use case it covers 
> is clear  
> > and we believe the proposal can be easily extended as soon as open  
> > questions mentioned above are addresses. We do not think that the  
> > questions will be addresses by the WS-BPEL TC 
> (collaborative processes  
> > are not part of the TC Charter).
> >
> >   
> >
> > Regarding your doubt: The reason why we included all port types is  
> > that operations partners must implement describe messages partners  
> > must be able to consume (and produce, in case of request-response  
> > operations) but do not prescribe any specific behavior 
> (e.g. whether  
> > messages are received in sequence or not). They only describe  
> > requirements for the service consumer(s) (in the same sense 
> in which  
> > the abstract process of the service provider does).
> >
> >  
> >
> > Kind regards,
> >
> >  
> >
> > Ivana 
> >
> >  -----Ursprüngliche Nachricht-----
> > Von: steve capell [mailto:steve.capell@redwahoo.com]
> > Gesendet: Mittwoch, 1. Dezember 2004 12:59
> > An: 'Luc Clement'; drj@us.ibm.com; jevdemon@microsoft.com
> > Cc: uddi-spec@lists.oasis-open.org; wsbpel@lists.oasis-open.org;  
> > 'James Bryce Clark'; 'Mary McRae'; 'Tony Rogers'
> > Betreff: [wsbpel] [uddi-spec] some comments on "Using BPEL4WS in a  
> > UDDI registry" Technical Note
> >
> > Hello all,
> >
> >  
> >
> > I think the BPEL technical note is pretty good but it seems 
> to me that  
> > there is a potentially very useful little bit of meta-data missing:
> >
> >  
> >
> > An Abstract BPEL is supposed to model a multi-party long running  
> > process.  The series of interactions in the process are 
> broken down  
> > into bilateral conversations modelled by the partnerlink 
> Type element  
> > that defines the two roles (and the port types they implement)  
> > involved in the conversation.  
> >
> >   
> >
> > It seems to me that a common application of abstract BPEL 
> will be to  
> > model B2B processes and the choreography of interactions within a  
> > two-party conversation.  For two parties to engage in such a  
> > conversation they must play COMPLEMENTARY roles in the 
> conversation.   
> > Accordingly a common query that might be made by a business entity  
> > that plays the role "seller" in the "eancom procurement 
> process" bpel  
> > could be "show me all business Entities in my geography 
> that provide a  
> > business service that supports the role seller in the eancom  
> > procurement process".  In short the seller is trying to 
> find customers  
> > that have a compatible (ie complementary) interface.
> >
> >  
> >
> > Now the problem is that the TN (so far as I can see) only 
> results in  
> > publication of one tModel for the process.  The TN says 
> that "all port  
> > types used in the process" are listed in the process tModel 
> using the  
> > wsdl portTypeReference tModel.  If a particular bpel 
> references (say)  
> > 4 port types in various namespaces, there is no way to 
> support this  
> > query because we don't know which of the four port types is 
> linked to  
> > which role and therefore which ones are complementary.  
> Would it not  
> > make sense to also have a tModel for each ROLE in the bpel 
> (defined by  
> > the partnerlink types) and a new tmodel keyed reference 
> that points to  
> > the "complementary role".  In this case the model would look more  
> > like:
> >
> >  
> >
> > Process tModel (with links to roles via a roleReference 
> category bag  
> > element)
> >
> > Role tModel (with links to the portTypes provided by the 
> Role via the  
> > wsdl portType reference AND a link to the complementary 
> Role with a  
> > new reference tModel)
> >
> > PortType tModel - as per TN2 standard.
> >
> >  
> >
> > Also - just a point of clarification here, when the TN says 
> that the  
> > process tModel references that "all port types used in the 
> process" -  
> > I assume this means ALL port types in the BPEL, whether in 
> an <invoke>  
> > element or a <receive> element?  Ie all port types whether 
> they are  
> > PROVIDED by the bpel or CONSUMED by the bpel?  If so then 
> my previous  
> > discussion make some sense.  If only the portTypes PROVIDED by the  
> > bpel are included then the whole discussion around 
> complementary roles  
> > is invalid and the eancom seller can't find his potential customers.
> >
> >  
> >
> > In our implementation of UDDI in Australia, we are taking a very  
> > process centric view of B2B collaborations and this whole story of  
> > roles and complementary roles is fundamental to the architecture.
> >
> >  
> >
> > Of course there is an entirely separate discussion about whether  
> > abstract BPEL is an appropriate standard to model 
> collaborative B2B  
> > processes in the first place (they are really 
> choreographies whilst  
> > bpel is an orchestration language).  That aside, I am sure that at  
> > some point bpel will be targeted at describing abstract 
> conversations  
> > and then this issue of how you represent them in uddi 
> becomes quite  
> > important.
> >
> >  
> >
> > Sorry this is so late in the day (but it is still before the 3rd  
> > December deadline!).
> >
> >  
> >
> > Regards
> >
> >  
> >
> >
> > From: Luc Clement [mailto:luc.clement@systinet.com]
> >  Sent: Saturday, 27 November 2004 12:47 AM
> > To: drj@us.ibm.com; jevdemon@microsoft.com
> > Cc: uddi-spec@lists.oasis-open.org; wsbpel@lists.oasis-open.org;  
> > 'James Bryce Clark'; 'Mary McRae'; 'Tony Rogers'
> > Subject: [uddi-spec] RE: [wsbpel] "Using BPEL4WS in a UDDI 
> registry"  
> > OASIS UDDI Spec TC Technical Note - Review Requested
> >
> >  
> >
> > Having provided sufficient time to review the "Using 
> BPEL4WS in a UDDI  
> > Registry" Technical Note it is the UDDI Spec TC's opinion this  
> > Technical Note is ready to be published. It is our intent 
> to publish  
> > this TN by the end of this calendar year. That said, should 
> you have  
> > additional feedback please provide it no later than 3 Dec 
> so it may be  
> > considered prior to the expected ratification of the TN by 
> this TC in  
> > mid-Dec.
> >
> >  We understand that there may be unresolved issues relating to the  
> > relevance of abstract processes as it relates to the WSBPEL  
> > specification. We would like to draw your attention to the 
> fact that  
> > the TN applies to the BPEL4WS 1.1 specification submitted to the  
> > WSBPEL TC and which defines the concept of abstract processes. The  
> > decision to map BPEL4WS 1.1 was deliberate - the TN aims at 
> addressing  
> > current market needs.
> >
> >  
> >
> > Luc Clément
> > Senior Program Manager, Systinet
> >  Co-Chair OASIS UDDI Spec TC
> >  Tel: +1.617.768.4268 / Cell: +1.978.793.2162 / www.systinet.com
> >
> >  
> >
> >
> > From: Luc Clement [mailto:luc.clement@systinet.com]
> >  Sent: Tuesday, August 03, 2004 20:59
> > To: drj@us.ibm.com; jevdemon@microsoft.com
> > Cc: uddi-spec@lists.oasis-open.org; 
> wsbpel@lists.oasis-open.org; Karl  
> > F. Best; James Bryce Clark; Mary McRae; Tony Rogers
> > Subject: [wsbpel] "Using BPEL4WS in a UDDI registry" OASIS 
> UDDI Spec  
> > TC Technical Note - Review Requested
> >
> > Dear WSBPEL Chairs,
> >
> > The UDDI Spec TC has been working on a "Using BPEL4WS in a UDDI  
> > registry" Technical Note (TN) that it would like your input 
> on before  
> > proceeding to ratify this TN.
> >
> > The TN provides a mapping for publishing BPEL4WS abstract 
> processes  
> > into a UDDI registry. The primary goals of mapping BPEL4WS 
> artifacts  
> > to the UDDI model are to:
> > 	1.  	Enable the automatic registration of BPEL4WS 
> definitions in
> UDDI
> > 	2.  	Enable optimized and flexible UDDI queries 
> based on specific
> 
> > BPEL4WS artifacts and metadata
> > 	3.  	Provide composability with the mapping described in
> the "Using  
> > WSDL in a UDDI Registry, Version 2.0.2" [1] Technical Note.
> >
> > We would like to invite the BPEL TC to review and comment on the  
> > document and ask that you assign two or more reviewers.
> >
> >  The TN is posted at the following locations by format:
> > 	* 	PDF:  
> > 
> http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/ 
> > 8442/uddi-spec-tc-tn-bpel-20040725.pdf
> > 	* 	MSWord:  
> > 
> http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/ 
> > 8441/uddi-spec-tc-tn-bpel-20040725.doc
> >
> > We would appreciate comments as soon as possible but 
> preferably before  
> > 31 Aug 04. Please submit comments:
> >
> > To: Claus von Riegen, SAP (claus.von.riegen@sap.com),
> >
> >  cc: (UDDI Chairs): luc.clement@systinet.com; tony.rogers@ca.com
> >
> > cc: uddi-spec@lists.oasis-open.org
> >
> > Thanks in advance
> >
> > Luc Clément                       
> >
> >  Co-Chair OASIS UDDI Spec TC
> >
> > Systinet Corporation
> >  Tel: +1.617.395.6798
> >
> >  
> >
> >  
> >
> > [1] OASIS UDDI Spec TC Technical Note: "Using WSDL in a 
> UDDI Registry,  
> > Version 2.0.2",  
> > http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm#WSDLTNV2
> >
> 
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
Received on Thursday, 9 December 2004 12:51:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:01:15 GMT