2:43 p.m.
I think everyone is probably familiar with the danger of optional
dependencies, and the reason they've been deprecated, but I'll reiterate
it just to make sure nobody has lingering questions about it.
When a service A has an optional dependency on service B, whether or not
that dependency is filled depends not on the simple presence of B, but
also on whether B is installed before A. This is a necessary
consequence of our algorithm, which in turn is what gives us the
performance that we have (which is tied directly to the algorithmic
complexity of the MSC service installation process).
So given that we have to externally control the order of installation,
such that we know B will come before A, there's actually no reason to
even have optional dependencies, since if you already know that B is
missing, you can simply opt to exclude the dependency in the first
place. Optional dependencies merely become a minor convenience, saving
you from having to do one "if" statement, at this point. Yet their mere
presence has resulted in 100% misuse.
So, there is a different preferred strategy. Here's how it is supposed
to work, conceptually.
Imagine I have a subsystem X, which optionally consumes subsystem Y.
The correct time to detect the presence or absence of Y is related to
the lifecycle of the management model data. When X is added to the
model, and that transaction completes, we know that we have X with no Y.
All the services produced on behalf of X would then statically be
aware of this information, and would elide any dependency on Y.
One obvious question with this scheme is: what happens when Y is added,
after the fact? The answer to this question depends on X. X must, in
the same transaction, detect the addition of Y and decide what to do.
Several actions are possible, depending on how X works and how its
dependency on Y works. Options include automatically removing and
rebuilding services with the new dependency, retroactively modifying X
in some way so as to update it without stopping it, or simply ignoring
the addition of Y, using a "reload-required" or similar state to
indicate to the user that the running system is inconsistent with the
stored model.
I know we don't really have any APIs to directly facilitate these
concepts, but this is a part of what the management SPI redesign is all
about. In the new model, one will be able to express optional
dependencies at a resource level rather than a service level.
On 06/03/2014 02:23 PM, Richard Achmatowicz wrote:
Hi
A general question on which services we can assume are available in a
sever configuration and which we cannot.
When installing services, we often need to add in service dependencies.
If a dependency is marked as required and it does not exist, the service
will not start correctly. So, when setting up a service and its
dependencies, if possible, I would like to know which dependencies are
guaranteed to be available and which I may need to optionally check for.
The OPTIONAL flag for dependencies was meant to address this but it now
deprecated as it doesn't work so well when you are unlucky enough to
have your dependency start after your dependent service.
The web profile is intended to be a slimmed down version of the full
profile, and in the case of the EJB subsystem, the spec says that it
need not implement certain EJB feature subsets, among which are
asynchronous method invocations, timer service and remote invocations.
However, our web profile EJB subsystem includes all of these. It is
conceivable that an admin would want to create a slimmed down version of
the EJB subsystem and remove some of these services. All three of these
can be easily removed by deleting configuration elements.
What to do here?
- assume that all subsystems and services defined in the shipped web
profile will be present and no dependency checking is required?
- assume that a certain minimal subset of subsystems and services
defined in the shipped web profile will be present and that an admin may
"turn off" some services, for example the features not part of EJB Lite
and so some form of dependency checking is required? And which services
can we assume are present?
In the case of the EJB subsystem, I would expect that dependencies like
the Remoting system endpoint can be assumed to be present, but the
optional features above and beyond EJB Lite may not be. But this is all
pretty much ad hoc.
Any thoughts?
--
- DML