OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Yes.  That's part of my point.  Today's conversation is a constrained
session concept, between two parties, not a very useful session concept
because it requires business logic to tie conversations together into the
larger notion of a session.

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


                                                                           
             Simon Nash                                                    
             <NASH@uk.ibm.com>                                             
                                                                        To 
             03/19/2008 06:59          sca-j@lists.oasis-open.org          
             AM                                                         cc 
                                                                           
                                                                   Subject 
                                       RE: [sca-j] ISSUE 21 - Clarify      
                                       Request Scope lifetime              
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





Dave,
I always thought that SCA's conversation was the equivalent of a session.
If we are going to invent a session concept as well, we need to think very
carefully about the relationship between these.

    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999

                                                                           
 David Booz <booz@us.ibm.com>                                              
                                                                           
                                                                           
 18/03/2008 14:00                                                       To 
                                              sca-j@lists.oasis-open.org   
                                                                        cc 
                                                                           
                                                                   Subject 
                                              RE: [sca-j] ISSUE 21 -       
                                              Clarify Request Scope        
                                              lifetime                     
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





+1 to dropping request scope.

...with a word of caution.  We have not yet created constraints in the
assembly model which force developers/architects to place boundaries on
composites (with the exception of  composites that are used as
implementations).  Any semantic which can only be obtained through
collocation of components in a composite will turn out to be overly
constraining as it will force developers and assemblers to aggregate
components which otherwise might not need to be aggregated.

I would hope that we could explore these new ideas from the perspective of
a session concept, and I mean session in a generic form.  I would also hope
that we could avoid the temptation to tie this semantic too tightly with
composites.  I'm thinking about components which cooperate to provide
coarse grained business services with some shared runtime context called a
session.  We will have to debate how much of the session is visible to the
business logic.  We will have to debate system managed vs. application
managed session correlation.  Other technologies have been here.  WS RM has
this idea baked into it.  CORBA has activity session.


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



            Mike Edwards
            <mike_edwards@uk.
            ibm.com>                                                   To
                                      sca-j@lists.oasis-open.org
            03/17/2008 08:59                                           cc
            AM
                                                                  Subject
                                      RE: [sca-j] ISSUE 21 - Clarify
                                      Request Scope lifetime











Michael,

Yes, I'm OK with the idea of dropping request scope.

The conversation propagation idea is interesting - possibly it is part of a
wider consideration of sets
of components within a composite acting in a coordinated or unified way,
that may apply to a number
of things beyond conversations.

Perhaps this is going to turn into some mechanics that apply to composites
as a whole.  Intents at the
composite level that are meaningful to the composite itself -and which has
specific implications on the
components within the composite.  An example might be the idea that all
conversations between
components within the composite are shared.


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:  mike_edwards@uk.ibm.com


"Michael Rowley"
<mrowley@bea.com>

                                                                       To
13/03/2008 18:31                           Mike Edwards/UK/IBM@IBMGB,
                                           <sca-j@lists.oasis-open.org>
                                                                       cc

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












Mike,

You are absolutely right.  The resolution was only w.r.t. java components.

Given that, I will agree with Dave B that in this case the
conversation-propagation idea is a little bit different from request scope
semantics.  Nonetheless, I think it would be close enough to warrant
getting rid of the request scope.

Michael




From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Thursday, March 13, 2008 10:44 AM
To: sca-j@lists.oasis-open.org
Subject: RE: [sca-j] ISSUE 21 - Clarify Request Scope lifetime


Folks,

Unless I've got the wrong end of the stick here, I think that the SCA Java
TC is acting ultra vires.

Dave posed a question about a composite exposing two services, one
conversational one non,
conversational.

Michael responded saying that the Java F2F decided that a component cannot
offer both a
conversational and non-conversational service.

Now, I can agree that the SCA Java TC decided that a Java implementation
could not offer both a
conversational and a non-conversational service.  However, to extend this
idea to apply to all
components, using whatever implementation type, I think must be a decision
of the SCA Assembly
TC.

If the Java TC really wants to limit ALL components to only expose either
conversational or non conversational
services, but never both, then I think the TC must get an appropriate issue
raised in the Assembly TC. I suspect
that the other C&I TCs would need to be consulted also.


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:  mike_edwards@uk.ibm.com



"Michael Rowley"
<mrowley@bea.com>

                                                                       To
13/03/2008 14:30                          "David Booz" <booz@us.ibm.com>,
                                          <sca-j@lists.oasis-open.org>
                                                                       cc

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


















At the F2F we resolved that a component is not allowed to offer both a
conversational and non-conversational service.

Michael

-----Original Message-----
From: David Booz [mailto:booz@us.ibm.com]
Sent: Wednesday, March 12, 2008 10:35 PM
To: sca-j@lists.oasis-open.org
Subject: RE: [sca-j] ISSUE 21 - Clarify Request Scope lifetime

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.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php









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











---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php









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












[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]