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


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

"Michael Rowley" <mrowley@bea.com> 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

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