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 <>
To: Frank Leymann/Germany/IBM@IBMDE, <>
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
