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

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

Peter,

A couple of comments...

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

"Peshev, Peter" <peter.peshev@sap.com>
wrote on 08/01/2008 11:57:25:

> HI Mike,
>  
> That's very interesting question. I think for
that use case 
> injecting a dead reference (or invalidating somehow the old working
> reference) is more consistent with the resolution that was made as
> ASSEMBLY-6 :
>  
> ...
> A reference with multiplicity  1..1 or 1..n MUST have at least
one 
> target service defined. 
> 
> Where it is detected that the above rules have been violated, either
> at deployment 
> or at execution time, an SCA Runtime MUST generate an error no later
than 
> when the reference is invoked by the component implementation. 
>  
> So that would lead to having "dead references"
and saying that the 
> "null representation" rule is not applied for domain level
wires.
<mje>
If you support a dynamic,
changing configuration, then it may only be possible to
detect the violation at
invocation time, particularly for long-lived components.

Not starting the component
because all its references are not yet there does not
seem very practical to
me, although that is one possible approach.  On the other
hand subsequent changes
to the wiring could cause the reference to become
null - and you are then
left with an equivalent problem
</mje>
>  
>  
> Btw, another way of thinking would be to require
from the deployment
> tooling to detect such invalid deployment operations that lead to
> unwired references with multiplicity 1 and reject them. 
> I.e. a good implementation could show a dialog
- " You are trying to
> undeploy a wire from A to B, however component A is using the wire
> with multiplicity 1 and the operation can not be performed, do you
want to 
>   
> - undeploy A as well 
> - abort undeployment.
> - redeploy A with changed multiplicity to 0
<mje>
Well, yes, you *could*
do this, but perhaps the implications are disturbing:

- what happens if you force
undeployment? - either you kill a set of components
"mid flight",
with unknown consequences, or you have to  quiesce them, being
prepared to wait an unknown
amount of time for their current processing to end.

- what does "redeploy
A with changed multiplicity to 0" mean?  I inject a null to
any components that accept
reinjection?

This is forcing me to think
more deeply about the deployment process.  We have
indicated previously a
need to deploy contributions separately - and this includes
"wiring" that
is separate from references (autowire and the separate <wire/>
elements).

We envisaged the possibility
that a reference might be initially deployed
unwired and that a separate
contribution, deployed later, would be necessary to
complete the wiring.  Equally,
if this is the case, then an undeployment operation
on the contribution(s)
providing the wiring would clearly have the potential to
leave the reference "unwired".

The difference between
the initial deployment operation and the ones that
occur later is that, on
the initial deployment we have the luxury of being able to
prevent instantiation of
the components with references that are unwired.  We
can't do this for later
configuration changes once some component instances are 
already in existence.

We could avoid some pain
by having "combined" deployment operations that
involve undeploying some
contribution(s) at the same time as deploying some
new contribution(s) (a
kind of update process) - by treating them as a single
overall operation, this
would possibly avoid an "intermediate" state where some
references are "unwired".

This might lead to a set
of rules along these lines:

1) On initial deployment,
(1..x) references can be unwired, but in these circumstances
the components cannot be
instantiated BEFORE the references get wired (by subsequent
deployment actions). (0..x)
references get given NULL values in this case.

2) Subsequent deployment
operations cannot cause (1..x) references to become
unwired.  The reference
wires may be updated.  Updates can be received by the
related components through
reinjection, but never is a (1..x) reference injected with
a null value.  (0..x)
references can become unwired and a reinjection can inject
a null reference for these
references.

3) Reference objects always
point to the original target service defined by the reference
wiring at the point at
which the reference object was injected or retrieved (from the context).
A reference object can
continue to be used by a component even after wiring changes and 
even after reinjection
of a new reference object takes place.  Where the target of the
reference object has been
removed (ie service no longer running) then the reference object
will generate a ServiceUnavailable
exception when any of its business methods are
invoked.


Sorry that this has got
so long - I think there is a need to start building a document with
all this in it.  This
smells of being an Assembly TC document  ;-)
</mje>
>  
> Just thinking aloud.
>  
> Best Regards
> Peter
> 
> From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] 
> Sent: Tuesday, 8. January 2008 12:22
> To: OASIS Java
> Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection

> 
> Peter, 
> 
> I'd be happy keeping the use of null for unwired references for 0..x
> multiplicity cases.  This gives the implementation 
> code a very simple way of checking whether the reference is wired
or
> not.  Note in your table below, reinjection 
> may give a null reference, an empty collection or simply a reduced
> size collection (for 0..n cases with multiple 
> targets present). 
> 
> The more interesting question is what to do in the case of 1..x 
> multiplicity cases where the wiring is supplied "externally"
> - ie not in the direct configuration of the reference itself, at 
> domain level.  So, I'm thinking of 
> 
> a) reference is marked with autowire & targets arrive from other
contributions
> b) reference is wired with explicit <wire/> elements supplied
in a 
> separate contribution 
> 
> If the multiplicity constraints are not honoured at some time, what
> is supposed to happen?  Is it valid to inject a null 
> reference object in this case?  If not, what DOES the runtime
inject
> when the wiring changes so that there is no wire 
> present any longer..... 
> 
> I don't have a clear view of this at the moment.  The consistent
> thing to do is to inject a null reference.  However, for 
> a component declaring the reference 1..x, this should not happen.
 
> An alternative is to inject a "dead" reference - 
> one which can only ever generate an exception if any of its business
> methods are invoked. 
> 
> 
> 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 
>

---

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