OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]