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