Re: [ws-caf] policy ai

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

After discussion and subsequent reflection, I'd be in favor of resolving 
the policy issue with a acid:Supports assertion only. I also think we 
should drop the isolation level informational policy. Let's discuss today.

Greg

Newcomer, Eric wrote:

>In general I think the main policies that are needed include whether or
>not a transaction is required, supported, or disallowed.  I think Greg
>has identified these in his proposal.
>
>-----Original Message-----
>From: Mark Little [mailto:mark.little@arjuna.com] 
>Sent: Tuesday, July 26, 2005 10:29 AM
>To: Greg Pavlik
>Cc: Green, Alastair J.; ws-caf
>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>
>>>
>>> 
>>>
>>>      
>>>
>>    
>>
>
>  
>