Peter,
I think I am getting into a discussion
that properly belongs to the Assembly TC.
We need to spell out how the dynamic
aspects of the Domain really work.
Batch deployment is not something I'd
originally considered, but that might be possible.
What we really need to do is to build
a model of the Domain and the operations that
can occur on the domain - and then establish
the implications of those operations on
individual contributions and components.
Issue 4 has been debating part of this, but
without having the full context described
properly. The full context of the Domain needs
to be described in the Assembly spec
and then each implementation type needs to
decide how its facilities relate to
the aspects of the 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:
"Peshev, Peter"
<>
08/01/2008 17:36
To
Mike Edwards/UK/IBM@IBMGB, "OASIS
Java" <>
cc
Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection
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
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
