[jboss-as7-dev] Standalone Server: Domain Model

[Brian Stansberry]

On 1/11/11 4:44 AM, Heiko Braun wrote:
>
>
> Referring to:
> https://community.jboss.org/wiki/DomainManagementModelDesign
>
> "Internally, the object model representing the domain configuration for
> a standalone server may be quite similar to that shown above. However,
> the XML configuration schema and perhaps the management API will be
> simplified to remove extraneous concepts like the ServerGroup. (/Whether
> creating a distinct management API for this use case is appropriate
> needs discussion. A separate API means clients like JON and the embedded
> console need to be coded against two APIs in order to cover all use
> cases./)"
>
> Creating to API's doesn't make sense at all. Instead we should try to
> collapse the concepts when used standalone. I.e. by referencing a
> default server group "standalone".
>
> What domain model concepts can you think of that don't match the
> standalone scenario?
>

Maybe there aren't any. Please forgive the long journey I'm about to go 
on...

There are two main difficulties:

1) A standalone mode server exposes some operations that are not 
available to a domain mode server. E.g. in domain mode the alias of a 
virtual host is a domain level configuration, and can't be independently 
altered on an individual server.

2) In domain mode, a server's configuration is synthesized from two 
inputs: domain.xml and server.xml. The model exposed by the management 
API (from DomainController) reflects those inputs:

(If e-mail mangles this, see http://pastebin.com/2a2GV0iA)

{
   "profile" => {
     "default" => {
       // domain-wide config here
     }
   },
   "server-group" => {
     "group1" => {
       "profile => "default"
         ...
      }
   },
   "host" => {
     "host1" => {
       "interface" => {
         "public" => {
           "ip-address" => "10.0.0.1"
         }
       }
       "server-config" => {
         "server-one" => {
           // host-specific configs here
         }
       },
       "server" => {
         "server-one" => {
           "profile" => {
             "default" => {
               // read-only view
             }
           }
           "interface" => {
             "public" => {
               // read-only view
             }
           }
         }
       }
     }
   }
}

The "profile" and "server-group" elements above reflect what's in 
domain.xml.

The "host/host1" element above represents a particular HostController's 
portion of the model.

The "host/host1/interface" and "host/host1/server-config" elements 
represent what's in host1's host.xml.
	
The "host/host1/server/server-one" element represents server-one's view 
of the model. In terms of configuration, it's a read-only view of the 
synthesis of relevant stuff from domain.xml and host.xml. The details of 
"host/host1/server/server-one/profile/default" are not directly writable 
via the management API; the update operations are in "profile/default" 
at the domain level.

In standalone mode, the view is simpler:

{
   "profile" => {
     "default" => {
       // writable view
     }
   }
   "interface" => {
     "public" => {
       // writable view
     }
   }
}

That directly represents what's in standalone.xml, and the details are 
writable.

Now, it is possible to eliminate (at least internally) that simple view 
for standalone mode. Essentially, standalone mode could "desynthesize" 
the standalone.xml content and pretend everything either came from a 
domain.xml or a host.xml. The internal model representation would then 
look like the complex one above. The operations available from the 
different addresses would then be identical.

TBH, doing it that way will probably solve a lot of internal problems. 
And I can certainly see how it makes life easier for sophisticated 
clients, like the console code itself.

The downside to it is it's conceptually confusing for standalone mode users.


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat