Dave,

I don't think the proposal is a hack - it expresses some capability in a way very familiar to Java programmers.

I agree that there is still a bigger problem - see my subsequent posting which muses about the bigger problem.

Allowing reference reinjection has only a small connection with the bigger issues.

So, to address the particular issue you raise here - if a component has a reference and if it cannot tolerate the loss of that reference then:

a) you are then establishing a contract between the component and the wider SCA runtime along the lines that the runtime cannot undeploy a target component instance that is "being used" by this component. This may imply a process of quiescing the target component when a change is required, or the ability to run old and new versions of the target in parallel. This is part of the "bigger picture" question. It may be indicated by an intent of some kind, although the target of the intent is a very curious one - it is the runtime container of the target service component. We haven't got one quite like that, although it is close to some of the transaction intents.....

b) how do you deal with cases where the loss is of a service that is external to the SCA domain over which SCA has no control? I suppose "serviceunavailable" fault is the likely response to this occurrence. If this is so, why would things be different for a target service WITHIN the SCA 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: mike...@uk.ibm.com

David Booz <bo...@us.ibm.com> To sca...@lists.oasis-open.org cc 05/12/2007 13:29 Subject RE: [sca-j] ISSUE 4 - Dependency reinjection

Seems like a hack to me. And it doesn't address the larger problem where the reference suddenly becomes unusable because the target was changed. This is similar to a referential integrity problem. The component wants to state that it can't tolerate the loss of a valid reference part way through it's processing.

Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:bo...@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome

Mike Edwards <mike_edwards@uk. ibm.com> To sca...@lists.oasis-open.org 12/05/2007 04:28 cc AM Subject RE: [sca-j] ISSUE 4 - Dependency reinjection

Folks,

Controlling whether reinjection is allowed AT ALL for a component is relatively simple in my opinion:

- if a component does not want reference reinjection to occur, ever, then the implementation simply declares the reference annotation on a constructor parameter and does not provide the reference via either a field or via a setter method. If the reference is only injectable via the constructor then it can never be changed by the container.

This simple design choice allows complete control by the developer of the implementation.

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

David Booz <bo...@us.ibm.com>

05/12/2007 02:37 To sca-j@lists.oasis-open.o rg cc

Subject RE: [sca-j] ISSUE 4 - Dependency reinjection

It's simple, just not well expressed. I'm wondering if there are cases where a component implementation might want to delay or "opt out" of re-injection either permanently or temporarily. There might be cases where a particular component implementation really can't tolerate a re-injection. I was thinking out loud about using concurrency control as a temporary means to delay re-injection. There are other ways. Maybe a different approach like an annotation @AllowsReinjection (or the opposite) is sufficient.

I understand that what you are proposing is optional for a runtime to support, but for those runtimes that do support it, each component implementation might need to have a say in how it works. Still thinking out loud....

Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:bo...@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome

"Michael Rowley" <mrow...@bea.com> To 12/04/2007 08:11 David Booz/Poughkeepsie/IBM@IBMUS, PM <sca...@lists.oasis-open.org> cc

Subject RE: [sca-j] ISSUE 4 - Dependency reinjection

-----Original Message----- From: David Booz [mailto:bo...@us.ibm.com] Sent: Tuesday, December 04, 2007 3:06 PM To: sca...@lists.oasis-open.org Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection

Michael,

And tagging on a few more questions:

1) I presume that the use of setter based injection would allow for] concurrency serialization by the component implementation so that it could: stabilize it's use of references. This brings up an interesting question;: is there (or should there be) some linkage between the lifecycle of the target service and these references? Just because a ref target has been altered, does not mean that the target service is gone. It's the lifecycle of that target service which will determine how long a reference remains usable after a wiring change occurs. Just raising the question for now because it will affect all the component's whose references can't be re-injected.

[MR: I'm sorry, but I don't follow you.]

2) I'm curious about your introduction of InvalidServiceException. We already have ServiceUnavailableException. I think there's room to clarify the wording of SUE to make room for ISE..

[MR: I think that a service that has been correctly identified, but isn't currently available is quite different from a service that is incorrectly identified (it isn't in the logical domain). As such, I think it deserves a different exception.]

3) +1 to Mike E.

[MR: No objection from me.]

Michael

Dave Booz STSM, SCA and WebSphere Architecture Co-Chair OASIS SCA-Policy TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:bo...@us.ibm.com http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome

Mike Edwards <mike_edwards@uk. ibm.com> To "OASIS Java" 12/04/2007 10:22 <sca...@lists.oasis-open.org> AM cc

Subject RE: [sca-j] ISSUE 4 - Dependency reinjection

Michael,

Thanks for the proposal. It is good to have something concrete as it help crystallise the issues.

Please help me understand the rationale for treating Composite-scoped components differently from Conversation scoped components.

Both types of component have an extended lifecycle. Both may easily have a lifecycle that spans changes in configuration that affects their references, even where those references are not conversational and do not in themselves involve some extended lifetime. Why is it justified to change references in the one case and not allow changes in the other case?

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

"Michael Rowley" <mrow...@bea.com> wrote on 29/11/2007 20:19:28:

> > I took an action item to make a more specific proposal for: > dependency reinjection. Here it is: > > Reinjection > ----------- > > References MAY be reinjected after the initial creation of a > component due to a change in wiring that has occurred since the > component was initialized. In order for reinjection to occur, the > following MUST be true: > - The component MUST be composite-scoped. > - The reference MUST use either field-based injection or setter > injection. References that are injected through constructor > injection MUST NOT be changed. > - If the reference has a conversational interface, then a > conversation MUST NOT be active at the time of the reinjection. > > If processing in reaction to a change in a reference is necessary, > then setter injection should be used, with code in the setter method > that does the proper processing in reaction to a change. > > Components with any scope other than the composite scope MUST NOT > have references reinjected. If an operation is called on a > reference where the target of that reference is no longer valid, > then InvalidServiceException MUST be thrown. > > In cases where changes to a reference are not valid, the reference > as accessed through the component context also MUST NOT change. > More precisely, the ComponentContext.getService() and > getServiceReference() methods MUST return the same reference target > as would be accessed through injection. However, the > ServiceReference that is returned by getServiceReference() never > changes its target. If the wiring of a composite component causes a > reference to be reinjected, any ServiceReference object that was > acquired before the reinjection will still correspond to the target > prior to the change. If the target service for a ServiceReference > ever becomes invalid, then attempts to call business methods through > that ServiceReference MUST throw InvalidServiceException. > > The rules for reference reinjection also apply to references with a > 0..N or 1..N. This means that in the cases listed above where > reference reinjection is not allowed, the array or Collection for > the reference MUST NOT change their contents. In cases where the > contents of a reference collection MAY change, then for references > that use setter injection, the setter method MUST be called for any > change to the contents. The injected collection MAY be the same > collection object as is currently used by the component, but with > some change to its contents. > > 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

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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