sca-j message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-j] Can we use method-level Intent/PolicySet annotations in thejava component implementation class to express implementation QoSrequirements?
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: sca-j@lists.oasis-open.org
- Date: Thu, 29 Oct 2009 11:43:05 +0000
Folks,
I think that going down this road could
lead to problems.
Implementation intents like @ManagedSharedTransaction
and @NoManagedTransaction are really between an implementation
and the container which runs it. Using
different annotations on different methods implies that the container must
treat the implementation
differently depending on which operation
is invoked. This might be doable for stateless implementations but
just forget it for stateful
(eg composite scoped).
It is possible to have interaction intents
that are different for different methods, although I would be cautious
in handling different methods
differently. This could be used
to propagate or not propagate a transaction context, for example.
However, it would probably be wise to
separate out different operations with different transactional characteristics
into separate service
interfaces, since the need to transmit
a transaction context, for example, has an impact on the behaviour of the
whole of the client to such
a service.
It is more clearly the case that other
types of intent can be on an operation basis - security stuff like encryption
is a good example.
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From:
| David Booz <booz@us.ibm.com>
|
To:
| sca-j@lists.oasis-open.org
|
Date:
| 27/10/2009 13:30
|
Subject:
| Re: [sca-j] Can we use method-level
Intent/PolicySet annotations in the java component implementation class
to express implementation QoS requirements? |
Honestly, I don't feel strongly either way. We have to
be careful with transactions because they can create tight coupling between
services. Different transaction behaviors for each method doesn't strike
me as a central focus for SOA style interfaces. Such an interface would
limit the possible alternative interfaces which could connect to it, thus
making it a fine grained interface and not appropriate for a SOA. That
said, I recognize that there are varying degrees of interpretation on what's
appropriate in SOA interfaces.
EJB3 is a very good fine grained model which supports different use cases
than SCA.
Are there other opinions?
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
Raymond
Feng---10/20/2009 06:02:17 PM---Hi, For example, I would like to set up
the implementation class with
From:
|
Raymond Feng/Burlingame/IBM@IBMUS
|
To:
|
sca-j@lists.oasis-open.org
|
Date:
|
10/20/2009 06:02 PM
|
Subject:
|
[sca-j] Can we use method-level Intent/PolicySet annotations in the java
component implementation class to express implementation QoS requirements? |
Hi,
For example, I would like to set up the implementation class with transaction
requirements using method-level annotations to declare implementation intents/policySets
for a java component.
@Service(AccountService.class)
public class AccountServiceImpl {
@ManagedSharedTransaction
public void transfer(String account1, String account2, float amount) {
}
@NoManagedTransaction
public float getBalance(String account) {
}
}
We can do similar things in EJB3.
But the Java CAA spec has the following statement:
854 Intent annotations MUST NOT be applied to the following:
855 • A method of a service implementation class, except for a setter
method that is either
856 annotated with @Reference or introspected as an SCA reference according
to the rules in
857 the appropriate Component Implementation specification
This will make the sample above invalid.
I don't think we should be forced to require the same intent for the whole
class as it is quite common that different operations have different QoS
requirements.
We could argue that this can be done at interface methods. But in this
case, the transaction requirements are decided by the implementation instead
of the interface.
What do you think?
Thanks,
Raymond
Raymond Feng
Senior Software Engineer, Apache Tuscany PMC Member & Committer
IBM Bay Area Lab, 1001 E Hillsdale Blvd, Suite 400, Foster City, CA 94404,
USA
E-mail: rfeng@us.ibm.com,
Notes: Raymond Feng/Burlingame/IBM, Tel: 650-645-8117,
T/L: 367-8117
Apache Tuscany: http://tuscany.apache.org
Co-author of Tuscany In Action: http://www.manning.com/laws
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]