[wildfly-dev] Service assumptions and the web profile

[Brian Stansberry]

On 6/3/14, 2:43 PM, David M. Lloyd wrote:
> 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.

A bit more than that though, as it's really

if (readModelFromOtherSubystemToSeeIfFooIsSet(...))

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

This should be done in the OperationStepHandler that adds the service, 
in Stage.RUNTIME. In Stage.RUNTIME you know that all changes that will 
be made to the model during the current transaction are present, even 
during boot when we do a lot of work concurrently.

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

Jeff Mesnil -- I'm curious how useful the internal notification stuff 
you've added in the existing code will be for this use case. Prior to 
that there was nothing at all that X could count on to become aware of 
the later addition Y.

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


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat