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

Hi Mike,

 

That's a perfect wording  

 

I just wanted to clarify for myself what other usecases and 
scenarios you are envisioning for the java part of the SCA. 

 

Best Regards

Peter  

From: Mike Edwards 
[mailto:] 
Sent: Friday, 8. February 2008 
13:50
To: OASIS Java
Subject: RE: [sca-j] ISSUE 12: Relation 
between conversational annotation and scope conversation

Peter, 

The range of runtimes and runtime strategies is large and 
it is hard to avoid making statements that might 
limit SCA runtimes unintentionally. 

"typically" is used here to avoid having to discuss the 
complex strategies of grid-style runtimes, where 
"instances" could get moved around between grid 
nodes. 

If you can think of some 
better wording that deals with the possibilities of differing runtime 
strategies, I'd 
be grateful to see 
it. 

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: 
  

  
  

    "Peshev, Peter" 
      <> 
      
08/02/2008 11:44 

    
      
        
        

          
            
To

          Mike Edwards/UK/IBM@IBMGB, "OASIS 
            Java" <> 
        

          
            
cc

          
        

          
            
Subject

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

      
        
        

          
          

Hi Mike, 
  
just a clarification question for my better 
understanding, when you say : 
  
 If the class has conversation scope, the class benefits 
from the runtime maintaining state associated 
with the conversation, typically through 
routing each operation invocation associated with the conversation to the 
same 
instance of the 
class, 
  
Does the word "typically" imply the runtime could do something else 
besides invoking the same instance, when the class is conversationally scoped 
? 
  
  
Besides 
Peter 

From: Mike Edwards 
[mailto:] 
Sent: Friday, 8. February 2008 
12:06
To: OASIS Java
Subject: RE: [sca-j] ISSUE 12: Relation 
between conversational annotation and scope conversation

Folks, 

I'm not keen on double 
negatives, so let me try some wordsmithing of the second part: 

A class which provides a 
service with a conversational interface can have any scope.  In particular, 
it is not necessary for the class 
to have conversation scope.  If the class has 
conversation scope, the class benefits from the runtime maintaining state 
associated 
with the 
conversation, typically through routing each operation invocation associated 
with the conversation to the same 
instance of the class, with state data held in 
instance variables within the class.  However, for classes of any scope, 
when an 
operation of 
a conversational interface is executing, the 
ComponentContext.getConversationID() returns the conversation ID of 
the conversation.  The 
conversation ID can be used by the class as an index to store and to look up 
state data associated with the 
conversation, using some suitable storage 
mechanism. 

OK, this is a longer set of words, but I hope it explains things more 
clearly by being explicit about what is going on. 

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:   

  
  

    "Michael Rowley" 
      <> 
      
07/02/2008 19:33 
      

    

      
        
        

          
            
To

          "Peshev, Peter" 
            <>, Simon Nash/UK/IBM@IBMGB, 
            <> 
        

          
            
cc

          
        

          
            
Subject

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

      
        
        

          
          

 
On today’s call, 
we resolved the first part of this issue as follows: 

 
Resolved: Add 
these words to section 2.4.4: "A conversational scoped class MUST NOT expose a 
service using a non-conversational interface." 
 
We discussed possible wording for the second 
part of the proposal.  I made some attempts at wording during the meeting 
that weren’t very good.  Here is my latest attempt: 

 
When a class 
provides a service with a conversational interface, it does not implicitly 
affect the scope of that class.  If the scope is not conversational, then 
the runtime will not automatically maintain state that is associated with the 
conversation.  However, when an operation of a conversation interface is 
executing, the ComponentContext.getConversationID() will return the conversation 
ID for the conversation, irrespective of the scope of the component. 
 
Michael 
  

From: Peshev, Peter 
[mailto:] 
Sent: Thursday, February 07, 2008 1:03 
PM
To: Simon Nash; 
Subject: 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 

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 

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