[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to values not defined in portType
Satish, Please let me know what you think of my message following the one below, where I reformulate the issue and show that the problem is there even if we only talk purely in terms of abstract interfaces. Ugo > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: Sunday, November 02, 2003 1:41 PM > To: Ugo Corda; Ron Ten-Hove > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to > values not defined in portType > > > Ugo, > > I completely agree that very many real BPEL implementations > communicate using SOAP, and they will probably use MIME and > other packaging formats for some time as well. I am > questioning the wisdom of going beyond interface > specifications to address all the possibilities. As Yaron > pointed out many things in a message, headers, attachments, > etc may be optional stuff, and addressing the complexity of > figuring out meaningful access and usage modes for optional > and binding level data at the level of abstraction BPEL > targets does not seem like a good idea, especially for the > initial version of this standard. > > Satish > > ________________________________ > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > Sent: Sun 11/2/2003 10:33 AM > To: Satish Thatte; Ron Ten-Hove > Cc: wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require > access to values not defined in portType > > > > Satish, > > Please let's be realistic here. Real BPEL implementations > deal with SOAP and SOAP headers. Whether we like it or not, > real BPEL implementations are able to process some SOAP > headers and not others. Ignoring the problem does not make it > go away, and it's like trying to hide behind a finger. I > believe the spec should say something about this, one way or another. > > Ugo > > > -----Original Message----- > > From: Satish Thatte [mailto:satisht@microsoft.com] > > Sent: Saturday, November 01, 2003 11:24 PM > > To: Ugo Corda; Ron Ten-Hove > > Cc: wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require access to > > values not defined in portType > > > > > > Ugo and Ron, > > > > Where in BPEL do we even talk about SOAP, headers, body, > > etc.? We only talk about abstract message types. And if we > > are using WSDL 1.1 they may have multiple parts with > > independent XML (or I suppose other) types. In WSDL 2.0 they > > may be pure XML types. We know nothing about how they are > > rendered in any wire format. > > > > My basic position is that we stick to message types as > > presented in the web service interfaces a BPEL process > > imports or exports. Anything else opens a Pandora's box of > > binding variability and complexity that we should not be > dealing with. > > > > Satish > > > > ________________________________ > > > > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > > Sent: Sat 11/1/2003 11:24 AM > > To: Ron Ten-Hove > > Cc: wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] RE: Issue - 77 - Motion to require > > access to values not defined in portType > > > > > > Ron, > > > > Good point. (The WSDL 1.1 example you are referring to is > > Example 3 in sec. 3.1). > > > > This, by the way, shows that the position that BPEL should > > only deal with bodies is not even realized in the current > > BPEL spec. In fact, all headers defined in a way similar to > > the example mentioned above are perfectly accessible by BPEL. > > It's only headers that are defined in a separate message that > > are not accessible by BPEL - which is the original scope of > > this Issue. > > > > The only way to reconcile this inconsistency between headers > > that BPEL can process and those that it cannot process would > > be to say that headers specified in the same abstract message > > as the body are "application" headers (which BPEL can see), > > and those specified in a separate abstract message are QoS > > headers (which BPEL cannot see). But I would challenge > > anybody to find a single WS spec where such distinction is > > clearly specified ... > > > > Ugo > > > > -----Original Message----- > > From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM] > > Sent: Saturday, November 01, 2003 10:41 AM > > To: Ugo Corda > > Cc: wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] RE: Issue - 77 - Motion to > > require access to values not defined in portType > > > > > > Ugo, > > > > See BP 1.0 R2712; this applies only to doc-literal > > encodings, but I believe that will be the most common case in > > the SOAP-flavoured version of the BPEL universe. This > > restricts us to one message part in the body; other parts > > must be carried as headers. This is a fairly common practice > > anyway; the message body, when extracted from the S:Envelope > > and S:Body wrappers, constitutes a proper XML document (sans > > the <?xml?> header or doc-type declarations), rather than a > > fragment. IIRC, the WSDL 1.1 spec even includes an example of > > how to do this. > > > > Cheers, > > -Ron > > > > (Sorry about the delayed reply; I was working from home > > yesterday, and lost power for 12 hours. First rule of network > > computing: failures happen; expect them!) > > > > Ugo Corda wrote: > > > > > > Ron, > > > > Could you please clarify your point below about > > BP 1.0 conformance? As far as I know, BP 1.0 is neutral in > this area. > > > > Ugo > > > > -----Original Message----- > > From: Ron Ten-Hove > > [mailto:Ronald.Ten-Hove@Sun.COM] > > Sent: Friday, October 31, 2003 10:36 AM > > To: Frank Leymann > > Cc: wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] RE: Issue - 77 - > > Motion to require access to values not defined in portType > > > > > > Frank, > > > > Your points about the user of SOAP > > headers are well taken. Just a few comments in response: > > > > > > * The use of composability via > > SOAP header blocks is applicable at several levels in the > > "stack." It is conceivable that business process-level > > protocols may be supported by such mechanisms (some forms of > > transactions are sneaking up on this). Could this eventually > > require BPEL "awareness" of header blocks in support of > > higher-level protocols? > > > > * Also, a message doesn't > > necessarily have a single payload. This is commonly "worked > > around" in SOAP/WSDL by placing the extra payloads into > > header blocks, especially if conformance to BP 1.0 is desired. > > * While we, as a technically > > sophisticated group would not abuse SOAP/WSDL in unnatural > > ways, there are plenty of people devising web services today > > that have no such sensibilities. Are we, the BPEL TC, to > > stick to the "high road" and refuse to treat with such > > abominations, or take the "low road" and get a bit dirty in > > process (no pun intended). Will this substantially affect > > adoption of BPEL? > > > > > > Regards, > > -Ron > > > > Frank Leymann wrote: > > > > > > Yaron (or do you prefer > > "Yoland" in the meantime? ;-)), > > > > the scope of the problem you > > describe is generic, not coupled to BPEL at > > all. Thus, the BPEL TC > > shouldn't attempt at all to solve that problem. This > > includes defining new > > mechanisms to declare optional headers, teach people > > how to specify appropriate WSDL etc.. > > > > The fundamental importance of > > SOAP headers is to provide for composability > > of Web service mechanisms at > > the message level. So, headers are about > > folding in "QoS" aspects like > > security, reliability, addressability, > > transactionality etc etc. It > > is the SOAP body that is intended to carry > > the "real" application payload. > > I personally don't think that application > > programmers should take care > > about headers (i.e. QoS-like stuff), but take > > care only of the body. The > > "environment" should take care about headers, > > i.e. QoS-like stuff. > > > > Regards, > > Frank > > > > ------------------- > > Prof. Dr. Frank Leymann, > > Distinguished Engineer > > IBM Software Group > > Member, IBM Academy of Technology > > > > Phone 1: +49-7031-16 39 98 > > Phone 2: +49-7056-96 50 67 > > Mobile: +49-172-731 5858 > > -------------------- > > > > > > > > > > > > Please respond to > > <ygoland@bea.com> <mailto:ygoland@bea.com> > > > > To: Frank > > Leymann/Germany/IBM@IBMDE, <wsbpel@lists.oasis-open.org> > > <mailto:wsbpel@lists.oasis-open.org> > > cc: > > Subject: RE: [wsbpel] RE: > > Issue - 77 - Motion to require access to > > values not defined in portType > > > > > > I'm unsure how one > > differentiates between middleware payload and endpoint > > payload. For example, there are > > many good reasons why an endpoint would > > want > > to be able to access a SOAP > > header containing digital signature or > > correlation information. So I > > don't think we can ever say that it's o.k. > > not > > to be able to get to the SOAP headers. > > > > It has been suggested that > > perhaps we could tell people to write enhanced > > WSDL definitions that contain > > headers that are present at the SOAP level > > but > > weren't defined in the original WSDL. > > > > Unfortunately this isn't a > > workable solution in a case where the SOAP > > header > > is itself optional. For > > example, one could have an operation that MAY be > > digital signed which means that > > in some cases you will have a digital > > signature header and in other > > cases you wouldn't. WSDL 1.1 is incapable of > > expressing the concept of > > 'optional' headers. > > > > I think the easiest way to get > > around this problem would be for the group > > to > > introduce a new attribute for > > use with WSDL that would specify when a > > message part is optional both > > for incoming and outgoing messages. The > > normative behavior would then > > become that you would have to take the > > original WSDL, which doesn't > > mention the optional headers, mark it up to > > include those headers (i.e. the > > previously suggested 'enhanced' WSDL) and > > then mark those headers as optional. > > > > If a message is received > > without the optional part then that part would be > > left as uninitialized in the > > message variable and accessing that part of > > the > > message variable would throw a > > fault. We would have to introduce a function > > to allow one to test if a part > > is uninitialized. > > > > If a message is sent whose > > definition contains an optional part then if the > > part is never assigned to, > > that's fine, it just means that the part won't > > appear in the outgoing message. > > > > The main downside I see to this > > proposal is that if someone sends you a > > message with content you just > > weren't expecting (For example, an > > intermediary throws in a SOAP > > header that is made up) then you can't get to > > it. But the only use case I can > > see for wanting access to that information > > is for logging purposes and I'm > > not sure that is a compelling enough use > > case to worry about this in V1. > > > > But I believe it is important > > that one be able to both send and receive > > optional message parts (e.g. > > optional SOAP headers) so some change to the > > BPEL standard seems called for. > > > > Just an opening thought, > > > > Yaron > > > > > > > > > > -----Original Message----- > > From: Frank Leymann > > [mailto:LEY1@de.ibm.com] > > Sent: Friday, October > > 24, 2003 6:47 AM > > To: > wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] > > RE: Issue - 77 - Motion to require access to > > values not defined in portType > > > > > > > > The WSDL 1.2/2.0 group > > is currently considering to remove headers from > > messages at all, and > > replacing this by appropriate applications of > > "policies". I read > > this as another indicator that application data is > > assumed to be part of > > the message body, and that headers should carry > > "middleware payload" > > (indicated by appropriate "policies"). > > > > Regards, > > Frank > > > > ------------------- > > Prof. Dr. Frank > > Leymann, Distinguished Engineer > > IBM Software Group > > Member, IBM Academy of > > Technology > > > > Phone 1: +49-7031-16 39 98 > > Phone 2: +49-7056-96 50 67 > > Mobile: +49-172-731 5858 > > -------------------- > > > > > > > > > > > > To: Frank > > Leymann/Germany/IBM@IBMDE, <wsbpel@lists.oasis-open.org> > > <mailto:wsbpel@lists.oasis-open.org> > > cc: > > Subject: RE: > > [wsbpel] RE: Issue - 77 - Motion to require access to > > values not > > defined in portType > > > > > > I'm still not clear > > whether it's expected that bpel users > > will sometimes > > have to construct > > bpel-convenient wsdl > > for web-services that already have wsdl > > defintions > > but which don't give > > the required > > accessiblity/granularity in the existing wsdl. The wsdl, > > with some accompanying > > free text description > > of what the parameters are, might have been good > > enough for implementation > > of client and service > > by hand, but now bpel wants a standard > > expression > > of some of that free text. > > Or would such wsdl > > reworking be regarded as a Bad Thing ? it's > > conceptually a refinement, > > though whether it would > > be visibly such in the two wsdl > > descriptions I'm > > not sure). > > > > If the bpel user is > > expected to have such a trick in his mind (and > > perhaps his tools), would an > > alternative solution to > > the underlying problem here be say if the > > abstract wsdl doesn't give you > > the access you want, > > then write one that does. The bindings are then > > more explicit, but still below > > the woodwork from the > > bpel position. > > > > Peter > > > > > > > > > > > > -----Original Message----- > > From: Frank Leymann > > [mailto:LEY1@de.ibm.com] > > Sent: 23 October 2003 11:57 > > To: > wsbpel@lists.oasis-open.org > > Subject: Re: [wsbpel] > > RE: Issue - 77 - Motion to require > > access to values not > > defined in portType > > > > > > > > I wholeheartedly > > support Satish's position! > > > > Regards, > > Frank > > > > ------------------- > > Prof. Dr. Frank > > Leymann, Distinguished Engineer > > IBM Software Group > > Member, IBM Academy of > > Technology > > > > Phone 1: +49-7031-16 39 98 > > Phone 2: +49-7056-96 50 67 > > Mobile: +49-172-731 5858 > > -------------------- > > > > > > > > > > > > To: > > <ygoland@bea.com> <mailto:ygoland@bea.com> , "Furniss, Peter" > > > > <Peter.Furniss@choreology.com> > <mailto:Peter.Furniss@choreology.com> , > > > > <wsbpel@lists.oasis-open.org> <mailto:wsbpel@lists.oasis-open.org> > > cc: > > Subject: [wsbpel] > > RE: Issue - 77 - Motion to require > > access to values > > not defined in portType > > > > > > I was simply making the > > point that BPEL is deliberately > > agnostic about > > bindings, thus allowing deployment > > flexibility. Process > > models that are meant to capture the > > essence of business > > process logic in a portable way should > > not become dependent on > > deployment descriptors, which is at > > least the intent of the > > binding element of WSDL 1.1 service > > descriptions. The fact > > that the intent may be imperfectly > > realized is not a > > reason to throw the principle out. > > > > > > From: Yaron Goland > > [mailto:ygoland@bea.com] > > Sent: Wednesday, > > October 22, 2003 3:27 PM > > To: 'Furniss, Peter'; > > wsbpel@lists.oasis-open.org; Satish Thatte > > Subject: Issue - 77 - > > Motion to require access to values not > > defined in portType > > > > In a previous mail in > > this thread Satish Thatte said: > > > > > > 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. > > > > > > Section 3.7 of the WSDL > > 1.1 states " It is not necessary to > > exhaustively list all > > headers that appear in the SOAP > > Envelope using > > soap:header. " This means that even a portType > > which has been done > > 'properly' may not necessarily have > > messages for every > > header that may appear in the SOAP > > envelope received over > > the wire. Given that even WSDL 1.1 > > recognizes that one can > > reasonably receive SOAP headers that > > weren't defined in the > > portType it would seem reasonable for > > BPEL to provide a > > mechanism to access such values. > > > > > > I would therefore > > propose that we put forward a motion that > > requires the group to > > define a mechanism that will enable > > access to the full > > contents of a WSDL described message as > > transmitted over the > > wire including contents not specifically > > defined in the portType > > definition. > > > > > > Yaron > > -----Original Message----- > > From: Furniss, Peter > > [mailto:Peter.Furniss@choreology.com] > > Sent: Tuesday, October > > 21, 2003 5:14 PM > > To: > wsbpel@lists.oasis-open.org > > Subject: [wsbpel] > > Reannouncement - Issue - 77 - BPEL cannot > > handle some SOAP header > > bindings Due to a mistake on my part, > > this issue was > > erroneously announced as number 78. It is > > really number 77 and is > > in the issues list with that number. > > Here it is again with a > > hand-edit of the number. > > > > This issue has already > > had considerable discussion as > > "Possible new issue > > ...", which I've grandfathered into the > > links list - please use > > an Issue - 77 - subject line on > > further discussion messages. > > > > Peter > > -----Original Message----- > > From: Furniss, Peter > > Sent: 21 October 2003 21:36 > > To: > wsbpel@lists.oasis-open.org > > Subject: [wsbpel] > > Issue - 78 - BPEL cannot handle some SOAP > > header bindings > > > > > > This issue has been > > added to the wsbpel issue list. The > > issues list is posted > > as a Technical Committee document to > > the OASIS WSBPEL TC > > pages on a regular basis. The current > > edition, as a TC > > document, is the most recent document with > > the title in the > > "Issues" folder of the WSBPEL TC document > > list - the next posting > > will include this issue. The list > > editor's working copy, > > which will normally include an issue > > when it is announced, > > is available at this constant URL. > > > > > > Issue - 77 - BPEL > > cannot handle some SOAP header bindings > > Status: open > > Date added: 21 Oct 2003 > > Submitter: Ugo Corda > > Date submitted: 21 > October 2003 > > Description: 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. > > Links: Ugo Corda, 20 > > Oct 2003 Frank Leymann, 21 Oct > > > > > > 2003 Ugo > > > > > > Corda, 21 Oct 2003 > > Satish Thatte, 21 Oct 2003 Peter > > Furniss, 21 > > Oct 2003 Ugo > > Corda, 21 Oct 2003 Satish Thatte, 21 > > Oct 2003 Ugo > > Corda, 21 Oct 2003 > > Satish Thatte, 21 Oct 2003 Ugo > > Corda, 21 Oct > > 2003 > > Changes: 21 Oct 2003 - > > new issue > > > > > > > > To comment on this > > issue, please follow-up to this > > announcement on the > > wsbpel@lists.oasis-open.org list > > (replying to this > > message should automatically send your > > message to that list), > > or ensure the subject line as you > > send it starts "Issue - > > 78 - [anything]" or is a reply to > > such a message. > > > > > > To add a new issue, > > see the issues procedures document (but > > the address for new > > issue submission is the sender of this > > announcement). > > > > > > 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_workgr > > oup.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_workgr > oup.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/leave_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 . 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]