Re: [sca-j] Can we use method-level Intent/PolicySet annotations in the java component implementation class to express implementation QoS requirements?

Hi,

I agree it's not the best design to have different transactional semantics for operations on the same service contract. However, I have ran into a number of cases where this is needed for a client. One case is operation-level metering (a SAAS multi-tenant environment) and SLA metrics. 

I don't really follow the comment about stateful components. JTA transactions for example are associated with an execution context, not a component implementation instance, so scope is orthogonal in this case. This is also the case for our metering and SLA policies as they are associated with the subject of the execution context.

Jim

 

On Oct 29, 2009, at 7:43 AM, Mike Edwards wrote:

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:
 
 <mime-attachment.gif>Raymond Feng---10/20/2009 06:02:17 PM---Hi, For example, I would like to set up the implementation class with
   
 <mime-attachment.gif>
 From: <mime-attachment.gif>
 Raymond Feng/Burlingame/IBM@IBMUS 

 <mime-attachment.gif>
 To: <mime-attachment.gif>
  

 <mime-attachment.gif>
 Date: <mime-attachment.gif>
 10/20/2009 06:02 PM 

 <mime-attachment.gif>
 Subject: <mime-attachment.gif>
 [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