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 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

From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
Sent: Tuesday, 8. January 2008 14:46
To: OASIS Java
Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection


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

> ...
> 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.

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
> 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
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/>

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

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  ;-)
> 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

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