[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-j] ISSUE 21 - Clarify Request Scope lifetime
|
During the F2F it was observed that the
request scope is similar to the conversation scope, except that it
automatically propagates around the local components of a composite. Perhaps
it would be simpler to take advantage of this similarity and also expand on
conversation scopes. If an entire conversation can be marked as conversational,
it could mean that all of the components within the composite work within the
same conversation. This is also something that BEA has had customers ask
for on its own right. However, if we did this, the request-scope could be
removed, since basically same semantics could be achieved by having a composite
that has been marked as “local” be also marked as conversational. The rules that we discussed at the F2F
were: 1. Composite can be marked to propagate
conversations through all components within the composite
("propagatesConversation"). 2. Request scope goes away. 3. If the composite service has a
conversational interface, then if the composite is marked as
"propagatesConversation" then the conversation of the composite's
client will be propagated throughout all of the components within the
composite. 4. If the composite service has a
non-conversational interface, then if the composite is marked as
"propagatesConversation", then (unless step 3 applies) a new
conversation will be started on each operation of the composite service
and propagated throughout the components within the composite. 5. Marking a composite as
"propagatesConversation" acts as if all the components have been
marked as "propagatesConversation". Marking a component with
"propagatesConversation" means that any conversationID passed into
the component through a service will be passed with any call on a
intra-composite wire from the component. If this were to happen, it would probably
have to be done in either the policy or assembly TC. Michael From: Barack,
Ron [mailto:ron.barack@sap.com] http://www.osoa.org/jira/browse/JAVA-21 Von: RAISER: TARGET: SCA Java Component
Implementation Specification section titled “Request Scope” DESCRIPTION: The section currently starts with
the following sentence: “The lifecycle of request scope extends from the
point a request on a remotable interface enters the SCA runtime and a thread
processes that request until the thread completes synchronously processing the
request.” From this description, it is not
clear whether the request scope lasts through a remotable call to another
component that happens to be local. In one possible interpretation it
would depend on the binding. A call through a web service binding would
be seen as changing threads, and therefore would be a new request scope.
The same call through an SCA binding might be assumed to remain within
the thread and therefore be within the same scope. It is probably a bad idea for the
scope to depend on the binding that is used, and it may even be a bad idea for
the scope to depend on whether a call through a remotable interface _happens_ to be local. PROPOSALS: 1) Have the request scope be only
for a single remotable operation call. From that operation, any request
scope component that is reached through only local-service calls would reach
the same component instance. Calls through a remotable interface would
introduce a new request scope. 2) Alternately, the request scope
could last from the time a request “enters the SCA runtime” until
it is done, but with the clarification that the “SCA Runtime” is
domain-wide. As long as a call is made to another SCA component within
the same domain (irrespective of the binding used) it is part of the same
request scope. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]