Edwin,
I agree these are pretty abstract discussions, but I wouldn't say
we've managed to engineer much of anything at this point.
I don't think we need a full use case, complete with WSDL, BPEL and
deployment descriptor. A simple scenario should suffice to clarify the
issues.
Let's say we have two participants: a buyer, and a seller. The
seller provides a well-known (static) address for a
quotation/purchasing service. The buyer provides a dynamic address for
a service it provides for asynchronous call-backs from the purchaser.
The basic process the seller implements to provide these services
is simple: the process is initiated by the buyer with a quotation
request. The quotation is generated by internal processing, and then
returned, asynchronously, to the buyer. (The buyer supplied the
callback address to receive the quote with the initiating request). The
process continues with negotiation, purchasing, shipping and invoicing
phases, but we can skip that part.
The supplier's analyst actually specifies two processes: the
supplier's own executable process, described above, and an abstract
process for buyers to follow when interacting with the
quotation/purchasing.
The supplier's analyst constructing these processes has a
particular need in this scenario. In order to preserve the
confidentiality of the supplier's price list and discount structures,
the quotation must be sent in a secure (encrypted) fashion across the
internet. Since this is a service provided by the buyer, he must
communicate this need to the buyer. This could be part of the abstract
process, or its associated WSDL, or accomplished by out-of-band means.
Let's explore the first two options, starting with WSDL. Since
WSDL doesn't allow extension elements in a portType/operation, there is
no way to extent the abstract operation as desired. Instead, the
supplier may use comments, or private a sample binding with the
operation corresponding to the reception of the quotation decorated
with some sort of policy assertions. If we used WS-SecurityPolicy
(which, of course is legally impossible for most of us) , we could use
the <Confidentiality> assertion. (SAML would be a better choice,
since it is an open standard.)
Regardless, this whole approach is pretty brittle. If the buyer
fails to notice and honour the implied need for security on the
callback, there is no simple means for the supplier to detect this
omission at run-time (deployment-time being out of the question, since
buyer service is dynamically resolved). There is no way to
automatically test for and enforce conformance to the intention to
secure quotations. The intention is lost.
Exploring our second option, let us suppose that BPEL permits
high-level security intentions to be expressed in the process. In this
case the buyer has, in the abstract process, an explicit requirement
(@isConfidential) to use encrypted messaging when receiving the quote
request. This can be enforced by deployment tooling, making human error
much less likely to cause deviation from the high-level security
policy. Even if the buyer somehow elects to use unencrypted
communications, it is feasible for the supplier's run-time
infrastructure to verify that the dynamically determined callback
address supplied by the buyer in fact complies to the given security
requirements.
* * *
My main take-away from this scenario is: WSDL 1.1 is pretty
limited. (I was going to say broken, but that sounds overly judgemental
;-) WSDL causes some interesting problems, due in part to how certain
features (like extensibility) weren't thought through properly,
strongly affecting portability and interoperability. Let us not make
the same mistake with BPEL.
Does this help clarify the issues at hand? This is only an example,
and perhaps not the best; there are plenty of variants on this theme.
-Ron
Ron,
All this seems rather abstract
to me so I will tend to agree with Satish that we should not over
engineer areas of the language where the requirements are not cristal
clear. Could you please provide a detailed us case with associated
WSDL, BPEL and Deployment Descriptor?
Thank you,
Edwin
