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 binding should 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) that are 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 defined fault 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@