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

["Peshev, Peter" <peter.peshev@sap.com>]

Hi, 

as discussed in the meeting, here is some java code & wording to clarify
the issue :

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: Peshev, Peter [mailto:peter.peshev@sap.com] 
Sent: Thursday, 27. September 2007 18:48
To: sca-j@lists.oasis-open.org
Subject: [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.