5:09 p.m.
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