Download Networking Features of the JAVA Programming Language

50-20-44
DATA COMMUNICATIONS MANAGEMENT
NETWORKING FEATURES OF
THE JAVA PROGRAMMING
LANGUAGE
John P. Slone
INSIDE
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
Java is the first language of significance to be developed in what could
be called the ÒPost-Internet RevolutionÓ environment. Although the Internet had been under development for several decades, the advent of the
World Wide Web in the early-to-mid 1990s sparked an explosion of
growth of the Internet that could only be characterized as a revolution.
Consequently, the Internet became a household word and a mainstay of
business computing. Industry analysts project the number of Internetconnected computers to exceed 100 million in the very near future.
Among those 100 million computers, one finds a variety of computing
platforms, ranging from microprocessors costing a few hundred dollars
to highly specialized mainframe or supercomputers costing millions. At
the low end of the cost spectrum, hardware generation life cycles are
measured in months.
For languages developed prior to Java, networking was a specialty area, and the technology of networking was typically handled outside the
language itself, such as through system calls. For Java, networking is a
PAYOFF IDEA
Java is a programming language designed to fafundamental assumption, handled
cilitate development of applications which will run
within the language itself. In the next
in any networked environment across many platsection, some basic concepts are exforms and could be considered as the “ideal” lanamined related to networking in this
guage for heterogeneous computing. It is necesenvironment. In the sections that folsary to understand its networking features to take
maximum advantage of its capabilities.
low, severa l networking mechanisms
Auerbach Publications
© 1999 CRC Press LLC
EXHIBIT 1 — Layered Communications Model of the Internet
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 architecture is the layered architecture developed for the Internet depicted in Exhibit 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. Specifications for this layer address such things as the type of communication medium (such as copper wire, optical fiber, or radio waves), signal
modulation, and bitwise encoding. This layer is almost always implemented 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 retransmission requests as needed to ensure successful delivery. In a local area network (LAN) environment, this layer is often used to implement forwarding
of data packets between LAN segments. This layer is also typically integrated 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 complexity 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 ultimately to the destination end system or systems. The most commonly 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 developer is the IP address. The IP address is a 32-bit number, more commonly 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 telephone 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: connection-oriented and connectionless. The most common service is the connectionoriented 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 exchanging data, the connection is torn down at the request of either end.
A less commonly known service is the connectionless service provided by the user datagram protocol (UDP). UDP provides an unreliable delivery mechanism by simply sending a packet toward the intended
destination, without taking any steps to ensure successful delivery. Although 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 delivered 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 application 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 address. 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 specified 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.
EXHIBIT 2 — Socket-and-Port Transmission of Data
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 network 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 Protocol, or HTTP. This protocol, along with other familiar protocols such as
ftp, gopher, and telnet, is considered a layer 7 protocol. Programmers taking advantage of these protocols can accomplish network programming
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 “presentation,” respectively, with layer 7 defining the “application” layer. Although 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 parties. 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 sockets, and “ServerSocket,” which implements server sockets. The distinction is needed to provide server applications 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 address/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 previous constructor, this one also resolves the name of the remote host
specified in String to find its IP address prior to issuing the connection request.
Constructors on the server side include the following:
• ServerSocket (int) — creates a server socket and binds it to the specified 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 constructor, 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 setTcpNoDelay. Thus, between the constructors and methods, the Socket
and ServerSocket classes provide programmers with a fairly powerful assortment of tools for developing networked applications.
Connectionless Networking
In contrast to connection-oriented networking, connectionless networking is accomplished by sending independent packets between the parties
involved. Rather than having the notion of a connection, which is established at the beginning of the exchange and torn down following the exchange, 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 individually to its destination.
Java provides a separate type of socket class for this purpose: the DatagramSocket. 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 DatagramSocket 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 socket and binds it to the specified port/interface combination on the local 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 “receive,” 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 datagram packet for sending packets of length int to the address and
port specified
DatagramPacket methods are provided to get or set the datagram’s address, 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 DatagramSocket. Of particular interest are the methods joinGroup and
leaveGroup, which allow the system to join and leave a particular multicast group, and the methods getTTL and setTTL, which handle the datagram’s time-to-live attribute.
High-Level Java Networking Abstractions
Up to this point, the discussion has been limited to fairly low-level networking concepts, focused at the transport layer service interface, the
socket. Although extremely powerful when compared with the networking 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 concept also supported within the java.net package. In general terms, URLbased programming allows the programmer to focus on the concepts associated with actually handling a remote object, rather than on all the lower-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 notation 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 assumed), 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 constructors 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, except 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 capabilities 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 subsequent 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 important for interacting with Web-enabled applications, such as those implementing 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 URLConnection. Once a URLConnection object has been created, the programmer 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 concepts such as reading and writing.
Remote Method Invocation (RMI)
As discussed above, URL-based programming allows the Java programmer to interact at a high level with primarily non-Java resources on the
network. RMI provides the Java programmer with the capability of developing 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 magnitude increase in the degrees of complexity and sophistication of the resulting networked applications.
To achieve this level of sophistication, it is necessary to grasp concepts that go beyond the simple definition of classes and methods, although 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 implements 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 value returned by a method. The first such reference is typically obtained
from an RMI remote object registry. For clarity of discussion, the remainder 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. However, instead of containing a reference to the actual remote object, it contains a reference to a locally implemented stub representing the remote
object interface. The stubs are generated through the use of a special compiler tool called “rmic.” Thus, the actual remote method invocation is abstracted 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 extremely 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
EXHIBIT 3 — RMI Architecture
other than the simple fact that they facilitate the development of networked 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 programming 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 directory 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 networking environment. For example, the Internet Domain Name Service
(DNS) is the directory that maps machine names (such as www.yahoo.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 situation, 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).
EXHIBIT 4 — JNDI Architecture
JNDI is implemented in three standard Java extension packages: javax.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 Provider Interface (SPI). Conceptually, a Java application accesses the JNDI
Implementation Manager through the JNDI API, while a variety of naming and directory services sit transparently behind the JNDI Implementation 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 object 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, including 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 spectrum of abstraction levels, ranging from socket-level primitives to remotely accessing objects of any type by merely knowing the object’s name. By
building upon the object-oriented nature of Java, higher and higher levels 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 environment. If one only considers the single aspect of networking as a fundamental 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 potential role of Java in their own environments, and to encourage and promote the development of Java expertise among their staffs.
John P. Slone is Chief Designer, Directory Services at Lockheed Martin Enterprise Information Systems in Orlando, FL, and a consulting editor for Auerbach Publications. He has worked
in the information processing industry since 1978.