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...@uk.ibm.com

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

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

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

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