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

[Brian Stansberry]

On 1/20/11 8:29 AM, ssilvert at redhat.com wrote:
> Extra network hops are always a problem.  It's not a problem of load
> but rather just the inherent uncertainty of network calls and the
> extra complexity of marshalling/unmarshalling everything twice.
>
> IMO, we should go with the simplest design possible, especially for
> the first version.

We need a listing of what runtime services the console is going to need, 
and how configurable those services will need to be.

The DomainController is not a server. It does not run a profile. It 
doesn't have deployment unit processors (think AS 5/6 deployers) 
running. So configuring and running a bunch of runtime services on it 
isn't necessarily the simplest design.

BTW, even if the console is run on an ordinary server and not the DC, we 
should aim to keep the list of required runtime services and their 
configuration options as minimal as possible.

>
> Besides, wouldn't you need to to talk to the domain controller even
> when nothing else is running?
>
> Quoting Heiko Braun<hbraun at redhat.com>:
>
>>
>>
>> The remoting is not the problem. We don't speak of system under heavy load.
>> As for the topology i think flexibility is the key. Apart from the
>> default installation,
>> which would probably have all API entrypoints on the same host (next
>>   to the DC, not necessarily same process though),
>> I cannot tell who an operational team would like to spread out their
>>   components.
>> Might be that someone want's to move the web-UI to another host
>> (i.e. DMZ) in order to access it from outside the company. Who
>> knows? IMO we should aim for an architecture that's lightweight, but
>>   flexible.
>>
>> On Jan 20, 2011, at 2: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.
>>>
>>>
>>> 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
>>
>>
>
>
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat