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:]
> Sent: Thursday, October 23, 2003 6:48 AM
> To: Frank Leymann;
> 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:]
> > Sent: 23 October 2003 11:57
> > To:
> > 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: <>, "Furniss, Peter"
> > <>,
> > <>
> > 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:]
> > Sent: Wednesday, October 22, 2003 3:27 PM
> > To: 'Furniss, Peter'; ; 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:]
> > Sent: Tuesday, October 21, 2003 5:14 PM
> > To:
> > 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:
> > 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 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.
