[wildfly-dev] Service assumptions and the web profile

[David M. Lloyd]

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