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

[Darran Lofthouse]

On 01/20/2011 01:54 PM, ssilvert at redhat.com wrote:
> I don't want to reinvent the Servlet API either.
>
> 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.

The DC is not an AS host so one benefit of running elsewhere at the 
moment is that you could potentially create a cut down AS host with 
enough services provided such as JBoss Web, Security etc...

>
>
> 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