[RSD] Re: [ebxml-bp] WSDL / BPSS proposal

["David RR Webber" <david@drrw.info>]

Title: Message

DRRW@

 

Dale,

 

I kinda realized now that there's some effort here to attempt to

exactly replicate BPSS / ebMS via WSDL.

 

I think that is not possible today - maybe in a year from now

it might be possible.

 

We are going to have to spell out that a WSDL

interface can only deliver some minimum level of

service - and leave it at that for now.  Therefore people should

use it knowing what the limitations are - they will not get

fully featured ebMS here.

 

This may be OK for certain requirements that

people have -particularly against backend components into

their own infrastructure.  Example - I receive a StockAvailability

request via ebMS - now I check with my warehouse system(s)

via internal WSDL calls - bring those responses back - then

generate the outbound Response via ebMS again.  This is

a hybrid use of BPSS of course - but that is one point of

having a WSDL interface.   And if people want this and

agree it with their CPA - then that is their decision as

opposed to using ebMS.

 

When I concurred that the WSDL idea made sense - I made

mention of the use of defaults to bridge between BPSS and

WSDL.   I suggest we look at what JJ has in mind here - and

the cross-matrix of features in BPSS and some measure

of support possible in WSDL.  

 

Also - we should not spend days of time agonising over if

using some arcane feature of WSDL in some way - may

allow us to achieve this or that. 

 

Let's try and stick with what plain vanilla WSDL can

do - so our approach will work across a wide

deployment set - for our V2.0 release. 

 

Better to document the gaps - and let the WSDL folks

work on addressing those over time.  Once those fixes

are available - then we can upgrade our own WSDL.

 

Thanks, DW.

 

@DRRW

----- Original Message -----

From: Dale Moberg

To: Jean-Jacques Dubray ; ebxml-bp@lists.oasis-open.org

Sent: Monday, February 09, 2004 9:50 AM

Subject: RE: [ebxml-bp] WSDL / BPSS proposal

 

 

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@