the integration of applications within and between business is made possible using middleware...

Introduction to Middleware

Technologies

The integration of applications within and between business is made possible using middleware technology.

Introduction

Need for Middleware Client/Server Building Blocks Generic Middleware Service-Specific Middleware RPC Middleware Message-oriented Middleware (MOM) Java RMI

Learning Objectives

Need For Middleware

Till 1980s most of computing was based on central host computers equipped with powerful processors and memory

Users interact with the host through the terminals that capture keystrokes and send the information to the host

Bottlenecks of this architecture are:◦ Processing power is limited to that of central host system.◦ Over dependence on the vendor for application software.◦ Lack of support for GUI and access to multiple dBs

Mainframes are an example of this architecture

Middleware

With the advent of PCs the files are downloaded from the shared location, processed and uploaded back to the file server.

The file server approach had a major drawback as it generated too much n/w traffic.

However, with the emergence of the client/server architecture the computing power for process management was distributed between file and server

For example, the client could query database server using relational database management systems through SQL

The results of the query are send to the client which then manipulates and processes the data.

Middleware

This 2 tier client/server architecture has a scalability limitation as the server is unable to contain the load when the number of users grows beyond a certain limit.

Moreover, any changes in applications or parameters would entail changes at all clients.

To overcome these limitations, middle tier was added between the user system interface client environment and dB management server environment

This middleware provides for connectivity across the heterogeneous platform.

A middleware is in some way analogous to a middleman who acts as a translator between a 2 people speaking different languages.

Middleware

Some of the design constraints of a good client/server system are as follows:◦ Facility to hide communication details◦ Language and platform independency◦ Enable processing on client or server or both

Middleware has emerged as a solution to satisfy these constraints.

Middleware is a distributed s/w that aids in transparent communication between client and server.

It runs on both the client and the server as shown in the following figure

Middleware

Middleware

Middleware

Log

ical V

iew

Ph

ysic

al V

iew

Middleware

Middleware

In the client/server model, the client requests for a service to be provided by the server.

A proper s/w glue between client and server system is essential to support all interactions between them.

Middleware serves this purpose. It plumbs 2 sides of an application and passes information

between them. It is a software that seamlessly integrates two disparate

entities – the client and the server. It includes all software needed to support interactions

between the client and the server. It starts with the client API that invokes the service, covers

the transmission of request over the n/w and the resulting response

Middleware

Middleware thus manages the interaction between disparate applications across the heterogeneous computing platforms

Middleware aids in business process integration, application integration, data integration, standards integration and platform integration.

Middleware exists between the application and the OS and network services on a system node in the n/w

Middleware services are sets of distributed software that provide an extension to the functional APIs provided by the OS and n/w services

Middleware

This increased functionality allows an application to:◦ Locate transparently across the n/w, provide

interaction with another application or service.◦ Be independent from n/w services◦ Be reliable and available◦ Scale up in capacity w/o losing functionality◦ Be OS & PL transparent

Middleware(advantages)

The OS for distributed computing can be networked OS, distributed OS or middleware-based OS.

Distributed OS◦ A distributed OS performs the same function as a uni-

proccessor OS, but it runs on multiple CPUs◦ The goal of distributed OS is to hide and manage

hardware resources.◦ It is manages as a single system.◦ Distributed OS may be multi-processor based or multi-

computer based.◦ Multiple computers are homogenous or heterogeneous

is nature.

Middleware-Based Operating System

Distributed OS◦ Structure


Distributed Operating System Services

Application Application Application

Networked OS◦ Distributed OS try to realize full system

transparency, whereas in networked OS multiple computers are connected in a network.

◦ The systems can be heterogeneous in nature◦ The user explicitly maintains an account in each

machine◦ As nodes are independent of each other, they are

easily extensible.


Networked OS◦ Structure


Network OS


Network OS Network OS

Network OS◦ The basic difference between a network OS and a

distributed OS is that the network OS does not attempt to provide a single image view for any of its services.

◦ Its main goal is to offer local services to remote clients.◦ The following are the characteristics of networked OS.

The individual nodes are highly autonomous All distribution of tasks is explicit to the user It includes software for providing remote access services

and file transfer Data/ device sharing is provided using networks

◦ The advantage of networked OS is its scalability and of distributed OS is its transparency and ease of use


Middleware-Based OS◦ Distributed OS does not have independent

computers and network OS does not have a single coherent view.

◦ Hence a middleware is added on top of network OS to combine the advantages of both distributed and network OS.


Networked OS◦ Structure


Network OS


Network OS Network OS

Middleware Operating System Services

Item Distributed OS Network OS

Middleware-Based OS

Multi-processor

Multi-computer

Degree of Transparency

Very High High Low High

Single OS Yes Yes No No

Number of copies of OS

1 N N N

Communication Mechanism

Shared Memory

Messages Files Model Specific

Resource Management

Global, central

Global, distributed

Per Node

Per Node

Scalability No Moderately Yes Varies

Openness Closed Closed Open Open

Middleware-Based Operating SystemComparison of distributed, network and middleware-based OSs

Middleware-Based OS (ORBExpress)◦ Middleware further raises the level of programming

of distributed applications, as developers need not worry about the platform or operating systems.

◦ Middleware is classified broadly as general middleware and service specific middleware based in whether it is generic or specifically provides a particular service

◦ Middleware services can be implemented in transaction-processing monitors, message servers, RPCs and Object Request Broker (ORB) or application servers.


It acts as a substrate for all client/server interactions. It is analogous to a common translator who translated

from Chinese, Spanish, French and Russian to English. Such a middleware includes

◦ the communication stacks for client/server communication, ◦ distributed directories for location, ◦ Authentication services for security,◦ RPCs for accessing remote functionalities &◦ Queuing services for asynchronous and loosely coupled

communication. Distributed file services and print services fall under this

category. Distributed Computing Environment is an example of

generic middleware.

Generic Middleware

In a heterogeneous distributed environment, a common set of distributed services should be available to the applications.

The Open Software Foundation’s DCE is a rich s/w technology that enables the development of distributed applications across heterogeneous systems, taking advantage of open, distributed computing.

DCE is a suite of integrated services available from a vendor neutral source that enables organizations to develop, use an maintain distributed applications across heterogeneous networks.

It is used in WWW, stock markets, telecom services

Distributed Computing Environment


Local Operating System & Transport Service

Thread Service

Remote Procedure Call

Applications

Time Service CDSSecurity Service

DFSDiskless Support

The key services required for supporting distributed applications provided by DCE are◦ Remote Procedure Call (RPC)◦ Directory Service◦ Security Service◦ Time Service◦ Threading Service◦ Distributed File Service◦ IDL Compiler◦ Diskless Support


Remote Procedure Call (RPC) RPC between clients and servers facilitates efficient

access of resources distributed across the network. It provides portability and network independence. At-most-once semantics over a connectionless

protocol such as UDP is the default semantics of DCE RPC

The protocol is as follows:◦ Client sends request packet to server◦ Server sends response packet to client which acknowledges

to the client the receipt of the request packet by the server◦ Client sends acknowledgement to server indication receipt of

the response request


Remote Procedure Call (RPC)◦ Like ONC RPC, DCE RPC solves the problem of

different data representations on different systems by translating the local data representations into a common data representation called NDR (Network Data Representation).

◦ This is done using stubs generated by the interface definition language (IDL) compiler using IDL of the objects.


Directory Service◦ It allows clients to identify and locate servers by

name.◦ The DCE directory service is a central repository

for information about resources in the distributed system.

◦ It provides a single naming model using X.500◦ The information consists of the name of the

resource and its associated attributes.◦ A DCE cell is a group of systems that share a

namespace under a common administration.◦ The DCE directory service consists of 3 parts


Directory Service◦ Cell Directory Service (CDS)

Manages a database of information about the resources in a group of machines called a DCE cell.

It is a high performance distributed service that provides a consistent location-independent method for naming and using resources inside a cell.

Can also be used for communication between cells. Enables DCE clients to locate compatible servers.


Directory Service◦ Cell Directory Service (CDS)

The directory services supports a hierarchical namespace structure similar to that found in common file systems

It consists of a root directory and a number of sub-directories.

Within each directory, there can reside zero or more leaf entries.

These entries contain structured information about the servers in the cell.

Each directory in the CDS namespace can hold 4 types of entries: Directories, soft-links, clearinghouses & objects


Directory Service◦ Global Directory Service (GDS)

Implements an international standard directory service and provides a global namespace that connects the local DCE cells into a universal hierarchy.

The GDS client and server are based on the X.500 standard


Directory Service◦ Global Directory Agent (GDA)

The GDA is between the cell and the GDS. It facilitates inter-operability between cells. CDS needs to be able to contact at least on GDA to

participate in the global naming environment. GDA helps CDS access names outside a cell. When CDS determines that a name is not in its own

cell, it passes the name to a GDA, which searches the appropriate naming environment (DNS etc.)

The GDA then returns information that enables the original CDS server to contact the CDS server in whose cell the name resides


Directory Service◦ Global Directory Agent (GDA)


GDS

GDA

CDS

Directory Service◦ A directory service programming interface

Both CDS and GDS are accesses using a single directory service API


Security Service◦ It ensures access between clients & servers.◦ It guarantees authenticity, integrity and privacy in

communications.◦ Its authentication service is based on Kerberos.

Kerberos is a trusted service that validates the identity of a user or service.

◦ After a user is authenticated he must be authorized to use the system resources. The authorization service provides a simple,

consistent way to manage access control information.


Time Service◦ Different components can obtain clocks from

different computers.◦ This service facilitates precise, fault-tolerant

synchronization of the system clocks throughout the n/w and reduces the load on the system administrator


Threading Service◦ It provides multiple threads of execution

capability◦ It includes operations to create and control

multiple threads of execution in a single process and to synchronize the access to global data within an application

◦ It thus facilitates multiple servers to access multiple clients simultaneously.


Distributed File Service◦ It provides access to files across the n/w in a

scalable, transparent, reliable, secure and efficient manner.

◦ As it provides a client/server model, it is easy to use and efficient.

◦ The benefits of the DFS are: Capability to interoperate with Sun’s Network File

System (NFS) Improvement in performance due to caching of files Support for small and large group of users Secure RPC facilitates secure access to user files and

directories


IDL Compiler◦ It is a compiler for converting high level interface

descriptions of the remote procedures into portable C-language source codes.

Diskless Service◦ It allows low-cost workstations to use disks on

servers.


It is needed to accomplish a particular client/server type of service.

Some of the service-specific middleware are listed as follows:◦ Database Middleware:

It allows direct access to data structures and provides interaction directly with databases.

There are database gateways that provide a single system view of heterogeneous dBs.

ETLC packages come under this middleware category Other examples are ODBC, ORACLE Glue, SQL etc.

Service Specific Middleware

continued Some of the service-specific middleware are listed as

follows:◦ OLTP Middleware:

Transaction processing monitors provide tools and an environment for developing and deploying distributed applications that have to manage transactions.

This is a type of message queuing, transaction scheduling and prioritization service where the client connects to the middle tier which in turn connects to the back-end dB

The transaction is accepted by the monitor which queues it and then takes responsibility for managing it, thus relieving the client.

It has the ability to connect to different DBMS in a single transaction irrespective of whether it is a flat file or non-relational DBMS.

Examples are:? ATMI, Transactional RPC


continued Some of the service-specific middleware are

listed as follows:◦ Communication Middleware

Sun RPC, ONC (Open N/W Connectivity) RPC RPCs enable the logic of an application to be

distributed across the n/w The distributed program logic on remote systems can

be executed like calling a local routine



listed as follows:◦ MOM – Message Oriented Middleware

Provides program-to-program data exchange enabling the creation of distributed applications.

MOM in analogous to email in the sense it is asynchronous and requires the recipients of messages to interpret their meaning and to take appropriate action

It increases flexibility of architecture by enabling applications to exchange messages with each other without the need to bother about underlying OS etc.

It is most appropriate for event driven applications Examples are PEERLOGIC and IBM’s MOM



listed as follows:◦ Object-Specific Middleware

CORBA, Microsoft’s DCOM These include ORBs which enable the objects that

comprise an application to be distributed and shared across heterogeneous n/ws.

It facilitates reusability and interoperability of distributed objects



listed as follows:◦ Workflow Management Middleware

Can track transactions from launch to landing Primarily focuses on the management of activity flow

in a client/server system



listed as follows:◦ Portals

Front end integration through portals facilitates transactions between user’s desktops and back-end systems.

Portals integrate portlets which can work independently



listed as follows:◦ Internet-Specific Middleware

It is a type of communication middleware It includes tools for communication such as HTTP, S-

HTTP and SSL.


Client Server Building Blocks

Clients◦ Thin Clients+◦ Fat Clients+◦ Runs the client side of the application◦ It runs on the OS that provides a GUI or an OOUI

and that can access distributed services, wherever they may be.

◦ The client also runs a component of the Distributed System Management (DSM) element.


Servers◦ Runs the server side of the application◦ The server application typically runs on top of some

shrink-wrapped server software package.◦ The five contending server platforms for creating the

next generation of client/server applications are SQL database severs, TP Monitors, groupware servers, Object servers and the Web server.

◦ The server side depends on the OS to interface with the middleware building block.

◦ The server also runs DSM component◦ It may be a simple agent or a shared object database

etc.


Middleware◦ Runs on both the client and server sides of an

application◦ This is broken into two categories

Middleware for Data Integration ODBC, JDBC

Middleware for system level process integration RPC, RMI, MOM

◦ Middleware is the nervous system of the client/server infrastructure

◦ This also has the DSM component


DSM◦ Runs on every node in the client/server network.◦ A managing workstation collects information from

all its agents on the network and displays it graphically.

◦ The managing workstation can also instruct its agents to perform actions on its behalf.


These building blocks can be rearranged to use them in the following situations:◦ 1. Client/Server for tiny shops and nomadic tribes - This is a

building-block implementation that runs the client, the middleware software, and most of the business services on the same machine. It is the suggested implementation for the one-person shops, home offices, and mobile users with well-endowed laptops. It is easy to run the client and server portion of an application on

the same machine. Vendors can easily package single-user versions of a client/server

application. The business critical client/server application runs on one

machine and does some occasional communications with outside servers to exchange data, refresh a database and send or receive mail and faxes. Ex: Internet.


These building blocks can be rearranged to use them in the following situations:◦ 2. Client/Server for small shops and departments - This is

the classic Ethernet client/single-server, building block implementation. It is used in small shops, departments, and branch offices. This is the predominant form of client/server today. The client/server architecture is particularly well-suited for the

LAN-based single server establishments. It consists of multiple clients talking to a local server. This is the model used in small businesses. The single-server nature of the model tends to keep the

middleware simple. The client only needs to look into a configuration file to find its

server's name.


These building blocks can be rearranged to use them in the following situations:◦ 2. Client/Server for small shops and departments - This

is the classic Ethernet client/single-server, building block implementation. It is used in small shops, departments, and branch offices. This is the predominant form of client/server today. Security is implemented at the machine level and kept

quite simple. The network is usually relatively easy to administer; it's a

part-time job for a member of the group. There are no complex interactions between servers, so it

is easy to identify failures- they're either on the client or on the local server.


These building blocks can be rearranged to use them in the following situations:◦ 3. Client/Server for intergalactic enterprises - This is the

multiserver building-block implementation of client/server. The servers present a single system image to the client. They can be spread out throughout the enterprise, but they can be made to look like they are part of the local desktop. This implementation meets the initial needs of intergalactic client/server computing. The client/server enterprise model addresses the needs of

establishments with a mix of heterogeneous servers. These models are upwardly scalable. When more processing power is needed for various intergalactic

functions, more servers can be added, or the existing server machine can be traded up for the latest generation of superserver machine.


These building blocks can be rearranged to use them in the following situations:◦ 3. Client/Server for intergalactic enterprises –

The servers can be partitioned based on the function they provide, the resource they control, or the database they own.

The servers can be replicated to provide a fault-tolerant service or to boost an application's performance.

Multiserver capability, when properly used, can provide an awesome amount of compute power and flexibility, in many cases rivaling that of mainframes.

To exploit the full power of multiservers, we need low-cost, high-speed bandwidth and an awesome amount of middleware features –including * network directory services * network security * remote procedure calls and * network time services.


These building blocks can be rearranged to use them in the following situations:◦ 3. Client/Server for intergalactic enterprises –

Middleware creates a common view of all the services on the network called a single system image.

Good software architecture for intergalactic enterprise client/server implementations is all about creating system "ensembles" out of modular building blocks.

Intergalactic client/server is the driving force behind middleware standards as distributed objects and the Internet.


These building blocks can be rearranged to use them in the following situations:◦ 4. Client/Server for a post-scarcity world - This model

transforms every machine in the world into both a client and a server. Personal agents on every machine will handle all the negotiations with their peer agents anywhere in the universe. This dream is almost within reach. Every machine is both a client and a full-function server. Because every machine is a full-function server, it will run, at a

minimum, a file server, database server, workflow agent, TP Monitor, and Web server - all connected via an ORB.

This is in addition to all the client software and middleware. In next few years, a hundred million machines or more may be

running almost all the forms of client/server software In this model instead of mobile agents, personal agents will be

used.


In this model, there is no difference between client and server side of communication

In this model, both the sides of the communication link use the same protocol interface for networked communication

The protocol is symmetrical and masks the underlying network communication from the user

Any computer can initiate a conversation with any other computer

In a p2p network relationship, a computer on the network communicates with any other computer as its equal.

Each computer is responsible for making its own resources available.

Peer-to-Peer (P2P) Communications

P2P communication is facilitated using sockets.

Some of the commercial implementations of P2P protocols are:◦ Unix Sockets◦ Novell Netware◦ IBM’s NetBIOS◦ Named pipes


Sockets◦ The communication between applications is handled

using a data structure called socket◦ Socket is a software abstraction used to represent the

terminals of a connection between 2 machines.◦ It provides a mechanism for the client to pass data to

the server and for the server to listen and service the client requests.

◦ A socket is used to allow one process to speak to another

◦ Sockets provide an abstraction in the session layer of ISO-OSI networking model to hide the complexities of wire transmission.


Sockets◦ The Berkeley socket interface is an application programming

interface (API) to code applications performing communication between hosts or between processes on one computer, using the concept of an Internet socket.

◦ It can work with many different Input/output devices, although support for these depends on the operating-system implementation.

◦ This interface implementation is the original API of the Internet Protocol Suite (TCP/IP).

◦ It was first developed at the University of California, Berkeley for use on Unix systems.

◦ All modern operating systems now have some implementation of the Berkeley socket interface, as it became the standard interface for connecting to the Internet.


Sockets◦ Socket interfaces are accessible at three different

levels. ◦ The most detailed and powerful method is control

at the raw socket level. ◦ Very few applications need the degree of control

over communications that this provides, so raw sockets support was intended to be available only on computers used for developing Internet-related technologies.

◦ In recent years, most operating systems have implemented support for it, including Microsoft Windows.


Sockets◦ Header Files

The Berkeley socket interface is defined in several header files. The names and content of these files differ slightly between implementations. In general, they include: <sys/socket.h> : Core BSD socket functions and data structures. <netinet/in.h> : AF_INET and AF_INET6 address families and their

corresponding protocol families PF_INET and PF_INET6. Widely used on the Internet, these include IP addresses and TCP and UDP port numbers.

<sys/un.h> : PF_UNIX/PF_LOCAL address family. Used for local communication between programs running on the same computer. Not used on networks.

<arpa/inet.h> : Functions for manipulating numeric IP addresses. <netdb.h> : Functions for translating protocol names and host

names into numeric addresses. Searches local data as well as DNS.


Sockets◦ API Functions

This list is a summary of functions or methods provided by the Berkeley sockets API library: socket() creates a new socket of a certain socket type,

identified by an integer number, and allocates system resources to it.

bind() is typically used on the server side, and associates a socket with a socket address structure, i.e. a specified local port number and IP address.

listen() is used on the server side, and causes a bound TCP socket to enter listening state.

connect() is used on the client side, and assigns a free local port number to a socket. In case of a TCP socket, it causes an attempt to establish a new TCP connection.



This list is a summary of functions or methods provided by the Berkeley sockets API library: accept() is used on the server side. It accepts a received

incoming attempt to create a new TCP connection from the remote client, and creates a new socket associated with the socket address pair of this connection.

send() and recv(), or write() and read(), or sendto() and recvfrom(), are used for sending and receiving data to/from a remote socket.

close() causes the system to release resources allocated to a socket. In case of TCP, the connection is terminated.

gethostbyname() and gethostbyaddr() are used to resolve host names and addresses. IPv4 only.



This list is a summary of functions or methods provided by the Berkeley sockets API library: select() is used to prune a provided list of sockets for

those that are ready to read, ready to write, or that have errors.

poll() is used to check on the state of a socket in a set of sockets. The set can be tested to see if any socket can be written to, read from or if an error occurred.

getsockopt() is used to retrieve the current value of a particular socket option for the specified socket.

setsockopt() is used to set a particular socket option for the specified socket.


Sockets◦ Types of Sockets

There are 3 types of sockets Stream Sockets: SOCK_STREAM

It provides byte-by-byte stream communication It facilitates sequenced, reliable, bi-directional

communication of data. Datagram Sockets: SOCK_DGRAM

It is used for datagram transmission It is used in connectionless protocol including information

such as sequence numbers Each packet of data is called a datagram It provides no ordering, so sequence numbers are used It provides an unreliable and bi-directional means of

communication


Sockets◦ Types of Sockets

There are 3 types of sockets Raw Interface Sockets: SOCK_RAW

It is a raw interface It is provided for more detailed control of messages Using it, users can define their own protocol.


Sockets◦ Client/Server Communication using TCP

Connection Oriented Protocol Socket() Bind() Listen() Accept() Write() Process() Read() Close()


Sockets◦ Client/Server Communication using UDP

Connection-Less Protocol Socket() Bind() Recvfrom() Sendto() Process() Read()


Sockets◦ Some of the implementations of communication

protocols are: Unix / Windows Sockets Novell Netware IBM’s NetBIOS Named Pipes


RPCRemote Procedure Calls

75

Masks remote function calls as being local Client/server model Request/reply paradigm usually implemented with

message passing in RPC service Marshalling of function parameters and return value

Remote Procedure Call (RPC)

Caller RPC Service RPC Service RemoteFunction

call(…)

1) Marshal args

2) Generate ID3) Start timer

4) Unmarshal5) Record ID

6) Marshal7) Set timer

8) Unmarshal9)

Acknowledge

fun(…)

message

76Spring 2002 CS 461

RPC Timeline

Client Server

Request

Reply

Computing

Blocked

Blocked

Blocked

RPC = Remote Procedure Call Birell and Nelson (1980s) calling procedures on remote machines basis for two tier systems start of the developement of distributed

systems basis for middleware, EAI and web

services

RPC - History

interface for procedures ◦ IDL (Interface Definition Language)

Compilation of IDL Result of compilation

◦ client and server stub for every defined procedure

◦ interface headers

RPC – How it works I

RPC - IDL Compilation - result

client code

language specific call

interface

client stub

client process server process

server code

server stub

language specific call

interface

development environment

IDL

IDL sources

IDL compile

r

interfaceheaders

RPC – How it works II

client

procedure call

client stub

locate(un)marshal(de)serialize

send (receive) com

munic

ati

on m

od

ule

com

munic

ati

on m

od

ule server

procedure

server stub

(un)marshal(de)serialize

receive (send)

dispatcher

selects stub


static binding◦ hard coded stub◦ simple◦ efficient◦ not flexible◦ stub recompilation necessary if the location

of the server changes◦ use of redundant servers not possible

RPC - binding

dynamic binding◦ name and directory server

load balancing◦ IDL used for binding◦ flexible◦ redundant servers possible

RPC - binding

RPC - dynamic binding

client

procedure call

client stubbind


findsend

receive

com

munic

ati

on m

od

ule

com

munic

ati

on m

od

ule server

procedure

server stubregister


receivesend

dispatcher

selects stub


name and directory server

2

4

5 6

7

8

9

1

12

11 10

12

13

12

3

RPC hides heterogeneity of a system x servers, y clients 2*x*y stubs, for each combination

◦ too much, not efficient solution: common form of representation

◦ mapped in IDL (platform independent)◦ x+y stubs need to be implemented

RPC - Heterogeneity

conventional RPC: sequential execution of routines

client blocked until response of server asynchronous RPC – non blocking

◦ client has two entry points(request and response)◦ server stores result in shared memory◦ client picks it up from there

RPC - Extensions

+ programmer aware of distribution, performance and reliability issues

+ error detection is easier

- no need to worry about details- simplicity- less opportunities to cause errors

RPC - Transparency

87

Protocol Stack◦ BLAST: fragments and reassembles large messages◦ CHAN: synchronizes request and reply messages ◦ SELECT: dispatches request to the correct process

Stubs

Spring 2002 CS 461

RCP Components

Caller(client)

Clientstub

RPCprotocol

Returnvalue

Arguments

ReplyRequest

Callee(server)

Serverstub

RPCprotocol

Returnvalue

Arguments

ReplyRequest

88

Unlike IP, tries to recover from lost fragments

Strategy◦ selective

retransmission ◦ aka partial

acknowledgements

Spring 2002 CS 461

Bulk Transfer (BLAST)Sender Receiver

Fragment 1Fragment 2Fragment 3

Fragment 5

Fragment 4

Fragment 6

Fragment 3Fragment 5

SRR

SRR

89

Sender:◦ after sending all fragments, set timer DONE◦ if receive SRR, send missing fragments and

reset DONE◦ if timer DONE expires, free fragments

Spring 2002 CS 461

BLAST Details

90

Receiver:◦ when first fragments arrives, set timer

LAST_FRAG◦ when all fragments present, reassemble and

pass up◦ four exceptional conditions:

if last fragment arrives but message not complete send SRR and set timer RETRY

if timer LAST_FRAG expires send SRR and set timer RETRY

if timer RETRY expires for first or second time send SRR and set timer RETRY

if timer RETRY expires a third time give up and free partial message

Spring 2002 CS 461

BLAST Details (cont)

91

MID must protect against wrap around

TYPE = DATA or SRR NumFrags indicates number of

fragments FragMask distinguishes among

fragments◦ if Type=DATA, identifies this fragment◦ if Type=SRR, identifies missing fragments

Spring 2002 CS 461

BLAST Header Format

Data

ProtNum

MID

Length

NumFrags Type

FragMask

0 16 31

92

Guarantees message delivery Synchronizes client with server Supports at-most-once semantics

Simple case Implicit Acks

Spring 2002 CS 461

Request/Reply (CHAN)

Client Server

Request

ACK

Reply

ACK

Client ServerRequest 1

Request 2

Reply 2

Reply 1

…

93

Lost message (request, reply, or ACK)◦ set RETRANSMIT timer◦ use message id (MID) field to distinguish

Slow (long running) server◦ client periodically sends “are you alive” probe,

or ◦ server periodically sends “I’m alive” notice

Want to support multiple outstanding calls◦ use channel id (CID) field to distinguish

Machines crash and reboot◦ use boot id (BID) field to distinguish

Spring 2002 CS 461

CHAN Details

94

typedef struct { u_short Type; /* REQ, REP, ACK, PROBE */ u_short CID; /* unique channel id */ int MID; /* unique message id */ int BID; /* unique boot id */ int Length; /* length of message */ int ProtNum; /* high-level protocol */} ChanHdr;

typedef struct { u_char type; /* CLIENT or SERVER */ u_char status; /* BUSY or IDLE */ int retries; /* number of retries */ int timeout; /* timeout value */ XkReturn ret_val; /* return value */ Msg *request; /* request message */ Msg *reply; /* reply message */ Semaphore reply_sem; /* client semaphore */ int mid; /* message id */ int bid; /* boot id */} ChanState;

Spring 2002 CS 461

CHAN Header Format

95

Asynchronous interfacesend(Protocol llp, Msg *message)

deliver(Protocol llp, Msg *message)

Synchronous interfacecall(Protocol llp, Msg *request, Msg *reply)

upcall(Protocol hlp, Msg *request, Msg *reply)

CHAN is a hybrid protocol◦ synchronous from above: call◦ asynchronous from below: deliver

Spring 2002 CS 461

Synchronous vs Asynchronous Protocols

96

Dispatch to appropriate procedure

Synchronous counterpart to UDP

Implement concurrency (open multiple CHANs)

Spring 2002 CS 461

Dispatcher (SELECT)Caller

SELECT

CHAN

call

call

deliversend

Callee

SELECT

CHAN

upcall

upcall

deliversend

ServerClient

• Address Space for Procedures– flat: unique id for each possible procedure – hierarchical: program + procedure number

97Spring 2002 CS 461

Simple RPC Stack

BLAST

ETH

IP

SELECT

CHAN

98

IP implements BLAST-equivalent◦ except no selective retransmit

SunRPC implements CHAN-equivalent ◦ except not at-most-once

UDP + SunRPC implement SELECT-equivalent ◦ UDP dispatches to program (ports bound to programs)◦ SunRPC dispatches to procedure within program

Spring 2002 CS 461

SunRPC

IP

ETH

SunRPC

UDP

99

XID (transaction id) is similar to CHAN’s MID

Server does not remember last XID it serviced

Problem if client retransmits request while reply is in transit

Spring 2002 CS 461

SunRPC Header Format

Data

MsgType = CALL

XID

RPCVersion = 2

Program

Version

Procedure

Credentials (variable)

Verifier (variable)

0 31

Data

MsgType = REPLY

XID

Status = ACCEPTED

0 31

100

Marshalling (encoding) application data into messages

Unmarshalling (decoding) messages into application data

Data types we consider◦ integers◦ floats◦ strings◦ arrays◦ structs

Spring 2002 CS 461

Presentation Formatting

Applicationdata

Presentationencoding

Applicationdata

Presentationdecoding

Message Message Message…

• Types of data we do not consider– images – video– multimedia documents

101

Representation of base types◦ floating point: IEEE 754 versus non-standard ◦ integer: big-endian versus little-endian (e.g.,

34,677,374)

Compiler layout of structures

Spring 2002 CS 461

Difficulties

(126)(34)(17)(2)

00000010Big-endian

Little-endian

(2)(17)(34)(126)

Highaddress

Lowaddress

0 0111111 00 001 0 01

00 001 001 00 001 0 01

00 001 001 000 000 01

0 0111111

102

Data types◦ base types (e.g., ints, floats); must convert◦ flat types (e.g., structures, arrays); must pack◦ complex types (e.g., pointers); must linearize

Conversion Strategy◦ canonical intermediate form◦ receiver-makes-right (an N x N solution)

Spring 2002 CS 461

Taxonomy

Marshaller

Application data structure

103

Language-level pattern of function call◦ easy to understand for programmer

Synchronous request/reply interaction◦ natural from a programming language point-of-view◦ matches replies to requests◦ built in synchronisation of requests and replies

Distribution transparency (in the no-failure case)◦ hides the complexity of a distributed system

Various reliability guarantees◦ deals with some distributed systems aspects of failure

Properties of RPC

104

Invocation semantics supported by RPC in the light of:

network and/or server congestion, client, network and/or server failure note DS independent failure

modes RPC systems differ, many examples, local

was Mayflower

Failure Modes of RPC

Exactly once (RPC system retries a few times)• Hard error return – some failure most likely note that “exactly once” cannot be guaranteed

Maybe or at most once (RPC system tries once)• Error return – programmer may retry

105

Synchronous request/reply interaction◦ tight coupling between client and server◦ client may block for a long time if server

loaded◦ leads to multi-threaded programming at

client◦ slow/failed clients may delay servers when

replying ◦ multi-threading essential at servers

Distribution Transparency◦ Not possible to mask all problems

RPC paradigm is not object-oriented◦ invoke functions on servers as opposed to

methods on objects

Disadvantages of RPC

fork(…)

join(…)

remote call

MessagingMessage Oriented Middleware

Message oriented communication

RPCs, i.e., enhance access transparency but they are not always appropriate to distributed system.

Persistence and SynchronicityDifferent types of communications

General organization of a communication system in which hosts are connected through a network

Example : E-mail system. If the target server is unreachable, the local one continue to store messages ( in contrast with a transient communication method).

Persistent communication

2-20

a) Persistent asynchronous communicationb) Persistent synchronous communication

Persistence and Synchronicity in Communication

2-22.1

c) Transient asynchronous communication (one way RPC)

d) Receipt-based transient synchronous communication


2-22.2

e) Delivery-based transient synchronous communication at message delivery(asynchronous RPCs)

f) Response-based transient synchronous communication (RPCs)


The need for persistent communication services is clear in developing middleware for large-scale distributed applications.

Only transient or persistent communications, like only synchronous or asynchronous communications, are not sufficient!

Message passing communication

◦ Anything can be a message : string, object, XML, JSON

◦ Arbitrary interaction patterns possible◦ 1-1, n-n, with replies, with no replies

What is a message?

Messaging Models

Topic

Subscriber

Subscriber

Publisher

Publish and Subscribe ( 1-> many )(pub/sub)

Queue

Receiver

Receiver

Sender

Point-to-Point ( 1-> 1 )(p2p, PTP)

115

Two main mode of message consumption on the receiver:◦ Blocking (synchronous, pull mode) with

MessageConsumer.receive()◦ Non-blocking (asynchronous, push mode) with:

MessageListener.onMessage(..)

Interaction Styles

Typically used with point-to-point queues

Active Reception (Pull)

Producer Queue Consumer

send(m1)

send(m3)

send(m2)

receive()m1

Put message into queue

Consume message

Typically used with 1-n communication (Publish/Subscribe)

Passive Reception (Push)

Producer Broker Consumer Consumer

Pass message to broker

publish(m1)

send(m2)

send(m2)

send(m1)

send(m1)Dispatch message to all consumers

publish(m2)

publish(m3)

Four combinations for loosely-coupled communications using queues.

Message oriented persistent communications Message-Queuing Model

basic idea: applications communicate by inserting messages in specific queues

2-26

Basic interface to a queue in a message-queuing system.

Message-Queuing Model

Primitive Meaning

Put Append a message to a specified queue

Get Block until the specified queue is nonempty, and remove the first message

Poll Check a specified queue for messages, and remove the first. Never block.

Notify Install a handler to be called when a message is put into the specified queue.

The relationship between queue-level addressing and network-level addressing.

General Architecture of a Message-Queuing System (1)The collection of queues is distributed across multiple machines queue names db

A message-queuing system with routers (or relays) can solve the problem of a static large scale system queue-to-location mapping

General Architecture of a Message-Queuing System (2)

2-29

The general organization of a message broker in a message-queuing system. It is generally not considered an integral part of the queuing system.

Message Brokersit converts incoming messages to a format compatible with the destination application

2-30

Setting up a stream between two processes across a network.

Data Stream (1)Sometime timing is crucial for communication…asynchronous, synchronous and isochronous mode for data stream

Setting up a stream directly between two devices.

Data Stream (2)

An example of multicasting a stream to several receivers.

Data Stream (3)

A flow specification.

Specifying QoS (1)Time dependent requirements are expressed as QoS

Characteristics of the Input Service Required

•maximum data unit size (bytes)•Token bucket rate (bytes/sec)•Toke bucket size (bytes)•Maximum transmission rate (bytes/sec)

•Loss sensitivity (bytes)•Loss interval (sec)•Burst loss sensitivity (data units)•Minimum delay noticed (sec)•Maximum delay variation (sec)•Quality of guarantee

The principle of a token bucket algorithm A token is a fixed number of bytes that an application can pass to the network. Tokens are buffered in buckets

Specifying QoS (2)

The basic organization of RSVP for resource reservation in a distributed system.

Receiver-initiated protocol

Setting Up a StreamResources required for streaming: bandwidth, buffers, processing capacity

Resource reSerVation Protocol

The principle of explicit synchronization on the level data units. The application is responsible for synchro.

Synchronization Mechanisms (1)

The principle of synchronization as supported by high-level interfaces.

Synchronization Mechanisms (2)

2-41

RPC vs. MOM

Feature RPC Advantage MOM

Client/Server model

Unlimited clients and servers with multiple brokers running anywhere in the network

RPC

Multiple clients with multiple servers restricted to limited number of queues on pre-determined servers in the network.

Client/Server relationship

Synchronous with Asynchronous possible. Clients and Servers designed to run concurrently. Clients can choose not to wait on Server response by using asynchronous option.

RPC

Asynchronous. Clients and Servers may operate at different times and speeds, response to Client is not guaranteed (synchronous not possible). Also, message queue backups can cause performance problems.

Platform Support

Unlimited; every vendor in the world supports RPC. RPC

Limited platform support for MOMs

Communication

Listen, Connect, Accept

NAPost a message then wai

RPC vs. MOMFeature RPC Advantage MOM

Administration and Monitoring

Many different commercially available monitors.

RPCNone

Scalability Easily done by starting additional servers based on load.

RPC

Very difficult to scale because there is no way to distribute queues dynamically.

Load-balancing Can be accomplished with performance monitors and application management systems.

RPC

Requires a monitor to manage more than as single queue. Single queue can be used to implement FIFO or priority based policy

Transactional Support

Yes; easily supported with RPC. RPC

Limited (Some Products) Message Queue can participate in the commit synchronization

RPC vs. MOMFeature RPC Advantage MOM

Message Filtering

NoMOM

Yes

Performance

Very Fast RPC Very Slow. An intermediate hop is required

Asynchronous processing

Yes; easily implemented with callback.

NONE

Yes. Queues and triggers are required

Java RMIRemote Method Invocation

135

Java RMI is a mechanism that allows a Java program running on one computer to apply a method to an object living on a different computer.◦ RMI is an implementation of the of the Distributed Object

programming model—similar to CORBA, but simpler and specialized to the Java language.

The syntax of the remote method invocation looks like an ordinary Java method invocation.◦ The remote method call can be passed arguments computed in

the context of the local machine. It can return arbitrary values computed in the context of the remote machine. The RMI runtime system transparently communicates all data required.

◦ In some ways Java RMI is more general than CORBA—it can exploit Java features like object serialization and dynamic class loading to provide more complete object-oriented semantics.

Remote Method Invocation

The Java Remote Method Invocation Application Programming Interface (API), or Java RMI, is a Java application programming interface that performs the object-oriented equivalent of remote procedure calls (RPC).

1. The original implementation depends on Java Virtual Machine (JVM) class representation mechanisms and it thus only supports making calls from one JVM to another.

◦ The protocol underlying this Java-only implementation is known as Java Remote Method Protocol (JRMP).

2. In order to support code running in a non-JVM context, a CORBA version was later developed.

RMI (1)

RMI (2)

Usage of the term RMI may denote solely the programming interface or may signify both the API and JRMP, whereas the term RMI-IIOP denotes the RMI interface delegating most of the functionality to the supporting CORBA implementation.

The programmers of the original RMI API generalized the code somewhat to support different implementations, such as a HTTP transport.

Additionally, the ability to pass arguments "by value" was added to CORBA in order to support the RMI interface.

Still, the RMI-IIOP and JRMP implementations do not have fully identical interfaces.

RMI (3)

RMI functionality comes in the package java.rmi, while most of Sun's implementation is located in the sun.rmi package.

Jini (IBM) offers a more advanced version of RMI in Java. ◦ It functions similarly but provides more advanced

searching capabilities and mechanisms for distributed object applications.

RMI (4)

Fundamental Idea (1) Rely on the same programming paradigm

for distributed applications as for centralized applications◦ In procedural languages, we will rely on the notion

of Remote Procedure Call (RPC)◦ In object-oriented language, we will rely on the

notion of Remote Method Invocation (RMI)

RMI (5a)

Fundamental Idea (2)

RMI (5b)

RMI (6)

RMI (7)

RMI (8)

In Java, Remote method invocation is integrated in the standard class library, via packages such as java.rmi, java.rmi.server, etc.

In addition , Sun’s Java Development Kit (JDK) includes a set of tools for supporting RMI, e.g., rmic, rmiregistry, etc.

We can distinguish three distinct times when building rmi-based applications, namely development, deployment and execution.

RMI (9)

Execution time◦ The server object registers its name & proxy in

the naming service (rmi registry)◦ The client object obtains a proxy of the server

object via that naming service ◦ The client object can then invoke the server

proxy, which will then forward the invocation to the server object

RMI (10)

Server side: create & bind

RMI (11)

Client Side: lookup & use

RMI (12)

Calendar Application

RMI (13)

Development time◦ Define the interface of the remote service◦ Implement the client and server classes in a

decoupled way, thanks to the interface◦ Use javac to compile all above sources ◦ Use the rmic compiler to create the proxy of the

remote class for you

RMI (14)

Argument Passing Rules◦ An argument or a return value can be a primitive

type, a local serializable object (i.e, implementing java.io.Serializable), or a remote object.

◦ A primitive type value is passed by copy.◦ A local object is also passed by copy, using

standard object serialization.◦ A remote object is passed by reference, i.e., its

proxy is passed rather than the object itself.

RMI (15)

Deployment time◦ Start the rmi registry◦ Start the server process◦ Start the client process

RMI (16)

Checkup◦ On the server we have:

CalendarServer theServer= new CalendarServer();◦ whereas on the client we have:

CalendarService calServ = (CalendarService) Naming.lookup(calServName);

◦ why this difference?◦ Where are calendars located?◦ How does the client get access to calendars?◦ How do we communicate with the rmi registry ?

RMI (17)

RMI callbacks (1) A remote object does not need to be

registered in the naming service to be remotely accessible, e.g., DayCalendarImpl.

The client can also make an object remotely accessible to the server, allowing the latter to asynchronously call back the client, e.g., to notify the client that a new event was scheduled on some calendar.

RMI (19)

Dynamic code download (1)◦ The Java platform allows for the dynamic

download of classes from any URL (Uniform Resource Locator)

◦ The proxy is located on the client but it conceptually belongs to the server

◦ Because we have a Java Virtual Machine on both the server and the client, it is possible to have the proxy move from the server to the client at runtime (dynamic code download)

◦ Dynamic code download can be used not only for proxies but for any Java class

RMI (20)

Security viewpoint◦ From a security viewpoint, downloading classes is

a critical action (i.e., potentially dangerous)◦ For this reason, when code download is activated

(via the java.rmi.server.codebase property), the Java Virtual Machine requires a security manager to be installed

◦ The security policy enforced by the security manager can be expressed declaratively in a security policy file

RMI (21)

Distributed Garbage Collection◦ The Java platform transparently extends garbage

collection to distributed objects. ◦ This extension is known as Distributed Garbage

Collection (DGC).◦ A remote object is collected when there no longer

exists any remote or local references to it ◦ Any object referenced by the naming service (rmi

registry) is not collected

RMI (22)

Unreferenced vs. finalized By implementing the Unreferenced

interface, a remote object can ask to be notified when there no longer exists any remote references to it

In the unreferenced() method, the remote object is given the opportunity to release some resources, e.g., the remote reference on a another remote object

RMI (23)

Limitations of DGC◦ An implementation of DGC should ensure

Safety, which implies not collecting too early Liveness, which implies eventually collecting

◦ Due to its inherent decentralized nature, the implementation of DGC is based on reference counting, which poses several issues: It does not deal properly with circular references It does not deal properly with asynchronous systems

◦ Partial solution: the notion of lease

RMI (24)

The notion of lease◦ A lease is a remote reference with a validity

limited in time◦ In Java, remotes references are actually leases ◦ If the client does not renew its lease before the

associated timeout expires, the reference counter on the server side is decremented

◦ Leases are automatically managed for you, i.e., the renewal is automatic as long as the client is alive and the remote reference exists

RMI (25)

[email protected] 162

A Simple Use of RMI

163

In RMI, a common remote interface is the minimum amount of information that must be shared in advance between “client” and “server” machines. It defines a high-level “protocol” through which the machines will communicate.

A remote interface is a normal Java interface, which must extent the marker interface java.rmi.Remote.◦ Corollaries: because the visible parts of a remote object are

defined through a Java interface, constructors, static methods and non-constant fields are not remotely accessible (because Java interfaces can’t contain such things).

All methods in a remote interface must be declared to throw the java.rmi.RemoteException exception.

The Remote Interface

164

A file MessageWriter.java contains the interface definition:◦ import java.rmi.* ;◦ public interface MessageWriter extends

Remote {◦ void writeMessage(String s) throws

RemoteException ;◦ }

This interface defines a single remote method, writeMessage().

A Simple Example

165

The interface java.rmi.Remote is a marker interface.

It declares no methods or fields; however, extending it tells the RMI system to treat the interface concerned as a remote interface.◦ In particular we will see that the rmic compiler

generates extra code for classes that implement remote interfaces. This code allows their methods to be called remotely.

java.rmi.Remote

166

Requiring all remote methods be declared to throw RemoteException was a philosophical choice by the designers of RMI.

RMI makes remote invocations look syntactically like local invocation. In practice, though, it cannot defend from problems unique to distributed computing—unexpected failure of the network or remote machine.

Forcing the programmer to handle remote exceptions helps to encourage thinking about how these partial failures should be dealt with.

See the influential essay: “A Note on Distributed Computing” by Waldo et al, republished in The Jini Specification:◦ http://java.sun.com/docs/books/jini

java.rmi.RemoteException

167

A remote object is an instance of a class that implements a remote interface.

Most often this class also extends the library class java.rmi.server.UnicastRemoteObject. This class includes a constructor that exports the object to the RMI system when it is created, thus making the object visible to the outside world.

Usually you will not have to deal with this class explicitly—your remote object classes just have to extend it.

One fairly common convention is to name the class of the remote object after the name of the remote interface it implements, but append “Impl” to the end.

The Remote Object

168

The file MessageWriterImpl.java contains the class declaration:◦ import java.rmi.* ;◦ import java.rmi.server.* ;◦ public class MessageWriterImpl extends UnicastRemoteObject◦ implements

MessageWriter {◦ public MessageWriterImpl() throws RemoteException {◦ }◦ public void writeMessage(String s) throws

RemoteException {◦ System.out.println(s) ;◦ }◦ }

A Remote Object Implementation Class

169

To compile classes that implement Remote, you must use the rmic compiler. The reasons will be discussed later. For example:◦ sirah$ rmic MessageWriterImpl

Compiling the Remote Object Class

170

We have completed the Java files for the remote object class itself, but we still need the actual client and server programs that use this class.

In general there are some pieces of administrivia one has to deal with—publishing class files and installing security managers.

We initially make the simplifying assumption that both client and server have copies of all class files for MessageWriter (e.g., they may share access through shared NFS directories).◦ Then “publishing class files” is not an issue, and we also

don’t need a security manager, because all code is “local”, and therefore trusted.

Client and Server Programs

171

We assume the file HelloServer.java contains the class declaration:◦ import java.rmi.* ;◦ public class HelloServer {◦ public static void main(String [] args) throws

Exception {◦ MessageWriter server = new

MessageWriterImpl() ;◦ Naming.rebind(“messageservice”,

server) ;◦ }◦ }

A Server Program

172

This program does two things:◦ It creates a remote object with local name server.◦ It publishes a remote reference to that object with

external name “MessageWriter”. The call to Naming.rebind() places a

reference to server in an RMI registry running on the local host (i.e., the host where the HelloServer program is run).

Client programs can obtain a reference to the remote object by looking it up in this registry.

Remarks

173

We assume the file HelloClient.java contains the class declaration:◦ import java.rmi.* ;◦ public class HelloClient {◦ public static void main(String [] args) throws

Exception {◦ MessageWriter server =◦ (MessageWriter) Naming.lookup(◦

“rmi://sirah.csit.fsu.edu/messageservice”) ;◦ server.writeMessage(“Hello, other world”) ;◦ }◦ }

A Client Program

174

Again the program does two things:◦ It looks up a reference to a remote object with external

name “MessageWriter”, and stores the returned reference with local name server.

◦ Finally (!), it invokes the remote method, writeMessage(), on server.

The call to Naming.lookup() searches in a remote RMI registry. Its argument is a URL, with protocol tag “rmi”.

This example assumes the remote object lives on the host “sirah”, and has been registered in the default RMI registry (which happens to listen on port 1099) on that machine.

Remarks

175

Compile HelloServer and HelloClient on their respective hosts, e.g.:◦ sirah$ javac HelloServer◦ merlot$ javac HelloClient

Either ensure client and server share the current directory, or copy all files with names of the form MessageWriter * .class to the client’s current directory.

Compiling and Running the Example

176

Running HelloClient/HelloServer

[email protected] 177

The Mechanics of Remote Method Invocation

178

Invocation of a method on a remote object reproduces the “look and feel” of local invocation very well.

But the internal mechanics of remote invocation are much more complex than local invocation:◦ Arguments—which may be objects of arbitrary complexity—

are somehow collected together into messages suitable for shipping across the Internet.

◦ Results (or exceptions) are similarly shipped back. Perhaps surprisingly, RMI involves no modification to

the Java language, compiler, or virtual machine.◦ The illusion of remote invocation is achieved by clever

libraries, plus one relatively simple “post-processor” tool (rmic).

Is RMI a Language Extension?

179

A powerful feature of distributed object models like RMI is that references to other remote objects can be passed as arguments to, and returned as results from, remote methods.

Starting with one remote object reference (presumably obtained from an RMI registry) a client can, for example, obtain references to additional remote objects—returned by methods on the first one.

Exchanging Remote References

180

Suppose we are on a LAN and we need to get a Java driver for one of several available printers:◦ public interface Printer extends Remote {◦ void print(String document) throws RemoteException ;◦ }◦ public interface PrinterHub extends Remote {◦ Printer getPrinter(int dpi, boolean isColor)◦ throws RemoteException ;◦ }

A client might initially obtain a PrinterHub reference from the RMI registry. The remote object contains some table of printers on the network.

An individual Printer interface is returned to the client, according to specifications given in getPrinter().

Jini takes an approach similar to this.

Example: a Printer Registry

181

This is a powerful feature, but there is one interesting restriction:◦ If a particular argument or result of a remote

method itself implements Remote, the type appearing in the method declaration must be a remote interface.

◦ The declared type of an RMI argument or result cannot be a remote implementation class.

◦ At the “receiving end” this reference cannot be cast it to the implementation class of the remote object. A ClassCastException will occur if you try.

Remote References have Interface Type

182

What this tells us is that “remote references” are not literally Java references to objects in other virtual machines.

In fact they are Java references to local objects that happen to implement the same remote interfaces as the remote objects concerned.

The local Java object referenced is an instance of a stub class.

Stubs

183

Stubs.◦ Each remote object class has an associated stub class, which

implements the same remote interfaces. An instance of the stub class is needed on each client. Client-side remote invocations are “actually” local invocations on the stub class.

Serialization. ◦ Arguments and results have to be “marshaled”—converted

to a representation that can be sent over the Net. In general this is a highly non-trivial transformation for Java objects. Serialization is also used for distributing stubs.

The Server-side “Run-time System”. ◦ This is responsible for listening for invocation requests on

suitable IP ports, and dispatching them to the proper, locally resident, remote object.

Some Important Parts of RMI

184

Architecture

ClientCode Stub

RMI“Run-time”

System

RemoteObject

Call stub methodlocally

Return valueor throw exception

Call remote object method locally

Return valueor throw exception

Send marshaledarguments

Send marshaledresult or

exception

InternetClient Server

185

The only “compiler” technology peculiar to RMI is the rmic stub generator.

The input to rmic is a remote implementation class, compiled in the normal way with javac (for example).

The stub generator outputs a new class that implements the same remote interfaces as the input class.

The methods of the new class contain code to send arguments to, and receive results from, a remote object, whose Internet address is stored in the stub instance.

The Role of rmic

186

An earlier example of a remote implementation class:◦ public class MessageWriterImpl extends UnicastRemoteObject◦ implements

MessageWriter {◦ . . .◦ public void writeMessage(String s) throws

RemoteException {◦ . . .◦ }◦ }

We issue the command:◦ rmic –keep MessageWriterImpl◦ The flag –keep causes the intermediate Java source to be

retained.

Example Operation of rmic

187

public final class MessageWriterImpl_Stub extends java.rmi.server.RemoteStub implements MessageWriter, java.rmi.Remote { . . . public MessageWriterImpl_Stub(java.rmi.server.RemoteRef ref) { super(ref); } public void writeMessage(java.lang.String $param_String_1) throws java.rmi.RemoteException { try { ref.invoke(this, $method_writeMessage_0, new java.lang.Object[] {$param_String_1}, 4572190098528430103L); } . . . } }

The Generated Stub Class

188

The stub class includes an inherited field ref, of type RemoteRef.◦ Essentially the stub class is just a wrapper for this remote

reference. Remote methods are dispatched through the invoke()

method on ref.◦ This is passed an array of Objects holding the original

arguments (in general it also returns an Object).◦ It is also passed arguments to identify the particular method to

be invoked on the server. Essentially the stub wrapper is providing compile-time

type safety. The actual work is done in library classes that don’t know the compile-time type in advance.

Remarks on the Stub Class

189

Objects passed as arguments to invoke() must be marshaled for transmission over the network.

Java has a general framework for converting objects (and groups of objects) to an external representation that can later be read back into an arbitrary JVM.

This framework is Object Serialization.

Marshalling of Arguments

Overview of CORBACommon Object Request Broker Architecture

Architecture for interoperable distributed computing◦ Based on the OMG’s Object Management

Architecture Internet Interoperability Protocol (IIOP) Language mappings (OMG IDL) Integrated and reusable services

What is CORBA?

Object Management Group founded 1989 CORBA 1.x (91-93)

◦ Experimental, architecture focused, IDL CORBA 2.0 (1996)

◦ Interoperability and COM integration CORBA 2.1 (1997)

◦ Security, language mappings

CORBA Timeline

CORBA 2.2 (1998)◦ DCOM interoperability, POA, IDL/Java

CORBA 2.3 (1999)◦ Objects by value, RMI/IIOP, language binding

enhancements CORBA 2.4 (2001)

◦ Quality of service enhancements, asynchronous messaging, real-time support

CORBA Timeline

Based on OMA Reference Model

CORBA Architecture

ApplicationObjects

Domain Objects

Object Services

Common Facilities

ORB

The ORB serves as the common backbone on which many discrete services can be integrated

Object Request broker Object Services Common Facilities Domain Interfaces Application Interfaces

CORBA Model Components

ApplicationObjects

Domain Objects

Object Services

Common Facilities

ORB

Enables object to transparently make and receive requests and responses

Object Request Broker (ORB)

“...like a telephone exchange, providing the basic mechanism for making and receiving calls…”

ORB

Collection of interfaces and objects

Object Services & Facilities

Object Services

Common Facilities

ORB

• Services– Support

functions for implementing and using objects

– i.e. life cycle

• Facilities– Services that

many applications may share, but are not fundamental

– i.e. system management

Domain Interfaces◦ OMG Domain Special Interest Groups (SIGs)◦ Market vertical specific services

Application Objects ◦ Vendor provided or custom object implementation◦ Top layer in Reference Model, not standardized by

OMG

Domain & Application Objects

ApplicationObjects

Domain Objects

ORB

Transport protocol◦ Defines inter ORB communication◦ Runs on top of TCP/IP◦ Defines CORBA messages

IIOP is a specification◦ Vendors must implement to be “CORBA-

compliant”◦ Allows for multi-vendor interoperability

Internet Inter ORB Protocol (IIOP)

DCOMDistributed Component Object ModelMicrosoft

the integration of applications within and between business is made possible using middleware...

Documents

database server

architecture slide

middleware technology

client requests

client api

file server approach

following figure slide

resulting response slide