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
