[jboss-as7-dev] Management Console JDK Server Example

[Jason Greene]

Comments inline

Sent from my iPad

On Jan 20, 2011, at 7:40 AM, Heiko Braun <hbraun at redhat.com> wrote:

> 
> Please see my comments inline.
> 
> On Jan 20, 2011, at 2:55 AM, Jason T. Greene wrote:
> 
>> Our management console architecture could follow a similar approach. We 
>> would have both the REST/JSON Domain API and console collected in the 
>> same DC JVM. The console would then just be static content 
>> (javascript/html) that issues the proper JSON requests via HttpRequest.
>> 
> 
> I agree that this looks like a desirable goal. However we have to stay pragmatic,
> especially with regard to timeline/goals. While leveraging the embedded HTTPD 
> is definitely lightweight, it also forces us to start developing on a very low level.
> Especially with regard to 
> 
> a) supporting libraries
> b) runtime service 
> c) deployment options
> 
> For instance the lack of a) would mean we don't benefit from libraries that may speed up development
> and reduce maintenance. Things like a REST framework or simply the Servlet API come to my mind.
> It basically means, we need to implement everything that might otherwise be provided by a feature complete library.
> (i.e. REST content negotiation)


All of these appear to apply to the thing serving the REST API and not the actual console. The REST API was already looking to do something similar since it would be able to run in the DC and HC processes, providing a simple consistent and robust architecture for accessing the domain. Having a standalone server just to run the REST API would add more complexity to the topology, and more possibilities of failure. 

REST frameworks like JAX-RS bring little value to our JSON/HTTP API, since it is just a wrapper of the underlying binary detyped DMR protocol. Even if we did use a framework we would still have to write the marshaling bits, which is the majority of the implementation.

> 
> Missing runtime service (b) that may result in more work are things like integration with a security subsystem
> and configuration. While a the Servlet API provides clear means to integrate with JAAS for instance, we would need to specify and implement that on our own.

Since JAAS is a SE API, you can use it without using servlet. Also, the jdk http server provides an impl for basic and digest auth as well as support for ssl (although these are trivial to implement anyway)

> 
> c) simply means we constraint ourselves and users a single deployment option. 
> In Neuchatel we discussed the deliverable as  a web application (war) that relies in the remoting protocol internally
> and the flexibility it would have in terms of running the web-UI anywhere in your system.

Actually what you propose is less flexible. As you know, GWT app the uses REST is just static content and doesn't even need a java web server. You can run it on apache, in a war if desired, or even directly off the filesystem. 

Although from a topology perspective, I would imagine most would prefer the admin console be ran from the dc. We would of course need to support additional configurations.

Doing remoting from the web server implies that you would be doing javascript http requests to the servlet engine (I'm guessing using GWT-RPC?) which would then do a remoting call to the DC. Instead you can just do a straight http request to the dc, and you have half the transport and marshaling happening.

> 
> I think it's still desirable to aim for a low footprint implementation with few dependencies,
> but in order to stay productive we need to be pragmatic with regard to common API, existing services and maintenance.

I guess I don't see how this approach creates more work.

> 
> An alternative solution would be TJWS. It's low footprint (<100kb) web server, that optionally supports the Servlet API.
> It does have more dependencies then the embedded httpd, but would at least allow for a),  provide common services (b),
> and works on simple web application archives (c). 

It is certainly an option to consider. However, I am not yet sure we really need the servlet API to do any of this. Another longer term option, if we decide we need comet style push notifications, and dont want to create blockig threadys, is I could look at writing a lightweight non-blocking http server API similar to the jdk one. 


> 
>> It's also possible to do GWT-RPC this way, but that would essentially be 
>> adding an extra layer, which is likely not needed. In both cases we 
>> would be shifting state to client, which saves resources.
> 
> AFAIKT is wouldn't be possible to run GWT RPC this way. GWT RPC relies on the servlet API.
> It's internal use of policy files and means to secure the RPC communication make it very difficult to use outside
> this context. For the sake of this discussion, I would say if we want to use GWT-RPC, then we have we need a servlet engine. Anything else introduces an extra amount of work, with very little benefit.

It looked like they exposed an SPI that I could easily map (the extra work should be tiny) I can check it out if you think you will need it. So far it seems talking straight json is a better approach.