[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] BPSS to WSDL mapping
+1 I'll add further comment in a subsequent email Chris Martin W Sachs wrote: > I generally agree with Dale's comments except as follows: > > A WSDL description can be referenced from a CPP through an alternative > process specification reference. A CPA would have to reference two WSDL > descriptions (one for each party) as an alternative to a BPSS instance. > Someone or something would have to determine that the two WSDL descriptions > are compatible. As Dale points out in (3), at this point since there is no > notion in Web Services of service requester descriptions. Has the W3C WSDL > team considered this matter yet? > > Regarding (5) below, to be more precise, things in the WSDL binding > overlap CPP, not CPA. A WSDL description describes a service provider's > properties only. It is not an agreement at this point and says nothing > about a service requester. > > Regards, > Marty > > ************************************************************************************* > > Martin W. Sachs > IBM T. J. Watson Research Center > P. O. B. 704 > Yorktown Hts, NY 10598 > 914-784-7287; IBM tie line 863-7287 > Notes address: Martin W Sachs/Watson/IBM > Internet address: mwsachs @ us.ibm.com > ************************************************************************************* > > > > Dale Moberg > <dmoberg@cycloneco To: Cory Casanave <cory-c@enterprise-component.com>, OASIS ebxml-cppa > mmerce.com> <ebxml-cppa@lists.oasis-open.org>, ebtwg-bps@lists.ebtwg.org > cc: > 03/11/2002 05:19 Subject: RE: [ebxml-cppa] BPSS to WSDL mapping > PM > > > > > > Cory, some comments in line. > > Cory> In a web services seminary this week it became clear that the kinds > of capabilities offered by ebXML were directly applicable to enterprise > adoption of web services technologies and architectures. In a panel > session it was stated (by an IBM representative) that problems with ebXML > were that the adoption was "to fast" and it was "Not linked to WSDL". > Well, we can't go back and slow down the process, but we can fix the > latter. > > Dale Moberg>The CPPA TC is also investigating how references to WSDL > documents (or portions of WSDL documents) might be used by or within future > CPPA documents. Please copy our list on your discussions of this issue! One > possible way in which WSDL might be referenced within the CPPA was through > an alternative ProcessSpecification reference. Other parts of WSDL could be > used to populate (and extend) CPPA binding information. > > Cory> Perhaps in this upcoming release we could include a short section > that > would specify a mapping from BPSS to WSDL. > There are three basic issues with this mapping. > * BPSS specifies two way mappings where as WSDL is one-way > * BPSS allows for nested collaborations > * BPSS has choreography and other semantics. > > Dale> I am not certain that I understand the issues quite the same way: > > 1. WSDL contains both IDL- or API-centric and Document-centric views on > the exchange of information between businesses. > ebXML has so far done little with the IDL-centric viewpoint. I think > something would need to be added to the BusinessDocument (akin to > wsdl:Message and the Message's wsdl:part(s) ) to support > setting up this correspondence.) I think you would need to beef up BPSS or > at least allow > BusinessDocument extensions to allow wsdl:Message and the Message's > wsdl:part(s). These > elements do seem to belong with BPSS constructs, however. > > 2. For the Request-response wsdl:PortType, the wsdl:input parameters are > analogous to a Request, wsdl:output parameters are analogous to a Response, > and wsdl:fault is analogous to a Signal. The other three PortTypes may be > of interest to BPSS, even though WSDL focuses on 2 PortTypes) > > 3. So a WSDL definition of PortType has its explicit descriptive focus on > "one side" of the 'service'. The other side is largely implicit, and is > specified only so far as it must be able to supply wsdl:inputs and receive > wsdl:outputs (for the wsdl:PortType ofRequestResponse) > > 4. I agree that nesting and choreographies are absent from basic WSDL (as > contrasted > with XLang or WSFL ). WSDL appears to view itself as characterizing the > atoms of services/flows. > > 5. WSDL combines some elements that CPPA has and some that are found > within BPSS. I think wsdl:PortType is more a BPSS-like construct. Within > the Binding elements (and the 3 Binding extensions for SOAP, HTTP GET/PUT, > and MIME), there are some things that overlap CPPA. So to map everything in > a WSDL document at the moment, parts would need to go into a BPSS-like > document,and parts into a CPPA style document, IMO. > > > To create a representation of the WSDL subset of BPSS semantics would > not be that hard. It would require the production of WSDL for each "side" > of a binary collaboration. > The nested collaborations could be "flattened" into one WSDL interface or > we could use multiple > separate interfaces. The choreography and other more advanced BPSS > semantics would be lost > in the WSDL representation but still binding on the services which > implement them. > > This is not a hard task - it could be done in a day or two. I suggest > that for greater acceptance in the industry we consider adding an XSLT > transform to produce the required WSDL and make this part of the next > revision - very soon. > This would help bind ebXML into the web services core technologies. > While we (DAT) don't have to bandwidth to do this in the sort time > required, > we would be happy to assist someone in such a task. > > Regards, > > Cory B. Casanave, President > Data Access Technologies > www.enterprise-component.com > (305) 234 7077 > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC