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 notdefined in portType



Obviously,  I wholeheartedly second Satish's position.

Regards,
Frank







To:    "Ugo Corda" <UCorda@SeeBeyond.com>, "Ron Ten-Hove"
       <Ronald.Ten-Hove@Sun.COM>
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/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
                                                 .







                                                 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]