Peter,
Thanks for taking the time to read my
ramblings - it looks as if you have some of the same concerns that
I have. We need to get the bigger
picture straight in order to have the details correct.
Responses in red
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:
"Peshev, Peter"
<>
07/12/2007 10:29
To
Mike Edwards/UK/IBM@IBMGB, "OASIS
Java" <>
cc
Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection
Hi Mike,
That's very detailed exploring,
thanks for bringing this. A couple of comments
Best Regards
Peter
From: Mike Edwards [mailto:]
Sent: Thursday, 6. December 2007 13:29
To: OASIS Java
Subject: RE: [sca-j] ISSUE 4 - Dependency reinjection
Folks,
We are all rightly worrying about complexity here. On the other hand
we are also thinking about genuinely
useful capabilities.
PP> I personally think that
it's better if everything is simple for
first versions, and then if the standard is accepted and used in practice
to be enhanced by the community with real use cases and requirements.
MJE> +1
I think I'd like to separate this into two different problem areas, which
I think are handled differently:
1) Change to or Removal of a Target service
2) Modification of wiring.
PP> Up to now I was thinking
that bringing a new version of target service
which is exposed on the domain is absolutely the same as changing
a domain level wire.
But maybe you do have a
point, that these are different.
MJE> Just changing wiring
does not necessarily get rid of the original target services
But changing the target
services themselves sure does get rid of the original services.
That is different, in muy
opinion.
For the present, this can ONLY affect connections being made at the SCA
domain level. Anything lower
in the composition hierarchy requires a redeployment of some composite
- and this involves stopping
and restarting something.
1) Change or Removal of a Service
Given the loose coupling implied by SOA, I assume that it is reasonable
for a service component to
be removed or updated at any time. The question is what happens to
any clients of the service:
a) Require all clients to be stopped and restarted too. Could be
a heavy burden for a popular service.
b) Existing client instances continue to use a "preserved copy"
of the old version of the service until all the
client instances have ceased to exist. Could be a problem with long-lived
clients (eg composite scoped)
since this would mean an indeterminate lifecycle for the preserved copy
of the service. Places a burden
of managing multiple versions of a service in parallel.
PP > Some
implementation types may not support two parallel versions living at the
same time.
In addition some protocols and
bindings may not support natively statefull communication, which brings
the problem in case a message comes, which of the two parallel version
needs to be instantiated and given the flow of control.
One additional point to discuss
here is what happens in case the interface of a service changes. Two wsdl-s
for one URI ?
MJE> Yes, this raises
the whole question of what it means to update a service component.
Same URI / new URI? Can
the old and new run in parallel?
It's no use us saying that
the "old wires" can still be used if they are talking with a
new
implementation - the API
might be different, any state will have been lost, etc.
c) Existing client instances either
get "service unavailable" faults or simply use the new version
of the service
on their next invocation (simply by means of calling the same endpoint
address as previously).
Gives the deployer/operator of the system certainty at the expense of causing
failures for the client applications.
I argue that reference reinjection should not take place for any of these
cases. It isn't going to help much.
2) Modification of Wiring.
Let's be clear that modifying wiring can be done in these ways:
a) Change the configuration of the reference
b) If the reference uses autowire, change the potential set of target services
in the domain (through
deployment actions on the services)
c) Where the wiring is expressed through Wire elements deployed separately
from the reference(s)
and those wires are changed or removed.
PP> If we are speaking in assembly
terms, and btw while reading the email I started wondering why such general
discussion is not addressed in the assembly TC, there is also wiredByImpl,
which allows the wiring to de bone dynamically by some API
The Java API-s allow the callback
to be set dynamically via API (and whether the callback is classified as
wire is another discussion)
MJE> This may well become
an Assembly discussion. How is the domain updated?
a) requires redeployment of the client components. I argue that this
cannot involve reinjection.
b) and c) originally required a decision on the part of the assembler/deployer
that the wiring config would
be separate from the client components.
PP> So you are suggesting that
reinjection should occur only when a wire is deployed separately ? If somebody
redeploys a component XXX with service YYY, than all wiring in the format
<reference "target="XXX/YYY" ..> should not
be subject to reinjection even though that may be matching the criterias
(composite scope, etc.)
MJE> If all the wiring
information is on the reference belonging to the client component, then
the ONLY way to change
it is to force a redeployment of the client component with the new
configuration information.
Only if the wiring is separate can it ever be possible to re-inject
an existing component instance.
It is these cases which may involve
reinjection, since the
targets can be changed without redeployment of the clients. One thing
to consider is what is the expectation
of the deployer when the changes are made - will it be too hard for the
deployer to understand that a
change in the wiring configuration does not necessarily take effect for
some (indeterminate) time after
it is made?
Peter's question of whether this type of rewiring should be supported at
all is a good one. The current
specification certainly allows it. The capability of ESBs is also
certainly along these lines (up to and including
dynamic selection of target services for each invocation).
If the client code cannot tolerate changing the target of
a reference by rewiring during component execution,
I think we've identified some approaches by which this may be handled:
i) Simple use of standard coding techniques - ie a reference injected via
constructor can't be reinjected.
Other methods allow for reinjection. Choose the technique suited
to your code.
ii) Use of an intent. This would mark a reference as "non reinjectable"
or rather "not changeable". This
would instruct the runtime not to reinject. Might this intent also
limit the ways in which wiring can be done?
(eg force the use of wires expressed as part of the configuration of the
reference, and prevent the use
of autowire?).
PP> When we are speaking about
ESB-s, the full chain will be - developer \ assembler \ deployer \ administrator
The administrator
will probably be not very much eager to have a look at the source code
in order to understand whether it is a constructor based injection and
whether his\her changes will take into effect. So if we are going to support
reinjection, maybe it's good to have some explicit intent
/ SCDL construct whether "dynamic change" is ok.
It could be that the componentType
generation for java says that constructor based injection maps to this
newly construct .
MJE> Yes, perhaps this
is the right approach. Have an intent.
On the other hand, what
does the administrator do for a client component that says it
does not support reinjection?
Does the admin then have to quiesce or stop all components
of that kind in order to
enforce wiring changes? Perhaps the simple answer is "yes".
I note that an intent is more general than the coding techniques. It
can apply to components written in
any language.
iii) Special handling for wires involving conversational interactions?
Or those involving callbacks?
There have been suggestions that wires involving these types of interactions
can't be changed
(reinjected) during the span of the conversation. Callbacks which
are not conversational are
troubling in that there is no indication of whether a callback is outstanding.
Perhaps this does not
matter in that the callback object will be held in some form by the target
service and will be
unaffected by the change in wiring. However this again implies that
the "old wiring" continues to
have a life after the "new wiring" is deployed.
iv) Limitation of reinjection based on lifecycle scope of the client component.
- No reinjection for stateless components (they are assumed to be "short
lived").
- Reinjection for composite scoped components (they "live forever")
- Uncertainty about conversation scoped components (they "live for
a while") -
reinjection may be desirable for these guys - assuming the preservation
of any
references involving conversations (as discussed in iii).
- so lack of toleration of reinjection requires choosing an appropriate
scope
We expect most components to be stateless, so things there are really simple.
Conversation scope is the next most common - "no reinjection"
is simple to
understand but it has the downside of "old wiring" living for
a potentially
considerable time after it has been replaced.
PP> That is a question which
is also bothering me. The fact that deployer makes a change in the wiring
and practically nothing changes is confusing. Especially since a conversation
may practically not end in reasonable time. (I have seen systems where
statefull session bean had lifetime for days) .
MJE> Yes, this bothers
me a lot. And in a large & complex domain, over a period of
days there could be many
changes to the configuration of the domain and as a result
there might be an unending
chain of "old wiring" configurations hanging around that
have to be tracked at some
level - consider:
A is wired to B...
A is conversation scoped
with no reinjection
wiring is changed: A is
wired to C
Now there will be invocations
of A -> B and also A -> C at the same time depending
on when the conversation
on A started. Looking at this from a management admin
console, this might look
incorrect from the standpoint of the current configuration
of the domain.....
- composite scoped components are a really special case - we don't expect
many of
them, and so special rules don't seem out of place - there are going to
be quite
a few rules anyway, I suspect.
I'm wondering whether a combination of techniques is the way forward here?
Views?
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:
"Peshev, Peter"
<>
06/12/2007 08:37
To
"OASIS Java" <>
cc
Subject
RE: [sca-j] ISSUE 4 - Dependency reinjection
Hi,
First +1 to Dave that reinjection could cause huge problems for unprepared
component, so it makes sense to allow it only if there is some explicit
"I can handle it" annotation
On a more general note, I think reinjection is a big issue, so it's good
if we clarify first what usecase we are solving and what we want to achieve
with that mechanism.
At least to me reinjection becomes relevant, only when the administrator
rewires \ unwires a domain reference. If we want to address the general
problem - administrator changes some of the wiring, why not simply restart
the application (i.e. contribution) which is the source of the wire ? Everything
will be initialized properly afterwards.
One quote, which is one of my favorites and IMO seems relevant
"This group of experts may be able to understand the subtle semantics
of the more esoteric cases, but I worry that the average business programmer
will find some of the advanced features ... more confusing
than beneficial."
And now we are speaking even not about programmers, but about administrator,
who would probably be even less familiar with specs. In addition we are
expecting that this guy will have deep understanding of the application
(what is setter\constructor based injection, whether the scope is composite,
etc.) All that information is even not in the SCDL-s, but at the java source.
Btw, are there any reinjection equivalents in the current java world ?
Some app. servers for example allow EJB reference resolving across two
applications. Does anyone support dynamic rewiring of @EJB via some UI
without redeployment ? Does any vendor offer reinjection of Java
EE resources (env-entries) or some Spring resources in case administrator
wants to change them ?
Peter
From: Blohm, Henning [mailto:]
Sent: Wednesday, 5. December 2007 17:05
To: Mike Edwards; OASIS Java
Subject: 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
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
