CSC 224 Lecture Notes

• Very large IO library (60+ classes)
• "Old"-style stream classes
  • Deal with bytes; not suitable for 2-byte chars
  • Not eliminated from use; still need for binary
• "New"-style reader/writer classes
  • Deal with 2-byte characters; e.g. for text files
  • Still need to interact with stream classes

• Both old and new follow decorator pattern
  • Also known as the filter design pattern
• Layers of functionality added
  • Decorate or filter stream to get desired access
  • e.g. <- ZipInputStream <- FileInputStream <-
• Extremely flexible; worth the trouble? No!
  • Mix and match to get exactly what’s needed
  • Learn the common combinations for now

• InputStream - byte input superclass
  • One abstract method: int read()
• DataInput interface for binary files
  • Methods for reading all primitive Java types
  • DataInputStream - reading input stream
• BufferedInputStream
  • Reading from an input stream using a buffer
• FileInputStream - reading from files

• Reader - character input superclass
  • Two abstract methods: read(...), close()
• InputStreamReader - byte to character
  • Reads characters from InputStream
• BufferedReader - reading buffered input
• FileReader - reading chars from files
• LineNumberReader - keeps track of lines

• OutputStream - byte output superclass
• One abstract method: write(int)
• DataOutput interface for binary files
  • Methods for writing all Java primitive types
  • DataOutputStream - writing output stream
• BufferedOutputStream - buffered
• FileOutputStream - output to a file

• Writer - character output superclass
  • Abstract methods: write, flush, close
• OutputStreamWriter - character to byte
  • Writes characters to OutputStream
• BufferedWriter - writing using buffer
• FileWriter - writing chars to files
• PrintWriter - textual rep of values
  • Using familiar print and println methods

• RandomAccessFile
  • Implements both DataInput and DataOutput
  • Constructor parameter for read or read/write
• Does not delete existing file when writing
  • Using any other output steam will!
• seek moves file pointer to byte location
  • writeInt, readInt, etc., to write/read data

• GZIPInputStream, GZIPOutputStream
  • Reading from and writing to a GZIP file
• ZipInputStream, ZipOutputStream
  • Reading and writing entries in a Zip file
  • ZipEntry class to hold entry information
  • {get,put}NextEntry then normal file I/O
• Checked{Input,Output}Stream
  • Computes checksum for validating file I/O

• File class encapsulates management ops
  • Can represent either a file or a directory
  • Getting info about file (date, size, path, etc.)
  • Renaming or removing a file
  • Getting all files in a directory (list methods)
• FilenameFilter selects certain files
  • accept method used to accept/reject files
  • list methods take FilenameFilter object

• Object serialization mechanism
  • Automatically reads/write entire object
    • As well as connected objects
  • Tag class: implements Serializable
• Use Object{Input,Output}Stream
  • writeObject serializes object automatically
  • readObject deserializes (Object returned)

Many current programming languages are object-oriented.

There is a mismatch between traditional sockets and RPC and object-oriented languages.

A distributed object system allows objects that are distributed across multiple hosts to interact with one another.

Examples:

• Java-RMI
• Distributed COM (DCOM)
• Common Object Request Broker Architecture (CORBA)
• SOAP (Simple Object Access Protocol)

Distributed objects should (mostly) provide location transparency.

Location transparency in the context of distributed objects means that we do not know or care where a distributed object is located.

Advantages of location transparency:

• Easier for the programmer.
• Reliability: if the host of an object fails, move the object to another machine.
• Performance: if the host of an object cannot support its clients, replicate the object on several hosts.

Of course, things are not quite that easy...

Distributed objects interact via Remote Method Invocation (RMI), just as normal objects interact via method invocation.

Terminology warning: RMI is used to name the concepts and the implementations.

At run-time on a particular system, some objects will be local and others will be remote.

If a method is invoked on a remote object, then a remote procedure call takes place.

The location of the remote object determines the destination of the remote procedure call.

• Distributed objects only use interfaces to interact with one another.
• Distributed object systems use an Interface Definition Language (IDL) to describe interfaces.
• IDLs need not be part of a programming language, but they often look suspiciously like C with extra keywords.
• Java-RMI uses Java interfaces, which are part of the Java programming language. This is possible because Java-RMI is intended to be used only between Java systems.

The interface is used to automatically generate code.

The stub code runs on the client and turns the local method invocation into a remote method invocation. The stub is also known as a proxy.

The skeleton code runs on the server. It receives a remote method invocation from the stub code, and forwards it to the real object.

With Java-RMI, the stub and skeleton code is generated from an interface using the RMI compiler (rmic).

How do distributed objects find out about one another?

A naming or lookup service is a separate server that records which distributed objects are available and where they can be found.

A server registers its objects with the naming service.

A client looks up a remote object in the naming service.

With Java-RMI, the RMI registry (rmiregistry) performs naming services for distributed objects.

CORBA has a similar mechanism: the CORBA Naming Service.

• Download the three files into your 'Calculator' directory
• (Unlike the socket code)To really run a distributed RMI program takes some trivial system programming which you can find in the tutorial, localhost is fine for our purposes for now (No matter what it will still run throught the TCP/IP stack, this is a legitimate RMI program.)
• Open three DOS/Command Prompt windows, and change to the directory with the source code in each window.
• Compile the Java source code: javac *.java
• Generate the stub and skeleton code: rmic CalculatorImpl
• In the first window, start the Java-RMI registry: rmiregistry
• In the second window, create the CalculatorImpl remote object: java CalculatorImpl
• In the third window, run the CalculatorClient: java CalculatorClient
• This is a good time to use .bat files!

Warning: if your network is misconfigured, you may get strange errors when you try Java-RMI examples. Try running it in the Software Exploration labs in the CS&T building instead. It does work there.

On a trial run:

$ netstat -a --inet
Proto Local Address           Foreign Address         State
tcp   *:1099                  *:*                     LISTEN
tcp   *:3408                  *:*                     LISTEN
tcp   localhost:3416          localhost:1099          TIME_WAIT
tcp   livy.cs.depaul.edu:3417 livy.cs.depaul.edu:3408 TIME_WAIT

What does this mean?

• The RMI registry is listening on port 1099.
• The CalculatorImpl object is listening for requests on port 3408.
• CalculatorClient opened a connection from port 3416 to the RMI registry to lookup the Calculator service (implemented by the CalculatorImpl object).
• CalculatorClient opened a connection from port 3417 to the CalculatorImpl object.

The client host supports two objects:

• An instance of the CalculatorClient class. The programmer writes this class.
• A stub or proxy, which is an instance of the CalculatorImpl_Stub class. This class is generated automatically by the RMI compiler.

The server host supports two objects:

• An instance of the CalculatorImpl class. The programmer writes this class.
• A skeleton, which is an instance of the CalculatorImpl_Skel class. This class is generated automatically by the RMI compiler.

The classes CalculatorImpl_Stub and CalculatorImpl implement the interface Calculator.

For example, the add method is invoked by the instances of CalculatorClient and CalculatorImpl_Skel. This is regular method invocation.

The RMI registry only needs to be contacted once, not once for every remote method invocation.

Provides the illusion of location transparency.

How can a server interact with a client?

In the calculator example, a client performs a remote method invocation, and the server returns some data.

But what if the server wants to initiate an interaction?

For example, a chat server needs to be able to notify all clients that one client has sent a message.

A generic solution is for the client to poll the server:

Child -> Parent: Are we nearly there yet?
Parent -> Child: No.
Child -> Parent: Are we nearly there yet?
Parent -> Child: No!
Child -> Parent: Are we nearly there yet?
Parent -> Child: No!!
Child -> Parent: Are we nearly there yet?
Parent -> Child: Yes.
        

For the chat server, each client repeatedly asks the server whether it has any new messages. The client may pause between questions.

Polling is not restricted to RMI, nor even to distributed systems.

Sometimes polling is the only solution, e.g., if the client is behind a firewall.

Polling can be an inefficient use of resources (network traffic, processor time).

The alternative is for the server to initiate an interaction with the client:

Child -> Parent: Please tell me when we have arrived.
...time passes...
Parent -> Child: We are there now.
        

This is a callback.

Callbacks are often used in non-distributed systems, e.g., graphical user interface programming, parsing XML documents.

The client (who wants to be called back) must tell the server (who will call back) how to contact the client.

The server will need to know the client's IP address and a port number.

Callbacks are straightforward with RMI. The client passes a remote object reference to the server, and the remote object reference knows how to contact the client on behalf of the server.

With Java-RMI, the RMI registry is not involved when the client passes a remote object reference to the server.

Primitive data types such as booleans, integers, and floating point numbers are marshalled and transmitted.

Sometimes objects are marshalled and transmitted in their entirety. This leads to duplication and call-by-value parameter passing.

Sometimes a remote object reference is sent instead of the object.

How can we tell for Java-RMI?

If an object's class implements the java.rmi.Remote interface, then a remote object reference is sent instead of a copy of the object.

If the client sends a remote object reference to the server, then the server can call back to the client by remote method invocations on the remote object reference. The client becomes a server!

Instructions:

• Open four DOS/Command Prompt windows, and change to the directory with the source code in each window.
• Compile the Java source code: javac *.java
• Generate the stub and skeleton code: rmic ChatReceiverImpl
• Generate the stub and skeleton code: rmic ChatServerImpl
• In the first window, start the Java-RMI registry: rmiregistry
• In the second window, create the ChatServerImpl remote object: java ChatServerImpl
• In the third window, create a ChatReceiverImpl object: java ChatReceiverImpl
• Create another ChatReceiverImpl object in the fourth window: java ChatReceiverImpl
• Now type a message into the third window and press return/enter. It should appear on the second, third, and fourth windows. You can also type messages into the fourth window.