HI Mike,
So in a way you are suggesting something like a
transactional (batched) deployment -- several deployment are grouped
and constraints are checked at the end, and everything is rolled back if there
is failure. Is that so ?
That looks like an interesting
idea.
Do you have in mind how an assembler \ developer
would signal the grouping of the deployment units ? Perhaps via
some data in sca-contribution.xml ?
Best Regards
Peter
From: Mike Edwards
[mailto:]
Sent: Tuesday, 8. January 2008
14:46
To: OASIS Java
Subject: RE: [sca-j] ISSUE 4 -
Dependency reinjection
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:
"Peshev, Peter"
<> 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:]
> 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:
>
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
