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