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

Thu Jan 20 15:32:09 EST 2011

On 1/20/11 10:53 AM, ssilvert at redhat.com wrote:
> Quoting Brian Stansberry<brian.stansberry at redhat.com>:
>
>> 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.
>
> Yea, it should only include the minimum it needs to do its job and
> allow management.  It's like my router.  It runs exactly one web app
> which allows management.  Other than that, it just boots up and gets
> warm.
>
>>
>> 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.
>
> Right.  So if you have to put this stuff somewhere you might as well
> co-locate it with the thing it is controlling.
>
> Think of it this way.  If the DC and console are in one process, I
> start the DC, hit a URL, and I'm off and running.  If it's up I can
> ALWAYS manage it with the UI.
>
> If they are separated, I start the DC.  Then I have to start another
> process to talk to it.  But before I do that I have to configure these
> two processes so they will talk to each other.  And any time this
> isn't working I have to figure out if one process is down or if they
> just aren't communicating.
>
> What's more, we have to write code that is aware of the fact that
> communication might be broken and we have to write more code to help
> the user deal with the extra complexity.  What a pain.
>

These are valid points. Being able to run the console on a process other 
than the DC is a plus for users who see the DC as critical 
infrastructure where they don't want anything extraneous going on; i.e. 
they do a lot of management via scripts and only occasionally run the 
console. But supporting that use case may not be worth the extra 
complexity of managing remote invocations.

Looking at that example Jason posted at the start of this thread, the 
webserver wasn't doing much anyway; i.e. it's not a big burder. Most of 
the work was in the browser or on Yahoo (the analogue to the DC's 
HTTP-based API.)

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