[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]