RE: [wsbpel] Possible new issue: BPEL cannot handle some SOAP header bindings

["Satish Thatte" <satisht@microsoft.com>]

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/leave_workgroup.php.