ebxml-cppa message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [ebxml-cppa] BPSS to WSDL mapping
- From: Dale Moberg <dmoberg@cyclonecommerce.com>
- To: Cory Casanave <cory-c@enterprise-component.com>,OASIS ebxml-cppa <ebxml-cppa@lists.oasis-open.org>, ebtwg-bps@lists.ebtwg.org
- Date: Mon, 11 Mar 2002 15:19:52 -0700
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
(305) 234 7077
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC