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