Client/server systems built from scratch typically require the design of a communications protocol. For example, before the Web could became as important as it is today, the Hypertext Transfer Protocol, or HTTP, had to be designed so that clients and servers could communicate. This protocol has been through several public versions: 0.9, 1.0, and 1.1. Clients and servers have had to be rebuilt on each version change of even this simple protocol.
RPC systems such as Sun's ONC, CORBA, COM+, and more recently SOAP also rely on a fixed protocol. In these cases, though, there are usually tools available that will generate code to manage the protocol messaging. However, these tools need to generate two sets of code: one for the client side and one for the server side. Any change to the protocol means that both client and server need to have this code regenerated.
This dependence on protocol is tightly bound to how clients address services, which depends on how they find these services. For example, to address a web service, you often need a Web Services Description Language (WSDL) document that contains the URL of the service's server and method names of the service. Coupled with knowledge that the service is addressed using SOAP, a client can then talk to it. With CORBA, you could obtain an object reference in a variety of ways (through a name server, using "stringified" references, or through a trader). Given this reference and the knowledge that CORBA uses the IIOP protocol, a client could then talk to a server.
Changes to a protocol are a nightmare once the protocol has become popular. It took years for all clients and servers to upgrade to HTTP 1.1, and the situation was similar for CORBA protocol changes. The protocol used by sendmail hasn't been touched for years because of the chaos to e-mail that would almost certainly result from any changes, even though many people think it is well past its use-by date.
When you discover a Jini service, you don't get an address to be dealt with by a particular protocol. Instead, you get a Java proxy object with known methods. This alters the playing field in a significant way: the client doesn't need to know the communications protocol at all! It just makes local method calls on the proxy.
The proxy comes from the server, and this is key to client ignorance. The client doesn't know the protocol used between proxy and service since it never has to know. The communications protocol is private to the proxy and the service. That means that the proxy and the service can use any protocol they wish, and it has no effect on the client at all. The proxy and service can change the protocol, and the client never knows.
There is often an assumption that Jini systems must be "all Java." This isn't quite true. Certainly, the client has to be a Java client, although even here there are caveats: strictly speaking, the client must be able to invoke a Java object through a JVM, and there are many languages that can now do this. The proxy needs to be JVM bytecode. Most likely, this bytecode is generated from Java source code, but not necessarily. But on the service side, who knows? The proxy can talk to any service it wants to, using any protocol it has chosen. For example, many people (including myself) have built proxies that will talk SOAP to UPnP devices or web services. The client is ignorant of the service language and has no need to care.
It isn't quite the end of protocols, unfortunately. Jini leads to the end of client knowledge of invocation protocols, but the client still has to discover the Jini proxy; a discovery protocol is still involved. However, the Jini discovery protocol is fairly lightweight and is customized to just this task rather than being a general-purpose protocol. Jini discovery involves a simple protocol to discover a lookup service and then a mechanism for downloading bytecode. In the last section, I pointed out the use of an HTTP server to deliver the proxy bytecode, but this is not a prescribed mechanism for Jini. It would be possible to use other mechanisms such as e-mail or FTP, although I don't think anyone has yet seriously considered doing this, since HTTP seems to be good enough so far.