RE: [ebxml-cppa] BPSS to WSDL mapping

[Dale Moberg <dmoberg@cyclonecommerce.com>]

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Monday, March 11, 2002 5:48 PM
To: Dale Moberg
Cc: Cory Casanave; OASIS ebxml-cppa; ebtwg-bps@lists.ebtwg.org
Subject: Re: [ebxml-cppa] BPSS to WSDL mapping


Please see below.

Cheers,
Chris,

Dale Moberg> Some more comments in-line (with some editing):

Dale Moberg wrote:

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


Chris Ferris> As Marty pointed out, CPP is logically more suited to
leveraging
WSDL (1.1) as it represents one side of the coin so to speak whereas
CPA represents something currently not reflected in any of the
de facto web services specs.

Dale Moberg> I think I blurred over what document WSDL is like,
just typing "CPPA," but I agree with both Marty and Chris that
WSDL is more like CPP (or perhaps a CPA template). It announces
what is available, how to contact, what to input, and what
to expect back. The representation of options, preferences, 
proposed CPAs, negotiations are all absent, so interoperability
has to be attained by being capable of contacting the service
in the manner announced. 

Chris again> Seems to me though that when dealing with the "abstract"
port
definition aspect of WSDL, one could easily describe a process
from both perspectives. Specifically, the <schema>, <message>
descriptions could be leveraged directly by BPSS replacing the
need for <BusinessDocument> and partially for <DocumentEnvelope>
which adds document security properties as well as a few other
bits of info that could be expressed as extensions to WSDL.

Dale> Agree.


>  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


Chris> Not necessarily. If you leave out the service binding aspects
of WSDL, there's no reason why you can't describe, in the abstract
at least, the messages themselves and to an extent the portType
(although there will need to be some accomodations for message-based
systems where there may be more than one possible "response" to a given
"request".) 

Dale> And also "responses" that dribble back, with
MessageAcknowledgements
in one channel, signed PositiveAcknowledgment along a second, and the
business response drifting back later on yet a third.

> Cory>
> * 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.


Chris> See above.

> 
> 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)


Chris> Not sure I would equate wsdl:fault with signal.

Dale> I can understand why it might be important to emphasize
the differences between the grab bag of signals (exceptions, NRR, 
ReceiptAcknowledgment, PositiveAcknowledgment)
and wsdl:faults. But an analogy is equivalent to an equation
only if you are a semiotician! So, my point was 
that wsdl:fault is the only thing _like_ signals
that I see in current WSDL.
Not worth squabbling about, however.

> 
Dale > 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)


Chris> basically I agree.
  
> 
Dale> 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.


Chris> right, it could therefore be easily leveraged to this end. It
needs
some work, and a few extensions but it is achievable IMO.


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


Chris> Agreed, I think that the binding could largely replace what is in
CPP/A now for the equivalent function. 

Dale> I think this would be a replacement for Packaging +
DeliveryChannel nodesets. Not sure
we could just drop Binding in right now and obtain equivalent
functionality. Certainly
a lot of the new security functionality involving matches of trust
anchors with certificates
is not going to be there. But worth investigating more.

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


Chris> Or it could simply be a set of abstract portType definitions for
both
sides which each party would map but a subset to a given service
binding.

Dale> Plus the document ( wsdl:Message plus wsdl:part ) stuff, right? 

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


Chris< That's certainly a possibility. I'd be happy to see this manner
of synergy between the ebXML and "web services" space. It shouldn't
be about ebxml vs web services, they are and they certainly should
be complementary. The only caution I would add is the issue of
IPR considerations.

[ Remark that Cory will assist someone.
Chris: me too!
]

Dale> Me too.