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