SCAPOLICY-3: Cannot attach method specific transaction intents

[David Booz <booz@us.ibm.com>]

Logged as

https://tools.oasis-open.org/issues/browse/SCAPOLICY-3

....in our shiny new JIRA system

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com



From:	David Booz/Poughkeepsie/IBM@IBMUS
To:	sca-policy@lists.oasis-open.org
Date:	02/14/2012 09:21 AM
Subject:	[sca-policy] NEW ISSUE: Cannot attach method specific
            transaction intents
Sent by:	<sca-policy@lists.oasis-open.org>




TARGET: SCA Policy Spec

DESCRIPTION:
Section 9.5.2 in the Policy spec has this normative statement;

The transactedOneWay intent MUST NOT be attached to a request/response
operation. [POL90028]

The problem with this statement is that it is too strict. If you read the
three preceding statements:

When a reference is marked as transactedOneWay, any OneWay invocation
messages MUST be transacted as part of a client global transaction. [
POL90008]


If the client component is not configured to run under a global transaction
or if the binding does not support transactional message sending, then a
reference MUST NOT be marked as transactedOneWay. [POL90009]


If a service is marked as transactedOneWay, any OneWay invocation message
MUST be received from the transport binding in a transacted fashion, under
the target service’s global transaction. [POL90010]


You can see stmts 8, 9 and 10 consider the fact that this intent might be
attached at locations where there are both oneway and request/response
operations. POL90028 does not have the same conditional behavior, and as a
result, prohibits this intent from being placed on an
interface/service/reference which has both one-way AND request/response
operations.

We have the same problem with immediateOneWay intent. Those statements
immediately follow in section 9.5.2.


PROPOSAL: Informally, a proposed resolution would look something like this:

The technical solution would be adjust POL90028, POL90029 and the
corresponding tests in the test suite. For example, POL90028 could be
re-written something like this...we can argue about the precise words
later:

The transactedOneWay intent MUST be ignored by the runtime for a
request/response operation. [POL90028]

We'd make a similar fix to POL90029.
The test suite tests would change to ignore the intent as appropriate
instead of raising an error as they do today.

thanks

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com