[jboss-as7-dev] Admin console

[Brian Stansberry]

On 12/22/10 11:10 AM, Alan Santos wrote:
>
> The console definitely needs to support standalone as well as domain,
> and I agree that historic data collection is outside the scope of an
> unmanaged instance.
>
> I'm curious about the question of hosting the mgmt console as I assumed
> it would live in the domain controller.  I don't have my notes from
> Antwerp available to double check, but isn't the domain controller just
> another AS instance?  If so why wouldn't it always live in that process?
>

No, a domain controller is not an EE-capable app server.* It's a 
specialized java process that only supports required functionality. From 
an external client POV, the functionality it needs to expose are:

1) A socket backed by a service that understands the proprietary Java 
protocol we'll use for the detyped management API.

2) An mbean server and a JMX connector.

3) A socket backed by a service that understands HTTP/HTTPS and can 
support our REST interface. Note that this does not require Servlet spec 
support. Our thinking at this time is to base this on the lightweight 
HTTP server in JDK 6.


* To be precise, a DomainController is a HostController whose host.xml 
config tells it to load the domain controller module rather than making 
a connection to a remote HostController.

> And now that I've asked that question I'm curious - Are there
> expectations with regard to continuity for deployed applications when
> transitioning a server from a single instance to a domain?
>

The deployed application depends on the runtime services provided by the 
AS instance's subsystems. There is no reason an AS instance running as 
part of a domain can't be configured to provide the same runtime 
services as a standalone server. If they can't be configured to provide 
the same runtime environment, it's a bug. Most of the configuration 
comes from the "profile" element, the contents of which can be identical 
between domain.xml and standalone.xml.

The only exceptions I see to this are:

1) Domain mode does not support automatic deployment based on scanning 
the filesystem. But that's not something the application itself uses.

2) The management API exposed by an AS instance is different in domain 
mode vs standalone. Basically, a standalone AS instance allows a client 
to the management API to update the instance's persistent configuration. 
In domain mode, any updates to the persistent configuration need to be 
done via the DomainController or HostController. But I doubt many 
applications will want to alter the AS instance's persistent 
configuration. If they do they'll need to be written to understand 
domain mode vs. standalone.

> -alan
>
>
> On 12/22/10 11:25 AM, Brian Stansberry wrote:
>> On 12/22/10 8:19 AM, Heiko W.Rupp wrote:
>>> Hi,
>>>
>>> we were talking about admin console before, but I am not sure if we reached any conclusion about
>>> - console for standalone (=non-domain) server mode
>> IMO we need the console to properly support standalone mode.
>>
>>> - will we have a "dedicated" server within a domain to host the console or could
>>>     theoretically every server host the console?
>> Theoretically any server could host the console. The console is a client
>> to the admin interface exposed by the DomainController, the
>> HostController(s) and any ServerController(s).
>>
>> I expect a typical scenario is users will want a separate server to host
>> the console; i.e. separate from the regular servers that handle user
>> requests. Since servers all belong to a server group, that implies a
>> separate server group running a profile sufficient to support the
>> console webapp. The configuration utilities we provide to help users set
>> up their configs need to make it easy to create such a configuration.
>>
>>> - do users expect to see metrics for the last hour from the moment they first
>>>     access the console or already for some time before?
>>>
>> There is no committed requirement to support maintaining a 1 hour
>> history of metrics. IMO if we want to support this, it should be a JON
>> feature, with JON responsible for storing the history. (I realize that
>> begs the question "What about if JON wasn't running..." to which the
>> response is "there is no committed requirement...")
>>
>>>      Heiko
>>>
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat