Request scoped components and conversations

[Simon Laws <si...@googlemail.com>]

If a component has request scope then the behaviour of the component,
w.r.tconversations, currently differs depending on whether it is
accessed via a
local or a remote binding. Consider components A and B where B has request
scope and A sends messages to B over local and remote  bindings in the
content of two conversations. The sequece of messages will be.

conversation1.initCount(1)
conversation1.incrementCount()
result = conversation1.getCount()

In the local case component B is always on the same thread as component A
and, regardless of which conversation is actually calling B the same
component instance is used. This component instance adopts the conversation
ID (through @ConversationID) it was created with regardless of which
conversation is actualy calling B. The result is the following sequence of
calls

init,initializeCount,incrementCount,retrieveCount,endConversation

In the remote case a new component B instance is created for each call and
hence B adopts the conversation ID from the incoming message. The resulting
the sequence of messages is.

init,initializeCount,init,incrementCount,init,retrieveCount,init,endConversation

Note. A new instance is created and init() is called for each message.

The assemble spec describes request scoped components in the following way.

285 1.2.4.2. Request scope
286 The lifecycle of request scope extends from the point a request on a
remotable interface enters the SCA
287 runtime and a thread processes that request until the thread completes
synchronously processing the
288 request. During that time, all service requests will be delegated to the
same implementation instance of a
289 request-scoped component.
290 There are times when a local request scoped service is called without
there being a remotable service
291 earlier in the call stack, such as when a local service is called from a
non-SCA entity. In these cases, a
292 remote request is always considered to be present, but the lifetime of
the request is implementation
293 dependent. For example, a timer event could be treated as a remote
request.

Is our interpretation of  the behaviour of request scoped components within
a conversation correct?

Regards

Simon