Simon,
Yes, you're right - I had a small brainstorm
when making my original comments about getService()
- I think that getService and getServiceReference()
must be identical in terms of the reference wiring
they return - and I agree that they
should always return the latest wiring.
If a component wants to continue using
the "old wiring", then what the component must do is to store
the reference proxy for the original
wiring somewhere and continue to use it when invoking operations.
The proxy should be guaranteed not to
change in terms of its wiring - the wiring may be invalidated
(at the choice of the runtime - meaning
that subsequent invocations fail with an exception) but
it cannot be changed silently "under
the covers" to point to somwhere new.
My thought is then to allow reinjection
of a reference via a setter method for any scope
of component
where the component marks the reference
with reinject="true". The calling of the
setter method then
acts as a signal to the component that
the wiring has changed, along with a new reference proxy that
represents the new wiring. The
component can decide whether or not to use the new reference proxy
at its own choosing.
Note that I am now thinking that reinjection
of a Field is not a good idea - there is no easy way for the
component to know that the change has
taken place.
If the component uses the alternative
approach of using getService() or getServiceReference(), then the
component needs to be made aware of
the fact that it may get back different reference proxy objects for
each subsequent invocation - and these
may represent different wiring. To avoid unexpected changes,
the component should store and use the
returned proxy. The returned proxy always reflects the "current"
Domain configuration at the time the
method is invoked.
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:
Simon Nash/UK/IBM@IBMGB
09/01/2008 12:18
To
"OASIS Java" <>
cc
Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection
Mike,
The getService() method is defined as follows:
getService(Class<B> businessInterface, String referenceName)
? Returns
a proxy for the reference defined by the current component.
This could be afftected by rewiring without redeployment.
The comments from various folks including Reza, Henning, Dave and Mike
are making me think that the only consistent way to handle API calls is
to
make them always use the most current wiring (except for cast, which
operates on an existing proxy). This would change the top right box
of
Reza's table.
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
09/01/2008 10:45
To
"OASIS Java" <>
cc
Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection
Dave,
Some of these literally can't occur, in my opinion - details follow.
Basically, my view is that if a component gets redeployed (ie original
configuration is undeployed
and a new configuration is deployed), then this is something completely
new - there is no question
of "updating" any instances of components of the old configuration.
I suppose there is a question of whether the pre-existing component
instances are allowed to remain
in existence when a redeployment of this kind takes place. I'm prepared
to punt on this for now and
leave it up to the runtime.
For me, redeployment of a component never creates reinjection of the
component instances belonging
to the old configuration.
Note that this is different from the case of references - as I pointed
out
previously, the wiring and the
target service(s) of a reference can change WITHOUT redeployment of the
component itself. In this
case, redeployment can occur either on separately deployed wire elements
and/or on target components
that are separately deployed. So there are special measures required
in
these cases, which is what we
have been debating.
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 <>
08/01/2008 20:46
To
cc
Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection
This thread is wandering around on various topics. I explicitly picked
this part of the thread to make an additional point.
The proposal needs to consider all the APIs:
(a) getURI() - A deployment change could affect what is returned
<mje> This can only happen with a redeployment, I think. </mje>
(b) getService() - Wiring could affect what is returned here
<mje> I'm not sure what changes you're implying here. Typically,
IF
wiring is deployed
separately from the component, then it CAN'T affect the service. It
CAN
affect reference
targets.</mje>
(c) createSelfReference() - A deployment change to the component itself
could affect what's returned here
<mje> Clearly, this is a redeployment of the component itself </mje>
(d) getProperty() - I don't know why we're limiting the re-injection issue
to references
<mje> Properties can only get changed if the component, or its containing
composite, is
itself redeployed.
</mje>
It is not wise to have some of the CC API's expose wiring or deployment
changes, but not others.
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
Simon Nash
<>
To
01/07/2008 01:48
"OASIS Java"
PM
<>
cc
Subject
RE: [sca-j]
ISSUE 4 - Dependency
reinjection
Reza,
My first thought was to propose what you have said. My second thought
was
that if an existing instance has not had the new target reinjected, it
could produce confusing results if calls to the reference using
ComponentContext.getServiceReference() use a target that's different from
any target currently known to the instance or available by other means.
I'll be interested to hear whether others think my first thought or second
thought was better.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
"Reza Shafii" <>
07/01/2008 17:23
To
Simon Nash/UK/IBM@IBMGB, "OASIS Java" <>
cc
Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection
Thanks Simon,
Along the same line of thought, shouldn't the effect of a "change
to the
target reference" on "subsequent invocations of getServiceReference()"
be a reference to the new target no matter whether reinjection has
occurred or not?
Cheers...
Reza
-----Original Message-----
From: Simon Nash [mailto:]
Sent: Monday, January 07, 2008 4:59 AM
To: OASIS Java
Subject: Re: [sca-j] ISSUE 4 - Dependency reinjection
Reza,
This table is very helpful. I have one comment. In the third
column,
you
have equated getServiceReference() and cast(). I don't think these
are
equivalent. getServiceReference() is obtaining a new reference, in
which
case I think the current wiring and target service should be used.
cast()
is converting an existing proxy to a ServiceReference, and I think the
semantics for this should match the semantics of using the proxy.
Here's
my attempt to capture this in tabular form.
Effect on
Change Event
Reference
Existing ServiceReference Object
Subsequent Invocations of ComponentContext.cast()
Subsequent Invocations of ComponentContext.
getServiceReference()
Change to the Target of a Reference
MAY be reinjected (if other conditions apply).
If not reinjected, then it MUST continue to work as if the reference
target was not changed.
MUST continue to work as if the reference target was not changed.
Result corresponds to the injected
reference (i.e. changed only if
reinjection occurred).
Result corresponds to the injected
reference (i.e. changed only if
reinjection occurred).
Targeted Service Undeployed
Target Service becomes Unavailable
Business methods SHOULD throw InvalidServiceException.
Business methods SHOULD throw InvalidServiceException.
Result SHOULD be a reference to the undeployed or unavailable service.
Business methods SHOULD throw InvalidServiceException.
Result SHOULD be a reference to the undeployed or unavailable service.
Business methods SHOULD throw InvalidServiceException.
Targeted Service Changed
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
Result SHOULD be a reference to the changed service.
Mike,
I don't agree that re-injection should be supported for all scopes. (I
presume you are proposing that if a runtime supports it at all, then it
must be supported for all scopes.) Locating and updating existing
short-lived instances when rewiring occurs would impose runtime
overheads
without providing useful value. The annotation is an interesting
idea,
but I think it should be additive to the scope restrictions already
agreed.
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
07/01/2008 09:27
To
"OASIS Java" <>
cc
Subject
Re: [sca-j] ISSUE 4 - Dependency reinjection
Reza,
This is a good contribution to settling this item of work.
I suggest one addition to the table - "Target Service Undeployed"
is OK
for services within the SCA Domain - to deal with services elsewhere,
"Target Service becomes Unavailable" is a better description
(we don't
know anything about HOW it became unavailable), but the effects are the
same.
Effect on
Change Event
Reference
Existing ServiceReference Object
Subsequent Invocations of ComponentContext.
getServiceReference() or
cast()
Change to the Target of a Reference
MAY be reinjected (if other conditions apply).
If not reinjected, then it MUST continue to work as if the reference
target was not changed.
MUST continue to work as if the reference target was not changed.
Result corresponds to the injected
reference (i.e. changed only if
reinjection occurred).
Targeted Service Undeployed
Target Service becomes Unavailable
Business methods SHOULD throw InvalidServiceException.
Business methods SHOULD throw InvalidServiceException.
Result SHOULD be a reference to the undeployed service. Business methods
SHOULD throw InvalidServiceException.
Targeted Service Changed
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
MAY continue to work, depending on the runtime and the type of change
that
was made. If it doesn't work, the exception thrown will depend on the
runtime and the cause of the failure.
Result SHOULD be a reference to the changed service.
Now, I'd like to propose the following, which I realize changes some of
the decisions we made previously, but I am getting concerned about
complexity:
1. No reinjection of references occurs by default for any component of
any
scope
2. Any component of any scope can declare that it requires reinjection.
My
suggestion is to provide a parameter to the @Reference
annotation reinject="true", which only has meaning for References
which
are a) Fields b) accessible via a setter method (ie it cannot apply to
a
reference injected via the constructor).
This I believe is much simpler and it gives the component writer a
chance
to decide for themselves whether they want to be concerned about
wiring changes occurring dynamically during the lifetime of a component.
It will also make it simpler for us to give a good description of the
kinds of circumstance in which it might be good to react to wiring
changes.
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:
"Reza Shafii" <>
04/01/2008 22:19
To
<>
cc
Subject
[sca-j] ISSUE 4 - Dependency reinjection
Hi All,
In an effort to try to put more structure around a potential solution to
issue 4, Michael and I put together the attached table. Most of the
content is derived from conlusions reached by the TC's past discussions.
A
matrix such as this might help us better focus future discussions.
Looking forward to your feedback,
Reza
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
and affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by
email and then delete it.[attachment "Dynamic Modification Behavior.xls"
deleted by Mike Edwards/UK/IBM]
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
and affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by
email and then delete it.
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
