Disabling HTTP Tunneling HTTP Tunneling

That said, HTTP tunneling is also universally used. At the OReilly P2P Conference in February of 2001, I spent a good part of the first day asking attendees how they dealt with firewalls. I asked 13 people and received the following responses: 2 people said, Firewalls are a problem. 11 people said, Oh. We just tunnel through them. I stopped asking when it sunk in that Id just been told that 11 distinct protocols, for everything from distributed computation to performing a naming-service lookup, were all tunneling through HTTP.

22.8 Disabling HTTP Tunneling

Suns implementation of HTTP tunneling is very nice and very convenient. However, there are situations when you just dont want to use it. For example, suppose there is no web server or servlet to forward the tunneled requests to the intended server. HTTP tunneling wont cause any functional problems in such a case. However, it doesnt help anything either, and could cause performance problems. When a server goes down, RMI will try four distinct ways to connect with it before deciding that the method call failed. If you know in advance that four of these ways will fail, you may as well save the bandwidth and processor cycles. There are two ways to disable HTTP tunneling: • Change the default socket factory. You can write a simple socket factory, one that returns plain-text sockets but does not do any sort of tunneling when requests fail. If you make this socket factory your default socket factory, then RMI will use it to get sockets for connections. Hence, HTTP tunneling will be disabled. Recall that serialized instances of socket factories are carried along with stubs. This means that the place to change the default socket factory is on the server. • Set the java.rmi.server.disableHttp property to the string literal true . The sockets returned by the default socket factory check this property before attempting to tunnel. This property needs to be set on each client. I prefer to use the first option. It involves a little more code and is less flexible™it forces all clients to obey the same policy™but it is a more thorough solution and is much harder to change. It requires a change to the server, which is presumably running in a controlled environment. Making such a change is much harder than changing a property in a client application. I also like the first option because, morally speaking, the server should get to choose the protocol being used. But thats a rather idiosyncratic bias.

Chapter 23. RMI, CORBA, and RMIIIOP

Since 1989, the Object Management Group OMG has been defining and refining a standard called the Common Object Request Broker Architecture or CORBA. CORBA is a specification for distributed object-based computing that enables clients and servers to communicate. CORBA is explicitly platform- and language-independent and is quite heavily used in enterprise computing. In this chapter, Ill introduce CORBA, compare CORBA to RMI, and then discuss RMIIIOP, which is a compromise that allows Java developers to take advantage of some of RMIs features while still writing CORBA applications. By the end of this chapter, youll have an elementary understanding of CORBA and a clear understanding of when to use CORBA and when to use RMI. At some point in the mid-1980s, a number of industry leaders began to realize that every large corporation has a fairly similar computing environment, consisting of the following five components: