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

[ssilvert at redhat.com]

Quoting Jason Greene <jason.greene at redhat.com>:

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

If that can really be achieved in a reasonable time frame then I'm all  
for it.  I'm just skeptical at the moment.

Heiko's point about needing a robust security layer like JAAS is a  
pretty good one.

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