[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
Certainly if we vote in favor of not modifying the BPEL language (position that I personally do not share), we should state very clearly in the spec what are the additional constraints imposed by BPEL to guarantee headers visibility. Ugo > -----Original Message----- > From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] > Sent: Thursday, October 23, 2003 6:48 AM > To: Frank Leymann; wsbpel@lists.oasis-open.org > 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>, "Furniss, Peter" > > <Peter.Furniss@choreology.com>, > > <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/leave_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/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]