The implicit objects and the power of Java are all brought together with JSP actions. Actions affect the current out stream and use, modify or create objects. The actions to be performed will be determined by the details of the request object received by the JSP page. The JSP specification includes actions types that are standard and must be implemented by conforming engines. The syntax for action elements is based on XML.

The actions all start with Directives. Directives are messages to the JSP engine and the syntax is:

<%@ directive {attr=”value”}*%>

Directives do not produce any output into the current out stream but they are important in setting up your JSP pages attributes and dependencies with the JSP engine. As an example the line:

<%@ page language=”java” %>

says that the scripting language being used within the JSP page is Java. In fact the specification only describes the semantics of scripts for the language attribute equal to Java. This should give you an idea of the flexibility that is being built into the JSP technology. In the future, if you were to choose another language, say Python (a good scripting choice), then that language would have to support the Java Run-time Environment by exposing the Java technology object model to the script environment, especially the implicit variables defined above, JavaBeans properties, and public methods.

The most important directive is the page directive. It defines a number of page dependent attributes and communications these attributes to the JSP engine. These attributes include: language, extends, import, session, buffer, autoFlush, isThreadSafe, info and errorPage. For example:

<%@ page session=”true” import=”java.util.*” %>

This line indicates that the page requires participation in an (HTTP) session. Since we have not set the language directive the JSP engine defaults to java and the implicit script language variable named “session” is of type javax.servlet.http.HttpSession. If the directive had been false then the implicit variable “session” would be unavailable, the default is true.

The import attribute describes the types that are available to the scripting environment. This attribute is used just as it would be in the Java programming language i.e. a (comma separated) list of either a fully qualified Java type name denoting that type, or of a package named followed by the “.*” string denoting all the public types declared in that package. The import list is imported by the translated JSP page implementation and is available to the scripting environment. Again, this is currently only defined for when the value of the language directive is “java”.

Once the directives have been used to set the scripting environment we can utilize the scripting language elements. JSP 1.1 has three scripting language elements—declarations, scriptlets, and expressions. A declaration will declare elements, a scriptlet is a statement fragment, and an expression is a complete language expression. In JSP each scripting element begins with a “<%”. The exact syntax for each is:

<%! declaration %>

<% scriptlet %>

<%= expression %>

White space is optional after “<%!”, “<%”, “<%=”, and before “%>”.

As mentioned earlier, all these tags are based upon XML. More accurately you could state that a JSP page could be mapped to a XML document and although this is a little touted section of the specification, I suspect you will be hearing more and more about this aspect of JSP as Java, XML, and server-side Java become more intertwined. I will not go into these mapping details here but you should be aware of them and if you need more details you should refer to the JSP specification. Therefore, you should realize that the XML equivalent syntax for the scripting elements above would be:

<jsp:declaration> declaration </jsp:declaration>

<jsp:scriptlet> scriptlet </jsp:scriptlet>

<jsp:expression> expression </jsp:expression>

Declarations are used to declare variables and methods in the scripting language used in a JSP page—Java at this time. The declaration should be a complete Java statement and should not produce any output in the current out stream. In the Hello.jsp example below the variables loadTime, loadDate and hitCount are all complete Java statements declares new variables and initializes them.

//:! c15:jsp:Hello.jsp

<%-- This JSP comment will not appear in the

generated html --%>

<%-- This is a JSP directive: --%>

<%@ page import="java.util.*" %>

<%-- These are declarations: --%>

<%!

long loadTime= System.currentTimeMillis();

Date loadDate = new Date();

int hitCount = 0;

<%-- The next several lines are the result of a

JSP expression inserted in the generated html;

the '=' indicates a JSP expression --%>

<H1>This page was loaded at <%= loadDate %> </H1>

<H1>Hello, world! It's <%= new Date() %></H1>

<H2>Here's an object: <%= new Object() %></H2>

<H2>This page has been up

<%= (System.currentTimeMillis()-loadTime)/1000 %>

seconds</H2>

<H3>Page has been accessed <%= ++hitCount %>

times since <%= loadDate %></H3>

<%-- A "scriptlet" which writes to the server

console. Note that a ';' is required: --%>

System.out.println("Goodbye");

out.println(“Cheerio”);

</body></html>

///:~

At the tail end of Hello.jsp is a scriptlet that writes “Goodbye” to the Web server console and “Cheerio” to the implicit out JspWriter object. Scriptlets can contain any code fragments that are valid Java statements. Scriptlets are executed at request-processing time. When all the scriptlets fragments in a given JSP are combined in the order they appear in the JSP page, they should yield a valid statement as defined by the Java programming language. Whether or not they produce any output into the out stream depends upon the actual code in the scriptlet. You should be careful as scriptlets can have side effects through their modification of the objects visible within them.

JSP expressions can found intermingled with the HTML in the middle section of Hello.jsp. Expressions are interesting because they must be complete Java statements, which are then evaluated. The result of the JSP expression is coerced to a java.lang.String which is emitted into the current implicit out JspWriter object. If the result of the expression cannot be coerced to a java.lang.String then a ClassCastException is thrown.

Extracting fields and values

//:! c15:jsp:DisplayFormData.jsp

<%-- Fetching the data from an HTML form. --%>

<%-- This JSP also generates the form. --%>

<%@ page import="java.util.*" %>

<H1>DisplayFormData</H1><H3>

Enumeration f = request.getParameterNames();

if(!f.hasMoreElements()) { // No fields

for(int i = 0; i < 10; i++) {

Field<%=i%>:

<input type="text" size="20"

name="Field<%=i%>" value="Value<%=i%>"><br>

<% } %>

</form>

<% } %>

Enumeration flds = request.getParameterNames();

while(flds.hasMoreElements()) {

String field = (String)flds.nextElement();

String value = request.getParameter(field);

}

%></H3></body></html>

///:~

JSP Page Attributes and Scope

I have spent some time trying to get my code editor to view a .jsp page with syntax highlighting. This is bit more difficult than it would seem. Is a .jsp page Java or is it HTML? That's easy - it's both. So setting up my color coding was like melding the HTML section with the Java section. The real pint is that a .jsp page provides a new set of tags that allows you to separate the passive display code (HTML) from the dynamic programming code (Java).

There is no reason you can't have a whole block of code that performs some action that will provide content for you HTML. This action could be a database call or a call to some other resource. PageContext.jsp below calls getAttributeNamesInScope( ) method of pageContext to get all the attributes in the scope passed in (1 refers to page).

//:! c15:jsp:PageContext.jsp

<%--Viewing the attributes in the pageContext--%>

<%-- Note that you can include any amount of code

inside the scriptlet tags --%>

<%@ page import="java.util.*" %>

session.setAttribute("My dog", "Ralph");

for(int scope = 1; scope <= 4; scope++) {

out.println("<H3>Scope: " +

scope + "</H3><BR>");

Enumeration e =

pageContext.getAttributeNamesInScope(scope);

while(e.hasMoreElements()) {

out.println("\t<li>" +

e.nextElement() + "</li>");

}

</body></html>

///:~

The output looks like this:

Scope: 1

• javax.servlet.jsp.jspOut

• javax.servlet.jsp.jspPage

• javax.servlet.jsp.jspSession

• javax.servlet.jsp.jspApplication

• javax.servlet.jsp.jspPageContext

• javax.servlet.jsp.jspConfig

• javax.servlet.jsp.jspResponse

• javax.servlet.jsp.jspRequest

Scope: 2

• org.apache.tomcat.servlet.resolved

Scope: 3

• My dog

Scope: 4

• sun.servlet.workdir

• javax.servlet.context.tempdir

End of list

Scope 1 is the page scope and all objects reference available in this scope will be discarded upon completion of the current request by the page body. Scope 2 refers to the request scope and will be discarded upon completion of the current client request. As you can see I am using the Apache Tomcat implementation of the Servlets and JSP. (I am not sure what org.apache.tomcat.servlet.resolved is I will try to find out.) Scope 3 will be our session scope and the only object we have with session scope is the one that we added right before the for loop - "My dog". Scope 4 is the scope of our application and is based upon the ServletContext object. There is one ServletContext per "Web application" per Java Virtual Machine. (A "Web application" is a collection of servlets and content installed under a specific subset of the server's URL namespace such as /catalog. In the Tomcat release this information is set via server.xml file.) At the application scope level we have to objects that represent paths for working directory and temporary directory.

Manipulating sessions in JSP

Let's take a closer look at sessions within the JSP model. The next example will exercise the session object a little bit and allow you to manipulate the amount of time before your session becomes invalid. First we must capture some information about this session object. I make a call to getID( ), getCreationTime( ) and getMaxInactiveInterval( ) and display these attributes about our session. When I first bring this session up in the Tomcat implementation the MaxInactiveInterval is 1800 seconds or 30 minutes. Now I know a bit about my session, so lets change its behavior by shortening the MaxInactiveInterval to 5 seconds. Now we should see some action. Next, I check to see if the object "My dog" is attached to the session object giving it session scope. The first time through this should be null but right afterwards we do create a String object "Ralph" and attach it to the session object by call setAttribute( ). Now Ralph should hang around for at least 5 seconds. The invalidate button at the bottom calls a second .jsp page SessionObject2.jsp that simply asks the session if it has the object tagged "My dog" then kills the session by calling invalidate( ) on the session object. "Ralph" is gone. The other button on the bottom of SessionObject.jsp is "Keep Around". This calls a third page, SessionObject3.jsp, that does NOT invalidate the session and you can see that "Ralph" in fact does hang around as long as your 5 second time interval does not expire. Try the refresh button on SessionObject.jsp or move back and forth between SessionObject and SessionObject3.jsp (Keep Around button) a couple of times using different intervals to get a feel for how long "My dog" stays around. (For those of you who have kids this is like the Tomagotchi pets - as long as you play with "Ralph" he will stick around otherwise he packs it up :-)

//:! c15:jsp:SessionObject.jsp

<%--Setting and getting session object values--%>

<html><body>

<H1>Session id: <%= session.getId() %></H1>

<H3><li>This session was created at

<%= session.getCreationTime() %></li></H1>

<H3><li>MaxInactiveInterval=

<%= session.getMaxInactiveInterval() %></li></H3>

<% session.setMaxInactiveInterval(5); %>

<H3><li>Reset MaxInactiveInterval=

<%= session.getMaxInactiveInterval() %></li></H3>

<H2>If this session object "My dog" is still around <H2>

<H3><li>Session value for "My dog" =

<%=

session.getAttribute("My dog")

%></li></H3>

<%-- Now add the session object "My dog" --%>

session.setAttribute("My dog",

new String("Ralph"));

<H1>My dog's name is

<%= session.getAttribute("My dog") %></H1>

<%-- See if "My dog" wanders to another form --%>

<FORM TYPE=POST ACTION=SessionObject2.jsp>

<INPUT TYPE=submit name=submit Value="Invalidate">

</FORM>

<FORM TYPE=POST ACTION=SessionObject3.jsp>

<INPUT TYPE=submit name=submit Value="Keep Around">

</FORM>

</body></html>

///:~

//:! c15:jsp:SessionObject2.jsp

<%--The session object carries through--%>

<html><body>

<H1>Session id: <%= session.getId() %></H1>

<H1>Session value for "My dog"

<%= session.getValue("My dog") %></H1>

<% session.invalidate(); %>

</body></html>

///:~

//:! c15:jsp:SessionObject3.jsp

<%--The session object carries through--%>

<html><body>

<H1>Session id: <%= session.getId() %></H1>

<H1>Session value for "My dog"

<%= session.getValue("My dog") %></H1>

<FORM TYPE=POST ACTION=SessionObject.jsp>

<INPUT TYPE=submit name=submit Value="Return">

</FORM>

</body></html>

///:~

Creating and modifying Cookies

//:! c15:jsp:Cookies.jsp

<%--This program has different behaviors under

different browsers! --%>

<H1>Session id: <%= session.getId() %></H1>

Cookie[] cookies = request.getCookies();

for(int i = 0; i < cookies.length; i++) { %>

Cookie name: <%= cookies[i].getName() %> <br>

value: <%= cookies[i].getValue() %><br>

Max age in seconds:

<%= cookies[i].getMaxAge() %><br>

<% cookies[i].setMaxAge(3); %>

Max age in seconds:

<%= cookies[i].getMaxAge() %><br>

<% response.addCookie(cookies[i]); %>

<% } %>

<%-- <% response.addCookie(

new Cookie("Bob", "Car salesman")); %> --%>

</body></html>

///:~

RMI (Remote Method Invocation)

Traditional approaches to executing code on other machines across a network have been confusing as well as tedious and error-prone to implement. The nicest way to think about this problem is that some object happens to live on another machine, and you can send a message to that object and get a result as if the object lived on your local machine. This simplification is exactly what Java 1.1 Remote Method Invocation (RMI) allows you to do. This section walks you through the steps necessary to create your own RMI objects.

Remote interfaces

RMI makes heavy use of interfaces. When you want to create a remote object, you mask the underlying implementation by passing around an interface. Thus, when the client gets a reference to a remote object, what they really get is an interface reference, which happens to connect to some local stub code that talks across the network. But you don’t think about this, you just send messages via your interface reference.

When you create a remote interface, you must follow these guidelines:

The remote interface must be public (it cannot have “package access,” that is, it cannot be “friendly”). Otherwise, a client will get an error when attempting to load a remote object that implements the remote interface.

The remote interface must extend the interface java.rmi.Remote.

Each method in the remote interface must declare java.rmi.RemoteException in its throws clause in addition to any application-specific exceptions.

A remote object passed as an argument or return value (either directly or embedded within a local object) must be declared as the remote interface, not the implementation class.

Here’s a simple remote interface that represents an accurate time service:

//: c15:rmi:PerfectTimeI.java

// The PerfectTime remote interface.

package c15.rmi;

import java.rmi.*;

interface PerfectTimeI extends Remote {

long getPerfectTime() throws RemoteException;

} ///:~

It looks like any other interface except that it extends Remote and all of its methods throw RemoteException. Remember that an interface and all of its methods are automatically public.

Implementing the remote interface

The server must contain a class that extends UnicastRemoteObject and implements the remote interface. This class can also have additional methods, but only the methods in the remote interface will be available to the client, of course, since the client will get only a reference to the interface, not the class that implements it.

You must explicitly define the constructor for the remote object even if you’re only defining a default constructor that calls the base-class constructor. You must write it out since it must throw RemoteException.

Here’s the implementation of the remote interface PerfectTimeI:

//: c15:rmi:PerfectTime.java

// The implementation of

// the PerfectTime remote object.

package c15.rmi;

import java.rmi.*;

import java.rmi.server.*;

import java.rmi.registry.*;

import java.net.*;

public class PerfectTime

extends UnicastRemoteObject

implements PerfectTimeI {

// Implementation of the interface:

public long getPerfectTime()

throws RemoteException {

return System.currentTimeMillis();

}

// Must implement constructor

// to throw RemoteException:

public PerfectTime() throws RemoteException {

// super(); // Called automatically

}

// Registration for RMI serving:

public static void main(String[] args) {

System.setSecurityManager(

new RMISecurityManager());

try {

PerfectTime pt = new PerfectTime();

Naming.bind(

"//peppy:2005/PerfectTime", pt);

System.out.println("Ready to do time");

} catch(Exception e) {

e.printStackTrace();

}

} ///:~

Here, main( ) handles all the details of setting up the server. When you’re serving RMI objects, at some point in your program you must:

Create and install a security manager that supports RMI. The only one available for RMI as part of the Java distribution is RMISecurityManager.

Create one or more instances of a remote object. Here, you can see the creation of the PerfectTime object.

Register at least one of the remote objects with the RMI remote object registry for bootstrapping purposes. One remote object can have methods that produce references to other remote objects. This allows you to set it up so the client must go to the registry only once, to get the first remote object.

Setting up the registry

Here, you see a call to the static method Naming.bind( ). However, this call requires that the registry be running as a separate process on the computer. The name of the registry server is rmiregistry, and under 32-bit Windows you say:

start rmiregistry

to start it in the background. On Unix, it is:

rmiregistry &

Like many network programs, the rmiregistry is located at the IP address of whatever machine started it up, but it must also be listening at a port. If you invoke the rmiregistry as above, with no argument, the registry’s port will default to 1099. If you want it to be at some other port, you add an argument on the command line to specify the port. For this example, the port will be located at 2005, so the rmiregistry should be started like this under 32-bit Windows:

start rmiregistry 2005

or for Unix:

rmiregistry 2005 &

The information about the port must also be given to the bind( ) command, as well as the IP address of the machine where the registry is located. But this brings up what can be a frustrating problem if you’re expecting to test RMI programs locally the way the network programs have been tested so far in this chapter. In the JDK 1.1.1 release, there are a couple of problems:[69]

localhost does not work with RMI. Thus, to experiment with RMI on a single machine, you must provide the name of the machine. To find out the name of your machine under 32-bit Windows, go to the control panel and select “Network.” Select the “Identification” tab, and you’ll see your computer name. In my case, I called my computer “Peppy.” It appears that capitalization is ignored.

RMI will not work unless your computer has an active TCP/IP connection, even if all your components are just talking to each other on the local machine. This means that you must connect to your Internet service provider before trying to run the program or you’ll get some obscure exception messages.

With all this in mind, the bind( ) command becomes:

Naming.bind("//peppy:2005/PerfectTime", pt);

If you are using the default port 1099, you don’t need to specify a port, so you could say:

Naming.bind("//peppy/PerfectTime", pt);

You should be able to perform local testing by leaving off the IP address and using only the identifier:

Naming.bind("PerfectTime", pt);

The name for the service is arbitrary; it happens to be PerfectTime here, just like the name of the class, but you could call it anything you want. The important thing is that it’s a unique name in the registry that the client knows to look for to procure the remote object. If the name is already in the registry, you’ll get an AlreadyBoundException. To prevent this, you can always use rebind( ) instead of bind( ), since rebind( ) either adds a new entry or replaces the one that’s already there.

Even though main( ) exits, your object has been created and registered so it’s kept alive by the registry, waiting for a client to come along and request it. As long as the rmiregistry is running and you don’t call Naming.unbind( ) on your name, the object will be there. For this reason, when you’re developing your code you need to shut down the rmiregistry and restart it when you compile a new version of your remote object.

You aren’t forced to start up rmiregistry as an external process. If you know that your application is the only one that’s going to use the registry, you can start it up inside your program with the line:

LocateRegistry.createRegistry(2005);

Like before, 2005 is the port number we happen to be using in this example. This is the equivalent of running rmiregistry 2005 from a command line, but it can often be more convenient when you’re developing RMI code since it eliminates the extra steps of starting and stopping the registry. Once you’ve executed this code, you can bind( ) using Naming as before.

Creating stubs and skeletons

If you compile and run PerfectTime.java, it won’t work even if you have the rmiregistry running correctly. That’s because the framework for RMI isn’t all there yet. You must first create the stubs and skeletons that provide the network connection operations and allow you to pretend that the remote object is just another local object on your machine.

What’s going on behind the scenes is complex. Any objects that you pass into or return from a remote object must implement Serializable (if you want to pass remote references instead of the entire objects, the object arguments can implement Remote), so you can imagine that the stubs and skeletons are automatically performing serialization and deserialization as they “marshal” all of the arguments across the network and return the result. Fortunately, you don’t have to know any of this, but you do have to create the stubs and skeletons. This is a simple process: you invoke the rmic tool on your compiled code, and it creates the necessary files. So the only requirement is that another step be added to your compilation process.

The rmic tool is particular about packages and classpaths, however. PerfectTime.java is in the package c15.rmi, and even if you invoke rmic in the same directory in which PerfectTime.class is located, rmic won’t find the file, since it searches the classpath. So you must specify the location off the class path, like so:

rmic c15.rmi.PerfectTime

You don’t have to be in the directory containing PerfectTime.class when you execute this command, but the results will be placed in the current directory.

When rmic runs successfully, you’ll have two new classes in the directory:

PerfectTime_Stub.class

PerfectTime_Skel.class

corresponding to the stub and skeleton. Now you’re ready to get the server and client to talk to each other.

Using the remote object

The whole point of RMI is to make the use of remote objects simple. The only extra thing that you must do in your client program is to look up and fetch the remote interface from the server. From then on, it’s just regular Java programming: sending messages to objects. Here’s the program that uses PerfectTime:

//: c15:rmi:DisplayPerfectTime.java

// Uses remote object PerfectTime.

package c15.rmi;

import java.rmi.*;

import java.rmi.registry.*;

public class DisplayPerfectTime {

public static void main(String[] args) {

System.setSecurityManager(

new RMISecurityManager());

try {

PerfectTimeI t =

(PerfectTimeI)Naming.lookup(

"//peppy:2005/PerfectTime");

for(int i = 0; i < 10; i++)

System.out.println("Perfect time = " +

t.getPerfectTime());

} catch(Exception e) {

e.printStackTrace();

}

} ///:~

The ID string is the same as the one used to register the object with Naming, and the first part represents the URL and port number. Since you’re using a URL, you can also specify a machine on the Internet.

What comes back from Naming.lookup( ) must be cast to the remote interface, not to the class. If you use the class instead, you’ll get an exception.

You can see in the method call

t.getPerfectTime( )

that once you have a reference to the remote object, programming with it is indistinguishable from programming with a local object (with one difference: remote methods throw RemoteException).

Introduction to CORBA

In large, distributed applications, your needs might not be satisfied by the preceding approaches. For example, you might want to interface with legacy datastores, or you might need services from a server object regardless of its physical location. These situations require some form of Remote Procedure Call (RPC), and possibly language independence. This is where CORBA can help.

CORBA is not a language feature; it’s an integration technology. It’s a specification that vendors can follow to implement CORBA-compliant integration products. CORBA is part of the OMG’s effort to define a standard framework for distributed, language-independent object interoperability.

CORBA supplies the ability to make remote procedure calls into Java objects and non-Java objects, and to interface with legacy systems in a location-transparent way. Java adds networking support and a nice object-oriented language for building graphical and non-graphical applications. The Java and OMG object model map nicely to each other; for example, both Java and CORBA implement the interface concept and a reference object model.

CORBA Fundamentals

The object interoperability specification developed by the OMG is commonly referred to as the Object Management Architecture (OMA). The OMA defines two components: the Core Object Model and the OMA Reference Architecture. The Core Object Model states the basic concepts of object, interface, operation, and so on. (CORBA is a refinement of the Core Object Model.) The OMA Reference Architecture defines an underlying infrastructure of services and mechanisms that allow objects to interoperate. The OMA Reference Architecture includes the Object Request Broker (ORB), Object Services (also known as CORBAservices), and common facilities.

The ORB is the communication bus by which objects can request services from other objects, regardless of their physical location. This means that what looks like a method call in the client code is actually a complex operation. First, a connection with the server object must exist, and to create a connection the ORB must know where the server implementation code resides. Once the connection is established, the method arguments must be marshaled, i.e. converted in a binary stream to be sent across a network. Other information that must be sent are the server machine name, the server process, and the identity of the server object inside that process. Finally, this information is sent through a low-level wire protocol, the information is decoded on the server side, and the call is executed. The ORB hides all of this complexity from the programmer and makes the operation almost as simple as calling a method on local object.

There is no specification for how an ORB Core should be implemented, but to provide a basic compatibility among different vendors’ ORBs, the OMG defines a set of services that are accessible through standard interfaces.

CORBA Interface Definition Language (IDL)

CORBA is designed for language transparency: a client object can call methods on a server object of different class, regardless of the language they are implemented with. Of course, the client object must know the names and signatures of methods that the server object exposes. This is where IDL comes in. The CORBA IDL is a language-neutral way to specify data types, attributes, operations, interfaces, and more. The IDL syntax is similar to the C++ or Java syntax. The following table shows the correspondence between some of the concepts common to three languages that can be specified through CORBA IDL:

CORBA IDL

Java

C++

Module

Package

Namespace

Interface

Pure abstract class

Method

Member function

The inheritance concept is supported as well, using the colon operator as in C++. The programmer writes an IDL description of the attributes, methods, and interfaces that will be implemented and used by the server and clients. The IDL is then compiled by a vendor-provided IDL/Java compiler, which reads the IDL source and generates Java code.

The IDL compiler is an extremely useful tool: it doesn’t just generate a Java source equivalent of the IDL, it also generates the code that will be used to marshal method arguments and to make remote calls. This code, called the stub and skeleton code, is organized in multiple Java source files and is usually part of the same Java package.

The naming service

The naming service is one of the fundamental CORBA services. A CORBA object is accessed through a reference, a piece of information that’s not meaningful for the human reader. But references can be assigned programmer-defined, string names. This operation is known as stringifying the reference, and one of the OMA components, the Naming Service, is devoted to performing string-to-object and object-to-string conversion and mapping. Since the Naming Service acts as a telephone directory that both servers and clients can consult and manipulate, it runs as a separate process. Creating an object-to-string mapping is called binding an object, and removing the mapping is called unbinding. Getting an object reference passing a string is called resolving the name.

For example, on startup, a server application could create a server object, bind the object into the name service, and then wait for clients to make requests. A client first obtains a server object reference, resolving the string name, and then can make calls into the server using the reference.

Again, the Naming Service specification is part of CORBA, but the application that implements it is provided by the ORB vendor. The way you get access to the Naming Service functionality can vary from vendor to vendor.

An example

The code shown here will not be elaborate because different ORBs have different ways to access CORBA services, so examples are vendor specific. (The example below uses JavaIDL, a free product from Sun that comes with a light-weight ORB, a naming service, and an IDL-to-Java compiler.) In addition, since Java is young and still evolving, not all CORBA features are present in the various Java/CORBA products.

We want to implement a server, running on some machine, that can be queried for the exact time. We also want to implement a client that asks for the exact time. In this case we’ll be implementing both programs in Java, but we could also use two different languages (which often happens in real situations).

Writing the IDL source

The first step is to write an IDL description of the services provided. This is usually done by the server programmer, who is then free to implement the server in any language in which a CORBA IDL compiler exists. The IDL file is distributed to the client side programmer and becomes the bridge between languages.

The example below shows the IDL description of our ExactTime server:

//: c15:corba:ExactTime.idl

//# You must install idltojava.exe from

//# java.sun.com and adjust the settings to use

//# your local C preprocessor in order to compile

//# This file. See docs at java.sun.com.

module remotetime {

interface ExactTime {

string getTime();

};

}; ///:~

This is a declaration of the ExactTime interface inside the remotetime namespace. The interface is made up of one single method that gives back the current time in string format.

Creating stubs and skeletons

The second step is to compile the IDL to create the Java stub and skeleton code that we’ll use for implementing the client and the server. The tool that comes with the JavaIDL product is idltojava:

idltojava remotetime.idl

This will automatically generate code for both the stub and the skeleton. Idltojava generates a Java package named after the IDL module, remotetime, and the generated Java files are put in the remotetime subdirectory. _ExactTimeImplBase.java is the skeleton that we’ll use to implement the server object, and _ExactTimeStub.java will be used for the client. There are Java representations of the IDL interface in ExactTime.java and a couple of other support files used, for example, to facilitate access to the naming service operations.

Implementing the server and the client

Below you can see the code for the server side. The server object implementation is in the ExactTimeServer class. The RemoteTimeServer is the application that creates a server object, registers it with the ORB, gives a name to the object reference, and then sits quietly waiting for client requests.

//: c15:corba:RemoteTimeServer.java

import remotetime.*;

import org.omg.CosNaming.*;

import org.omg.CosNaming.NamingContextPackage.*;

import org.omg.CORBA.*;

import java.util.*;

import java.text.*;

// Server object implementation

class ExactTimeServer extends _ExactTimeImplBase {

public String getTime(){

return DateFormat.

getTimeInstance(DateFormat.FULL).

format(new Date(

System.currentTimeMillis()));

}

// Remote application implementation

public class RemoteTimeServer {

public static void main(String[] args) {

try {

// ORB creation and initialization:

ORB orb = ORB.init(args, null);

// Create the server object and register it:

ExactTimeServer timeServerObjRef =

new ExactTimeServer();

orb.connect(timeServerObjRef);

// Get the root naming context:

org.omg.CORBA.Object objRef =

orb.resolve_initial_references(

"NameService");

NamingContext ncRef =

NamingContextHelper.narrow(objRef);

// Assign a string name to the

// object reference (binding):

NameComponent nc =

new NameComponent("ExactTime", "");

NameComponent[] path = { nc };

ncRef.rebind(path, timeServerObjRef);

// Wait for client requests:

java.lang.Object sync =

new java.lang.Object();

synchronized(sync){

sync.wait();

}

catch (Exception e) {

System.out.println(

"Remote Time server error: " + e);

e.printStackTrace(System.out);

}

} ///:~

As you can see, implementing the server object is simple; it’s a regular Java class that inherits from the skeleton code generated by the IDL compiler. Things get a bit more complicated when it comes to interacting with the ORB and other CORBA services.

Some CORBA services

This is a short description of what the JavaIDL-related code is doing (primarily ignoring the part of the CORBA code that is vendor dependent). The first line in main( ) starts up the ORB, and of course, this is because our server object will need to interact with it. Right after the ORB initialization, a server object is created. Actually, the right term would be a transient servant object: an object that receives requests from clients, and whose lifetime is the same as the process that creates it. Once the transient servant object is created, it is registered with the ORB, which means that the ORB knows of its existence and can now forward requests to it.

Up to this point, all we have is timeServerObjRef, an object reference that is known only inside the current server process. The next step will be to assign a stringified name to this servant object; clients will use that name to locate the servant object. We accomplish this operation using the Naming Service. First, we need an object reference to the Naming Service; the call to resolve_initial_references( ) takes the stringified object reference of the Naming Service that is “NameService,” in JavaIDL, and returns an object reference. This is cast to a specific NamingContext reference using the narrow( ) method. We can use now the naming services.

To bind the servant object with a stringified object reference, we first create a NameComponent object, initialized with “ExactTime,” the name string we want to bind to the servant object. Then, using the rebind( ) method, the stringified reference is bound to the object reference. We use rebind( ) to assign a reference, even if it already exists, whereas bind( ) raises an exception if the reference already exists. A name is made up in CORBA by a sequence of NameContexts—that’s why we use an array to bind the name to the object reference.

The servant object is finally ready for use by clients. At this point, the server process enters a wait state. Again, this is because it is a transient servant, so its lifetime is confined to the server process. JavaIDL does not currently support persistent objects—objects that survive the execution of the process that creates them.

Now that we have an idea of what the server code is doing, let’s look at the client code:

//: c15:corba:RemoteTimeClient.java

import remotetime.*;

import org.omg.CosNaming.*;

import org.omg.CORBA.*;

public class RemoteTimeClient {

public static void main(String[] args) {

try {

// ORB creation and initialization:

ORB orb = ORB.init(args, null);

// Get the root naming context:

org.omg.CORBA.Object objRef =

orb.resolve_initial_references(

"NameService");

NamingContext ncRef =

NamingContextHelper.narrow(objRef);

// Get (resolve) the stringified object

// reference for the time server:

NameComponent nc =

new NameComponent("ExactTime", "");

NameComponent[] path = { nc };

ExactTime timeObjRef =

ExactTimeHelper.narrow(

ncRef.resolve(path));

// Make requests to the server object:

String exactTime = timeObjRef.getTime();

System.out.println(exactTime);

} catch (Exception e) {

System.out.println(

"Remote Time server error: " + e);

e.printStackTrace(System.out);

}

} ///:~

The first few lines do the same as they do in the server process: the ORB is initialized and a reference to the naming service server is resolved. Next, we need an object reference for the servant object, so we pass the stringified object reference to the resolve( ) method, and we cast the result into an ExactTime interface reference using the narrow( ) method. Finally, we call getTime( ).

Activating the name service process

Finally we have a server and a client application ready to interoperate. You’ve seen that both need the naming service to bind and resolve stringified object references. You must start the naming service process before running either the server or the client. In JavaIDL, the naming service is a Java application that comes with the product package, but it can be different with other products. The JavaIDL naming service runs inside an instance of the JVM and listens by default to network port 900.

Activating the server and the client

Now you are ready to start your server and client application (in this order, since our server is transient). If everything is set up correctly, what you’ll get is a single output line on the client console window, giving you the current time. Of course, this might be not very exciting by itself, but you should take one thing into account: even if they are on the same physical machine, the client and the server application are running inside different virtual machines and they can communicate via an underlying integration layer, the ORB and the Naming Service.

This is a simple example, designed to work without a network, but an ORB is usually configured for location transparency. When the server and the client are on different machines, the ORB can resolve remote stringified references using a component known as the Implementation Repository. Although the Implementation Repository is part of CORBA, there is almost no specification, so it differs from vendor to vendor.

As you can see, there is much more to CORBA than what has been covered here, but you should get the basic idea. If you want more information about CORBA, the place to start is the OMG Web site, at http://www.omg.org. There you’ll find documentation, white papers, proceedings, and references to other CORBA sources and products.

Java Applets and CORBA

Java applets can act as CORBA clients. This way, an applet can access remote information and services exposed as CORBA objects. But an applet can connect only with the server from which it was downloaded, so all the CORBA objects the applet interacts with must be on that server. This is the opposite of what CORBA tries to do: give you complete location transparency.

This is an issue of network security. If you’re on an intranet, one solution is to loosen the security restrictions on the browser. Or, set up a firewall policy for connecting with external servers.

Some Java ORB products offer proprietary solutions to this problem. For example, some implement what is called HTTP Tunneling, while others have their special firewall features.

This is too complex a topic to be covered in an appendix, but it is definitely something you should be aware of.

CORBA vs. RMI

You saw that one of the main CORBA features is RPC support, which allows your local objects to call methods in remote objects. Of course, there already is a native Java feature that does exactly the same thing: RMI (see Chapter 15). While RMI makes RPC possible between Java objects, CORBA makes RPC possible between objects implemented in any language. It’s a big difference.

However, RMI can be used to call services on remote, non-Java code. All you need is some kind of wrapper Java object around the non-Java code on the server side. The wrapper object connects externally to Java clients via RMI, and internally connects to the non-Java code using one of the techniques shown above, such as JNI or J/Direct.

This approach requires you to write a kind of integration layer, which is exactly what CORBA does for you, but then you don’t need a third-party ORB.

Enterprise Java Beans

[70] By now, you've been introduced to CORBA and RMI. But could you imagine trying to develop a large-scale application using CORBA and/or RMI? Your manager has asked you to develop a multi-tiered application to view and update records in a database through a Web interface. You sit back and think of what that really means. Sure, you can write a database application using JDBC, a Web interface using JSP/Servlets, and a distributed system using CORBA/RMI. But what extra considerations must you make when developing a distributed object based system rather than just knowing API's? Here are the issues:

Performance: The new distributed objects that you are creating are going to have to perform, as they potentially could service many clients at a time. So you'll want to think of optimization techniques such as caching, pooling of resources (e.g., JDBC database connections). You'll also have to manage the lifecycle of your distributed object.

Scalability: The distributed objects must also be scalable. Scalable in a distributed application sense means that the number of instances of your distributed object can be increased and moved over to a different machine without the modification of any code. Take for example a system that you develop internally as a small lookup of clients inside your organization from a database. The application works well when you use it, but your manager has seen it and has said "Robert, that is an excellent system, get it on our public Web-site now!!!"-Will my distributed object be able to handle the load of a potentially limitless demand?

Security: Does my distributed object manage the authorization of the clients that accesses it? Can I add new users and roles to it without recompilation?

Distributed Transactions: Can my distributed object reference distributed-transactions transparently? Can I update my Oracle and Sybase databases simultaneously within the same transaction and roll them both back if a certain criteria is not met?

Reusability: Have I created my distributed object so that I can move it into another vendors' application server? Can I resell my distributed object (component) to somebody else? Can I buy somebody else's component and use it without having to recompile and 'hack it into shape'?

Availability: If one of the machines in my system was to go down, are my clients able to automatically fail-over to back up copies of my objects running on other machines?

As you can see from the above, the considerations that a developer must make when developing a distributed system and we haven't even mentioned solving the problem that we were originally trying to solve!

So you now have your list of extra problems that you must solve. So how do you go about doing it? Surely somebody must have done this before? Could I use some well-known design patterns to help me solve these problems? Then an idea flashes in your head... "I could create a framework that handles all of these issues and write my components on top of the framework!".... This is where Enterprise JavaBeans comes into the picture.

Sun, along with other leading distributed object vendors (listed at URL HERE!) realized that sooner or later every development team would be reinventing the wheel. So they created the Enterprise JavaBeans specification (EJB). EJB is a specification for a server-side component model that tackles all of the considerations mentioned above using a defined, standard approach that allows developers to create components-which are actually called Enterprise JavaBeans (EJB's)-that are isolated from low-level 'plumbing' code and focus solely on providing business logic. Because EJB's are defined as a standard they can be used without being vendor dependent.

What’s defined in the EJB specification?

The Enterprise JavaBeans specification, currently at version 1.1 - public release 2 - defines a server side component model. It defines 6 roles that are used to perform the tasks in development and deployment as well as defining the components of the system.

Roles

The EJB specification defines roles that are used during in the development, deployment and running of a distributed system. Vendors, administrators and developers play the various roles. They allow the partitioning of technical and domain knowledge. This allows the vendor to provide a technically sound framework and the developers to create domain specific components e.g., an Accounting component. The same party can perform one or many roles. The roles defined in the EJB specification have been summarized in the following table:

Role

Responsibility

Enterprise Bean Provider

The developer who is responsible for creating reusable EJB components. These components are packaged into a special jar file (ejb-jar file).

Application Assembler

Create and assemble applications from a collection of ejb-jar files. This includes writing applications that utilize the collection of EJB’s (e.g., Servlets, JSP, Swing etc. etc.)

Deployer

The Deployer’s role of the to take the collection of ejb-jar files from the Assembler and/or Bean Provider and deploy them into a run-time environment - one or many EJB Container(s).

EJB Container/Server Provider

Provide a run-time environment and tools that are used to deploy, administer and “run” EJB components.

System Administrator

Over see the most important goal of the entire system - That it is up and running. Management of a distributed application can consist of many different components and services all configured and interacting together correctly.

Components of EJB

EJB components are reusable business logic. EJB components adhere to strict standards and design patterns as defined in the EJB specification. This allows the components to be portable and also allow other services—such as security, caching and distributed transactions - to be performed on the components’ behalf. An Enterprise Bean Provider is responsible for developing EJB components. The internals of an EJB component are covered in - “What makes up an EJB component?”

EJB Container

The EJB Container is a run-time environment that contains -or runs—EJB components and provides a set of standard services to the components. The EJB Containers responsibilities are tightly defined by the specification to allow for vendor neutrality. The EJB container provides the low-level “plumbing” of EJB, including distributed transactions, security, life cycle management of beans, caching, threading and session management. The EJB Container Provider is responsible for providing an EJB Container.

EJB Server

An EJB Server is defined as an Application Server that contains and runs 1 or more EJB Containers. that both the Container and Server are the same vendor. The EJB Server Provider is responsible for providing an EJB Server. The specification suggests and you can assume for this introduction, that the EJB Container and EJB Server are the same.

Java Naming and Directory Interface (JNDI)

Java Naming and Directory Interface (JNDI) is used in Enterprise JavaBeans as the naming service for EJB Components on the network and other container services such as transactions. JNDI maps very closely to other naming and directory standards such as CORBA CosNaming and can actually be implemeted as a wrapper on top of it.

Java Transaction API / Java Transaction Service (JTA/JTS)

JTA/JTS is used in Enterprise JavaBeans as the transactional API. An Enterprise Bean Provider can use the JTS to create transactional code although the EJB Container commonly implements transactions in EJB on the EJB components’ behalf. The Deployer can define the transactional attributes of an EJB component at deployment time. The EJB Container is responsible for handling the transaction whether it is local or distributed. The JTS specification is the Java mapping to the CORBA OTS (Object Transaction Service)

CORBA and RMI/IIOP

The EJB specification defines interoperablility with CORBA. The 1.1 specification quotes “The Enterprise JavaBeans architecture will be compatible with the CORBA protocols.” CORBA interoperability is achieved through the mapping of EJB services such as JTS and JNDI to corresponding CORBA services and the implementation of RMI on top of the CORBA protocol IIOP.

Use of CORBA and RMI/IIOP in Enterprise JavaBeans is implemented in the EJB Container and is the responsibility of the EJB Container provider. Use of CORBA and RMI/IIOP in the EJB Container is hidden from the EJB Component itself. This means that the Enterprise Bean Provider can write their EJB Component and deploy it into any EJB Container without any regard of which communication protocol is being used.

The components and available services of EJB.

What makes up an EJB component?

Enterprise Bean

The Enterprise Bean is a Java class that the Enterprise Bean Provider develops. It implements an EnterpriseBean interface (more detail in a later section) and provides the implementation of the business methods that the component is to perform. The class does not implement any authorization/authentication code, multithreading, transactional code.

Home Interface

Every Enterprise Bean that is created must have an associated Home interface. The Home interface is used as a factory for your EJB. Clients use the Home interface to find an instance of your EJB or create a new instance of your EJB.

Remote Interface

The Remote interface is a Java Interface that reflects the methods of your Enterprise Bean that you wish to expose to the outside world. The Remote interface plays a similar role to a CORBA IDL interface.

Deployment Descriptor

The Deployment Descriptor is an XML file that contains information about your EJB. Using XML allows the Deployer to easily change attributes about your EJB. The configurable attributes defined in the Deployment Descriptor include:

The Home and Remote interface names that are required by your EJB

The name to publish into JNDI for your EJB’s Home interface

Transactional attributes for each method of your EJB

Access Control Lists for authentication

EJB-Jar File

The EJB-Jar file is a normal java jar file that contains your EJB, Home and Remote interfaces, as well as the Deployment Descriptor.

How does EJB work?

Now that we have our EJB-Jar file containing our Bean, Home and Remote interfaces and Deployment Descriptor, Let’s take a look at how all of these pieces fit together and why Home and Remote interfaces are needed and how the EJB Container uses them.

Who implements the Home and Remote Interfaces?

The EJB Container implements the Home and Remote interfaces that are in our EJB-Jar file. Because the EJB Container implements the Home interface that - as mentioned earlier - provides methods to create and find your EJB. This means that the EJB Container is responsible for the lifecycle management of your EJB. This level of indirection allows for optimizations to occur. For example 5 clients simultaneously request to create an EJB through a Home Interface, the EJB Container could create only one and share that EJB between all 5 clients. This is achieved through the Remote Interface, which is again implemented by the EJB Container. The implemented Remote object plays the role of a proxy object to the EJB.

The following diagram show the level of indirection achieved by this approach and that all calls to the EJB are ‘proxied’ through the EJB Container via the Home and Remote interfaces. This level of indirection is also the reason why the EJB Container can control security and transactional behavior.

Types of EJB’s

There should be one question in your head from the previous section, “Surely sharing the same EJB between clients can improve performance, but what If I want to maintain state on my server?”

The Enterprise JavaBeans specification defines different types of EJB’s that have different characteristics and exhibit different behavior. Two categories of EJB’s have been defined in the specification. Session Beans and Entity Beans, and each of these categories has variations. A hierarchy of the various types of EJB components is shown in the following figure.

Session Beans

Session Beans are used to represent Use-Cases or Workflow on behalf of a client. They represent operations on persistent data, not persistent data itself. There are two types of Session Beans, Stateless and Stateful. All Session Beans must implement the javax.ejb.SessionBean interface. The EJB Container governs the life of a Session Bean. If the EJB Container crashes, data for all Stateful Session Beans could be lost. Some high-end EJB Containers provide recovery for Stateful Session Beans.

Stateless Session Beans

Stateless Session Beans are the simplest type of EJB component to implement. They do not maintain any conversational state with clients between method invocations so they are easily reusable on the server side and because they can be cached, they scale well on demand. When using Stateless Session Beans, all state must be stored outside of the EJB.

Stateful Session Beans

Stateful Session Beans - as you could probably guess - maintain state between invocations. They have a 1 to 1 logical mapping to a client and can maintain state within themselves. The EJB Container is responsible for pooling and caching of Stateful Session Beans, which is achieved through Passivation and Activation.

Entity Beans

Entity Beans are components that represent persistent data and behavior of this data. Entity Beans can be shared amongst multiple clients, the same as data in a database. The EJB Container is responsible for caching Entity Beans and for maintaining the integrity of the Entity Beans. The life of an Entity Bean outlives the EJB Container, so if an EJB Container crashes, the Entity Bean is expected to still be available when the EJB Container becomes available.

There are two types of Entity Beans, those that have Bean-Managed persistence and Container Managed persistence.

Container Managed Persistence (CMP)

A CMP Entity Bean has its’ persistence implemented on its behalf by the EJB Container. Through attributes specified in the Deployment Descriptor, the EJB Container will map the Entity Bean’s attributes to some persistent store (usually -but not always—a database). CMP reduces the time to develop and dramatically reduces the amount of code required for the EJB.

Bean Managed Persistence (BMP)

A BMP Entity Bean has its’ persistence implemented by the Enterprise Bean Provider. The Enterprise Bean Provider is responsible for implementing the logic required to create a new EJB, update some attributes of the EJBS, delete an EJB and find an EJB from persistent store. This usually involves writing JDBC code to interact with a database or other persistent store. With BMP, the developer is in full control of how the Entity Bean persistence is managed.

BMP also gives flexibility where a CMP implementation may not be available e.g., if you wanted to create an EJB that wrapped some code on an existing mainframe system, you could write your persistence using CORBA.

How do I put the ‘E’ in my existing JavaBeans?

There is much confusion about the relationship between the JavaBeans component model and the Enterprise JavaBeans specification. Whilst both the JavaBeans and Enterprise JavaBeans specifications share the same objectives in promoting reuse and portability of Java code between development and deployment tools with the use of standard design patterns, the motives behind each specification are geared to solve different problems.

The standards defined in the JavaBeans component model are designed for creating reusable components that are typically used in IDE development tools and are commonly, although not exclusively visual components.

The Enterprise JavaBeans specification defines a component model for developing server side java code. Because EJB’s can potentially run on many different server-side platforms -including mainframes that do not have visual displays - An EJB cannot make use of the java.awt package.

Developing an Enterprise Java Bean

We will now implement the “Perfect Time” example from the previous RMI section as an Enterprise JavaBean component. The example will be a simple Stateless Session Bean. Enterprise JavaBean components will consist of at least one class and two interfaces.

The first interface defined is the Remote Interface to our Enterprise JavaBean component. When you create a Remote interface for an EJB , you must follow these guidelines:

The remote interface must be public.

The remote interface must extend the interface javax.ejb.EJBObject.

Each method in the remote interface must declare java.rmi.RemoteException in its throws clause in addition to any application-specific exceptions.

Any object passed as an argument or return value (either directly or embedded within a local object) must be a valid RMI-IIOP data type (this includes other EJB objects)

Here is the simple remote interface for our PerfectTime EJB:

//: c15:ejb:PerfectTime.java

//# You must install the J2EE Java Enterprise

//# Edition from java.sun.com and add j2ee.jar

//# To your CLASSPATH in order to compile

//# This file. See details at java.sun.com.

// Remote Interface of PerfectTimeBean

import java.rmi.*;

import javax.ejb.*;

public interface PerfectTime extends EJBObject {

public long getPerfectTime()

throws RemoteException;

} ///:~

The second interface defined is the Home Interface to our Enterprise JavaBean component. The Home interface is the factory where our component will be created. The Home interface can define create or finder methods. Create methods create instances of EJB’s, finder methods locate existing EJB’s and are used for Entity Beans only. When you create a Home interface for an EJB , you must follow these guidelines:

The Home interface must be public.

The Home interface must extend the interface javax.ejb.EJBHome.

Each method in the Home interface must declare java.rmi.RemoteException in its throws clause as well as a javax.ejb.CreateException

The return value of a create method must be a Remote Interface

The return value of a finder method (Entity Beans only) must be a Remote Interface or java.util.Enumeration or java.util.Collection

Any object passed as an argument (either directly or embedded within a local object) must be a valid RMI-IIOP data type (this includes other EJB objects)

The standard naming convention for Home interfaces is to take the Remote interface name and append “Home” to the end. Following is the Home interface for our PerfectTime EJB:

//: c15:ejb:PerfectTimeHome.java

// Home Interface of PerfectTimeBean.

import java.rmi.*;

import javax.ejb.*;

public interface PerfectTimeHome extends EJBHome {

public PerfectTime create()

throws CreateException, RemoteException;

} ///:~

Now that we have defined the interfaces of our component, we can now implement the business logic behind it. When you create your EJB implementation class, you must follow these guidelines, (note that you should consult the EJB specification for a complete list of guidelines when developing Enterprise JavaBeans):

The class must be public.

The class must implement an EJB interface (either javax.ejb.SessionBean or javax.ejb.EntityBean).

The class should define methods that map directly to the methods in the Remote interface, Note that the class does not implement the Remote interface, it mirrors the methods in the Remote interface but does NOT throw java.rmi.RemoteException.

Define one or more ejbCreate( ) methods to initialize your EJB.

The return value and arguments of all methods must be valid RMI-IIOP data types.

//: c15:ejb:PerfectTimeBean.java

// Simple Stateless Session Bean

// that returns current system time.

import java.rmi.*;

import javax.ejb.*;

public class PerfectTimeBean

implements SessionBean {

private SessionContext sessionContext;

//return current time

public long getPerfectTime() {

return System.currentTimeMillis();

}

// EJB methods

public void

ejbCreate() throws CreateException {}

public void ejbRemove() {}

public void ejbActivate() {}

public void ejbPassivate() {}

public void

setSessionContext(SessionContext ctx) {

sessionContext = ctx;

}

}///:~

Notice that the EJB methods (ejbCreate( ), ejbRemove( ), ejbActivate( ), ejbPassivate( ) ) are all empty. These methods are invoked by the EJB Container and are used to control the state of our component. As this is a simple example, we can leave these empty. The setSessionContext( ) method passes a javax.ejb.SessionContext object which contains information about context that the component is in, such as the current transaction and security information.

After we have created our Enterprise Java Bean, we then need to create a Deployment Descriptor. In EJB 1.1, the Deployment Descriptor is an XML file that describes the EJB component. The Deployment Descriptor should be stored in a file called ejb-jar.xml.

<?xml version="1.0" encoding="Cp1252"?>

<!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'>

<ejb-jar>

<description>example for chapter 15</description>

<display-name></display-name>

<small-icon></small-icon>

<large-icon></large-icon>

<enterprise-beans>

<session>

<ejb-name>PerfectTime</ejb-name>

<home>PerfectTimeHome</home>

<remote>PerfectTime</remote>

<ejb-class>PerfectTimeBean</ejb-class>

<session-type>Stateless</session-type>

<transaction-type>Container</transaction-type>

</session>

</enterprise-beans>

<ejb-client-jar></ejb-client-jar>

</ejb-jar>

Inside the <session> tag of our deployment descriptor we can see that our Component, the Remote interface and Home interfaces are begin defined. Deployment Descriptors can easily be automatically generated inside tools such as JBuilder.

Along with the standard ejb-jar.xml deployment descriptor the EJB 1.1 specification states that any vendor specific tags should be stored in a separate file, this is to achieve high portability between components and different brands EJB containers.

Now that we have created our component, and defined it’s composition in the Deployment Descriptor we then need to archive the files inside a standard Java Archive (JAR) file. The Deployment Descriptors should be placed inside the /META-INF sub-directory of the Jar file.

Once we have defined our EJB component in the Deployment Descriptor, the Deployer should then deploy the EJB component into the EJB Container. At the time of writing, this process was quite "gui intensive" and specific to each individual EJB Container, so we decided not to document the entire deployment process in this overview. Every EJB Container, however will have a documented process for deploying an EJB.

Because an EJB component is a distributed object, the deployment process should also create some client stubs for calling the EJB component. These classes whould be placed on the classpath of the client application. Because EJB components can be implemented on top of RMI-IIOP (CORBA) or RMI-JRMP, the stubs generated could vary between EJB Containers, nevertheless they are generated classes.

When a client program wishes to invoke an EJB, it must lookup the EJB component inside JNDI and obtain a reference to the Home interface of the EJB component. The Home Interface can then be invoked to create an instance of the EJB, which can then be invoked.

In this example the Client program is a simple Java program, but you should remember that it could just as easily be a Servlet, a JSP even a CORBA or RMI distributed object.

The PerfectTimeClient code is as follows.

//: c15:ejb:PerfectTimeClient.java

// Client program for PerfectTimeBean

public class PerfectTimeClient {

public static void

main(String[] args) throws Exception {

// Get a JNDI context using the

// JNDI Naming service:

javax.naming.Context context =

new javax.naming.InitialContext();

// Look up the home interface in the

// JNDI Naming service:

Object ref = context.lookup("perfectTime");

// Cast the remote object to the home interface:

PerfectTimeHome home = (PerfectTimeHome)

javax.rmi.PortableRemoteObject.narrow(

ref, PerfectTimeHome.class);

// Create a remote object from the home interface:

PerfectTime pt = home.create();

// Invoke getPerfectTime()

System.out.println(

"Perfect Time EJB invoked, time is: " +

pt.getPerfectTime() );

}

} ///:~

In Summary

The Enterprise JavaBeans specification - although intially seems very daunting - is a dramatic step forward in the standardization and simplification or distributed object computing. It is a major piece of the Java 2, Enterprise Edition Platform and is receiving much support from the Distributed Object community. Many tools are currently available or will be in the near future to help accelerate the development of EJB components.

This overview was aimed at giving you a brief tour as to what EJB is all about. For more information about the Enterprise JavaBeans specification you should see the Official Enterprise JavaBeans Home Page at http://java.sun.com/products/ejb/. Here you can download the latest specification as well as the Java 2, Enterprise Edition Reference Implementation, which you can use to develop and deploy your own EJB components.

Jini: distributed services

This section[71] gives an overview of Sun Microsystems's Jini technology. It describes some Jini nuts and bolts and shows how Jini's architecture helps to raise the level of abstraction in distributed systems programming, effectively turning network programming into object-oriented programming.

Jini in context

Traditionally, operating systems have been designed with the assumption that a computer will have a processor, some memory, and a disk. When you boot a computer, the first thing it does is look for a disk. If it doesn't find a disk, it can't function as a computer. Increasingly, however, computers are appearing in a different guise: as embedded devices that have a processor, some memory, and a network connection—but no disk. The first thing a cellphone does when you boot it up, for example, is look for the telephone network. If it doesn't find the network, it can't function as a cellphone. This trend in the hardware environment, from disk-centric to network-centric, will affect how we organize our software—and that's where Jini comes in.

Jini is an attempt to rethink computer architecture, given the rising importance of the network and the proliferation of processors in devices that have no disk drive. These devices, which will come from many different vendors, will need to interact over a network. The network itself will be very dynamic—devices and services will be added and removed regularly. Jini provides mechanisms to enable smooth adding, removal, and finding of devices and services on the network. In addition, Jini provides a programming model that makes it easier for programmers to get their devices talking to each other.

Building on top of Java, object serialization, and RMI (which enable objects to move around the network from virtual machine to virtual machine) Jini attempts to extend the benefits of object-oriented programming to the network. Instead of requiring device vendors to agree on the network protocols through which their devices can interact, Jini enables the devices to talk to each other through interfaces to objects.

What is Jini?

Jini is a set of APIs and network protocols that can help you build and deploy distributed systems that are organized as federations of services. A service can be anything that sits on the network and is ready to perform a useful function. Hardware devices, software, communications channels—even human users themselves—can be services. A Jini-enabled disk drive, for example, could offer a “storage” service. A Jini-enabled printer could offer a “printing” service. A federation of services, then, is a set of services, currently available on the network, that a client (meaning a program, service, or user) can bring together to help it accomplish some goal.

To perform a task, a client enlists the help of services. For example, a client program might upload pictures from the image storage service in a digital camera, download the pictures to a persistent storage service offered by a disk drive, and send a page of thumbnail-sized versions of the images to the printing service of a color printer. In this example, the client program builds a distributed system consisting of itself, the image storage service, the persistent storage service, and the color-printing service. The client and services of this distributed system work together to perform the task: to offload and store images from a digital camera and print a page of thumbnails.

The idea behind the word federation is that the Jini view of the network doesn't involve a central controlling authority. Because no one service is in charge, the set of all services available on the network form a federation—a group composed of equal peers. Instead of a central authority, Jini's run-time infrastructure merely provides a way for clients and services to find each other (via a lookup service, which stores a directory of currently available services). After services locate each other, they are on their own. The client and its enlisted services perform their task independently of the Jini run-time infrastructure. If the Jini lookup service crashes, any distributed systems brought together via the lookup service before it crashed can continue their work. Jini even includes a network protocol that clients can use to find services in the absence of a lookup service.

How Jini works

Jini defines a run-time infrastructure that resides on the network and provides mechanisms that enable you to add, remove, locate, and access services. The run-time infrastructure resides in three places: in lookup services that sit on the network, in the service providers (such as Jini-enabled devices), and in clients. Lookup services are the central organizing mechanism for Jini-based systems. When new services become available on the network, they register themselves with a lookup service. When clients wish to locate a service to assist with some task, they consult a lookup service.

The run-time infrastructure uses one network-level protocol, called discovery, and two object-level protocols, called join and lookup. Discovery enables clients and services to locate lookup services. Join enables a service to register itself in a lookup service. Lookup enables a client to query for services that can help accomplish its goals.

The discovery process

Discovery works like this: Imagine you have a Jini-enabled disk drive that offers a persistent storage service. As soon as you connect the drive to the network, it broadcasts a presence announcement by dropping a multicast packet onto a well-known port. Included in the presence announcement is an IP address and port number where the disk drive can be contacted by a lookup service.

Lookup services monitor the well-known port for presence announcement packets. When a lookup service receives a presence announcement, it opens and inspects the packet. The packet contains information that enables the lookup service to determine whether or not it should contact the sender of the packet. If so, it contacts the sender directly by making a TCP connection to the IP address and port number extracted from the packet. Using RMI, the lookup service sends an object, called a service registrar, across the network to the originator of the packet. The purpose of the service registrar object is to facilitate further communication with the lookup service. By invoking methods on this object, the sender of the announcement packet can perform join and lookup on the lookup service. In the case of the disk drive, the lookup service would make a TCP connection to the disk drive and would send it a service registrar object, through which the disk drive would then register its persistent storage service via the join process.

The join process

Once a service provider has a service registrar object, the end product of discovery, it is ready to do a join—to become part of the federation of services that are registered in the lookup service. To do a join, the service provider invokes the register( ) method on the service registrar object, passing as a parameter an object called a service item, a bundle of objects that describe the service. The register( ) method sends a copy of the service item up to the lookup service, where the service item is stored. Once this has completed, the service provider has finished the join process: its service has become registered in the lookup service.

The service item is a container for several objects, including an object called a service object, which clients can use to interact with the service. The service item can also include any number of attributes, which can be any object. Some potential attributes are icons, classes that provide GUIs for the service, and objects that give more information about the service.

Service objects usually implement one or more interfaces through which clients interact with the service. For example, a lookup service is a Jini service, and its service object is the service registrar. The register( ) method invoked by service providers during join is declared in the ServiceRegistrar interface (a member of the net.jini.core.lookup package), which all service registrar objects implement. Clients and service providers talk to the lookup service through the service registrar object by invoking methods declared in the ServiceRegistrar interface. Likewise, a disk drive would provide a service object that implemented some well-known storage service interface. Clients would look up and interact with the disk drive by this storage service interface.

The lookup process

Once a service has registered with a lookup service via the join process, that service is available for use by clients who query that lookup service. To build a distributed system of services that will work together to perform some task, a client must locate and enlist the help of the individual services. To find a service, clients query lookup services via a process called lookup.

To perform a lookup, a client invokes the lookup( ) method on a service registrar object. (A client, like a service provider, gets a service registrar through the previously-described process of discovery.) The client passes as an argument to lookup( ) a service template, an object that serves as search criteria for the query. The service template can include a reference to an array of Class objects. These Class objects indicate to the lookup service the Java type (or types) of the service object desired by the client. The service template can also include a service ID, which uniquely identifies a service, and attributes, which must exactly match the attributes uploaded by the service provider in the service item. The service template can also contain wildcards for any of these fields. A wildcard in the service ID field, for example, will match any service ID. The lookup( ) method sends the service template to the lookup service, which performs the query and sends back zero to any matching service objects. The client gets a reference to the matching service objects as the return value of the lookup( ) method.

In the general case, a client looks up a service by Java type, usually an interface. For example, if a client needed to use a printer, it would compose a service template that included a Class object for a well-known interface to printer services. All printer services would implement this well-known interface. The lookup service would return a service object (or objects) that implemented this interface. Attributes can be included in the service template to narrow the number of matches for such a type-based search. The client would use the printer service by invoking methods from the well-known printer service interface on the service object.

Separation of interface and implementation

Jini's architecture brings object-oriented programming to the network by enabling network services to take advantage of one of the fundamentals of objects: the separation of interface and implementation. For example, a service object can grant clients access to the service in many ways. The object can actually represent the entire service, which is downloaded to the client during lookup and then executed locally. Alternatively, the service object can serve merely as a proxy to a remote server. Then when the client invokes methods on the service object, it sends the requests across the network to the server, which does the real work. A third option is for the local service object and a remote server to each do part of the work.

One important consequence of Jini's architecture is that the network protocol used to communicate between a proxy service object and a remote server does not need to be known to the client. As illustrated in the figure below, the network protocol is part of the service's implementation. This protocol is a private matter decided upon by the developer of the service. The client can communicate with the service via this private protocol because the service injects some of its own code (the service object) into the client's address space. The injected service object could communicate with the service via RMI, CORBA, DCOM, some home-brewed protocol built on top of sockets and streams, or anything else. The client simply doesn't need to care about network protocols, because it can talk to the well-known interface that the service object implements. The service object takes care of any necessary communication on the network.

The client talks to the service through a well-known interface

Different implementations of the same service interface can use completely different approaches and network protocols. A service can use specialized hardware to fulfill client requests, or it can do all its work in software. In fact, the implementation approach taken by a single service can evolve over time. The client can be sure it has a service object that understands the current implementation of the service, because the client receives the service object (by way of the lookup service) from the service provider itself. To the client, a service looks like the well-known interface, regardless of how the service is implemented.

Abstracting distributed systems

Jini attempts to raise the level of abstraction for distributed systems programming, from the network protocol level to the object interface level. In the emerging proliferation of embedded devices connected to networks, many pieces of a distributed system may come from different vendors. Jini makes it unnecessary for vendors of devices to agree on network level protocols that allow their devices to interact. Instead, vendors must agree on Java interfaces through which their devices can interact. The processes of discovery, join, and lookup, provided by the Jini run-time infrastructure, will enable devices to locate each other on the network. Once they locate each other, devices will be able to communicate with each other through Java interfaces.

JavaSpaces

Summary

There’s actually a lot more to networking than can be covered in this introductory treatment. Java networking also provides fairly extensive support for URLs, including protocol handlers for different types of content that can be discovered at an Internet site. You can find other Java networking features fully and carefully described in Java Network Programming by Elliotte Rusty Harold (O’Reilly, 1997).

Exercises

Compile and run the JabberServer and JabberClient programs in this chapter. Now edit the files to remove all of the buffering for the input and output, then compile and run them again to observe the results.

Create a server that asks for a password, then opens a file and sends the file over the network connection. Create a client that connects to this server, gives the appropriate password, then captures and saves the file. Test the pair of programs on your machine using the localhost (the local loopback IP address 127.0.0.1 produced by calling InetAddress.getByName(null)).

Modify the server in Exercise 2 so that it uses multithreading to handle multiple clients.

Modify JabberClient so that output flushing doesn’t occur and observe the effect.

Modify MultiJabberServer so that it uses thread pooling. Instead of throwing away a thread each time a client disconnects, the thread should put itself into an “available pool” of threads. When a new client wants to connect, the server will look in the available pool for a thread to handle the request, and if one isn’t available, make a new one. This way the number of threads necessary will naturally grow to the required quantity. The value of thread pooling is that it doesn’t require the overhead of creating and destroying a new thread for each new client.

Build on ShowHTML.java to produce an applet that is a password-protected gateway to a particular portion of your Web site.

(More challenging) Create a client/server pair of programs that use datagrams to transmit a file from one machine to the other. (See the description at the end of the datagram section of this chapter.)

(More challenging) Take the VLookup.java program and modify it so that when you click on the resulting name it automatically takes that name and copies it to the clipboard (so you can simply paste it into your email). You’ll need to look back at the IO stream chapter to remember how to use the Java 1.1 clipboard.

--------------------------------------------------------------------------------

[68] This means a maximum of just over four billion numbers, which is rapidly running out. The new standard for IP addresses will use a 128-bit number, which should produce enough unique IP addresses for the foreseeable future.

[69] Many brain cells died in agony to discover this information.

[70] This section was contributed by Robert Castaneda, with help from Dave Bartlett.

[71] This section was contributed by Bill Venners (www.artima.com).

[ Previous Chapter ] [ Short TOC ] [ Table of Contents ] [ Index ] [ Next Chapter ]

Last Update:03/13/2000

15.8 远程方法

为通过网络执行其他机器上的代码，传统的方法不仅难以学习和掌握，也极易出错。思考这个问题最佳的方式是：某些对象正好位于另一台机器，我们可向它们发送一条消息，并获得返回结果，就象那些对象位于自己的本地机器一样。Java 1.1的“远程方法调用”（RMI）采用的正是这种抽象。本节将引导大家经历一些必要的步骤，创建自己的RMI对象。

15.8.1 远程接口概念

RMI对接口有着强烈的依赖。在需要创建一个远程对象的时候，我们通过传递一个接口来隐藏基层的实施细节。所以客户得到远程对象的一个句柄时，它们真正得到的是接口句柄。这个句柄正好同一些本地的根代码连接，由后者负责通过网络通信。但我们并不关心这些事情，只需通过自己的接口句柄发送消息即可。

创建一个远程接口时，必须遵守下列规则：

(1) 远程接口必须为public属性（不能有“包访问”；也就是说，它不能是“友好的”）。否则，一旦客户试图装载一个实现了远程接口的远程对象，就会得到一个错误。

(2) 远程接口必须扩展接口java.rmi.Remote。

(3) 除与应用程序本身有关的异常之外，远程接口中的每个方法都必须在自己的throws从句中声明java.rmi.RemoteException。

(4) 作为参数或返回值传递的一个远程对象（不管是直接的，还是在本地对象中嵌入）必须声明为远程接口，不可声明为实施类。

下面是一个简单的远程接口示例，它代表的是一个精确计时服务：

898页程序

//: c15:rmi:PerfectTimeI.java

// The PerfectTime remote interface.

package c15.rmi;

import java.rmi.*;

interface PerfectTimeI extends Remote {

long getPerfectTime() throws RemoteException;

} ///:~

它表面上与其他接口是类似的，只是对Remote进行了扩展，而且它的所有方法都会“掷”出RemoteException（远程异常）。记住接口和它所有的方法都是public的。

15.8.2 远程接口的实施

服务器必须包含一个扩展了UnicastRemoteObject的类，并实现远程接口。这个类也可以含有附加的方法，但客户只能使用远程接口中的方法。这是显然的，因为客户得到的只是指向接口的一个句柄，而非实现它的那个类。

必须为远程对象明确定义构建器，即使只准备定义一个默认构建器，用它调用基础类构建器。必须把它明确地编写出来，因为它必须“掷”出RemoteException违例。

下面列出远程接口PerfectTime的实施过程：

899-900页程序

//: c15:rmi:PerfectTime.java

// The implementation of

// the PerfectTime remote object.

package c15.rmi;

import java.rmi.*;

import java.rmi.server.*;

import java.rmi.registry.*;

import java.net.*;

public class PerfectTime

extends UnicastRemoteObject

implements PerfectTimeI {

// Implementation of the interface:

public long getPerfectTime()

throws RemoteException {

return System.currentTimeMillis();

}

// Must implement constructor

// to throw RemoteException:

public PerfectTime() throws RemoteException {

// super(); // Called automatically

}

// Registration for RMI serving:

public static void main(String[] args) {

System.setSecurityManager(

new RMISecurityManager());

try {

PerfectTime pt = new PerfectTime();

Naming.bind(

"//peppy:2005/PerfectTime", pt);

System.out.println("Ready to do time");

} catch(Exception e) {

e.printStackTrace();

}

} ///:~

在这里，main()控制着设置服务器的全部细节。保存RMI对象时，必须在程序的某个地方采取下述操作：

(1) 创建和安装一个安全管理器，令其支持RMI。作为Java发行包的一部分，适用于RMI唯一一个是RMISecurityManager。

(2) 创建远程对象的一个或多个实例。在这里，大家可看到创建的是PerfectTime对象。

(3) 向RMI远程对象注册表注册至少一个远程对象。一个远程对象拥有的方法可生成指向其他远程对象的句柄。这样一来，客户只需到注册表里访问一次，得到第一个远程对象即可。

1. 设置注册表

在这儿，大家可看到对静态方法Naming.bind()的一个调用。然而，这个调用要求注册表作为计算机上的一个独立进程运行。注册表服务器的名字是rmiregistry。在32位Windows环境中，可使用：

start rmiregistry

令其在后台运行。在Unix中，使用：

rmiregistry &

和许多网络程序一样，rmiregistry位于机器启动它所在的某个IP地址处，但它也必须监视一个端口。如果象上面那样调用rmiregistry，不使用参数，注册表的端口就会默认为1099。若希望它位于其他某个端口，只需在命令行添加一个参数，指定那个端口编号即可。对这个例子来说，端口将位于2005，所以rmiregistry应该象下面这样启动（对于32位Windows）：

start rmiregistry 2005

对于Unix，则使用下述命令：

rmiregistry 2005 &

与端口有关的信息必须传送给bind()命令，同时传送的还有注册表所在的那台机器的IP地址。但假若我们想在本地测试RMI程序，就象本章的网络程序一直测试的那样，这样做就会带来问题。在JDK 1.1.1版本中，存在着下述两方面的问题（注释⑦）：

(1) localhost不能随RMI工作。所以为了在单独一台机器上完成对RMI的测试，必须提供机器的名字。为了在32位Windows环境中调查自己机器的名字，可进入控制面板，选择“网络”，选择“标识”卡片，其中列出了计算机的名字。就我自己的情况来说，我的机器叫作“Colossus”（因为我用几个大容量的硬盘保存各种不同的开发系统——Clossus是“巨人”的意思）。似乎大写形式会被忽略。

(2) 除非计算机有一个活动的TCP/IP连接，否则RMI不能工作，即使所有组件都只需要在本地机器里互相通信。这意味着在试图运行程序之前，必须连接到自己的ISP（因特网服务提供者），否则会得到一些含义模糊的违例消息。

⑦：为找出这些信息，我不知损伤了多少个脑细胞。

考虑到这些因素，bind()命令变成了下面这个样子：

Naming.bind("//colossus:2005/PerfectTime", pt);

若使用默认端口1099，就没有必要指定一个端口，所以可以使用：

Naming.bind("//colossus/PerfectTime", pt);

在JDK未来的版本中（1.1之后），一旦改正了localhost的问题，就能正常地进行本地测试，去掉IP地址，只使用标识符：

Naming.bind("PerfectTime", pt);

服务名是任意的；它在这里正好为PerfectTime，和类名一样，但你可以根据情况任意修改。最重要的是确保它在注册表里是个独一无二的名字，以便客户正常地获取远程对象。若这个名字已在注册表里了，就会得到一个AlreadyBoundException违例。为防止这个问题，可考虑坚持使用rebind()，放弃bind()。这是由于rebind()要么会添加一个新条目，要么将同名的条目替换掉。

尽管main()退出，我们的对象已经创建并注册，所以会由注册表一直保持活动状态，等候客户到达并发出对它的请求。只要rmiregistry处于运行状态，而且我们没有为名字调用Naming.unbind()方法，对象就肯定位于那个地方。考虑到这个原因，在我们设计自己的代码时，需要先关闭rmiregistry，并在编译远程对象的一个新版本时重新启动它。

并不一定要将rmiregistry作为一个外部进程启动。若事前知道自己的是要求用以注册表的唯一一个应用，就可在程序内部启动它，使用下述代码：

LocateRegistry.createRegistry(2005);

和前面一样，2005代表我们在这个例子里选用的端口号。这等价于在命令行执行rmiregistry 2005。但在设计RMI代码时，这种做法往往显得更加方便，因为它取消了启动和中止注册表所需的额外步骤。一旦执行完这个代码，就可象以前一样使用Naming进行“绑定”——bind()。

15.8.3 创建根与干

若编译和运行PerfectTime.java，即使rmiregistry正确运行，它也无法工作。这是由于RMI的框架尚未就位。首先必须创建根和干，以便提供网络连接操作，并使我们将远程对象伪装成自己机器内的某个本地对象。

所有这些幕后的工作都是相当复杂的。我们从远程对象传入、传出的任何对象都必须“implement Serializable”（如果想传递远程引用，而非整个对象，对象的参数就可以“implement Remote”）。因此可以想象，当根和干通过网络“汇集”所有参数并返回结果的时候，会自动进行序列化以及数据的重新装配。幸运的是，我们根本没必要了解这些方面的任何细节，但根和干却是必须创建的。一个简单的过程如下：在编译好的代码中调用rmic，它会创建必需的一些文件。所以唯一要做的事情就是为编译过程新添一个步骤。

然而，rmic工具与特定的包和类路径有很大的关联。PerfectTime.java位于包c15.Ptime中，即使我们调用与PerfectTime.class同一目录内的rmic，rmic都无法找到文件。这是由于它搜索的是类路径。因此，我们必须同时指定类路径，就象下面这样：

rmic c15.PTime.PerfectTime

执行这个命令时，并不一定非要在包含了PerfectTime.class的目录中，但结果会置于当前目录。

若rmic成功运行，目录里就会多出两个新类：

PerfectTime_Stub.class

PerfectTime_Skel.class

它们分别对应根（Stub）和干（Skeleton）。现在，我们已准备好让服务器与客户互相沟通了。

15.8.4 使用远程对象

RMI全部的宗旨就是尽可能简化远程对象的使用。我们在客户程序中要做的唯一一件额外的事情就是查找并从服务器取回远程接口。自此以后，剩下的事情就是普通的Java编程：将消息发给对象。下面是使用PerfectTime的程序：

903-904页程序

ID字串与那个用Naming注册对象的那个字串是相同的，第一部分指出了URL和端口号。由于我们准备使用一个URL，所以也可以指定因特网上的一台机器。

从Naming.lookup()返回的必须造型到远程接口，而不是到类。若换用类，会得到一个违例提示。

在下述方法调用中：

t.getPerfectTime( )

我们可看到一旦获得远程对象的句柄，用它进行的编程与用本地对象的编程是非常相似（仅有一个区别：远程方法会“掷”出一个RemoteException违例）。

15.8.5 RMI的替选方案

RMI只是一种创建特殊对象的方式，它创建的对象可通过网络发布。它最大的优点就是提供了一种“纯Java”方案，但假如已经有许多用其他语言编写的代码，则RMI可能无法满足我们的要求。目前，两种最具竞争力的替选方案是微软的DCOM（根据微软的计划，它最终会移植到除Windows以外的其他平台）以及CORBA。CORBA自Java 1.1便开始支持，是一种全新设计的概念，面向跨平台应用。在由Orfali和Harkey编著的《Client/Server Programming with Java and CORBA》一书中（John Wiley&Sons 1997年出版），大家可获得对Java中的分布式对象的全面介绍（该书似乎对CORBA似乎有些偏见）。为CORBA赋予一个较公正的对待的一本书是由Andreas Vogel和Keith Duddy编写的《Java Programming with CORBA》，John Wiley&Sons于1997年出版。

15.9 总结

由于篇幅所限，还有其他许多涉及连网的概念没有介绍给大家。Java也为URL提供了相当全面的支持，包括为因特网上不同类型的客户提供协议控制器等等。

除此以外，一种正在逐步流行的技术叫作Servlet Server。它是一种因特网服务器应用，通过Java控制客户请求，而非使用以前那种速度很慢、且相当麻烦的CGI（通用网关接口）协议。这意味着为了在服务器那一端提供服务，我们可以用Java编程，不必使用自己不熟悉的其他语言。由于Java具有优秀的移植能力，所以不必关心具体容纳这个服务器是什么平台。

所有这些以及其他特性都在《Java Network Programming》一书中得到了详细讲述。该书由Elliotte Rusty Harold编著，O'Reilly于1997年出版。

15.10 练习

(1) 编译和运行本章中的JabberServer和JabberClient程序。接着编辑一下程序，删去为输入和输出设计的所有缓冲机制，然后再次编译和运行，观察一下结果。

(2) 创建一个服务器，用它请求用户输入密码，然后打开一个文件，并将文件通过网络连接传送出去。创建一个同该服务器连接的客户，为其分配适当的密码，然后捕获和保存文件。在自己的机器上用localhost（通过调用InetAddress.getByName(null)生成本地IP地址127.0.0.1）测试这两个程序。

(3) 修改练习2中的程序，令其用多线程机制对多个客户进行控制。

(4) 修改JabberClient，禁止输出刷新，并观察结果。

(5) 以ShowHTML.java为基础，创建一个程序片，令其成为对自己Web站点的特定部分进行密码保护的大门。

(6) （可能有些难度）创建一对客户／服务器程序，利用数据报（Datagram）将一个文件从一台机器传到另一台（参见本章数据报小节末尾的叙述）。

(7) （可能有些难度）对VLookup.java程序作一番修改，使我们能点击得到的结果名字，然后程序会自动取得那个名字，并把它复制到剪贴板（以便我们方便地粘贴到自己的E-mail）。可能要回过头去研究一下I/O数据流的那一章，回忆该如何使用Java 1.1剪贴板。