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

[Simon Nash <NASH@uk.ibm.com>]

Mike,
I think there is a difference of view on what is the "simpler" approach in 
this situation.

One view of "simpler" is to have the minimum of rules.  So reinjection 
would be allowed with all component types and the component developer 
would have total flexibility.  This means that the component developer is 
responsible for understanding all the implications of making certain 
choices, which could give rise to problems (perhaps of a very subtle 
nature) if used inadvisedly.

It's the last point that bothers me.  We have four different scopes, so if 
each of them allows reinjection or not, this gives 8 combinations.  The 
developer has to understand the implications of all 8 of these.  Some 
combinations may not be useful or may carry subtle pitfalls, but 
developers needs to understand this or may make a wrong choice and get 
themselves into trouble.  SCA doesn't help here, because all options are 
possible, so the developer must rely on best practices articles to provide 
the necessary guidance.  And if it's too hard to decide, they just copy 
what their colleague in the next desk is doing, and hope that their 
circumstances and needs are the same as their colleague's.

The other approach is for SCA to be more prescriptive and to rule out 
certain combinations because they don't make sense or have too many 
pitfalls.  With this approach, SCA would say "These are the 
characteristics of a stateless component; it does this and it does that 
and it can't do the other", and similarly for the other scopes.  The 
combinations of "can do" and "can't do" aren't arbitrary, but would be 
explained by SCA based on how the component is intended to be used.  The 
choices of what to allow would be based on what is required to support 
known real world use cases.  This is the alternate view of "simpler".  If 
the limited choice turns out to be too restrictive and there's some user 
requirement that isn't covered, it's easy enough to relax the restrictions 
later without breaking compatibility.  The converse doesn't apply as it's 
generally not possible to impose restrictions once some functionality has 
been allowed..

    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



Mike Edwards/UK/IBM@IBMGB 
08/01/2008 08:42

To
"OASIS Java" <sca-j@lists.oasis-open.org>
cc

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







Reza, 

I have one specific comment to make here - done inline.... 

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 

"Reza Shafii" <rshafii@bea.com> wrote on 07/01/2008 21:07:32:

> 
> Another option would be to use Mike's idea of a "reinject" parameter on
> @Reference to also derive the behavior of the getServiceReference()
> method. If reinject="true" reinjection should occur and subsequent
> invocations of getServiceReference() would lead to an object referencing
> the new target.  If reinject="false", reinjection should not occur and
> subsequent invocations of getServiceReference() would lead to the target
> prior to rewiring. 
> 
> I am also thinking that the reinject=true value would only be valid if
> the conditions previously discussed apply (i.e. scope is composite,
> conversational interfaces must not be active, and the reference is field
> based or setter based). This would change the table as attached. 

This was NOT my proposal. 

My proposal is that IF reinject=true is set, then reinjection occurs for 
ANY 
scope of component.  My thinking here is that, since by default no 
reinjection 
occurs, and that the programmer has to do something active to get 
reinjection 
to occur, then it is reasonable to allow reinjection for any and all 
scopes 
- at the request of the programmer.  This gets rid of those rules that you 

list above. 

The thinking here is that IF you care about reinjection, then you will 
take 
the trouble to think through what it means to change the reference you are 

using (or perhaps, writers of material about SCA will take the trouble to 
tell you....). 


> 
> Cheers,
> 
> Reza





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