RE: [sca-j] ISSUE 12: Relation between conversational annotation and scope conversation

Hi Simon,

 

I am Ok with that suggestion. 

I am just trying to clarify some parts of the spec  
which are left not clearly stated.

 

NEW PROPOSAL :
It should be clarified that in the above example 
- 

Having a StatefullClass exposing service over a 
non-conversational interface MUST generate an error at deployment.

The 
instances of the class StatelessClass  are NOT REQUIRED to 
contain
conversational state between methods; Any instance can be used for 
any client. An SCA runtime MAY provide a
pool of such objects and reuse them 
among calling clients or MAY instantiate each time a new instance. 
ConversationalId MUST be provided
since the interface was marked via 
@Conversational

From: Simon Nash [mailto:] 

Sent: Thursday, 7. February 2008 19:37
To: 

Subject: RE: [sca-j] ISSUE 12: Relation 
between conversational annotation and scope conversation

I'm OK with the second part of the 
proposal, but not with the first part.  When a conversation is initiated, 
action is needed on the client side as well as the service side.  If the 
interface is not marked conversational, the client can't know that it should 
perform the necessary actions.  These include creating a conversation ID 
and sending it on the wire. 

I think 
this combination of a non-conversational interface and a conversational 
implementation should be treated as an error. 

    Simon 

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM 
Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999 

  
  

    "Peshev, Peter" 
      <> 
      
05/10/2007 09:20 

    
      
        
        

          
            
To

          <> 
        

          
            
cc

          
        

          
            
Subject

          RE: [sca-j] ISSUE 12: Relation 
            between conversational annotation and scope 
        conversation

      
        
        

          
          

Resending the email in this mail thread, just to keep track  : 
 

DESCRIPTION:
The annotation @Conversational is put on 
interfaces, while the
annotation @Scope is put on the implementation types 
for POJO-s. They
are used to control whether the runtime  will keep 
state or not between
invocations.  (Some other future implementation 
types in scope of the TC
may provide their own stateless and stateful 
semantics equivalent to the
scope mechanics)

It should be clarified 
what should happen if @Conversational is put on a
service interface however 
the class which is exposing that service is
lacking @Scope(Conversation) 

It should be clarified what should happen if there is NO 
@Conversational
on a service interface however the class which is exposing 
that service
is having @Scope(Conversation).

More precisely having 
in mind the following definitions (each in its own
file) :

import 
org.osoa.sca.annotations.Conversational;
@Conversational public interface 
ConversationalInterface {}

---

public interface 
NonConversationalInterface {public void test();}

---

import 
org.osoa.sca.annotations.Scope;
import 
org.osoa.sca.annotations.Service;
@Service(NonConversationalInterface.class)@Scope("CONVERSATION")
public 
class StatefullClass implements NonConversationalInterface {
public void 
test() {}}

---

import 
org.osoa.sca.annotations.Service;
@Service(ConversationalInterface.class)
public 
class StatelessClass implements ConversationalInterface{       
          public
void test() {}}

It 
should be clraified whether it is legal to deploy such components and
what 
should happen if a client calls via sca two times the method test()
for 
ServiceReferences correspondant to the two classes. Is the 
runtime
responsible to keep the state between the invocations 
?

PROPOSAL :
It should be clarified that in the above example 
- 

Instances of the StatefullClass MUST contain conversational state 
which
MUST be retained across methods and transactions called from the 
client.

The instances of the class StatelessClass  are NOT REQUIRED 
to contain
conversational state between methods;
Any instance can be used 
for any client. An SCA runtime MAY provide a
pool of such objects and reuse 
them among calling clients or MAY
instantiate each time a new instance. 
ConversationalId will be provided
since the interface was marked via 
@Conversational

-----Original Message-----
From: Barack, 
Ron [mailto:] 
Sent: Thursday, 4. October 2007 21:07
To: 

Subject: [sca-j] ISSUE 12: Relation between 
conversational annotation and scope conversation

http://www.osoa.org/jira/browse/JAVA-12 

-----Ursprüngliche 
Nachricht-----
Von: Peshev, Peter [mailto:] 
Gesendet: 
Donnerstag, 27. September 2007 17:48
An: 

Betreff: [sca-j] NEW ISSUE: Relation between 
conversational annotation and scope conversation

TARGET:

Java 
Common Annotations and APIs specification

DESCRIPTION:

The 
specification mentions @Conversational and @Scope(Conversation) but
there is 
no clarification how these interfere together and what should
happen in all 
the possible combinations.

PROPOSAL:

Two new paragraphs 
should be added in section (3.2 @Conversational) that
have the following 
wording :

In case an interface is marked as conversational  but the 
scope of the
target implementation is different than @Scope(Conversation), 
than the
SCA runtime would invoke an instance as defined by the scope. In 
case
the scope is the default one (stateless) than the container may 
dispatch
to a new instance each time or alternatively pull one from a pool. 
 In
this case, it is assumed that the implementation itself will 
manage
state. The implementation would be responsible for using 
the
conversation id associated with the request (obtaining it 
through
injection or via the SCA API) to obtain state stored somewhere (cache 
,
database , etc.).

In case the target implementation has 
@Scope(Conversation) and the
interface is NOT marked as conversational than 
there will be no
conversation, attempts to retrieve conversationId will 
result in null,
and the SCA runtime may behave as if for that particular 
invocation the
scope has been defined as 
stateless.

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