[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-caf] policy ai
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? 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? 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]