Using different middleware

Same problem, different middleware

The client-half object pattern has been given as a means of abstracting away from particular middleware solutions, so that code not directly involved in networking is not affected by changes of middleware.

In this section, we look at the "simple ftp" problem considered earlier, and give a variety of solutions using different middleware systems

Service specification

We specify the service using a Java interface.

There is a concession to lessons from RMI being adopted by a number of middleware systems: in recognition that network errors can occur in calling remote services, the interface extends Remote and all methods throw RemoteException. This exception should not be visible "on the wire" since it is not a cross-platform solution - for example, .NET remoting has its different equivalent System.Runtime.Remoting.RemotingException However, these exceptions are normally generated in the client HOPP and do not appear on the wire. Web Services don't conform to this and the WSDL lists remote exceptions even though they are not generated on the service side.

Service Implementation

Client view

Client UI

The client UI is independent of the network code. It just needs to know that the client half-object implements the common interface common.FileTransfer. To avoid hard-coding the actual half-object into the UI, a call is made to a factory object.

Factory

A factory object is used to generate specific client half-objects. It uses command line parameters passed from the UI object to determine which half-object to return. All half-objects implement the FileTransfer interface

Sockets

The socket-based solution requires a client half-object and a server talking across an ordinary socket

Socket constants

This just defines strings that are common to both client and server

Socket client

Socket server

Running

To run the server,

java socket.FileTransferServer

java client.FileTransferClientUI socket localhost

Web services

• There are several ways of deploying a Web Service, and that has an effect (unfortunately) on the code you can use
• "Instant deployment" places strong restrictions on the service and so is not really recommended
• It is better to use the more complex mechanisms, but they take more work

Instant deployment using Axis

Steps:

• Write the Java source code eg FileTransferServerHOPP.java
• Copy this to the Axis directory e.g. /home/local/jakarta-tomcat/webapps/axis and change the extension to .jws
  

  cp FileTransferServerHOPP.java \
        /home/local/jakarta-tomcat/webapps/axis/FileTransferServerHOPP.jws

• That's all you need to do from the service side
• The endpoint address of the service will be

  http://host:8088/axis/FileTransferServerHOPP

Instant deployment Service HOPP

• The service cannot be in a package - so the service implementation above cannot be used without change
• Only standard data-types can be used, not custom ones
• Make a copy of the server implementation above but not including the package
• The modified service is (note: not in a package):

Client HOPP

There are several ways of building a client HOPP. One way is to generate the WSDL and from there generate a set of client-side classes. This is the technically simpler but more laborious way based on constructing each function call by hand. Note that call.invoke() will throw a RemoteException if an error occurs.

Running

Download Axis from Apache.org. Copy the FileTransferClientHOPP.java to the axis subdirectory with the .jws extension. Start Axis

To run the client, the classpath needs to include the Axis libraries and also the Xerces XML parser library. Then

java -classpath ... client.FileTransferClientUI webservice localhost

CORBA

IDL

The file ftp.idl contains

Generate files by

idlj -fall ftp.idl

Generated files are

• FileTransferHelper.java
• FileTransferHolder.java
• FileTransfer.java
• FileTransferOperations.java
• FileTransferPOA.java
• _FileTransferStub.java
• string_seqHelper.java
• string_seqHolder.java

CORBA generates its own interfaces and classes. By specifying the module as corba, it generates the corba.FileTransfer, not common.FileTransfer. It also introduces classes such as FileTransferPOA which have to be used. So introduce a "wrapper" class to translate between CORBA and our implementation.

CORBA Server

CORBA Server HOPP

CORBA Client HOPP

CORBA IDL allows the application-defined exceptions. However, any remote method call can also throw an exception. These exceptions are unchecked, that is, they do not form part of the method signature and do not need to be caught. However, if an unchecked exception is thrown and not caught, then it will terminate the application. So it is better to catch them. They are all subclasses of org.omg.CORBA.SystemException.

Running

A name server needs to run

tnameserv -ORBInitialPort 9876

Then you can run the server

java corba.FileTransferServer \
	  -ORBInitialHost localhost \
	  -ORBInitialPort 9876

The client is

java client.FileTransferClientU corba \
	  -ORBInitialHost localhost \
	  -ORBInitialPort 9876

RMI

RMI client

RMI server

Running

Run an RMI name server

rmiregistry

Run the server

java -classpath classes \
     -Djava.rmi.server.codebase=http://localhost/classes/ \
     -Djava.security.policy=policy.all \
     rmi.FileTransferServer

Run the client

java -classpath classes \
     -Djava.security.policy=policy.all \
     client.FileTransferClientUI \
     rmi \
     localhost

Alternative clients

The HOPP model shows that we can change the middleware without too many problems for a decent middleware system. But we can also change the UI for any given system in the same way!

Here is a GUI based client that uses Swing and exactly the same HOPP objects

Session state

• There are three possibilities for managing client state on the server:
  1. The server keeps no state
  2. The server keeps state on a per-client basis
  3. The session keeps a single client state
• The Web Service follows (1) and keeps no state at all. Each request runs a new copy of the service. Even if the client does a chdir, the next time a getdir is requested it is to a new copy of the service, which remembers no state changes
• The CORBA and RMI servers follow case (3): there is a single server object that keeps one copy of server state. If multiple clients do a chdir then the value of the state changes for every client
• The socket server creates a new service object for each client connection and so follows (2). Each chdir is unique for each client connection
• All of the middleware models agree only if the protocol has no state requirements.
• There do not appear to be any formal models to describe state models in the server