[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-caf] policy ai
Greg Pavlik wrote: > 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. +1 The WSDL shouldn't define the implementation semantics of the service. Wouldn't it make more sense to put it in the MetaData bucket in WS-Addressing? > >> 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. I think the basic yes/no make sense. If a service needs a transaction context on an invocation and one is not present, then it can fault to the invoker. To be honest, I don't have a strong feeling either way, but it seems like keeping it simple to start with is the best way to go IMO. > > 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. Whoever said EJB/J2EE was perfect ;-)? Mark. > >> 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> >> >> >> > > -- Mark Little Chief Architect Arjuna Technologies Ltd www.arjuna.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]