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
