Re: [ws-caf] policy ai

[Greg Pavlik <greg.pavlik@oracle.com>]

Green, Alastair J. wrote:

>Greg,
>
>I have a couple of questions, which may be a bit elementary from your
>standpoint, to understand what you are looking for here.
>
>I understand the value of a policy expression in the WSDL to indicate
>transactional capability. Is there a standardized mechanism for faulting
>in the event of a mismatch?
>
>  
>
No, not really. The fault would be protocol specific.

One other point: I think personally that its a mistake to include policy 
snippets in WSDL. Having had to look closely at the WS policy management 
space (we have a product there from our Oblix acquisition), we pretty 
clearly see a need to keep policies independent.  The WS-Policy related 
specs and the vendor implementations I've seen appear to be 
schizophrenic on this: WS-MEX clearly lays the groundwork for a loose 
coupling between polices and WSDL, but the WS-Policy family provides 
embedded WSDL capabilities. If you look at the last Indigo drop, its 
clear that even the original authors aren't dealing with this problem well.

>I'm less clear about the relevance of the EJB-style declarations. Are
>you suggesting that a service (presumably outside the container
>potentially) can state to the client what its declared approach will be?
>Is this really any business of the client?
>
>  
>
No, its not any business of the client and not what I meant: the writeup 
must be misleading.

I  meant to suggest that application servers using EJB or COM+ semantics 
will find this does not conflict with the kinds of assertions I listed. 
I probably shouldn't even have mentioned EJB. Its not clear to me we 
need to say more than Supports/Doesn't Support, but since we didn't have 
particularly strong requirements, I started to explore other assertions 
that may be of interest.

Having said all of that, there is a problem with client-server 
transaction semantics in EJB that was never really resolved: the only 
way one can reason about the relationships in EJB based systems is to 
sit in a position of omniscience.

>This is not an area I've thought about very much at all, so forgive me
>if I'm missing something obvious.
>
>Alastair
>
>-----Original Message-----
>From: Greg Pavlik [mailto:greg.pavlik@oracle.com] 
>Sent: 25 July 2005 16:31
>To: ws-caf
>Subject: [ws-caf] policy ai
>
>This email provides a strawman proposal for policy assertions for the 
>WS-CAF acid transaction protocol. My intention here is to stimulate 
>forward work in this area. Bear in mind that there has not been a strong
>
>set of requirements or invariants established by the TC to drive a
>proposal.
>
>Some background
>
>In order for clients to make informed decisions about the implications 
>of using a component or service in the context of an activity, the 
>service must be able to express its capabilities with respect to the 
>transaction protocol. This was pursued at length with the CORBA OTS 
>working group.
>
>In OTS, policies are set on the Portable Object Adapter (POA) that is 
>responsible for managing the lifecycle of objects (or references, since 
>the incarnation of the object generally relies on the pairing of a 
>servant). Policies on the POA are encoded into the Interoperable Object 
>Reference (IOR) as tag values. All clients of the object can inspect the
>
>policies of the POA and determine the transaction characteristics of the
>
>object. As we've discussed, CORBA also defines an asynchronous 
>invocation facility. Methods dispatched through this mechanism may carry
>
>transactions, but will result in "unshared" transactions: the client 
>transaction applies only to the delivery but not the execution of the 
>method. All other transactions are "shared".
>
>The OTS specification expresses the following policies with respect to 
>transactions:
>* The object requires that no transaction be on the request
>* The object forbids that a transaction be on the request.
>* the object allows either case.
>
>In addition the object may express policies with respect to shared or 
>unshared transactions. Note that it is possible to strucuture unshared 
>relationships at a higher level in the invocation stack. For example, an
>
>EJB accessed via IIOP may suspend the imported transaction and start a 
>new transaction scoping the execution of its business logic if the EJB 
>method has the transaction demarcation attribute RequiresNew. Also, note
>
>that EJB's provide method level transaction attributes, which creates a 
>structural conflict between the two models. The EJB 2.0ff specification 
>provides rules to resolve this.
>
>The web service solution is likely to differ in important respects from 
>the OTS solution, though policy expression within WSDL service elements 
>in WSDL 2.0 may provide an equivalent reference encoding and exchange 
>style to web service clients.
>
>Similarly, EJB provides a way to express the transaction characteristics
>
>of a component. EJB provides a richer model that indicates more fully 
>the behavior of the service at the level of an operation. In J2EE (and 
>roughly speaking in COM+) the capabilities of the service operation are:
>
>* NotSupported: indicates the transaction will be suspended;
>* Requires: if not present in the request context, a transaction will be
>
>started;
>* RequiresNew: if a transaction is present on the request context, it is
>
>suspended; in all cases, a new transaction is used to dispatch the 
>business method.
>* Supports: will execute with a transaction from the request context or 
>with no transaction.
>* Never: indicates that calling the method in the scope of a transaction
>
>is an error.
>
>EJBs may also defer transaction management to the bean instance. In this
>
>case, all calling transactions will be suspended.
>
>Note that the client (in the canonical EJB model) is unable to determine
>
>the transaction attributes of an operation without access to the 
>deployment descriptor or some other out-of-band technique. Despite the 
>fact that the transaction attributes strongly influence how beans may be
>
>sensibly used, these are really implementation instructions for the 
>container to deal with. The transaction demarcations do not make 
>promises about the semantics of the participant with respect to any 
>outside activity/transaction models.
>
>I'll say up front that we have an interest in overlaying this protocol 
>on our J2EE application server: this is not the only use case, of 
>course, but one I'd like to show has been carefully considered.
>
>Concerete proposals:
>
>1) Following the convention of the WS-RX TC, I suggest we talk in terms 
>of assertions as XML fragments that define declarative statements about 
>what is required for the consumer to conform to its role in the 
>protocol. WS-RX is currently modeled to comply with the latest version 
>of WS-Policy: this draft does not allow declarative statements around 
>assertions that do not alter the wire level message, ie, "observed" 
>behavior of a service or so-called "informational policies". While I 
>think this severely retards what we can reasonably achieve with Web 
>services, I believe this is also a practical problem for us: policies 
>around the isolation levels of a service (as have been proposed) clearly
>
>impact the decision to use a service rather than the specifics of the 
>wire message itself. It is not clear how WS-Policy in its current form 
>would regard a "No Support/Support" assertion.
>
>For the acid transaction protocol(s), I don't believe we will have to 
>worry about intra-domain composition, but obviously we need to decide 
>this as a group based on what we think is necessary.
>
>This proposal does not discuss the binding of policies to specific 
>aspects of WSDL, eg, the operation, porttype, port and service level. I 
>see no reason to restrict this.
>
>The following element information items are proposed for acid 
>transaction policy assertions:
>
>* Support: transactions may be imported but no guarantees are made with 
>respect to their use by the service.
>* No Support: transactions on the calling context will not be used.
>* Disallowed: transaction on the current context is a fault condition.
>* Use: an explicit contract that all work done in the operation will be 
>scoped by the transaction on the calling context.
>
>Each element information item may contain one or more subprotocol 
>attribute informations indicating whether the policy applies to the two 
>phase commit subprotocol, synchronization subprotocol, or both. It is 
>possible to have two element information items, once for each
>subprotocol.
>
>The absence of a policy assertion results in undefined interaction 
>semantics. The proposal tries to suggest enough information to allow 
>end-users to reason about the overall interaction semantic, but there 
>may be too strong an RPC bias and attempt to say more than is reasonable
>
>(I've left a richer set of choices as a starting point). On the plus 
>side, this should work reasonably well with Java/J2EE. While I don't 
>think we should mention it explicity in the specification, a strawman 
>default mapping for EJB might be:
>
>EJB Transaction Demarcation Attribute Default Capability Assertion
>Requires Support
>RequiresNew Support
>Supports Support
>NotSupported No Support
>Never Disallowed.
>
>Though some of the defaults could be overridden with alternative values.
>
>For example, an EJB with RequiresNew could be exposed as web service 
>with a "Transaction Disallowed" capability assertion.
>
>Second, following the instructions of the TC, I suggest an optional 
>attribute information item for the isolation level observed. The 
>following values are valid: read_uncommitted, read_committed, 
>repeatable_read, serializable. (Editor note: I am not convinced of the 
>real utility of this attribute for a system of composite services).
>
>A non normative example XML fragment would appear as:
>
><ws-acid:TransactionAssertion ... >
><ws-acid:Supports subprotocol="acid uri" subprotocol="synchronization 
>uri" isolation="read_committed" />
></ws-acid:TransactionAssertion>
>
>  
>