Hi everyone, Now that we are using Undertow as the domain management HTTP server it is now possible to use a HTTP upgrade for the native management and remote-jmx protocols. This will allow us to run all management protocols over port 9990, and allow us to remove 9999 from our default config. The idea is significantly reduce the ports that are open in our default config, ideally eventually we will just have a management and application HTTP ports and that will be it (although some technologies such as CORBA are not compatible with HTTP Upgrade). With this in mind I have started working on a series of patches[1] to implement this, that I am hoping will be ready to merge early next week. (These patches are still a work in progress, but the core functionality works). For those of you who are not familiar with HTTP upgrade it is a mechanism where a client makes a HTTP request to the client with the Upgrade: header set, the server will then respond with a HTTP 101 response. In our implementation the server then hands the channel over to JBoss Remoting which then performs its normal handshake, including authentication. The upshot of all this will be: - We no longer have port 9999 open by default, which will break older clients that attempt to talk to a default AS8 instance (it will still be possible to add a native interface to allow it to work with older clients). - ModelControllerClient.Factory.create() now allows you to specify a protocol, which can be either remote, http or https. - Remote JMX will now require a service:jmx:http(s)-remoting-jmx:// URL rather than the current service:jmx:remoting-jmx:// I have not touched domain management yet, and these patches are not yet ready for merging, but because this is a fairly big change I thought I would get peoples thoughts before I finish it off and submit a PR. Stuart [1] https://github.com/stuartwdouglas/xnio/compare/http-upgrade https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Sounds good, just one point before it reaches a point people are using it - Is 'remote' really a suitable protocol name? Within Remoting JMX the reason I went for 'remoting-jmx' was to indicate that it was JMX over Remoting. RMI is also considered remote so I think having a protocol of 'remote' is ambiguous. Regards, Darran Lofthouse. On 28/03/13 10:15, Stuart Douglas wrote: > Hi everyone, > > Now that we are using Undertow as the domain management HTTP server it > is now possible to use a HTTP upgrade for the native management and > remote-jmx protocols. This will allow us to run all management protocols > over port 9990, and allow us to remove 9999 from our default config. The > idea is significantly reduce the ports that are open in our default > config, ideally eventually we will just have a management and > application HTTP ports and that will be it (although some technologies > such as CORBA are not compatible with HTTP Upgrade). > > With this in mind I have started working on a series of patches[1] to > implement this, that I am hoping will be ready to merge early next week. > (These patches are still a work in progress, but the core functionality > works). > > For those of you who are not familiar with HTTP upgrade it is a > mechanism where a client makes a HTTP request to the client with the > Upgrade: header set, the server will then respond with a HTTP 101 > response. In our implementation the server then hands the channel over > to JBoss Remoting which then performs its normal handshake, including > authentication. > > The upshot of all this will be: > > - We no longer have port 9999 open by default, which will break older > clients that attempt to talk to a default AS8 instance (it will still be > possible to add a native interface to allow it to work with older > clients). > > - ModelControllerClient.Factory.create() now allows you to specify a > protocol, which can be either remote, http or https. > > - Remote JMX will now require a service:jmx:http(s)-remoting-jmx:// URL > rather than the current service:jmx:remoting-jmx:// > > I have not touched domain management yet, and these patches are not yet > ready for merging, but because this is a fairly big change I thought I > would get peoples thoughts before I finish it off and submit a PR. > > Stuart > > [1] > https://github.com/stuartwdouglas/xnio/compare/http-upgrade > https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade > https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade > https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >

On 28/03/13 11:04, Stuart Douglas wrote: > This is what we have been using to represent JBoss remoting URI's so > far. I do agree that is is a bit ambiguous. I am not sure if that has been a deliberate decision but apart from naming it has not really been that visible so far. I think what happened was the Remoting test suite had tests that had local and remote connection providers registered and then these names have stuck as new communication libraries have followed the test suite. So those names work when using the remoting APIs directly but are not so good once you are using an alternative API that is wrapping Remoting. I think whatever set of protocol names we choose they are going to need to be ones we can live with long term. The suggestions for Remoting JMX I think are fine, if we ever wanted pure http for JMX that could be a new library with a completely different protocol in the Service URL. However another question for 'ModelControllerClient' are we also sure we will never want to add support for pure HTTP invocations?

> Stuart > > Darran Lofthouse wrote: >> Sounds good, just one point before it reaches a point people are using >> it - Is 'remote' really a suitable protocol name? >> >> Within Remoting JMX the reason I went for 'remoting-jmx' was to indicate >> that it was JMX over Remoting. >> >> RMI is also considered remote so I think having a protocol of 'remote' >> is ambiguous. >> >> Regards, >> Darran Lofthouse. >> >> >> On 28/03/13 10:15, Stuart Douglas wrote: >>> Hi everyone, >>> >>> Now that we are using Undertow as the domain management HTTP server it >>> is now possible to use a HTTP upgrade for the native management and >>> remote-jmx protocols. This will allow us to run all management >>> protocols >>> over port 9990, and allow us to remove 9999 from our default config. >>> The >>> idea is significantly reduce the ports that are open in our default >>> config, ideally eventually we will just have a management and >>> application HTTP ports and that will be it (although some technologies >>> such as CORBA are not compatible with HTTP Upgrade). >>> >>> With this in mind I have started working on a series of patches[1] to >>> implement this, that I am hoping will be ready to merge early next >>> week. >>> (These patches are still a work in progress, but the core functionality >>> works). >>> >>> For those of you who are not familiar with HTTP upgrade it is a >>> mechanism where a client makes a HTTP request to the client with the >>> Upgrade: header set, the server will then respond with a HTTP 101 >>> response. In our implementation the server then hands the channel over >>> to JBoss Remoting which then performs its normal handshake, including >>> authentication. >>> >>> The upshot of all this will be: >>> >>> - We no longer have port 9999 open by default, which will break older >>> clients that attempt to talk to a default AS8 instance (it will >>> still be >>> possible to add a native interface to allow it to work with older >>> clients). >>> >>> - ModelControllerClient.Factory.create() now allows you to specify a >>> protocol, which can be either remote, http or https. >>> >>> - Remote JMX will now require a service:jmx:http(s)-remoting-jmx:// URL >>> rather than the current service:jmx:remoting-jmx:// >>> >>> I have not touched domain management yet, and these patches are not yet >>> ready for merging, but because this is a fairly big change I thought I >>> would get peoples thoughts before I finish it off and submit a PR. >>> >>> Stuart >>> >>> [1] >>> https://github.com/stuartwdouglas/xnio/compare/http-upgrade >>> https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade >>> https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade >>> https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>

Darran Lofthouse wrote: > On 28/03/13 11:04, Stuart Douglas wrote: >> This is what we have been using to represent JBoss remoting URI's so >> far. I do agree that is is a bit ambiguous. > > I am not sure if that has been a deliberate decision but apart from > naming it has not really been that visible so far. > > I think what happened was the Remoting test suite had tests that had > local and remote connection providers registered and then these names > have stuck as new communication libraries have followed the test suite. > > So those names work when using the remoting APIs directly but are not so > good once you are using an alternative API that is wrapping Remoting. > > I think whatever set of protocol names we choose they are going to need > to be ones we can live with long term. The suggestions for Remoting JMX > I think are fine, if we ever wanted pure http for JMX that could be a > new library with a completely different protocol in the Service URL. > > However another question for 'ModelControllerClient' are we also sure we > will never want to add support for pure HTTP invocations? That is also a question that will need to be answered for EJB. I know work is being done on a pure HTTP client, so we need to make sure that there is no ambiguity there. Also if we have HTTP upgrade, why would we need a pure HTTP client library? The only reason that I can think of is that if there are some firewalls that block HTTP upgrade, but I am not really sure if that is really a thing.

Stuart > >> Stuart >> >> Darran Lofthouse wrote: >>> Sounds good, just one point before it reaches a point people are using >>> it - Is 'remote' really a suitable protocol name? >>> >>> Within Remoting JMX the reason I went for 'remoting-jmx' was to indicate >>> that it was JMX over Remoting. >>> >>> RMI is also considered remote so I think having a protocol of 'remote' >>> is ambiguous. >>> >>> Regards, >>> Darran Lofthouse. >>> >>> >>> On 28/03/13 10:15, Stuart Douglas wrote: >>>> Hi everyone, >>>> >>>> Now that we are using Undertow as the domain management HTTP server it >>>> is now possible to use a HTTP upgrade for the native management and >>>> remote-jmx protocols. This will allow us to run all management >>>> protocols >>>> over port 9990, and allow us to remove 9999 from our default config. >>>> The >>>> idea is significantly reduce the ports that are open in our default >>>> config, ideally eventually we will just have a management and >>>> application HTTP ports and that will be it (although some technologies >>>> such as CORBA are not compatible with HTTP Upgrade). >>>> >>>> With this in mind I have started working on a series of patches[1] to >>>> implement this, that I am hoping will be ready to merge early next >>>> week. >>>> (These patches are still a work in progress, but the core functionality >>>> works). >>>> >>>> For those of you who are not familiar with HTTP upgrade it is a >>>> mechanism where a client makes a HTTP request to the client with the >>>> Upgrade: header set, the server will then respond with a HTTP 101 >>>> response. In our implementation the server then hands the channel over >>>> to JBoss Remoting which then performs its normal handshake, including >>>> authentication. >>>> >>>> The upshot of all this will be: >>>> >>>> - We no longer have port 9999 open by default, which will break older >>>> clients that attempt to talk to a default AS8 instance (it will >>>> still be >>>> possible to add a native interface to allow it to work with older >>>> clients). >>>> >>>> - ModelControllerClient.Factory.create() now allows you to specify a >>>> protocol, which can be either remote, http or https. >>>> >>>> - Remote JMX will now require a service:jmx:http(s)-remoting-jmx:// URL >>>> rather than the current service:jmx:remoting-jmx:// >>>> >>>> I have not touched domain management yet, and these patches are not yet >>>> ready for merging, but because this is a fairly big change I thought I >>>> would get peoples thoughts before I finish it off and submit a PR. >>>> >>>> Stuart >>>> >>>> [1] >>>> https://github.com/stuartwdouglas/xnio/compare/http-upgrade >>>> https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade >>>> https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade >>>> https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade >>>> _______________________________________________ >>>> 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 Mar 28, 2013, at 6:32 AM, Kabir Khan <kabir.khan(a)jboss.com&gt; wrote: > > On 28 Mar 2013, at 11:27, Stuart Douglas wrote: > >> >> >> Darran Lofthouse wrote: >>> On 28/03/13 11:04, Stuart Douglas wrote: >>>> This is what we have been using to represent JBoss remoting URI's so >>>> far. I do agree that is is a bit ambiguous. >>> >>> I am not sure if that has been a deliberate decision but apart from >>> naming it has not really been that visible so far. >>> >>> I think what happened was the Remoting test suite had tests that had >>> local and remote connection providers registered and then these names >>> have stuck as new communication libraries have followed the test suite. >>> >>> So those names work when using the remoting APIs directly but are not so >>> good once you are using an alternative API that is wrapping Remoting. >>> >>> I think whatever set of protocol names we choose they are going to need >>> to be ones we can live with long term. The suggestions for Remoting JMX >>> I think are fine, if we ever wanted pure http for JMX that could be a >>> new library with a completely different protocol in the Service URL. >>> >>> However another question for 'ModelControllerClient' are we also sure we >>> will never want to add support for pure HTTP invocations? >> >> That is also a question that will need to be answered for EJB. I know >> work is being done on a pure HTTP client, so we need to make sure that >> there is no ambiguity there. >> >> Also if we have HTTP upgrade, why would we need a pure HTTP client >> library? The only reason that I can think of is that if there are some >> firewalls that block HTTP upgrade, but I am not really sure if that is >> really a thing. > > I think a pure http client library would open up nice possibilities for porting the cli to android, afaik remoting/xnio will not work there (although my impression there is based on rumours). Perhaps that isn't so important, but it sounds like fun to me :-) Fixing it on android should be fun too!! :)

>> >> Stuart >> >>> >>>> Stuart >>>> >>>> Darran Lofthouse wrote: >>>>> Sounds good, just one point before it reaches a point people are using >>>>> it - Is 'remote' really a suitable protocol name? >>>>> >>>>> Within Remoting JMX the reason I went for 'remoting-jmx' was to indicate >>>>> that it was JMX over Remoting. >>>>> >>>>> RMI is also considered remote so I think having a protocol of 'remote' >>>>> is ambiguous. >>>>> >>>>> Regards, >>>>> Darran Lofthouse. >>>>> >>>>> >>>>> On 28/03/13 10:15, Stuart Douglas wrote: >>>>>> Hi everyone, >>>>>> >>>>>> Now that we are using Undertow as the domain management HTTP server it >>>>>> is now possible to use a HTTP upgrade for the native management and >>>>>> remote-jmx protocols. This will allow us to run all management >>>>>> protocols >>>>>> over port 9990, and allow us to remove 9999 from our default config. >>>>>> The >>>>>> idea is significantly reduce the ports that are open in our default >>>>>> config, ideally eventually we will just have a management and >>>>>> application HTTP ports and that will be it (although some technologies >>>>>> such as CORBA are not compatible with HTTP Upgrade). >>>>>> >>>>>> With this in mind I have started working on a series of patches[1] to >>>>>> implement this, that I am hoping will be ready to merge early next >>>>>> week. >>>>>> (These patches are still a work in progress, but the core functionality >>>>>> works). >>>>>> >>>>>> For those of you who are not familiar with HTTP upgrade it is a >>>>>> mechanism where a client makes a HTTP request to the client with the >>>>>> Upgrade: header set, the server will then respond with a HTTP 101 >>>>>> response. In our implementation the server then hands the channel over >>>>>> to JBoss Remoting which then performs its normal handshake, including >>>>>> authentication. >>>>>> >>>>>> The upshot of all this will be: >>>>>> >>>>>> - We no longer have port 9999 open by default, which will break older >>>>>> clients that attempt to talk to a default AS8 instance (it will >>>>>> still be >>>>>> possible to add a native interface to allow it to work with older >>>>>> clients). >>>>>> >>>>>> - ModelControllerClient.Factory.create() now allows you to specify a >>>>>> protocol, which can be either remote, http or https. >>>>>> >>>>>> - Remote JMX will now require a service:jmx:http(s)-remoting-jmx:// URL >>>>>> rather than the current service:jmx:remoting-jmx:// >>>>>> >>>>>> I have not touched domain management yet, and these patches are not yet >>>>>> ready for merging, but because this is a fairly big change I thought I >>>>>> would get peoples thoughts before I finish it off and submit a PR. >>>>>> >>>>>> Stuart >>>>>> >>>>>> [1] >>>>>> https://github.com/stuartwdouglas/xnio/compare/http-upgrade >>>>>> https://github.com/stuartwdouglas/jboss-remoting/compare/http-upgrade >>>>>> https://github.com/stuartwdouglas/remoting-jmx/compare/http-upgrade >>>>>> https://github.com/stuartwdouglas/jboss-as/compare/http-upgrade >>>>>> _______________________________________________ >>>>>> 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 > > --------------------------------------- > Kabir Khan > Prinicipal 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

Darran Lofthouse wrote:

> However another question for 'ModelControllerClient' are we also sure we > will never want to add support for pure HTTP invocations? That is also a question that will need to be answered for EJB. I know work is being done on a pure HTTP client, so we need to make sure that there is no ambiguity there. Also if we have HTTP upgrade, why would we need a pure HTTP client library?

The only reason that I can think of is that if there are some firewalls that block HTTP upgrade, but I am not really sure if that is really a thing. Stuart

On 03/28/2013 06:27 AM, Stuart Douglas wrote: > > > Darran Lofthouse wrote: >> On 28/03/13 11:04, Stuart Douglas wrote: >>> This is what we have been using to represent JBoss remoting URI's so >>> far. I do agree that is is a bit ambiguous. >> >> I am not sure if that has been a deliberate decision but apart from >> naming it has not really been that visible so far. >> >> I think what happened was the Remoting test suite had tests that had >> local and remote connection providers registered and then these names >> have stuck as new communication libraries have followed the test suite. >> >> So those names work when using the remoting APIs directly but are not so >> good once you are using an alternative API that is wrapping Remoting. >> >> I think whatever set of protocol names we choose they are going to need >> to be ones we can live with long term. The suggestions for Remoting JMX >> I think are fine, if we ever wanted pure http for JMX that could be a >> new library with a completely different protocol in the Service URL. >> >> However another question for 'ModelControllerClient' are we also sure we >> will never want to add support for pure HTTP invocations? > > That is also a question that will need to be answered for EJB. I know > work is being done on a pure HTTP client, so we need to make sure that > there is no ambiguity there. > > Also if we have HTTP upgrade, why would we need a pure HTTP client > library? The only reason that I can think of is that if there are some > firewalls that block HTTP upgrade, but I am not really sure if that is > really a thing. It would be useful for thin (e.g. JS in the browser) clients which cannot do upgrade.

On 3/28/13 8:31 AM, David M. Lloyd wrote: > On 03/28/2013 06:27 AM, Stuart Douglas wrote: >> >> >> Darran Lofthouse wrote: >>> On 28/03/13 11:04, Stuart Douglas wrote: >>>> This is what we have been using to represent JBoss remoting URI's so >>>> far. I do agree that is is a bit ambiguous. >>> >>> I am not sure if that has been a deliberate decision but apart from >>> naming it has not really been that visible so far. >>> >>> I think what happened was the Remoting test suite had tests that had >>> local and remote connection providers registered and then these names >>> have stuck as new communication libraries have followed the test suite. >>> >>> So those names work when using the remoting APIs directly but are not so >>> good once you are using an alternative API that is wrapping Remoting. >>> >>> I think whatever set of protocol names we choose they are going to need >>> to be ones we can live with long term. The suggestions for Remoting JMX >>> I think are fine, if we ever wanted pure http for JMX that could be a >>> new library with a completely different protocol in the Service URL. >>> >>> However another question for 'ModelControllerClient' are we also sure we >>> will never want to add support for pure HTTP invocations? >> >> That is also a question that will need to be answered for EJB. I know >> work is being done on a pure HTTP client, so we need to make sure that >> there is no ambiguity there. >> >> Also if we have HTTP upgrade, why would we need a pure HTTP client >> library? The only reason that I can think of is that if there are some >> firewalls that block HTTP upgrade, but I am not really sure if that is >> really a thing. > > It would be useful for thin (e.g. JS in the browser) clients which > cannot do upgrade. > I haven't heard of any proposal to remove the existing REST-ish HTTP API though.

On 03/28/2013 03:02 PM, Jason Greene wrote: > Right I took pure HTTP client library as == ejb client over http talking > to a servlet that does EJB invocation (the pending EAP 6.x change). I don't > see any reason at all to have such a thing now that we support http upgrade > to remoting. I understand there is a new component that people feel they have to use, or something like it. But this is actually simply replacing standards by proprietary APIs. Although I understand why this is tempting (faster in the short term ?), a Servlet 3.1 has the same HTTP upgrade capabilities and async IO as the proprietary component, and is functionally identical. Normally, the evolution is the opposite: a proprietary API exists initially, and some people may use it (but most wait) because there's no standardized one yet. Ex: the async IO and upgrade capabilities of web as available in EAP 6.1, which mimic Servlet 3.1.

On 03/28/2013 03:32 PM, Jason Greene wrote: > Hmm not sure I follow. We are talking about the implementation of our ejb client library (or any other existing remoting client). How it communicates to the server (via upgrade, web sockets, socket, etc) is just an implementation detail of the client/server implementation. The user isn't exposed to those APIs to do it. Yes, I know it is about the remoting component (and it's the same for websockets as well - the user uses the websocket JSR, not the API used for the implementation). But you can still choose between proprietary or Servlet 3.1 for the implementation since they are supposed to be able to do the same thing.

On 3/28/13 8:31 AM, David M. Lloyd wrote: > On 03/28/2013 06:27 AM, Stuart Douglas wrote: >> >> Darran Lofthouse wrote: >>> On 28/03/13 11:04, Stuart Douglas wrote: >>>> This is what we have been using to represent JBoss remoting URI's so >>>> far. I do agree that is is a bit ambiguous. >>> I am not sure if that has been a deliberate decision but apart from >>> naming it has not really been that visible so far. >>> >>> I think what happened was the Remoting test suite had tests that had >>> local and remote connection providers registered and then these names >>> have stuck as new communication libraries have followed the test suite. >>> >>> So those names work when using the remoting APIs directly but are not so >>> good once you are using an alternative API that is wrapping Remoting. >>> >>> I think whatever set of protocol names we choose they are going to need >>> to be ones we can live with long term. The suggestions for Remoting JMX >>> I think are fine, if we ever wanted pure http for JMX that could be a >>> new library with a completely different protocol in the Service URL. >>> >>> However another question for 'ModelControllerClient' are we also sure we >>> will never want to add support for pure HTTP invocations? >> That is also a question that will need to be answered for EJB. I know >> work is being done on a pure HTTP client, so we need to make sure that >> there is no ambiguity there. >> >> Also if we have HTTP upgrade, why would we need a pure HTTP client >> library? The only reason that I can think of is that if there are some >> firewalls that block HTTP upgrade, but I am not really sure if that is >> really a thing. > It would be useful for thin (e.g. JS in the browser) clients which > cannot do upgrade. > I haven't heard of any proposal to remove the existing REST-ish HTTP API though. I do think it makes sense to be less ambiguous about the protocol names for ModelControllerClient.Factory. Call them http-upgrade/https-upgrade and that removes the ambiguity and leaves http/https available for the future. It's just clearer anyway; otherwise people will incorrectly assume "http" results in the client using the REST-ish API.

Just thinking would http-remoting and https-remoting be better names

Ok, I will change this again, and this this will probably be ready for review. I have also added some additional headers to the handshake to make sure both client and server are using the correct protocol, basically I took the web socket handshake from the websocket v13 spec but with different header names and a different magic number. Stuart Jason Greene wrote: > On Apr 2, 2013, at 4:42 AM, Darran > Lofthouse&lt;darran.lofthouse(a)jboss.com&gt; wrote: > >> Just thinking would http-remoting and https-remoting be better names > > Sounds good to me.