5:22 a.m.
Jumping right into a previous discussion:
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.
If the DomainController (HostController) serves the REST API, the question would be how
wan't to build it.
I would propose RestEasy+TJWS [1]. TJWS has very small footprint, but still supports the
Servlet API.
In that case we would buy a suitable runtime for serving the admin console. It could
integrate through the REST API.
(or even GWT-RPC if we go that way)
If you skip RESTeasy, fleshing out the REST API becomes more work, but it would reduce the
dependencies.
Any thoughts on this?
Ike
12:35 p.m.
On 1/11/11 5:22 AM, Heiko Braun wrote:
If the DomainController (HostController) serves the REST API, the
question would be how wan't to build it.
I would propose RestEasy+TJWS [1]. TJWS has very small footprint, but
still supports the Servlet API.
In that case we would buy a suitable runtime for serving the admin
console. It could integrate through the REST API.
(or even GWT-RPC if we go that way)
If you skip RESTeasy, fleshing out the REST API becomes more work,but
it would reduce the dependencies.
I think its important to conceptually separate the console from the REST
API server. The main reason is to keep the DC process complexity
somewhat constrained, so that it's less likely to fail, it limits the
amount of updates needed, and manages overhead.
*IF* we end up with a very lightweight console (at least from the server
requirements), then it might make sense to collocate it in the DC. If
not then we can use the console as a subsystem of a server that acts as
a client to the DC.
No matter the technology choice for the REST API service, we will need
to implement a detyped <-> json marshalling component, but this should
be pretty simple. I suspect most of the time won't be the
implementation, but rather deciding high-level protocol details (how URL
mapping will work, and how REST-pure we want to be*).
[*] Note that we have already decided to bend the REST rules by doing
updates over JSON POSTs (which is really RPCish). However, this is the
only real practical way to solve the problem without having to write
REST conversion code for each and every operation we support.
--
Jason T. Greene
JBoss, a division of Red Hat
5085
days inactive
5085
days old
1 comments
2 participants
participants (2)
-
Heiko Braun -
Jason T. Greene