OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

[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]