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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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&lt;hbraun(a)redhat.com&gt;: > > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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(a)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(a)redhat.com&gt;: > >> >> 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > > > > > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 1/20/11 8:29 AM, ssilvert(a)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&lt;hbraun(a)redhat.com&gt;: > >> >> >> 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(a)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&lt;hbraun(a)redhat.com&gt;: >>> >>>> >>>> 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> > > > > > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Quoting Brian Stansberry&lt;brian.stansberry(a)redhat.com&gt;: > On 1/20/11 8:29 AM, ssilvert(a)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.

> >> >> Besides, wouldn't you need to to talk to the domain controller even >> when nothing else is running? >> >> Quoting Heiko Braun&lt;hbraun(a)redhat.com&gt;: >> >>> >>> >>> 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(a)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&lt;hbraun(a)redhat.com&gt;: >>>> >>>>> >>>>> 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> >> >> >> >> >> >> >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 01/20/2011 08:32 PM, Brian Stansberry wrote: > 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. One question that came up this week was why isn't the DC also running on a minimal AS? I assume this has already been considered but it would bring some additional benefits: - - The DC becomes just another host so any instability in the DC and the host controller is unaffected and can restart it as required. - Whilst minimal services is still desirable services already provided within AS can be used. And also later if there was ever need to implement a more master/slave domain controller architecture this could be achieved with a server group specifically for the domain controller.

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(a)redhat.com&gt;: > > 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On Jan 20, 2011, at 5:29 PM, Jason Greene wrote: >> >> 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. All I am trying to say it that you loose flexibility when you tie them together. Whatever deployment consideration taken for the console will then directly affect the DC or REST interface. I.e. moving the console to the DMZ (demilitarized zone), would require exposing the DC or REST interface there as well. Do you know what I mean? Hence the idea to keep it decoupled and rely on the java protocol underneath. Why is everyone so afraid of extra network hops and serialization overhead? I think we are going to have a kickass remoting protocol, no?

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

On Jan 20, 2011, at 6:02 PM, ssilvert(a)redhat.com wrote: >> It's not reinventing the servlet API, it's using an alternative one >> that accomplishes then same thing but with minimal overhead. > Let's get back to more concrete requirements. I already suggested a discussion about security to begin with. If any of those identify a dependency on the servlet API, or reveal that supporting libraries that depend on the servlet API help us achieving our goals with less work, then we should consider a servlet runtime. If nothing of that is the case, fine, then proceed with the embedded server approach.

Another thing that we might consider it configuration of the HTTP endpoints. TLS has been mentioned. How would that work on embedded HTTP? How would you specify and use certificates? Would we need to write all that on our own?

Might look trivial, but simple bit's easily add up to a pile of work.

Overall, I'm concerned about the security aspects of this console, and how it will fit in with a customers overall security implementation. Considering customers like Mastercard, which have network devices for encryption and key management, etc., they will want everything to be able to work through that infrastructure, and not have to manage security differently for our console. This type of thing could become a very real impediment to adoption of EAP 6 down the road. Let's make sure we include Anil and his folks in these security discussions, so we don't end up with something that doesn't fit into the long term goals, and potentially becomes a show stopper for customer to adopt the next major EAP release. Andy ----- Original Message ----- > From: "Heiko Braun&quot;&lt;hbraun(a)redhat.com&gt; > To: ssilvert(a)redhat.com > Cc: jboss-as7-dev(a)lists.jboss.org > Sent: Thursday, January 20, 2011 10:10:43 AM > Subject: Re: [jboss-as7-dev] Management Console JDK Server Example > On Jan 20, 2011, at 6:02 PM, ssilvert(a)redhat.com wrote: > >>> It's not reinventing the servlet API, it's using an alternative one >>> that accomplishes then same thing but with minimal overhead. >> > > > Let's get back to more concrete requirements. I already suggested a > discussion about security to begin with. > If any of those identify a dependency on the servlet API, or reveal > that supporting libraries > that depend on the servlet API help us achieving our goals with less > work, then we should consider a servlet runtime. > > If nothing of that is the case, fine, then proceed with the embedded > server approach. > > > Another thing that we might consider it configuration of the HTTP > endpoints. > TLS has been mentioned. How would that work on embedded HTTP? How > would you specify > and use certificates? Would we need to write all that on our own? > > Might look trivial, but simple bit's easily add up to a pile of work. > > Ike > > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Quoting Jason Greene <jason.greene(a)redhat.com&gt;: > On Jan 20, 2011, at 7:55 AM, ssilvert(a)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.

On 1/20/11 11:02 AM, ssilvert(a)redhat.com wrote: > Quoting Jason Greene&lt;jason.greene(a)redhat.com&gt;: >> On Jan 20, 2011, at 7:55 AM, ssilvert(a)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. So servlet containers give you a set of pre-established authentication mechanisms: - Basic Implemented in the embedded server (Although this one is very easy to write even if we had to do it) - Digest Digest causes problems in multi-layer auth scenarios since its designed around 2-party communication. Although we could still use it regardless, granted it requires more work than a servlet container (you have to implement an Authenticator to do it) - Cert The embedded server provides the hooks to use JSSE for establishing the connection. There you can tell it to require a Cert. You would then implement an Authenticator that just read the cert off the current SSLSession and passed it off to JAAS or picketlink or whatever - Form This form of auth is pretty much useless. Almost everyone prefers something custom to the cookie-cutter servlet form To go beyond these things you have to either not use servlet security (and instead do custom servlet filters) OR write a container specific plugin (like a tomcat valve). Once you get to this point it's equivalent to implementing security directly. Also, keep in mind that most likely the DC will have to be the one doing the "true" authentication, or at least redundant authentication. The primary reason for this is both auditing, and to allow the same credentials to be used via the CLI and the web app. So this means the DC will already have to be written to auth somehow (using picketlink or whatever)

REST frameworks like JAX-RS bring little value to our JSON/HTTP API, since it is just a wrapper of the underlying binary detyped DMR protocol. Even if we did use a framework we would still have to write the marshaling bits, which is the majority of the implementation.

> 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. Since JAAS is a SE API, you can use it without using servlet. Also, the jdk http server provides an impl for basic and digest auth as well as support for ssl (although these are trivial to implement anyway)

> 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. Actually what you propose is less flexible. As you know, GWT app the uses REST is just static content and doesn't even need a java web server. You can run it on apache, in a war if desired, or even directly off the filesystem. Although from a topology perspective, I would imagine most would prefer the admin console be ran from the dc. We would of course need to support additional configurations. Doing remoting from the web server implies that you would be doing javascript http requests to the servlet engine (I'm guessing using GWT-RPC?) which would then do a remoting call to the DC. Instead you can just do a straight http request to the dc, and you have half the transport and marshaling happening.

As an example we have the notion of a deployment plan, which is a set of operations that are supposed to be applied atomically according to a policy. The best mapping for this is to send the plan over an HTTP post. Such a thing is far easier then coming up with a bunch of abstract resources, and numerous http requests to interact with them.

On 1/20/11 11:00 AM, Heiko Braun wrote:

- The ERD clarified that ACLS would be a JON feature above the console. We could if we have time, support some form of basic permissions

Yes I would not be surprised if the requirement comes in - the filter that is available for the JMX console in the AS/EAP 4/5 distributions is used with occasional requests on how to refine it further.

One point regarding the requirements is that it is 'complex permissions' that are delegated to JON so there is still the middle ground of 'simple permissions' not explicitly included or excluded.

At the very least tackling simple permissions could provide the same kind of functionality as is provided by the filter for the JMX console and this would ensure the domain management does contain some form of authorization that can potentially be extended in the future to introduce more complex permissions. I know the API discussion has moved on but in terms of a REST API with everything mapped to a URI with one of four methods (GET/POST/PUT/DELETE) you could fairly simply define ACLs as a combination of methods and URIs that are either allowed or prohibited for a role or set of roles. Making use of wildcards and using the allowed and prohibited for the URIs similar to Ant includes and excludes you could have a lot of flexibility without the ACL mechanism itself being overly complex.

For the server group administration would we really want to make it as complex as dynamically identifying which profiles are pulled into which server groups? During the meeting it was identified that we need further clarification regarding how either server group or host specific configuration and updates would be provided so that links closely with this but to simplify both the implementation and the description / documentation of the ACLs wouldn't it make sense to just work on the lines of groups of users being given access to maintain specific profiles and other groups of users to be given access to maintain specific server groups.

If there is a requirement to have administrators that look after a server group and the profiles that feed into the server group suitable naming conventions could then be defined at the time the domains are defined to allow a separation in configuration rather than trying to implement identification of permissions by traversing the hierarchy from server group and up.

Regards, Darran Lofthouse. On 01/20/2011 08:05 PM, Brian Stansberry wrote: > On 1/20/11 12:56 PM, Jason T. Greene wrote: >> On 1/20/11 11:00 AM, Heiko Braun wrote: > > <snip/> > >> >> - The ERD clarified that ACLS would be a JON feature above the console. >> We could if we have time, support some form of basic permissions >> > > I think we should think a bit about how ACLs could work and confirm that > our design could support them. There's no requirement to implement them, > but I'd be surprised if there wasn't such a requirement in a year or so, > so good to think a bit. > > Our model has: > > -- hierarchical addresses > -- attribute names > -- operation names > -- some generic metadata that we can attach to operation descriptions, > e.g. RO/WO/RW, affects config, affects runtime state > > It seems like out of that some reasonable ACL schemes could be derived. > It would be good to think a bit about how the enforcement would work and > whether the necessary information is cheaply available at the control > point. (E.g. that "RO/WO/RW, affects config, affects runtime state" > metadata isn't super-cheaply available.) > > What I see that's not so clean for ACLs is the way server groups work. > Server groups have shared resources (e.g. profile configs, host > interface configs) mapped on to them, and then servers as logical > children. That mapping is problematic, e.g. if only users in the > "groupA-admin" role could touch stuff that affects server group "groupA" > (a likely construct), then before updating anything we'd have to see if > that something directly or indirectly affects groupA. >

Think in terms of the core detyped management API, not REST. Your line of thinking is fine, but try not to discuss things in terms of REST. HTTP is just one mechanism for exposing the core management API.

> For the server group administration would we really want to make it as > complex as dynamically identifying which profiles are pulled into which > server groups? > > During the meeting it was identified that we need further clarification > regarding how either server group or host specific configuration and > updates would be provided so that links closely with this but to > simplify both the implementation and the description / documentation of > the ACLs wouldn't it make sense to just work on the lines of groups of > users being given access to maintain specific profiles and other groups > of users to be given access to maintain specific server groups. > Would that be acceptable to users? Honestly asking; I don't know.

90% of what it means to *configure* a server group is: 1) Configure the profile it runs. 2) Map deployments to the group. So, 1) is the issue. But managing configuration is just one part of what it means to manage something. If excluding 1) from the rights of users in the "server-groupA-admin" role, is acceptable, that certainly simplifies things.

Yeah, I figured that's where you were going, and it's fine in terms of direction; I didn't mean to be critical. I just want us to avoid REST analogies and focus on developing precise language for discussing stuff in terms of the core management API.

As you carry on with your thinking, be sure to get an understanding of how the classes in [1] work. See how well they fit/don't fit. Those, plus a convention of using "add" and "remove" as the name of operations that add/remove resources, should cover a very high % of the operations people will perform. The one that's somewhat neither fish nor fowl is reading a metric.

We could model a metric as a read-only attribute and use the "read-attribute" operation, or we could have a bunch of ad-hoc "read-connection-count" operations, but neither feel exactly right. The former is closer. [1] https://github.com/bstansberry/jboss-as/tree/detyped2/controller/src/main... > As it stands at the moment the HTTP API will probably not need to do a > lot more than the HTTP specific steps in the authentication process. > >>> For the server group administration would we really want to make it as >>> complex as dynamically identifying which profiles are pulled into which >>> server groups? >>> >>> During the meeting it was identified that we need further clarification >>> regarding how either server group or host specific configuration and >>> updates would be provided so that links closely with this but to >>> simplify both the implementation and the description / documentation of >>> the ACLs wouldn't it make sense to just work on the lines of groups of >>> users being given access to maintain specific profiles and other groups >>> of users to be given access to maintain specific server groups. >>> >> >> Would that be acceptable to users? Honestly asking; I don't know. > > One issue you would have with dynamically identifying the profiles a > user can modify based on the server groups that they can administer is > that there would be nothing preventing them from updating their own > server group to use a different profile and hence gain access to a > profile they didn't previously have access to. > > You could then go to the level of defining permissions to specify which > profiles an administrator can actually use but by that point you may as > well be setting the permissions in relation to what they can actually > modify. > > Another way to view this may be to consider the profile as a template > for the server with either server group or host specific overrides, you > may have a limited set of users that can update the main templates and > then define administrators that can maintain their own profile to > aggregate the template profiles together into their own profile and then > apply server group / host overrides. Dynamically discovering which > utilised profiles can be modified would prevent the ability to do this. > > Also encouraging server group / host overrides over profile manipulation > could possibly be a best practice anyway to prevent administrators > inadvertently affecting all server groups in a domain when they only > really want to update one. > > >> 90% of what it means to *configure* a server group is: >> >> 1) Configure the profile it runs. >> 2) Map deployments to the group. >> >> So, 1) is the issue. But managing configuration is just one part of what >> it means to manage something. If excluding 1) from the rights of users >> in the "server-groupA-admin" role, is acceptable, that certainly >> simplifies things. >>

To me, "simple permissions" means if you can authenticate as an admin, you're root. Everything else below is "complex permissions."

On 1/21/11 11:04 AM, Heiko W.Rupp wrote: > > Am 21.01.2011 um 16:20 schrieb Brian Stansberry: >> To me, "simple permissions" means if you can authenticate as an admin, >> you're root. Everything else below is "complex permissions." > > One may (as we discussed on the phone iirc) have three categories: > - root > - deploy + view > - view only > This is a kind of in-between stage between really simple permissions and truly complex permissions. In a "complex permission" system, we'd: a) Figure out all the request characteristics which users would want to use in access control decisions. b) Determine the control point(s) where the request could be evaluated. c) Provide a configuration mechanism where users can express what roles are allowed to access what combination of characteristics. Expose such via the configuration files and all our management interfaces. This 3 category approach eliminates c) by making it static. Big savings in effort. One that by itself doesn't prevent a full, more complex approach in a later release; i.e. we could always add configuration capability as a new feature. It also affects a) by specifying a limited number of relevant request charactistics (is request read-only, is it deployment related.) That could be ok too as a way to reduce the amount of AS 7.0 work, but we'd need to think through what all the characteristics are that we're going to be asked (i.e. required) to support in the future. And make sure we don't design things in a way where that's not doable. > If the REST verbs would be used, GET could be filtered for read-only, > and all allowed for root - and the deploy role would need some > filtering on the url. > The REST verbs are just other ways of describing CRUD. And what a request does in CRUD terms is certainly a big characteristic in any ACL system. > But then urls could also be constructed in a way of > > /metric/domain/x/subsystem/y/... Metrics aren't the only CRUD "Read" so I don't think elevating them to a top level concern in the model solves much. > /deploy/server-group/x/.. Deployment related stuff is already in just a couple easily identified branches of the resource tree, so I don't think making it a top level concept helps much in terms of evaluating requests. > /<other>/.... > > Which can be relatively easy be matched to the above three roles. > > But then I am fine with "root" - only being present :-) It's a good discussion though. -- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 1/24/11 8:08 AM, Heiko Braun wrote: > > If I understand you correctly, you say: > > - we could do role based authentication Right. > - simplify it by providing fixed set of roles the UI knows of For now, yes. But we'd want to understand how to make that set of roles configurable in the future. > - allow for a highlevel mapping of roles to management use cases (what ever highlevel means) This is the hard part. We'd want to design this to be flexible for the future. I suspect that's *much* easier to do for the core management infrastructure than it is for the console. > - defer the decision how roles are being mapped to principals > Well, we'd have to solve this problem even for the simplest use case; i.e. just because a user can authenticate against corporate LDAP, he may not be an admin.

Another aspect to consider is that values in the model can be described as "read only" and "read write"

Yes I agree it should all be role based. What I was really getting at here rather than the specifics of 'read only' or 'read write' attributes is that the detyped model is self describing - should that description actually take into account what the current user can actually do? i.e. The users view of the domain could filter out everything they don't have access to so they would only see a subset. Or would it still make sense to expose everything that they can not do and maybe provide an alternative indicator that although an operation exists they can not invoke it?

On 01/25/2011 02:25 PM, Heiko Braun wrote: > > On Jan 25, 2011, at 12:35 PM, Darran Lofthouse wrote: > >> Another aspect to consider is that values in the model can be >> described as "read only" and "read write" > > > IMO this distinction doesn't make sense at all. All attributes are > read-only by default and for operations you don't know > if they change state (guess this would be called 'write'). IMO we > should drop these weak classifications and simply use a role based > approach. Similar to the EE specs. Either can execute the operation or > you can't, depending wether or nor you inherit a particular role. > > > > > >

On 01/26/2011 02:38 PM, Brian Stansberry wrote: > On 1/25/11 9:00 AM, Darran Lofthouse wrote: >> Yes I agree it should all be role based. >> >> What I was really getting at here rather than the specifics of 'read >> only' or 'read write' attributes is that the detyped model is self >> describing - should that description actually take into account what the >> current user can actually do? i.e. The users view of the domain could >> filter out everything they don't have access to so they would only see a >> subset. Or would it still make sense to expose everything that they can >> not do and maybe provide an alternative indicator that although an >> operation exists they can not invoke it? >> > > Either of could be done by making security information available to > OperationHandler(s) that handle requests for descriptions. This would be > done by adding something to the NewOperationContext param. So, either or > both can be done without perturbing things much. > > TBH, I don't have a strong opinion on whether or not filtering out > descriptions is the right thing from the end user point of view. My strongest opinion here is that if the domain model can indicate what the current user can do then we should do that to avoid a situation where we have an authorization check within the core API and have the same logic duplicated in each console.

Regarding the hiding I don't have a strong view either but maybe the core API should return the unfiltered view and then the console can decide if this should be filtered. I think arguments one way or the other would be more likely in the context of the end user experience of the different consoles.

On 01/25/2011 08:41 AM, Heiko Braun wrote: > a) One for the client server communication (which operation can a 'role' invoke?) > b) another one discriminating which parts of the UI the user actually gets to see. We do need to be careful that the console itself doesn't attempt to perform it's own restrictions with it's own authorization checking as this can become quite easy for administrators to become dependent on and not realise that their users can bypass this and call the APIs directly. Also based on past experience I think we want to be able to document the security once and for it to then apply equally to all management APIs. From the perspective of the console I think this should be considered more from the point of preventing users wasting their time performing operations in the console that will subsequently fail when applied. I am going to go through the example Brian has now committed to take a better look at these potential calls but I am wondering if it would make sense to have some form of "What can I do here?" or "What operations am I allowed to call?" calls for the console to be able to discover this? Another aspect to consider is that values in the model can be described as "read only" and "read write" - would it make sense for this to also reflect what the user can actually do or maybe even add a "read write - but not for you". Regards, Darran Lofthouse.

Hi Anil, I have read through the XACML specification and it does seem very suited as the mechanism to define the policies. There is one thing that concerns me however and that is the complexity of the configuration for administrators that are new to XACML and also don't necessarily want to know the inner workings of domain management. I also see some similar concerns in one of your previous blog posts: - http://anil-identity.blogspot.com/search/label/XACML To overcome this would it then make sense for us to define a schema for a simplified policy that users can use and manipulate through the domain model - this could then undergo a transformation into a XACML policy. This would then potentially give us the benefit of providing a simplified authorization / ACL configuration for users from the beginning and then for advanced users they could switch directly to XACML and write their own policies. At our own pace we can then expand on our schema but for the users that want more than we provide they will always have the option to switch to an advanced mode. (For switching to an advanced mode I would think you are definitely outside the scope of any tooling we provide assisting with the XACML version of the configuration which is why it would still be beneficial to expand on our schema) Another aspect I am also still looking into is how much we want to know about what a user can do before they do it or if we are just interested in an authorization check at the time they attempt an action so I need to consider how this would work with XACML policies. Regards, Darran Lofthouse. On 01/25/2011 03:58 PM, Anil Saldhana wrote: > Darran, > take a look at xacml policies. It gives the externalization of > policies plus the fine grained aspects perfectly > suited for management console. > > Regards, > Anil > > On 01/25/2011 05:35 AM, Darran Lofthouse wrote: >> On 01/25/2011 08:41 AM, Heiko Braun wrote: >>> a) One for the client server communication (which operation can a 'role' invoke?) >>> b) another one discriminating which parts of the UI the user actually gets to see. >> We do need to be careful that the console itself doesn't attempt to >> perform it's own restrictions with it's own authorization checking as >> this can become quite easy for administrators to become dependent on and >> not realise that their users can bypass this and call the APIs directly. >> >> Also based on past experience I think we want to be able to document the >> security once and for it to then apply equally to all management APIs. >> >> From the perspective of the console I think this should be considered >> more from the point of preventing users wasting their time performing >> operations in the console that will subsequently fail when applied. >> >> I am going to go through the example Brian has now committed to take a >> better look at these potential calls but I am wondering if it would make >> sense to have some form of "What can I do here?" or "What operations am >> I allowed to call?" calls for the console to be able to discover this? >> >> Another aspect to consider is that values in the model can be described >> as "read only" and "read write" - would it make sense for this to also >> reflect what the user can actually do or maybe even add a "read write - >> but not for you". >> >> Regards, >> Darran Lofthouse. > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Hi Darran, I am presuming that there will be some console plugin to manage the fine grained authorization aspects of the console. I proposed xacml as it is a decent standard for FGA and better than coming up with some ad-hoc ACL based solutions. Regards, Anil On 01/26/2011 04:55 AM, Darran Lofthouse wrote: > Hi Anil, > > I have read through the XACML specification and it does seem very > suited as the mechanism to define the policies. > > There is one thing that concerns me however and that is the complexity > of the configuration for administrators that are new to XACML and also > don't necessarily want to know the inner workings of domain > management. I also see some similar concerns in one of your previous > blog posts: - > > http://anil-identity.blogspot.com/search/label/XACML > > To overcome this would it then make sense for us to define a schema > for a simplified policy that users can use and manipulate through the > domain model - this could then undergo a transformation into a XACML > policy. > > This would then potentially give us the benefit of providing a > simplified authorization / ACL configuration for users from the > beginning and then for advanced users they could switch directly to > XACML and write their own policies. At our own pace we can then expand > on our schema but for the users that want more than we provide they > will always have the option to switch to an advanced mode. > > (For switching to an advanced mode I would think you are definitely > outside the scope of any tooling we provide assisting with the XACML > version of the configuration which is why it would still be beneficial > to expand on our schema) > > Another aspect I am also still looking into is how much we want to > know about what a user can do before they do it or if we are just > interested in an authorization check at the time they attempt an > action so I need to consider how this would work with XACML policies. > > Regards, > Darran Lofthouse. > > > > On 01/25/2011 03:58 PM, Anil Saldhana wrote: >> Darran, >> take a look at xacml policies. It gives the externalization of >> policies plus the fine grained aspects perfectly >> suited for management console. >> >> Regards, >> Anil >> >> On 01/25/2011 05:35 AM, Darran Lofthouse wrote: >>> On 01/25/2011 08:41 AM, Heiko Braun wrote: >>>> a) One for the client server communication (which operation can a >>>> 'role' invoke?) >>>> b) another one discriminating which parts of the UI the user >>>> actually gets to see. >>> We do need to be careful that the console itself doesn't attempt to >>> perform it's own restrictions with it's own authorization checking as >>> this can become quite easy for administrators to become dependent on >>> and >>> not realise that their users can bypass this and call the APIs >>> directly. >>> >>> Also based on past experience I think we want to be able to document >>> the >>> security once and for it to then apply equally to all management APIs. >>> >>> From the perspective of the console I think this should be considered >>> more from the point of preventing users wasting their time performing >>> operations in the console that will subsequently fail when applied. >>> >>> I am going to go through the example Brian has now committed to take a >>> better look at these potential calls but I am wondering if it would >>> make >>> sense to have some form of "What can I do here?" or "What operations am >>> I allowed to call?" calls for the console to be able to discover this? >>> >>> Another aspect to consider is that values in the model can be described >>> as "read only" and "read write" - would it make sense for this to also >>> reflect what the user can actually do or maybe even add a "read write - >>> but not for you". >>> >>> Regards, >>> Darran Lofthouse.