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

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Depending on by whom or when the portType was designed.

Wouldn't handling the legacy case that Ugo mentions (several quotations
levels down, below) require that a second WSDL definition for the same
service be defined to provide the visibility needed by BPEL, sort of
repartitioning the abstract:binding aspects. Which would imply some sort
of equivalence between the two WSDL descriptions. I suspect defining
guidelines for this equivalence might be useful, but strict rules more
or less impossible

Peter

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com] 
> Sent: 21 October 2003 19:54
> 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_workgr
oup.php.