This document is meant to facilitate discussion of the design of the AS 7 domain management features. More specifically, it is a list of requirements for those features. The intent is not to focus on how those requirements are realized; see other documents such as the Domain Management Model Design wiki for that. It is helpful to familiarize yourself with the definitions in that wiki, as the requirements below often use those terms.

At this point these requirements are organized

1. A domain is a management policy that applies to one or more servers/nodes, which may or may not be part of a cluster
2. The primary and  authoritative representation of the domain, the domain model,  will be stored in the domain.xml file.
3. All changes made to the in-memory model must be written to the domain.xml file
4. Various client interfaces to the domain will also be  provided including    
   • JON/JOPR
   • Java based management API
   • AS Admin Console
   • CLI tool
5. All client interfaces must be able to view the complete logical domain model representation
6. All client interfaces must also be able to view non-classified components, those which are not part of the domain but instead come from deployments or legacy management mechanisms.
7. The domain model always takes precedence over deployment specified resources/components.
8. It must be clear in all client interfaces which actions:
   1. affect the domain model
   2. affect components associated with the domain model but not the domain model itself (e.g. an obscure property exposed via a component's managment interface that isn't part of the domain model).
   3. affect non-classified components
9. Deployment of applications will only take place at the Server Group, and Cluster level, as well as being able to be a part of an Action Group.
10. We will support configuration changes that are made one time, that apply to the entire Server Group or Cluster.
11. Run-time configuration changes can be applied without restarting the server, if its defined in the API for that component.
12. We will have three main startup modes:
    1. Stand alone - single private domain, intended for the developer case, and would have the default EE set of services available after startup.
    2. Domain controller - server that runs the domain controller profile.
       1. No consideration of HA for the domain controller.
    3. Domain member - a server that gets its profile from a domain controller.
13. Domain configuration information will be allowed to be hand edited only with the server down.
14. We will have a "server/lib" profile. (Comment: let's disambiguate the term 'profile'. What's discussed here is an element in the overall set of capabilities a server is running.)
    1. This handles the case of things like JDBC drivers, and third party libraries for applications, that are provided by the customer, and not provided by us.
15. At the server group level we would have the ability to keep each InstalledImage in sync with the MasterRepository, or not.
    1. If synchronization is turned off, the customers provisioning scripts/tools, etc. would be responsible for keeping all the InstalledImages in the server group in sync.
    2. When a server joins a server group/cluster, end user applications and "server/lib" would be kept in sync, if syncing is turned on.
       1. We still need to isolate end user jars from our jars in the "server/lib" profile.  This must encompass all end user provided content.
       2. What about all the binaries, and configuration files?
          1. Yes, these should have an index, with hashes, etc., and be synced as a server joins a server group/cluster.
16. We will allow dynamic addition of a server to a domain/server group/cluster, etc.
    1. The domain controller will have a setting that will either allow this or not.
    2. The options for when you don't allow the dynamic addition of the server would be:
       1. Die (server is shutdown).
       2. Put in stand-by mode, without starting any services, until an administrator has added the server to the domain.
17. A server will always be in a server group.
    1. This may be a one-to-one relationship.
18. The domain controller will always have the complete list of services that are possible to be started.
19. A server group will also contain the full list of services, but with only certain services enabled, unless of course it requires all the services, then all of them would be enabled.
20. Maven, Ant, JBoss Tools/JDBS deployment scenarios all need to continue to function as they do today, from a user point of view.
21. The following elements need to be configurable at the server level
    1. Logging levels (default can be pulled from group)
    2. JVM Parameters (default can be pulled from group)
    3. System properties (default can be pulled from group)
    4. Pool sizes [Thread,DB, etc] (default can be pulled from group)
    5. IP addresses
22. When the domain controller is down the servers in the group or cluster will continue to work, but no administration will be possible until the domain controller becomes available.
    1. HA solution TBD (could be as simple as telling the customer to use a monitoring process that restarts if it fails, like watchdog, or if they have solutions like Tivoli, HP OpenView, they provide those functions).
    2. The requirement here, is that we need to be able to create a new domain controller to replace the current one, and have all the servers within the domain, understand where the new domain controller is.
23. When a server starts, and cannot contact the domain controller, then the following applies:
    1. Start with the last known state, but log a BIG warning!.
    2. Don't start, because there may have been administration changes that would mean the last known state (synchronization) could be incorrect for the server group/cluster.
    3. Don't start and you know that a synchronization operation has failed as the last operation.
    4. You shouldn't be able to start if you have never joined a domain to begin with.
       1. Obviously, doesn't include the developer case with a private domain.
24. We will need an "agent" or "server manager host controller" or "domain slave", call it what you will, that the domain controller will talk to it.
    1. The "agent" will need to be local to the server (may be a one to one relationship, if every server is on its own OS instance, or may be one to many if there are many servers on one OS instance).
    2. We must have one "agent", regardless of whether the customer is using JON or not, or has multiple products or not.
       1. This may not be possible in the case where we have multiple version families deployed in one customer environment.
25. We will have a REST interface for management.
    1. May not cover the entire management API, but will evolve.
26. The profile server API will be the programmatic API (Java).
27. The REST interface will be the basis for the CLI (it sits on top of it).
28. We must have a domain controller API.
    1. This is also part of the programmatic API.
29. Changes to the profile service API do not have to be backward compatible, since only JON and the Admin Console are the current users.
30. We will expose selected management capabilities through JMX, but not everything.
    1. Exactly what this would be is TBD
    2. There are quite of few projects that have exposed their management interface through JMX.
       1. So, we will need to add profile service support, via wrapper over their internal management API.
31. Projects must have an internal management API, and not be directly dependent on JMX for their management API.
32. Projects must maintain a profile service management API wrapper over their internal management API.
    1. This is an integration requirement.
33. We will not have a management capability for the old "pruned" or "deprecated" parts of EE 6.
34. We need to have the ability to have a profile generator.
    1. Post install, can use the services in the domain model, with dependency information to allow users to create their own profile, that will actually work.
    2. This gives formal support to what customers do with "slimming" today.
35. We need to be able to manage all the network request paths:
    1. JMS
    2. HTTP
    3. IIOP
    4. Remoting
36. It shall be possible within domain.xml to specify what capabilities/subsystems are allowed (whitelist) or disallowed (blacklist) in order to ensure that undesired subsystems are not inadvertently started causing unexpected performance penalties.
37. Domain subsystems and extensions are the recommended SPI for adding custom configuration driven services. Legacy models, such as single xml file deployments, will be deferred until community demand drives a particular solution
38. Domain Controller is just a Server Manager Host Controller running in "master" mode  (one less JVM)
39. Admin console will run in a Server instance, with a possible many-to-one relationship to the "controller"
40. The Standalone class will be renamed to ServerModel to avoid confusion with the "standalone" use case
41. Domain and Standalone will not share bootstrap as they are fundamentally different (AbstractServer bytes the dust)
42. Statistics will be associated with the domain
43. Server Manager Host Controller will handle stats/runtime queries to allow load distribution
44. DC will potentially redirect to the SM to simplify this
45. The "update" objects will be responsible for determining if the update is "runtime" or "requires restart" or "may require restart"
46. Incremental domain updates are low-priority for 7 GA.
47. Logging will be passed to the server via a stdin command pattern to solve the chicken egg problem
48. Security Manager Policies will not be in the domain
49. Policy file location and security manager impl class will be part of the JVM section of the domain
50. Domain will have password element for clear-text and inline encrypted passwords and a password ref to keystore
51. Domain will contain SSL element with keystore, truststore, keyPassword, trustPassword, module-ref to alternative keymanager, trustmanager
52. Ability to load custom security providers in domain.xml
53. Ability to sync keystores
54. security realms (e.g. login-config.xml) will be represented as a subsystem in the domain.xml, other subsystems will reference it, and it will provide natural language configs for login modules
55. DC & SM will use authentication