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.
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.
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
?
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)
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.)
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
.
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) .
- 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
