Middleware Systems

The underlying networking protocols on which middleware systems are built are

• IP
• UDP
• TCP

The middleware systems we have looked at are

• Sun ONC/RPC (Open Network Computing)
• RMI (Remote Method Invocation)
• CORBA (Common Object Request Broker Architecture)
• Web services (SOAP/WSDL/UDDI)
• Jini
• JXTA (to come)

There are a number of others that we haven't looked at, including

• Open Software Foundation DCE (Distributed Computing Environment)
• Microsoft DCOM
• Enterprise Java Beans

There are a lot of middleware services that we haven't looked at

• Transaction monitors
• Directory systems such as LDAP (Lightweight Directory Access Protocol)
• Messaging systems such as Java JMS
• Event-based systems such as Elvin

Data representation (what is moved)

Sockets	byte/char streams
ONC	XDR (External data representation)
RMI	Java MarshalledObject
Web services	SOAP
CORBA	CDR (Common data representation)
Jini	Java MarshalledObject

Transport (how it is moved)

Service description

Sockets	none
ONC	Sun IDL (Interface definition language)
RMI	Java interface
Web services	WSDL (Web service description language)
CORBA	CORBA IDL
Jini	Java interface

Locating services

Sockets	known address
ONC	known address
RMI	RMI Naming Service
Web services	UDDI (Universal Description, Discovery and Integration)
CORBA	Naming service/Trader
Jini	Jini Lookup Service

Lookup matching

Sockets	none
ONC	none
RMI	exact string match
Web services	string searches
CORBA	string match or string search
Jini	object match

Language bindings

Sockets	Unix C, Java, Perl, Visual Basic, Visual C++, ...
ONC	Unix C, Java, Perl, ...
RMI	Java only (JDK 1.1 on, not Visual Java)
Web services	Java, .NET, Perl
CORBA	C, C++, Cobol, Python, ...
Jini	Java only (JDK 1.2 on)

Language paradigm

Sockets	streams
ONC	procedujre call
RMI	method call
Web services	procedure call
CORBA	method call
Jini	method call

Remote reference

Sockets	socket
ONC	opaque data structure
RMI	proxy object
Web services	URL
CORBA	proxy reference
Jini	proxy object

Synchronicity

Some middleware systems support event mechanisms for asynchronous processing, some only support synchronous processing

Sockets	synchronous
ONC	synchronous
RMI	synchronous
Web services	synchronous
CORBA	synchronous/asynchronous
Jini	synchronous/asynchronous

Garbage collection

Some systems will garbage collect objects/services and clean up registries. Others won't.

Sockets	no
ONC	no
RMI	yes
Web services	no
CORBA	no
Jini	yes

Bridges

Can a Jini service talk to a CORBA client? Can a Web service be used by an ONC client? Generally not, even if the two middleware systems share lots of concepts (e.g. CORBA and RMI are both O/O based). Reasons

• the data type representations will be different
• the protocol format will be different

To allow services of one protocol to talk to clients of another, a bridge has to be built, where something understands enough of both protocols.

Jini to CORBA

See earlier lecture. Build a Jini service that is also a CORBA client to translate between protocols

RMI to CORBA

Standard RMI:

Since the client does not see the protocol, this can be changed from JRMP to IIOP. The server uses an object that uses IIOP instead of JRMP. i.e. it uses PortableRemoteObject instead of UnicastRemoteObject.

CORBA 2.3 introduced "objects by value". An ORB that supports this concept knows how to handle RMI stub objects

Tunnelling

Many RPC systems such as Sun ONC and RMI use a random port (above 1024) to perform the remote call. This means that it must be possible to connect to a random port. Network administrators do not like this, since attacks can be mounted on these ports.

Foe security, network admins will close off as many ports as they can, and only leave a few open. Typically they will leave open

• port 80 for HTTP traffic
• port 21 for an ftp server
• port 25 for mail

Tunnelling is the technique of wrapping a message as another protocol's message and sending it by the second protocol instead of the first. When the message arrives, it is unwrapped and sent to the correct receiver. HTTP tunnelling uses an HTTP server, and a CGI script (or equivalent). Messages are sent to the HTTP server which passes them to the CGI script. The CGI script knows how to handle the original message.