RE: [ebxml-cppa] BPSS to WSDL mapping

[Cory Casanave <cory-c@enterprise-component.com>]

Dale,
Of course these should be the same - but the concerns are somewhat
different.  I would like to support BPSS on a non-MHS binding, WSDL will
support the bindings to a many service implementations.  That WSDL may also
be used in the ebXML-MHS binding makes sense for the same reasons.

Consider all that is going on in the "extended WSDL" space. The semantics
defined in BPSS are very much like these (and in some cases better).  By
positioning BPSS in the WSDL extension space we can avoid duplication of
specification forms and messaging APIs.  But, doing this requires the
binding to WSDL to be explicit and independent of the other parts of ebXML.
I think it is GREAT that there exists the non-mapped support for BPSS in MHS
- this is a feature, but we should also embrace the other technologies.

IMHO BPSS is easier to understand and more powerful than the XLANG/WSFL
kinds of things, but is getting ignored because it has not been seen as a
part of web services.  ebXML should be positioned as the next generation of
web services, not a competitor to it.  

.. See below..
Cory

> -----Original Message-----
> From:	Dale Moberg [SMTP:dmoberg@cyclonecommerce.com]
> Sent:	Monday, March 11, 2002 5:20 PM
> To:	Cory Casanave; OASIS ebxml-cppa; ebtwg-bps@lists.ebtwg.org
> Subject:	RE: [ebxml-cppa] BPSS to WSDL mapping
> 
>  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.
> 
[CBC]  As to (1), I have two opposite comments : )
1.a) In a mapping such as this it is not required that all aspects of the
target technology (WSDL) be used by the source representation (BPSS).  That
BPSS is async document exchange centric is fine, and probably the best use
of WSDL to promote for B2B.  This also applies to the parts of WSDL that the
BPSS would not populate, such as service URIs, which should be provided by a
particular address (like a CPP) not in a specification of the service
contract.

It is also not required that the target technology capture all  of the
"source" semantics, the source is still part of the specification of the
service - just like a decompiler is not required to produce the exact
source.

	1.b) In the OMG-Component Collaboration Architecture (Part of
EDOC)[http://www.omg.org/techprocess/meetings/schedule/UML_Profile_for_EDOC_
RFP.html] - which is aligned with BPSS we have additional constructs to
support RPC like bindings (Like OMG Corba IDL) , the same structures would
not be hard to add to BPSS and this would be a good feature.
>  
> 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)
> 
	[CBC]  This is just a sync business transaction and could be
specified with one attribute.
>  
> 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) 
> 
	[CBC]  Yes, but to support a BPSS 2-way conversation will require a
pair of WSDL port types.
>  
> 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.
> 
	[CBC]  Yes - it is the "machine language" of web services, a good
role.
>  
> 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. 
> 
	[CBC] Yes - for a fully executable WSDL specification.  Perhaps we
should just produce the port types from BPSS and then show how this can be
used or augmented for a particular service (the part that would come from
the CPP).  WSDL implies an equivalence between a CPPA and CPP (if you call
this service you have agreed to the terms of this service).
>  
>  
> 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 <http://www.enterprise-component.com/>
> (305) 234 7077
>