Re: [wsbpel] policy annotations and BPEL

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

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