Next in thread →
Next in month →
Re: [sca-j] Can we use method-level Intent/PolicySet annotations in thejava component implementation class to express implementation QoSrequirements?
The original example I have is a service that provide a few
operations for managing the accounts. I think it is very natural that the
getBalance() doesn't require transaction as it's read only while the transfer()
needs to have either a global or local transaction depending on the implementation
(for example, update between two DBs, update two tables in one DB or simply
schedule it to a JMS queue).
@Service(AccountService.class)
public class AccountServiceImpl {
@ManagedSharedTransaction
public void transfer(String account1,
String account2, float amount) {
...
}
@NoManagedTransaction
public float getBalance(String account)
{
...
}
}
Do you think we should have two services for this case?
Isn't it overkilling?
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: ,
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
From:
Mike Edwards <>
To:
Date:
10/29/2009 04:41 AM
Subject:
Re: [sca-j] Can we use method-level
Intent/PolicySet annotations in the java component implementation class
to express implementation QoS requirements?
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:
From:
David Booz <>
To:
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:
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:
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: ,
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
S/MIME Cryptographic Signature
Next in thread →
Next in month →