RE: [sca-j] ISSUE 21 - Clarify Request Scope lifetime

[David Booz <booz@us.ibm.com>]

What if the composite exposes two services, one conversational and one
non-conversational?  Would the conversational service act as in 3 and the
non-conversational service as in 4?  That's not clear from your text.
While it seems desireable to be able to answer yes to the second question,
I'll observe that it means that components in that composite will run
differently (different context) depending on the inbound service.  This is
another divergence from request scope.

...and while I have your attention...regrets for the call tomorrow.

Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome


                                                                           
             "Michael Rowley"                                              
             <mrowley@bea.com>                                             
                                                                        To 
             03/12/2008 10:14          "Barack, Ron" <ron.barack@sap.com>, 
             PM                        "OASIS Java"                        
                                       <sca-j@lists.oasis-open.org>        
                                                                        cc 
                                                                           
                                                                   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]
      Sent: Thursday, January 31, 2008 11:26 AM
      To: OASIS Java
      Subject: [sca-j] ISSUE 21 - Clarify Request Scope lifetime

      http://www.osoa.org/jira/browse/JAVA-21


      Von:: Michael Rowley [mailto:mrowley@bea.com]
      Gesendet: Montag, 21. Januar 2008 21:24
      An: OASIS Java.
      Betreff: [sca-j] NEW ISSUE: Clarify Request Scope lifetime

      RAISER: Michael Rowley

      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.