Folks,
OK, it looks as if it might be wise
to treat "extended lifecycle" components in the same way
and allow reinjection for those cases.
Taking a step back, I am asking myself
the question of the relationship of the SCA Domain
configuration to the reference instances
present in a component instance.
In the current discussions, it is clear
that there is a separation between the SCA Domain
configuration and the reference instances.
Changing the SCA Domain configuration,
in terms of wiring, has zero impact
on the current set of reference instances. The references
(and their implied wiring) are unchanged
by a change to the Domain configuration. The
references still point to valid endpoints
(the old ones) and they work if invoked.
Only new component instances and their
associated new reference instances are guaranteed
to reflect the new configuration of
the SCA Domain. (Reinjection may or may not actually
change the reference instances used
by a component).
This may not be true for other changes
to the SCA Domain configuration. If the target service
of a reference instance is removed,
through changes to the SCA Domain configuration, then
that reference instance is now "invalid"
in the sense that if invoked, the invoker will get an error.
Now, what bothers me is the lack of
consistency for different changes to the Domain configuration.
Some changes potentially never get actioned
- think of changing the wiring from some composite
scoped component - there is no guarantee
that the target ever actually changes, unless the
component is "stopped and restarted".
Other changes such as removing a target service component
have an "instant" effect.
I suppose that this COULD be left as
something to be decided by the SCA runtime implementers.
For example, a runtime might provide
a facility to immediately invalidate references made
"stale" by changes to the
domain. Another alternative might be to supply "smart proxies"
for
references that get their target services
updated "on the fly" without ever troubling the component
instances that use them. Or combinations
of these facilities.... Perhaps these are QoS aspects
of the runtime itself - ie there may
be variable levels of configuration control.
Perhaps a simpler view of the whole
situation is as follows:
- let the developer of a component decide
whether reinjection of a reference is acceptable or not.
Reinjection is allowed if the component
declares the reference as a Field or on a Setter method.
Reinjection is not allowed if the reference
is declared on a construction parameter.
- let the runtime decide at what time
and in what circumstances changes to the domain configuration
are reflected in reinjection of reference
instances and/or updating of reference "smart proxies"
- the one case that still troubles me
are references involving a conversational interface. Clearly
here, if there is a conversation in
full flow between the reference and the target service, then any
change will disrupt the conversation.
The extreme case of the target service being removed
I suppose CAN be treated in the same
way as a failure of the target service (eg it crashes)
("serviceunavailable" fault),
the alternative might be some kind of "soft" quiescence of the
service
- ie no new conversations may be started,
but the existing ones continue until complete. This
may or may not be practical depending
on whether the target service is being upgraded, for
example, rather than simply removed.
- I have now strayed into a different
and complex area - versioning of services. That is a debate
for another day.
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:
"Michael Rowley" <>
wrote on 05/12/2007 01:07:45:
>
> The rationale is to keep the number of components
that have to deal
> with the complexity of references changing in the middle of their
> lifetime to a minimum. Since I think that composite-scoped
> components live indefinitely, it is especially important that they
> handle reinjection. Conversation-scoped components are likely
not
> to live much more than a few weeks (IMO), so a runtime could change
> over the wire target only as conversational-scoped components go outof
scope.
>
> That was the rationale, although after writing
this I had second
> thoughts, for exactly the reasons you mention. I could easily
> imagine allowing reinjection for both composite and conversational
> scoped components.
>
> Michael
>
>
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
