Auerbach Publications © 1999 CRC Press LLC
DATA COMMUNICATIONS MANAGEMENT
N
ETWORKING
F
EATURES
OF
THE
J
AVA
P
ROGRAMMING
L
ANGUAGE
John P. Slone
I N S I D E
Java’s Target Environment, Networking Basics, Java Networking Primitives, Connection-Oriented Networking, Connectionless Networking, Multicast Connectionless
Networking, High-Level Java Networking Abstractions, URL-Based Programming, Remote Method Invocation, Java Naming and Directory Interface
JAVA’S TARGET ENVIRONMENT
J a v a i s t h e f i r s t l a n g u a g e o f s i g n i f i c a n c e t o b e d e v e l o p e d i n w h a t c o u l d be called the ÒPost-Internet RevolutionÓ environment. Although the Inter-n e t h a d b e e Inter-n u Inter-n d e r d e v e l o p m e Inter-n t f o r s e v e r a l d e c a d e s , t h e a d v e Inter-n t o f t h e W o r l d W i d e W e b i n t h e e a r l y - t o - m i d 1 9 9 0 s s p a r k e d a n e x p l o s i o n o f g r o w t h o f t h e I n t e r n e t t h a t c o u l d o n l y b e c h a r a c t e r i z e d a s a r e v o l u t i o n . C o n s e q u e n t l y , t h e I n t e r n e t b e c a m e a h o u s e h o l d w o r d a n d a m a i n s t a y o f b u s i n e s s c o m p u t i n g . I n d u s t r y a n a l y s t s p r o j e c t t h e n u m b e r o f I n t e r n e t -c o n n e -c t e d -c o m p u t e r s t o e x -c e e d 1 0 0 m i l l i o n i n t h e v e r y n e a r f u t u r e . A m o n g t h o s e 1 0 0 m i l l i o n c o m p u t e r s , o n e f i n d s a v a r i e t y o f c o m p u t i n g p l a t f o r m s , r a n g i n g f r o m m i c r o p r o c e s s o r s c o s t i n g a f e w h u n d r e d d o l l a r s t o h i g h l y s p e c i a l i z e d m a i n f r a m e o r s u p e r c o m p u t e r s c o s t i n g m i l l i o n s . A t t h e l o w e n d o f t h e c o s t s p e c t r u m , h a r d w a r e g e n e r a t i o n l i f e c y c l e s a r e measured in months. F o r l a n g u a g e s d e v e l o p e d p r i o r t o J a v a , n e t w o r k i n g w a s a s p e c i a l t y a r -e a , a n d t h -e t -e c h n o l o g y o f n -e t w o r k i n g w a s t y p i c a l l y h a n d l -e d o u t s i d -e t h -e l a n g u a g e i t s e l f , s u c h a s t h r o u g h s y s -t e m c a l l s . F o r J a v a , n e -t w o r k i n g i s a f u n d a m e n t a l a s s u m p t i o n , h a n d l e d within the language itself. In the next s e c t i o n , s o m e b a s i c c o n c e p t s a r e e x -a m i n e d r e l -a t e d t o n e t w o r k i n g i n t h i s e n v i r o n m e n t . I n t h e s e c t i o n s t h a t f o l -l o w , s e v e r a -l n e t w o r k i n g m e c h a n i s m s
P A Y O F F I D E A
Java is a programming language designed to fa-cilitate development of applications which will run in any networked environment across many plat-forms and could be considered as the “ideal” lan-guage for heterogeneous computing. It is neces-sary to understand its networking features to take maximum advantage of its capabilities.
are reviewed that are built into Java for the purpose of exploiting this environment.
NETWORKING BASICS
In today’s era of enterprise LANs, the predominant networking architec-ture is the layered architecarchitec-ture developed for the Internet depicted in Ex-hibit 1. This architecture provides an abstract view of networking, arranging functions according to purpose, and providing a clean interface between applications software and the complexities of the network itself. Briefly working from the bottom, the following basic functions are found provided by each layer:
Layer 1 — Physical
This layer is where the actual transmission of data takes place. Specifica-tions for this layer address such things as the type of communication me-dium (such as copper wire, optical fiber, or radio waves), signal modulation, and bitwise encoding. This layer is almost always imple-mented in hardware, and is of no concern to the applications developer.
Layer 2 — Data Link
This layer ensures that transmitted data is actually delivered across the physical medium. Typical functions include error checking and retransmis-sion requests as needed to ensure successful delivery. In a local area net-work (LAN) environment, this layer is often used to implement forwarding of data packets between LAN segments. This layer is also typically integrat-ed in hardware, and is of no concern to the applications developer.
Layer 3 — Network
The primary purpose of this layer is routing. Given the size and complex-ity of networks such as the Internet and LAN-based enterprise networks,
protocols at this layer have been developed to handle the routing of data packets as needed to deliver data from the originating end system, through an indeterminate number of intermediate systems, and ultimate-ly to the destination end system or systems. The most commonultimate-ly known protocol at this layer is the Internet Protocol, or simply the “IP” part of “TCP/IP.” Protocols at this layer are implemented in a combination of hardware and software.
The only aspect of this layer that is of concern to the applications de-veloper is the IP address. The IP address is a 32-bit number, more com-monly expressed in a “dotted numeric” notation such as 204.5.208.18 where each of the four numbers represents the value contained in one of the four bytes of the IP address. The IP address is analogous to a tele-phone number; each system has a globally unique IP address which, when provided to the network layer, is sufficient to ensure that packets are correctly routed to the intended end system.
Layer 4 — Transport
This layer is responsible for the end-to-end delivery of data between end systems. This layer provides two fundamental services: ori-ented and connectionless. The most common service is the connection-oriented service provided by the transmission control protocol (TCP). TCP provides for reliable delivery by maintaining a connection between the end points, and by ensuring that all packets are transmitted without error and in the proper sequence. When the systems are through ex-changing data, the connection is torn down at the request of either end. A less commonly known service is the connectionless service provid-ed by the user datagram protocol (UDP). UDP provides an unreliable de-livery mechanism by simply sending a packet toward the intended destination, without taking any steps to ensure successful delivery. Al-though this concept may seem strange at first, it actually serves a very useful purpose. The classic example is that of time synchronization. If a packet is dropped, it is more important for the next packet to get deliv-ered than it is for the systems to take the time needed to retransmit the missing one, thus throwing the time synchronization system out of synch.
Both of these services provide the primary interface between the ap-plication and the network. From the network perspective, the interface is known as a “port.” A port is essentially a 16-bit extension to the IP ad-dress. It can be thought of as providing a capability similar to that of a telephone extension. That is, while a telephone number will successfully deliver a call to a business location, an extension may need to be speci-fied to reach the intended party. In the same fashion, the IP address will deliver the packet to the end system, but the port must be specified to reach the intended application.
From the perspective of the application, this same point of interface is viewed as a socket. A socket is an abstraction that behaves similarly to other input–output abstractions such as files or printers. A socket is made available for use by the application by binding it to an available port. The application then transmits data across the network by writing to a socket, and it receives data from the network by reading from the socket. This notion of sockets and ports is depicted in Exhibit 2.
Layer 7 — Application
Programmers can effectively utilize network capabilities without being concerned with the application layer. However, a number of standardized network-enabled applications have been written, providing a level of net-work abstraction significantly higher than that of the socket. Perhaps the most familiar of such applications is the World Wide Web, which provides a high-level network abstraction known as the HyperText Transport Pro-tocol, or HTTP. This proPro-tocol, along with other familiar protocols such as ftp, gopher, and telnet, is considered a layer 7 protocol. Programmers tak-ing advantage of these protocols can accomplish network programmtak-ing tasks without being concerned with lower level details such as binding a socket to a port, opening a connection, reading from or writing to the socket, and ultimately closing the connection and unbinding the port. All this is accomplished by the layer 7 protocol.
The Internet model is rooted historically in the OSI Basic Reference Model. In the OSI model, layers 5 and 6 are used for “session” and “pre-sentation,” respectively, with layer 7 defining the “application” layer. Al-though the Internet networking model does not generally use these two layers, the layer number designators have survived.
JAVA NETWORKING PRIMITIVES
With this application-oriented background on networking concepts, one can now discuss Java networking features within the context of these
concepts. In this section, Java networking primitives will be discussed that enable the programmer to develop applications that interact directly with the layer 4. These primitives are found within the java.net package.
Connection-Oriented Networking
Connection-oriented networking employs a paradigm analogous to the telephone network. First, a connection is established between two par-ties. Once established, communications take place by having each party send and listen as needed. Once finished, the connection is broken. As discussed above, rather than using a telephone, each party “speaks” into and “listens” from a socket.
As with practically everything else in Java, the concept of a socket is provided as a class; thus sockets are treated just like any other object in the language. For connection-oriented networking, there are actually two classes of socket objects in Java: “Socket,” which implements client sock-ets, and “ServerSocket,” which implements server sockets. The distinc-tion is needed to provide server applicadistinc-tions with the processing capability of listening for and accepting connection requests from clients. Both are subclasses of SocketImpl, which is where most of the low-level methods and variables are defined. The two subclasses hide many of these details from the programmer. For example, among the constructors for the client-side socket are the following:
• Socket (InetAddress, int) — creates a socket and connects it to the specified port on the host at the specified IP address. With this one, simple constructor, the program will actually create a socket, bind it to a local port, issue a connection request to the remote IP ad-dress/port combination, and wait for an acknowledgment.
• Socket (String, int) — creates a socket and connects it to the specified port on the host named in String. In addition to everything in the pre-vious constructor, this one also resolves the name of the remote host specified in String to find its IP address prior to issuing the connec-tion request.
Constructors on the server side include the following:
• ServerSocket (int) — creates a server socket and binds it to the spec-ified port on the local host.
• ServerSocket (int, int) — same as above, but allows the programmer to specify the maximum allowable backlog of pending requests. • ServerSocket (int, int, InetAddress) — same as the previous
construc-tor, but allows programmer to specify which network interface on multi-homed machines (e.g., machines sitting on firewalls).
Similarly powerful methods are available for these classes, including fairly high-level methods such as getInputStream and getOutputStream,
as well as lower-level methods such as getInetAddress, getPort, and set-TcpNoDelay. Thus, between the constructors and methods, the Socket and ServerSocket classes provide programmers with a fairly powerful as-sortment of tools for developing networked applications.
Connectionless Networking
In contrast to connection-oriented networking, connectionless network-ing is accomplished by sendnetwork-ing independent packets between the parties involved. Rather than having the notion of a connection, which is estab-lished at the beginning of the exchange and torn down following the ex-change, each individual packet, called a datagram, must be provided with the necessary addressing information. This paradigm is closer to that of the postal system, in which a letter, complete with destination and return addresses, is dropped in the nearest mailbox and routed individu-ally to its destination.
Java provides a separate type of socket class for this purpose: the Da-tagramSocket. In this case, there is no distinction between a server socket and a client socket, since datagrams are sent and received outside the context of a connection. Fundamentally a simpler concept, the Data-gramSocket has only three constructors:
• DatagramSocket ( ) — This constructor creates a socket and binds it to any available port on the local machine.
• DatagramSocket (int) — This constructor creates a socket and binds it to the specified port on the local machine.
• DatagramSocket (int, InetAddress) — This constructor creates a sock-et and binds it to the specified port/interface combination on the lo-cal machine.
Note that this class of socket is only associated with the local machine. Because there is no notion of a connection, there is no association with a remote machine.
Once a datagram socket object has been created, the programmer may invoke one of several methods. Of most importance are “send” and “re-ceive,” used to send or receive datagrams, respectively. Datagrams are implemented as a separate class, known as a DatagramPacket. This class has two constructors:
• DatagramPacket (byte[ ], int) — used to create a datagram packet for receiving datagrams of length int
• DatagramPacket (byte[ ], int, InetAddress, int) — used to create a da-tagram packet for sending packets of length int to the address and port specified
DatagramPacket methods are provided to get or set the datagram’s ad-dress, port, data, or length as needed.
Multicast Connectionless Networking
Connectionless networking can also be accomplished between multiple parties, as opposed to the limited notion of point-to-point networking. Java provides a MulticastSocket class for this purpose as a subclass of Da-tagramSocket. Of particular interest are the methods joinGroup and leaveGroup, which allow the system to join and leave a particular multi-cast group, and the methods getTTL and setTTL, which handle the data-gram’s time-to-live attribute.
High-Level Java Networking Abstractions
Up to this point, the discussion has been limited to fairly low-level net-working concepts, focused at the transport layer service interface, the socket. Although extremely powerful when compared with the network-ing features of most other languages, these features are little more than primitives within the context of Java networking features. The remainder of this article focuses on several of the higher-level networking concepts provided in Java.
URL-Based Programming
The first such concept discussed is that of URL-based programming, a con-cept also supported within the java.net package. In general terms, URL-based programming allows the programmer to focus on the concepts as-sociated with actually handling a remote object, rather than on all the low-er-level mechanisms involved in creating a socket and binding it to a port, establishing a connection to the object’s machine, locating the object, and retrieving information from or sending information to the object. How this is accomplished should become clearer in the following paragraphs.
The fundamental class provided for this purpose is the URL. This class, whose name stands for Uniform Resource Locator, uses a standard nota-tion for representing a resource on the network. Popularized by the World Wide Web, the basic URL provides four primary components: a protocol identifier (such as http, ftp, or gopher), a machine name (such as www.yahoo.com), a port number (if not specified, a default port is as-sumed), and a file name (including the path to the file). The file name component can also optionally contain an internal reference to a specific named label within the file. The Java URL class provides four construc-tors to allow flexibility in the way a URL object is created:
• URL (String) — allows the creation of a URL object by specifying a complete, familiar URL specification such as http://www.yahoo.com/
• URL (String, String, int, String) — allows the creation of a URL object by separately specifying the protocol, host name, port, and file name • URL (String, String, String) — same as the previous constructor,
ex-cept that the default port is assumed
• URL (URL, String) — allows the creation of a URL by specifying its path relative to an existing URL object
Once the URL object has been created, Java provides a number of low-level methods, such as those that parse the URL and return specific elements, as well as several high-level methods, providing powerful ca-pabilities to the programmer. Examples of high-level methods include getContent, which returns the entire content of the specified URL with a single line of code. Other high-level methods include openStream, which creates a connection to the URL and opens an input stream for subse-quent reading of the contents, and openConnection, which creates a connection to the URL and opens a bidirectional stream for subsequent writing to or reading from the URL. This latter method is especially portant for interacting with Web-enabled applications, such as those im-plementing the Common Gateway Interface (CGI).
As implied by the previous paragraph, there is a concept of a URL connection, a concept that is also provided as a class known as a URL-Connection. Once a URLConnection object has been created, the pro-grammer has nearly 40 methods at his disposal for handling the connection. Among the capabilities provided by these methods are those of reading selected header fields, testing to see whether the URL accepts input, whether the URL is cached, when it was last modified, or when it expires. These methods are in addition to the methods for obvious con-cepts such as reading and writing.
Remote Method Invocation (RMI)
As discussed above, URL-based programming allows the Java program-mer to interact at a high level with primarily non-Java resources on the network. RMI provides the Java programmer with the capability of devel-oping truly distributed, yet fully cooperative Java-only applications. These cooperating Java components can be peer applications, client and server applications, or client applets interacting with server applications. Compared with URL-based programming, RMI allows an order of magni-tude increase in the degrees of complexity and sophistication of the re-sulting networked applications.
To achieve this level of sophistication, it is necessary to grasp con-cepts that go beyond the simple definition of classes and methods, al-though numerous classes are defined in the java.rmi family of packages. Instead, the exploitation of RMI requires a paradigm shift in the way one thinks about network-based programming. At a very high level, RMI
re-quires the development of two components: a Java object that imple-ments a method through a remote interface, and a Java object that remotely invokes that method. These two objects may be on the same machine or on different machines. Conceptually, all that is necessary to make this happen is for the calling object to obtain a valid reference to the called method in the form of a specially constructed URL. In most cases, the object reference is obtained either as a parameter or as the val-ue returned by a method. The first such reference is typically obtained from an RMI remote object registry. For clarity of discussion, the remain-der of this section will assume that the object that implements the remote method is a server application, and that the object requesting the remote invocation is an applet.
Looking first at the server, the necessary ingredients are the definition of a remote interface, the definition of constructors for the remote object, and the definition of methods that can be invoked remotely. In addition, there are security requirements, but treatment of security is beyond the scope of this article. Finally, at least one of the remote objects must be registered in the RMI remote object registry on the server machine. At execution time, the constructor for the remote object creates an instance of the object and exports the object by having it listen to a socket for incoming calls.
Turning attention to the applet side, it can be seen that the calling object calls the remote method very much as it would any other method. How-ever, instead of containing a reference to the actual remote object, it con-tains a reference to a locally implemented stub representing the remote object interface. The stubs are generated through the use of a special com-piler tool called “rmic.” Thus, the actual remote method invocation is ab-stracted in a way that isolates the programmer from the details.
The invocation and all the necessary semantics are actually handled by the remote reference layer, and take place as follows. First, the applet calls a method making reference to a locally held stub. The stub then places the appropriate remote call, across the network if necessary, to its counterpart remote interface on the server side. That interface, in turn, invokes a method on the server side and passes the resulting return value back through the interface, across the network to the applet stub code, and on to the calling object. This interaction is depicted in Exhibit 3.
Thus it is shown that RMI provides the Java programmer with an ex-tremely powerful set of networking capabilities. As with other high-level networking features of the Java language, RMI allows the programmer to focus on the essentials of writing and invoking methods that accomplish a certain task, while ignoring the details of the underlying network.
Java Naming and Directory Interface (JNDI)
The two high-level networking features of the Java language discussed thus far, URL-based programming and RMI, have one thing in common
other than the simple fact that they facilitate the development of net-worked applications. Specifically, both involve the notion of binding a name to a network-based resource. With URL-based programming, this resource is either a file- or a stream-based interface to an application. With RMI, the resource is a method in some remote object. Broadening the perspective to yet another dimension, it is found that network pro-gramming for any purpose will inevitably involve the binding of names to resources.
At the broadest possible level, network-accessible resources can be any type of object. For example, in addition to files, stream interfaces, and methods, other valid resources could include printers, calendars, electronic mailboxes, telephones, pagers, humans, conference rooms, control valves, remote sensors, or practically anything else, limited only by the imagination. To expand programming to this broad horizon, the concept of a generalized directory is needed. In the broadest sense, a di-rectory can be thought of as a system that provides a mapping between the name of an object and one or more attributes that describe the object. In practice, there are multiple directories in existence in today’s net-working environment. For example, the Internet Domain Name Service (DNS) is the directory that maps machine names (such as www.ya-hoo.com) to IP addresses (such as 204.71.200.74). Other directories, such as X.500, LDAP, NIS, and NDS, provide mapping between objects named in other name spaces and their attributes. Further complicating the situa-tion, certain objects are actually identified by compound names — those names that exist in multiple, disjointed name spaces. URLs are a prime example, since part of the URL names the machine (named in the DNS name space), and part of it names the file (named within the name space managed by the particular machine).
To provide the simplest abstraction for programmers, what is needed is a mechanism that allows objects to be identified to programs by their compound names (such as a URL), while hiding the complexities of the underlying directory structures. This is precisely the objective of the Java Naming and Directory Interface (JNDI).
JNDI is implemented in three standard Java extension packages: jav-ax.naming, javax.naming.directory, and javax.naming.spi. The first two packages comprise the JNDI Application Programming Interface (API), giving application programmers a suite of powerful classes and methods for handling object names and for interacting with the directory services. The third package makes up what is referred to as the JNDI Service Pro-vider Interface (SPI). Conceptually, a Java application accesses the JNDI Implementation Manager through the JNDI API, while a variety of nam-ing and directory services sit transparently behind the JNDI Implementa-tion Manager, plugged in through the JNDI SPI. This concept is depicted in Exhibit 4.
Of particular interest for this article is the naming and directory service shown in the lower left portion of Exhibit 4, RMI. As shown, the RMI ob-ject registry becomes a part of a substantially larger naming and directory service, and is implemented through the same classes and methods used for other network-based resources. In this manner, the entire world of network-accessible resources is placed literally at the fingertips of the Java programmer.
CONCLUSION
This article has barely begun to scratch the surface of network features built into the Java programming language. Many powerful features, in-cluding those discussed in this article along with many more, are built into the core Java packages; others are implemented as extensions. Through these features, Java provides programmers with the ability to write programs that implement networking concepts along a wide spec-trum of abstraction levels, ranging from socket-level primitives to remote-ly accessing objects of any type by mereremote-ly knowing the object’s name. By building upon the object-oriented nature of Java, higher and higher lev-els of abstraction are readily accommodated.
In the opening, it was suggested that the ultimate success of Java as a language would depend to an extent on how purposeful the designers were with respect to designing the language in the context of its target en-vironment. If one only considers the single aspect of networking as a fun-damental component of Java’s target environment, one can only conclude that Java is set to profoundly impact the computer science discipline in the years to come. As such, IT managers are well advised to assess the po-tential role of Java in their own environments, and to encourage and pro-mote the development of Java expertise among their staffs.
John P. Slone is Chief Designer, Directory Services at Lockheed Martin Enterprise Informa-tion Systems in Orlando, FL, and a consulting editor for Auerbach PublicaInforma-tions. He has worked in the information processing industry since 1978.
