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

Jason Greene jason.greene at redhat.com
Thu Jan 20 11:29:25 EST 2011


On Jan 20, 2011, at 7:55 AM, ssilvert at redhat.com wrote:

> I don't want to reinvent the Servlet API either.


It's not reinventing the servlet API, it's using an alternative one that accomplishes then same thing but with minimal overhead.

> 
> I also don't understand the true benefit of running the console  
> somewhere other than the DC.  Why have the extra network hop for every  
> DC request?  Just call the API directly instead of messing with the  
> extra complexity of remoting.

Agreed. Ideally the console would be served up from the DC, as it's the most natural fit; however the DC and HC process need to have minimal overhead.

> 
> 
> Quoting Heiko Braun <hbraun at redhat.com>:
> 
>> 
>> 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)
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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'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.
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev




More information about the jboss-as7-dev mailing list