To: "Satish Thatte" <email@example.com>,"Ron Ten-Hove" <Ronald.Ten-Hove@Sun.COM>,<firstname.lastname@example.org>
Date: Wed, 19 Nov 2003 11:19:05 -0800
The concept of
optional header needs to be better specified in the context of Yaron's message.
There are two cases:
1 - The
optional header is defined in an abstract message (this is the case
I used when raising this issue).
2 - The optional
header is not defined in any part of the abstract interface (this is not the
case I exemplified when I filed this issue, and I prefer to keep it out of the
discussion of the issue itself).
about introspection does not apply to case 1. In case 1 BPEL does not need to
concern itself with how to get to the abstract message: that is just part of the
underlying binding machinery. All BPEL sees is the abstract message. Reaching
that abstract message is not any more complicated for BPEL than reaching any
other component of the abstract operation.
-----Original Message----- From:
Satish Thatte [mailto:email@example.com] Sent: Wednesday, November
19, 2003 11:04 AM To: Ron Ten-Hove; firstname.lastname@example.org Cc:
email@example.com Subject: RE: [wsbpel] Issue - 77 - Under
specified operation definitions
With your idea of
rinsing SOAP off the body of BPEL, your agreement with Yaron also amounts to
rejecting Yaron’s proposals for dealing with optional headers. I assume
that is intentionally left unsaid .. ;-)
From: Ron Ten-Hove
Sent: Wednesday, November 19,
firstname.lastname@example.org Subject: Re: [wsbpel] Issue - 77 - Under
specified operation definitions
I have to agree with
you; the only sane course of action here is to demand that any message
constructs that BPEL can use must be described in WSDL, otherwise BPEL is
blind to them. This doesn't prohibit lower-levels of a "stack" from mucking
around with the message further, injecting or processing headers as needs be.
We sure don't want to be in business of building exceptions to this rule into
the BPEL vocabulary!
I'm a little leary about
having processes directly mess around with secondary protocols (i.e. headers).
A process could easily become overwhelmed with chewing on and processing
headers, signatures, assertions, and the actual business process being
implemented could become unreadable. Do we want, at a business level, to be
messing around with such low-level protocols? My sense is that BPEL ought to
work at a higher level of abstraction, if it is to be used to express business
processes rather than a lot of technical protocol
Getting back on topic: some confusion
arises with the confusion of SOAP with WSDL. I know that SOAP and WSDL could
have been better designed to keep this clearer, but the fact is some (many,
perhaps?) associate web services only with SOAP, and look at BPEL as, in part,
a way to play directly with SOAP messages. This is a misleading way to look at
it, just as it is misleading to regard SOAP as just HTTP. Let's just
rinse all that SOAP off our thinking, and stick with nice, clean WSDL.
Issue - How do to deal with message content that is not specified in the
WSDL abstract operation definition?
For example, if a BPEL process receives a SOAP message with a SOAP
security header that wasn't specified in the WSDL abstract operation
definition then how does the BPEL process reach into the header and pull out
the name of the sender so that the BPEL process can send a message such as
"I just got a signed message from Joe"?
The inverse example is also possible. The BPEL engine may have been
given a standard WSDL definition that does not specify the use of a callback
header in the WSDL abstract operation definition. If the BPEL process needs