OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsbpel] Issue - 77 - (was RE: [wsbpel] Possible new issue: BPEL cannot handle some SOAP header bindings)


Ugo,

Here is my opinion:

Anything we do to allow WS operations to be associated with multiple
message types would be vastly more complex and burdensome for the future
than any conceivable benefit that might provide in completeness.  Very
few people are using headers as creatively as the WSDL spec allows
because there are few or no implementations that would support this in
their programming models.  My sense of where WSDL.Next is going relative
to message typing is precisely in the opposite direction of tightening
things up rather than liberalizing them further.

The net result of these considerations leads me to say that we should
stick with the abstract portType relationship we have with WSDL and
avoid getting entangled in bindings ..

Satish

 
-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
Sent: Wednesday, October 22, 2003 8:23 AM
To: Satish Thatte; Francisco Curbera
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 77 - (was RE: [wsbpel] Possible new issue:
BPEL cannot handle some SOAP header bindings)

Satish,

What I have been discussing here is not whether SOAP 1.1 and WSDL 1.1
are well defined and consistent specs (I have been working for many
months in the WS-I Basic Profile WG, so you don't need to convince me
that those specs have shortcomings ;-).

The questions I am asking are rather the following:

- Could a Web service developer describe SOAP headers using a different
message than the body?
My answer is definitely yes. As I have shown, there is nothing in those
specs that would prevent somebody to do that, or even indicate that it
would be bad practice. (Putting the blame on WS coders is ungrounded,
besides being unproductive).

- Does BPEL want to deal with legacy Web services that do not fit in the
current BPEL mold?
We can certainly say no, but let's be sure that it will put off a number
of potential users.

- Is there a simple way to deal with the problem?
We have not discussed this so far. How about allowing multiple variables
to be associated with BPEL operations instead of only one?

Ugo

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Tuesday, October 21, 2003 11:46 PM
> To: Ugo Corda; Francisco Curbera
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Possible new issue: BPEL cannot handle some SOAP
> header bindings
> 
> 
> Ugo,
> 
> You are correct that the original intent of (at least one of :-)) the
> SOAP authors was to treat headers and body on par, as the sentence you
> cite reflects.  However, the WSDL feature of allowing headers to be
> taken from other message types directly contradicts that 
> intent.  So we
> have that legacy of multiple mutually inconsistent intents.  You will
> notice that there are no common authors between SOAP 1.1 and WSDL 1.1
> :-)
> 
> Satish
> 
>  
> 
> -----Original Message-----
> From: Ugo Corda [mailto:UCorda@SeeBeyond.com] 
> Sent: Tuesday, October 21, 2003 3:01 PM
> To: Francisco Curbera
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Possible new issue: BPEL cannot handle some SOAP
> header bindings
> 
> Paco, you say:
> 
> > the WSDL service was badly designed (because business and quality of
> > service data were not appropriately factored)
> 
> Please find me a quote from WSDL 1.1 or SOAP 1.1 that says 
> that business
> information only goes in the body and QoS information only goes in the
> headers. I cannot find any.
> 
> SOAP 1.1, sec. 4.3.1, goes as far as saying: "A body entry is
> semantically equivalent to a header entry intended for the 
> default actor
> and with a SOAP mustUnderstand attribute with a value of '1'."
> 
> Ugo
> 
> > -----Original Message-----
> > From: Francisco Curbera [mailto:curbera@us.ibm.com]
> > Sent: Tuesday, October 21, 2003 2:18 PM
> > To: Ugo Corda
> > Cc: wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] Possible new issue: BPEL cannot 
> handle some SOAP
> > header bindings
> > 
> > 
> > 
> > 
> > 
> > 
> > Hi Ugo,
> > 
> > I think the assumption in your example can then be stated as 
> > saying that
> > the WSDL service was badly designed (because business and quality of
> > service data were not appropriately factored) but that it 
> > would be *really*
> > nice if BPEL could deal with it anyhow.
> > 
> > I think that the requirement to support legacy does not 
> > require being able
> > to seamlessly "patch over" any possible design however bad 
> it is. The
> > wrapper service that Rajesh suggests seems like a 
> reasonable approach.
> > 
> > Paco
> > 
> > 
> > 
> >                                                               
> >                                                                     
> >                       "Ugo Corda"                             
> >                                                                     
> >                       <UCorda@SeeBeyond        To:       
> > "Satish Thatte" <satisht@microsoft.com>, "Frank Leymann"      
> >            
> >                       .com>                     
> > <LEY1@de.ibm.com>, <wsbpel@lists.oasis-open.org>              
> >                     
> >                                                cc:            
> >                                                                     
> >                       10/21/2003 03:57         Subject:  RE: 
> > [wsbpel] Possible new issue: BPEL cannot handle some SOAP 
> header     
> >                       PM                        bindings      
> >                                                                     
> >                                                               
> >                                                                     
> > 
> > 
> > 
> > 
> > Satish, you say:
> > 
> > > presumably
> > > with the assumption that the parts from other message types
> > > used in headers affect only QoS not app-visible data.
> > 
> > That's an assumption that might sound good to you and me, but 
> > here we are
> > dealing with third parties that might have made all kind of 
> different
> > assumptions in the way they use headers (assumptions that, 
> > from the WSDL
> > 1.1 point of view - and probably from the SOAP 1.1 point of 
> > view too - are
> > perfectly legitimate). There lies the legacy problem with 
> this issue.
> > 
> > Ugo
> > 
> > > -----Original Message-----
> > > From: Satish Thatte [mailto:satisht@microsoft.com]
> > > Sent: Tuesday, October 21, 2003 12:40 PM
> > > To: Ugo Corda; Frank Leymann; wsbpel@lists.oasis-open.org
> > > Subject: RE: [wsbpel] Possible new issue: BPEL cannot 
> > handle some SOAP
> > > header bindings
> > >
> > >
> > > Ugo,
> > >
> > > I think the WSDL 1.2/2.0 model for dealing with headers is
> > > what we should look at for future guidance.  For WSDL 1.1 we
> > > don't apply any restrictions, just the principal that BPEL
> > > processes are binding agnostic.  Unfortunately, WSDL 1.1
> > > allows changes to the data model in binding, but presumably
> > > with the assumption that the parts from other message types
> > > used in headers affect only QoS not app-visible data.
> > >
> > > Satish
> > >
> > > ________________________________
> > >
> > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> > > Sent: Tue 10/21/2003 12:22 PM
> > > To: Satish Thatte; Frank Leymann; wsbpel@lists.oasis-open.org
> > > Subject: RE: [wsbpel] Possible new issue: BPEL cannot handle
> > > some SOAP header bindings
> > >
> > >
> > >
> > > So what you are saying is that BPEL imposes additional
> > > restrictions to the way information can be legally defined in
> > > a WSDL 1.1 file. This is a pretty serious statement because
> > > it affects BPEL compatibility with "legacy" Web services. Is
> > > this the only place in the BPEL spec where we specify such
> > > restrictions?
> > >
> > > It's also interesting to look at this issue from the point of
> > > view of WSDL 1.2, i.e. the elimination of the message
> > > construct. In the example I gave before, it just happens that
> > > the header is defined in terms of a part that is in an
> > > abstract message different than the one that defines the
> > > body. If the concept of message is removed, then we just have
> > > a bunch of abstract parts, one of which happens to end up in
> > > a SOAP header.
> > >
> > > Ugo
> > >
> > > > -----Original Message-----
> > > > From: Satish Thatte [mailto:satisht@microsoft.com]
> > > > Sent: Tuesday, October 21, 2003 11:54 AM
> > > > To: Frank Leymann; wsbpel@lists.oasis-open.org
> > > > Subject: RE: [wsbpel] Possible new issue: BPEL cannot
> > > handle some SOAP
> > > > header bindings
> > > >
> > > >
> > > > We must assume that the design of a portType is done
> > > > properly, i.e., the "application level" data required to
> > > > process a message in a business process is part of the
> > > > definition of each message.  If this assumption is violated
> > > > there is not much we can do.
> > > >
> > > > ________________________________
> > > >
> > > > From: Frank Leymann [mailto:LEY1@de.ibm.com]
> > > > Sent: Tue 10/21/2003 1:04 AM
> > > > To: wsbpel@lists.oasis-open.org
> > > > Subject: Re: [wsbpel] Possible new issue: BPEL cannot handle
> > > > some SOAP header bindings
> > > >
> > > >
> > > >
> > > >
> > > > Ugo,  this is a deployment/binding issue that is not
> > > > addressed by BPEL at
> > > > all. You easily write down bindings that won't work with a
> > > > certain BPEL
> > > > process model...
> > > >
> > > > Regards,
> > > > Frank
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > To:    <wsbpel@lists.oasis-open.org>
> > > > cc:
> > > > Subject:    [wsbpel] Possible new issue: BPEL cannot handle
> > > some SOAP
> > > >        header bindings
> > > >
> > > >
> > > > Let's suppose we have the following WSDL file:
> > > >
> > > >
> > > > <message name="In">
> > > >     <part name="InPart" element="InElement"/>
> > > > </message>
> > > >
> > > >
> > > > <message name="Header">
> > > >     <part name="HeaderPart" element="HeaderElement"/>
> > > > </message>
> > > >
> > > >
> > > > <portType name="myPortType">
> > > >     <operation name="op1">
> > > >         <input message="In"/>
> > > >     </operation>
> > > > </portType>
> > > >
> > > >
> > > > <binding type="myPortType" ... >
> > > >     <soap:binding ..../>
> > > >     <operation name="op1">
> > > >         <input>
> > > >             <soap:body parts="InPart" ...>
> > > >             <soap:header message="Header" 
> part="HeaderPart" .../>
> > > >         </input>
> > > >     </operation>
> > > > </binding>
> > > >
> > > >
> > > > In this example, the abstract operation "op1" refers to
> > > > message "In", but
> > > > the binding brings in an additional second message,
> > > "Header", for the
> > > > concrete operation.
> > > >
> > > >
> > > > It seems that BPEL would not be able to process the "Header"
> > > > information in
> > > > any way. For instance, a "receive" operation would only be
> > > > able to specify
> > > > one inputVariable, which would be associated with the "In"
> > > > message and not
> > > > the "Header" message. In other words, the "Header" message
> > > would carry
> > > > information to the "receive" operation that BPEL would have
> > > > no access to.
> > > >
> > > >
> > > > If this is the case, new Web services defined with BPEL in
> > > mind could
> > > > easily modify this scenario by defining both body and header
> > > > as being part
> > > > of a single message, but legacy Web services might be out
> > > of reach for
> > > > BPEL.
> > > >
> > > >
> > > > Please confirm that the current status is as I described. If
> > > > it is, I will
> > > > formally raise a new issue.
> > > >
> > > >
> > > > Thank you,
> > > > Ugo
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > To unsubscribe from this mailing list (and be removed from
> > > > the roster of the OASIS TC), go to
> > > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> > > ave_workgroup.php.
> > >
> > >
> > >
> > >
> > > To unsubscribe from this mailing list (and be removed from
> > > the roster of the OASIS TC), go to
> > > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> > ave_workgroup.php.
> > 
> > 
> > 
> > 
> > To unsubscribe from this mailing list (and be removed from 
> > the roster of
> > the OASIS TC), go to
> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
> ave_workgroup.php
> .
> 
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
ave_workgr
oup.php.







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]