Discussion|oasis.ebBP;
Topic|WSDL;
Point| Abstraction level for BT element,
WSDL lacks business transaction semantics, specializations of BT,
signals and faults ;
DM@
JJ states.
This proposal is based on WSDL 2.0.
We introduce in BPSS a new activity type called OperationActivity, that
performs like a BusinessTransactionActivity or a CollaborationActivity
An OperationActivity references an operation within a WSDL
interface.
In WSDL 2.0, the MEP
character (one-way, request-response and others) is found in a pattern
attribute. I think this MEP feature of WSDL is really below the
abstraction level
of BPSS. A BPSS BT
actually can go over several kinds of MEP, and can use several approaches to
messaging/services. For example, a bpss:BT with its requesting and
responding activity can in fact go over a wsdl:requestresponse or two
wsdl:one-ways. The same business semantics can be variously implemented.
If there is some defined
business semantic for WS, say a standard business contractual situation, then I
agree we can introduce a WS content model for a specialization of BT and its
referencing context (a specialization of BTA, called OperationActivity in JJ
proposal without violating our abstraction level. I am dubious about the
existence of a standard WS contractual situation. I doon't think there is any
tie to the business level for WS.
Also, I think the
selection of a specific WSDL bindingshould really occur within the CPA as
an implementation agreement.
What is not in the CPA at
present is an indication of the Document(s) (soap:envelope/soap:body contents)
thatare conveyed in the WSDL "message". The division of labor had
been to put that sort of information in the bpss:Document element. The
wsdl:type definition, referenced by the operation usually, is the perfect
candidate for that information.
I think that there is
something distinctive about the SOAP/WSDL situation. WSDL defines MEP patterns
with faults. The closest analog of these are (negative) signals.
Martin Roberts is
developing an approach to BT that regards BT as the base class, with several
specializations. Some specializations include information about signals.
I believe that the wsdl
definedfault information belongs there. If so, there would be a case for having
a WSDL specialization of BT, and possibly the OA you suggest. Whether we
reuse the current UN based categories of BTs or add to them, I think there
could be a way to regard WSDL as just another flavor of BT, differing mainly on
signals vs. faults
At least there will need
to be harmonizing between Martin's BT specialization enhancement and JJ's wsdl
enhancement. I also really think we must not omit the wsdl:type element. In
many ways, wsdl is just a complicated container for chunks of xml schema, where
schema chunks are associated with SOAP messages. I do not think we should lose
track of what is really going on in it because of WS-hoopla.
DM@