← Prev in month
← Prev in thread
AW: [sca-j] ISSUE 4 - Dependency reinjection
Hi all,
please, let's not go down that "smart proxies" road.
There should be precise description what a service reference instance
represents, since it might be kept, you could have more than one based on the
same ref, and you might even pass it on to some other
component.
I believe the most commonly expected behavior is
that the service reference instance represents a resolved client view to the
wire target of the reference specified when retrieving the service reference
instance. This way, a component has a chance of issueing several calls in
succession to the same target (that, even if stateless, are correlated via some
stored data) - unless that target was removed, taken out of service or went out
of scope for other administrative reasons - in which case an exception
should be thrown.
Every call to ComponentContext.getServiceReference
should return a new service reference instance.
The "convenience feature" of dependency injection
should be driven from a perspective of developer convenience. Since the most
basic approach is to refer to the injected field rather than copying it over to
other members, I believe conversational components should not be subject of
re-injection, as their state will usually be a reflection of an invocation
history with their reference targets (ignoring the additional information
provided via setter injection for the moment).
For the Component Context I find it harder to
identify the best behavior: stable over the life cycle scope of the component or
reflecting the latest wiring situation. Last week I was tending to the former,
but in the meantime I have been convinced that the latter is more appropriate
since it allows the component to chose whether it wants to get the latest
state.
I think... I just repeated the proposal made by
Michael ;-)
Thanks,
Henning
Von: Mike Edwards
[mailto:]
Gesendet: Mittwoch, 5. Dezember 2007
14:57
An: OASIS Java
Betreff: RE: [sca-j] ISSUE 4 -
Dependency reinjection
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:
David Booz
<>
05/12/2007 13:29
To
cc
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:
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
Mike Edwards
<mike_edwards@uk.
ibm.com>
To
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:
David Booz
<>
05/12/2007 02:37
To
-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:
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome
"Michael Rowley"
<>
To
12/04/2007 08:11
David Booz/Poughkeepsie/IBM@IBMUS,
PM
<>
cc
Subject
RE: [sca-j]
ISSUE 4 - Dependency
reinjection
-----Original Message-----
From: David Booz
[mailto:]
Sent: Tuesday, December 04, 2007 3:06
PM
To:
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:
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
<>
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:
"Michael Rowley"
<> 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
← Prev in month
← Prev in thread