RE: [sca-j] ISSUE 4 - Dependency reinjection

[Mike Edwards <mike_edwards@uk.ibm.com>]

Dave,

I don't think the proposal is a hack
- it expresses some capability in a way very familiar to Java
programmers.

I agree that there is still a bigger
problem - see my subsequent posting which muses about the
bigger problem.

Allowing reference reinjection has only
a small connection with the bigger issues.

So, to address the particular issue
you raise here - if a component has a reference and if it
cannot tolerate the loss of that reference
then:

a) you are then establishing a contract
between the component and the wider SCA runtime along
the lines that the runtime cannot undeploy
a target component instance that is "being used" by
this component. This may imply a process
of quiescing the target component when a change is
required, or the ability to run old
and new versions of the target in parallel.  This is part of the
"bigger picture" question.
 It may be indicated by an intent of some kind, although the target
of
the intent is a very curious one - it
is the runtime container of the target service component.  We
haven't got one quite like that, although
it is close to some of the transaction intents.....

b) how do you deal with cases where
the loss is of a service that is external to the SCA domain
over which SCA has no control?  I
suppose "serviceunavailable" fault is the likely response to
this occurrence.  If this is so,
why would things be different for a target service WITHIN the SCA
domain?


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

David Booz <booz@us.ibm.com>

05/12/2007 13:29

To	sca-j@lists.oasis-open.org
cc
Subject	RE: [sca-j] ISSUE 4 - Dependency reinjection

Seems like a hack to me.  And it doesn't address
the larger problem where
the reference suddenly becomes unusable because the target was changed.
This is similar to a referential integrity problem.  The component
wants to
state that it can't tolerate the loss of a valid reference part way through
it's processing.

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
         
             12/05/2007 04:28    
                     
                cc 
             AM        
                     
                     
       
                    
                     
                     
  Subject 
                    
                  RE: [sca-j]
ISSUE 4 - Dependency    
                    
                  reinjection
                     
  
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          





Folks,

Controlling whether reinjection is allowed AT ALL for a component is
relatively simple in
my opinion:

- if a component does not want reference reinjection to occur, ever, then
the implementation
simply declares the reference annotation on a constructor parameter and
does not
provide the reference via either a field or via a setter method.  If
the
reference is only
injectable via the constructor then it can never be changed by the
container.

This simple design choice allows complete control by the developer of the
implementation.


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

                    
                     
                     
          
 David Booz <booz@us.ibm.com>          
                     
             
                    
                     
                     
          
                    
                     
                     
          
 05/12/2007 02:37                
                     
                To 
                    
                     
       sca-j@lists.oasis-open.o 
                    
                     
       rg            
          
                    
                     
                     
       cc 
                    
                     
                     
          
                    
                     
                     
  Subject 
                    
                     
       RE: [sca-j] ISSUE 4 -    
                    
                     
       Dependency reinjection   
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          
                    
                     
                     
          





It's simple, just not well expressed.  I'm wondering if there are
cases
where a component implementation might want to delay or "opt out"
of
re-injection either permanently or temporarily.  There might be cases
where
a particular component implementation really can't tolerate a re-injection.
I was thinking out loud about using concurrency control as a temporary
means to delay re-injection. There are other ways.  Maybe a different
approach like an annotation @AllowsReinjection (or the opposite) is
sufficient.

I understand that what you are proposing is optional for a runtime to
support, but for those runtimes that do support it, each component
implementation might need to have a say in how it works.  Still thinking
out loud....

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
            12/04/2007 08:11    
     David Booz/Poughkeepsie/IBM@IBMUS,
            PM        
               <sca-j@lists.oasis-open.org>
                    
                     
                     
      cc

                    
                     
                     
 Subject
                    
                 RE: [sca-j]
ISSUE 4 - Dependency
                    
                 reinjection











     -----Original Message-----
     From: David Booz [mailto:booz@us.ibm.com]
     Sent: Tuesday, December 04, 2007 3:06 PM
     To: sca-j@lists.oasis-open.org
     Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection

     Michael,

     And tagging on a few more questions:

     1) I presume that the use of setter based injection would
allow for]
     concurrency serialization by the component implementation
so that it
     could:
     stabilize it's use of references.  This brings up an
interesting
     question;:
     is there (or should there be) some linkage between the lifecycle
of
     the
     target service and these references?  Just because
a ref target has
     been
     altered, does not mean that the target service is gone.
 It's the
     lifecycle
     of that target service which will determine how long a reference
     remains
     usable after a wiring change occurs.  Just raising
the question for
     now
     because it will affect all the component's whose references
can't be
     re-injected.

[MR: I’m sorry, but I don’t follow you.]


     2) I'm curious about your introduction of InvalidServiceException.
     We
     already have ServiceUnavailableException.  I think
there's room to
     clarify
     the wording of SUE to make room for ISE..

[MR: I think that a service that has been correctly identified, but isn’t
currently available is quite different from a service that is incorrectly
identified (it isn’t in the logical domain).  As such, I think it
deserves
a different exception.]

     3) +1 to Mike E.

[MR: No objection from me.]

Michael


     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
                    
                     
 "OASIS Java"
                  12/04/2007
10:22          <sca-j@lists.oasis-open.org>
                  AM
     cc

     Subject
                    
                     
 RE: [sca-j] ISSUE 4 -
     Dependency
                    
                     
 reinjection





     Michael,

     Thanks for the proposal.  It is good to have something
concrete as it
     help
     crystallise the
     issues.

     Please help me understand the rationale for treating Composite-scoped
     components
     differently from Conversation scoped components.

     Both types of component have an extended lifecycle.  Both
may easily
     have a
     lifecycle
     that spans changes in configuration that affects their references,
     even
     where those
     references are not conversational and do not in themselves
involve
     some
     extended
     lifetime.  Why is it justified to change references
in the one case
     and not
     allow changes
     in the other case?


     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> wrote
on 29/11/2007 20:19:28:

     >
     > I took an action item to make a more specific proposal
for:
     > dependency reinjection.  Here it is:
     >
     > Reinjection
     > -----------
     >
     > References MAY be reinjected after the initial creation
of a
     > component due to a change in wiring that has occurred
since the
     > component was initialized.  In order for reinjection
to occur, the
     > following MUST be true:
     > - The component MUST be composite-scoped.
     > - The reference MUST use either field-based injection
or setter
     > injection.  References that are injected through
constructor
     > injection MUST NOT be changed.
     > - If the reference has a conversational interface,
then a
     > conversation MUST NOT be active at the time of the
reinjection.
     >
     > If processing in reaction to a change in a reference
is necessary,
     > then setter injection should be used, with code in
the setter
     method
     > that does the proper processing in reaction to a change.
     >
     > Components with any scope other than the composite
scope MUST NOT
     > have references reinjected.  If an operation is
called on a
     > reference where the target of that reference is no
longer valid,
     > then InvalidServiceException MUST be thrown.
     >
     > In cases where changes to a reference are not valid,
the reference
     > as accessed through the component context also MUST
NOT change.
     > More precisely, the ComponentContext.getService() and
     > getServiceReference() methods MUST return the same
reference target
     > as would be accessed through injection.  However,
the
     > ServiceReference that is returned by getServiceReference()
never
     > changes its target.  If the wiring of a composite
component causes
     a
     > reference to be reinjected, any ServiceReference object
that was
     > acquired before the reinjection will still correspond
to the target
     > prior to the change.  If the target service for
a ServiceReference
     > ever becomes invalid, then attempts to call business
methods
     through
     > that ServiceReference MUST throw InvalidServiceException.
     >
     > The rules for reference reinjection also apply to references
with a
     > 0..N or 1..N.  This means that in the cases listed
above where
     > reference reinjection is not allowed, the array or
Collection for
     > the reference MUST NOT change their contents.  In
cases where the
     > contents of a reference collection MAY change, then
for references
     > that use setter injection, the setter method MUST be
called for any
     > change to the contents.  The injected collection
MAY be the same
     > collection object as is currently used by the component,
but with
     > some change to its contents.
     >
     > Michael







     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

---

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