[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 77 - (was RE: [wsbpel] Possible new issue: BPEL cannot handle some SOAP header bindings)
Regardless of WSDL and SOAP, it says in the current bpel text, in the third paragraph of clause 10 on correlation: The [business] token [used for correlation] can be in the message envelope in a header or in the business document (purchase order) itself which has always struck me as very wise, allowing maximal flexibility, not demanding a new special identity in bpel-handled messages, but being able to make use of one if it is there. So, if the pre-defined messages of some exchange all already contain, say, the social security number of the customer, a timestamp and an initiating location you can use those; but if for other reasons than bpel requirements, the exchange is defined as a conversation in some protocol that carries an unambiguous identifier in a ws-conversation header, then bpel can use that. More generally, it would seem very plausible that there are semantics to be communicated that are both sufficiently general to be factored out as headers, and have an impact on the required processing at business level - this is just a question for correlation sets. We (choreology) have already suggested this in the business transaction submission, but one could imagine it applying to security tokens (if previously checked, no need to recheck), expiry times. And, digging further down the stack, could one have a single process definition that was dynamically bound to but whose behaviour depended on where the other party was (intranet or extranet domain name ? - oh, I guess you could get that from the partnerLink information) Or (re-reading 10.1) is it the expectation that, if the "transport" provides instance-identifying information, then it never appears in the bpel. That would make sense for correlation purposes, but not more generally, and it in fact breaks the layering over abstract wsdl, then wsdl binding. If in one binding the information can be mapped into the "transport header" but in another it has to be carried by the transport as data, then either you must make it visible in bpel or define an extra levelling-up glue protocol to enhance the deficient transport. Peter > -----Original Message----- > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > Sent: 21 October 2003 23:01 > 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_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]