Unlike the socket transport and its derivatives, which interact directly with Sockets and ServerSockets, the http family of transports uses java.net.HttpURLConnections. While they do not exhibit the same performance as the socket transports, they have the advantage of using the universal http protocol.
Any of JBoss Messaging, EJB2, and EJB3 can use the http transports instead of the socket family of transports. Additional configuration information may be found in the wiki articles EJB, JMS and JNDI over HTTP with Unified Invoker and EJB, JMS and JNDI over HTTP via NAT Firewall with Unified Invoker.
On the client side, an org.jboss.remoting.transport.http.HTTPClientInvoker, a subclass of RemoteClientInvoker, creates a java.net.HttpURLConnection for each invocation. The caching of HttpURLConnections and their Socket is left to the implementation. On the server side, the org.jboss.remoting.transport.coyote.CoyoteInvoker, which is a subclass of ServerInvoker and is based on the coyote module in Tomcat, processes http requests, calls on ServerInvoker to hand invocations off to the appropriate ServerInvocationHandler, and returns a result along with a response code.
The https transport is derived from the http transport and uses javax.net.ssl.SSLSockets and javax.net.ssl.SSLServerSockets instead of Sockets and ServerSockets.
The servlet and sslservlet transports share the client side code of the http and https transports, respectively. On the server side, the difference is that the servlet and sslservlet transports use a servlet, org.jboss.remoting.transport.servlet.web.ServerInvokerServlet, to hand an invocation off to an org.jboss.remoting.transport.servlet.ServletServerInvoker. In other words, the servlet and sslservlet transports share a port with all other servlets running in the Application Server, while the http and https transports use a separate port managed by a CoyoteInvoker.
When the ServerInvokerServlet is initialized, it needs to be informed of which ServletServerInvoker to use. One way of doing that is to give it the appropriate InvokerLocator. For example, the following web.xml file is used by JBoss Messaging:
<web-app>
<servlet>
<servlet-name>JmsServerInvokerServlet</servlet-name>
<description>The JmsServerInvokerServlet receives JMS requests via HTTP
protocol from within a web container and passes it onto the
ServletServerInvoker for processing.
</description>
<servlet-class>org.jboss.remoting.transport.servlet.web.ServerInvokerServlet</servlet-class>
<init-param>
<param-name>locatorUrl</param-name>
<param-value>
<![CDATA[servlet://${jboss.bind.address}:8080/servlet-invoker/JmsServerInvokerServlet/?dataType=jms&JBM_clientMaxPoolSize=200&failureDisconnectTimeout=0&marshaller=org.jboss.jms.wireformat.JMSWireFormat&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&pingFrequency=214748364&pingWindowFactor=10&stopLeaseOnFailure=true&clientLeasePeriod=10000&validatorPingPeriod=10000&validatorPingTimeout=5000&timeout=0&blockingMode=blocking&blockingTimeout=30000&useAllParams=true&useClientConnectionIdentity=true]]>
</param-value>
<description>The servlet server invoker</description>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>JmsServerInvokerServlet</servlet-name>
<url-pattern>/JmsServerInvokerServlet/*</url-pattern>
</servlet-mapping>
</web-app>
Unlike the bisocket transport, which was designed especially to allow push callbacks without opening a port on the client side, a server in any of the http transports necessarily opens a ServerSocket, so push callbacks are ruled out when JBoss Messaging runs on any of the http transports. Pull callbacks are used instead, and there are some configuration parameters that can be set:
blockingMode - indicates whether to use blocking or nonblocking mode when doing pull callbacks. In nonblocking mode a poller periodically polls for waiting callbacks, and, if there are none, returns. In blocking mode, the poller periodically polls for waiting callbacks, and, if there are none, the call blocks on the server side until a callback is made available, at which point the poller immediately retrieves the callback to the client side. Blocking mode, then, is more responsive, and it is used by JBoss Messaging. By default, nonblocking mode is used.
blockingTimeout - when pull callbacks are used in blocking mode, indicates the amount of time the callback poller should block on the server side waiting for a callback. The default value is 5000 milliseconds, but JBoss Messaging uses 30000 milliseconds.