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:]
> Sent: 21 October 2003 19:54
> To: Frank Leymann;
> 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:]
> Sent: Tue 10/21/2003 1:04 AM
> To:
> 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: <>
> 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.
