Components

Components

Jini is just one of a large number of distributed systems architectures, including industry-pervasive systems, such as CORBA and DCOM. It is distinguished by being based on Java and deriving many features purely from this Java basis. One of the later chapters in this book discusses bridging between Jini and CORBA, as an example of linking these different distributed architectures.

There are other Java frameworks from Sun that might appear to overlap Jini, such as Enterprise Java Beans (EJBs). EJBs make it easier to build business logic servers, whereas Jini would be better used to distribute those services in a "network plug and play" manner.

You should be aware that Jini is only one competitor in a non-empty market. The success or failure of Jini will result partly from the politics of the market, but also (hopefully!) the technical capabilities of Jini, and this book will deal with some of the technical issues involved in using Jini.

In a running Jini system, there are three main players. There is a service, such as a printer, a toaster, a marriage agency, etc. There is a client which would like to make use of a service. Third, there is a lookup service (service locator), which acts as a broker/ trader /locator between services and clients . There is one additional component, and that is a network connecting all three of these. This network will generally be running TCP/IP. (The Jini specification is fairly independent of network protocol, but the only current implementation is on TCP/IP.) See Figure 1-1.

Figure 1-1: Components of a Jini system

Debugging

Debugging a Jini application is difficult because there are so many bits to it, and these bits are all running separately: the server for a service, the client, the lookup services, the remote activation daemons, and the HTTP servers. There are a few (not many) errors within the Jini objects themselves , but more importantly, many of these objects are implemented using multiple threads, and the flow of execution is not always clear. There are no magic "debug" flags that can be turned on to show what is happening.

On either the client or service side, a debugger such as jdb can be used to step through or trace execution of a client or server. Lots of print statements help too. There are also three flags that can be turned on to help:

java -Djava.security.debug=access \
   -Dnet.jini.discovery.debug=1 \
   -Djava.rmi.server.logCalls=true ...