JBossDeveloper

Emanuel Muckenhuber wrote:

 

So a DomainControllerProfile could then be a sub-profile providing the capabilities for a server to act as DomainController?

Either:

DomainControllerSubprofile: A subprofile that describes the capabilities necessary for a server to act as a DomainController.

or

DomainControllerProfile: A profile that includes a subprofile that describes the capabilities necessary for a server to act as a DomainController.

or perhaps both, with the context determining which is used:

DomainControllerSubprofile: A subprofile that describes the capabilities necessary for a server to act as a DomainController.

DomainControllerProfile: A profile that includes a DomainControllerSubprofile.

Note that I use the verb "describes" instead of the "includes" on my earlier wiki definition. This is to be consistent with Scott's verbiage in the "Subprofile" definition.

The one concern I have with those is the bit in Server Manager about "the distribution of deployments from the Domain Controller to the Server instances, and the management of the Installed Image." That has a lot of overlap with the DomainSynchronizer notion. Quite likely they'll end up becoming one thing, but I don't think we are there yet.

The main domain-ish thing I want to do this week is write down in detail the steps for various use cases related to starting servers of various types. There's been a fit amount of discussion around this on #jbossdev; I want to write it up more formally so people can poke holes in something concrete.

Without objection, I'll incorporate Scott's and David's definitions into the document.

Does anyone feel like drafting up an example domain.xml?  We're going to need to present this to a wider audience some time in the next few weeks and I think we'll need an example document. Plus I think an example would be a good base to help us clarify a bit things like how resources, connectors, etc map onto ServerGroups, whether some of templating ideas we've discussed make sense, etc.

The "use cases" document I was talking about is at https://community.jboss.org/docs/DOC-15303. This is still a work in progress, but comments, edits etc are appreciated.

I'm getting into a fair amount of detail on that page; maybe too much; I don't know.

Scott Stark wrote:

 

Some initial work on a collection of xml schema files to codify the notion of the domain metadata model have been uploaded here:

http://community.jboss.org/wiki/JBossASDomainSchema

 

I followed our http://community.jboss.org/wiki/DomainManagementModelDesign for the structure and incorporated some of our existing schemas as a starting point to see how well these would pull together since the domain metadata ultimately needs to map onto this view where it exists.

 

In general, the imported schemas expose too much detail, and there need to be better cross cutting configuration notions for common services such as security, threads, pools, remoting, logging, etc. We need alternate domain admin views similar to what I did with the profiles where it is very much simplified and only focused on the requirements the admin is looking for. There is no notion of deployments at this level.

 

Of course there is a ton of configuration data to add for the various containers as well.

 

I'm handing this off to Alexey, so good luck!

Getting more specific, this raises some questions.

The defined requirements around the domain.xml file are all very vague/general, for example "represents the primary and authoritative representation of the domain" [1] or "focused on the requirements the admin is looking for".  I think it's time that we start getting specific about what the domain.xml needs to be, not just in terms of example schemas or in terms of broad strokes but in detail.

If the domain.xml does, indeed, contain the authoritative representation of the domain, then it does indeed need to contain, directly or indirectly, definitions of all serivces available up to and including the list of active deployments.  For example, as defined in the existing requirements, a deployment can be associated with one or more server groups, which are defined as part of the domain. If the domain doesn't map deployments to server groups, what will?  In addition, adding deployments can very well imply other changes to domain.xml that are necessarily made at the same time.  Everything I see in the requirements says to me that the current deployment listing must be a part of the domain model.

So if you take that as a given, then the question isn't about too much detail in the domain model (which ultimately has to contain every detail, regardless of its relative relevance), it's more about too much detail in the domain.xml file itself, and how can we hide some of the less-likely-to-be-useful detail without crippling the administrators or us poor implementors.

For example, today the thread pool configuration is highly granular.  Many of the things can have reasonable defaults; for example rather than specifying the thread factory for every thread pool, and the thread group for every thread factory, etc. we can have a default thread factory and group, or auto-create one with reasonable parameters which can be overridden in the case where the admin needs finer-grained control.  Many of the quirks of jboss-threads in particular are due to JBossXB and MC, and just following the path of least resistance.

It might be helpful to break it down into categories, and for each category, formalize how it should be represented in the management view versus the domain.xml file.

[1] http://community.jboss.org/wiki/DomainRequirements

David Lloyd wrote:

 

If the domain.xml does, indeed, contain the authoritative representation of the domain, then it does indeed need to contain, directly or indirectly, definitions of all serivces available up to and including the list of active deployments.  For example, as defined in the existing requirements, a deployment can be associated with one or more server groups, which are defined as part of the domain. If the domain doesn't map deployments to server groups, what will?  In addition, adding deployments can very well imply other changes to domain.xml that are necessarily made at the same time.  Everything I see in the requirements says to me that the current deployment listing must be a part of the domain model.

This opens the door to new ideas.  If the domain.xml (including deployment listing) represents the current state of the domain, and server managers (SM) sync this down, why not make it a versioned database?  Then, if a SM comes up after some changes were made on the domain controller (DC), the SM can pull down only the differences, just like database replication.  This is good in the case of a very complex configuration with many deployments (the SM only has to pull down deployments that it needs [as defined by the domain.xml] and that it doesn't already have).  It may also allow something like atomic deployment, where multiple deployment units and/or config changes are deployed as a single unit.  Also, the coolest thing of all would be the ability to revert the whole domain to arbitrary previous states, by simply playing the log backwards.

If the differences prove too great (either in size or in age) to pull in diffs, then the whole state can always be pulled down into the SM.

David Lloyd wrote:

 

So if you take that as a given, then the question isn't about too much detail in the domain model (which ultimately has to contain every detail, regardless of its relative relevance), it's more about too much detail in the domain.xml file itself, and how can we hide some of the less-likely-to-be-useful detail without crippling the administrators or us poor implementors.

Moving away the idea of mixing configuration with XML scripting with ad-hoc management with ad-hoc deployment descriptors will be a big help in this arena.  No service shall be created that doesn't have (a) a management interface and (b) a concise domain.xml representation (directly or indirectly).

What do I mean by an indirect domain.xml representation?  Take for example an EAR deployment.  If you take as given all the crap from my past couple posts, you'd have something like this:

1. An EAR deployment which contains WARs, EJBs, etc.
2. A domain.xml file which includes the EAR listed something like this:

    <!-- ...stuff... -->
    <deployment name="my-deployment.ear" sha1="ab271b2...f58289" serverGroups="foo bar baz"/>

Now the deployment entry in the domain.xml file doesn't list every single EJB, thread pool, socket, web context, listener, etc. that is defined in the deployment.  The deployment has a deterministic, predictible implied mapping to services created as a result of processing the deployment descriptor.  Thus, the domain.xml remains the definitive and complete model of the domain, but it doesn't duplicate any information and it relies on the resources included therein to complete the picture.

In addition, the presence of an EAR deployment in the domain implies that the appropriate subsystems must be made available in order to start the domain.  There is no need to explicitly list the subsystems that we need to kick off in order for the deployments to all work.  However if a subsystem needs special configuration, we certainly can and should support explicity defining those parameters in the domain.

Implementation-wise this implies that the ability to recognize a deployment of a certain type is a separate concern from the code that actually does the deployment.  In addition, even the code that does the deployment might actually be split into concerns - for example we need not pull in and initialize the clustering subsystem if no components are clustered.  We can and should support lazy initialization of subsystems in this way.

This way the idea of profiles is something that happens invisibly to the developer and the administrator.

David Lloyd wrote:

 

In addition, the presence of an EAR deployment in the domain implies that the appropriate subsystems must be made available in order to start the domain.

For example, Imagine the simple case of an EJB deployment.  Making an EJB available remotely would imply that the remoting service is required.  Thus we should have a default configuration which creates the remoting endpoint and adds the EJB service with no

XML, but only when an EJB deployment occurs.  Instead this configuration is implied (in a well-defined, deterministic way) by the node name, the services being deployed, and possibly host-specific mapping of service to IP address.  In today's world, the Remoting Endpoint can't exist (and thus can't be used for built-in services) unless it is explicitly defined.

In the doman model, the definition can be implied, but can be overrideable by way of explicit configuration.  The service need not exist in reality until it is required by a subsystem (like EJB, JNDI, or JSR-160) or user deployment (like a custom user service).