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

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