Dr.-Ing.

Michael Eichberg

Middleware (Technologies)
Remoting - RPC and RMI

Middleware

Remoting? (A Denition)

Remoting allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.

Developing Distributed Enterprise Applications

Middleware
What is Middleware?

Middleware

What is Middleware?

Middleware is a class of software technologies designed to help (I) manage the complexity and (II) heterogeneity inherent in distributed systems.

Understanding the Complexity Inherent in Distributed Applications

A Simple Server Using Sockets

(Part I)
/* A simple server in the internet domain using TCP. The port number is passed as an argument */
#include #include #include #include <stdio.h> <sys/types.h> <sys/socket.h> <netinet/in.h>

void error(char *msg){perror(msg); exit(1);} int main(int argc, char *argv[]){ int sockfd, newsockfd, portno, clilen; char buffer[256]; int n; struct sockaddr_in serv_addr, cli_addr; sockfd = socket(AF_INET, SOCK_STREAM, 0); // socket() returns a socket descriptor if (sockfd < 0) error("ERROR opening socket"); bzero((char *) &serv_addr, sizeof(serv_addr)); // bzero() sets all values in a buffer to zero. portno = atoi(argv[1]); // atoi() converts str into an integer ...

Understanding the Complexity Inherent in Distributed Applications

A Simple Server Using Sockets

(Part II)
... serv_addr.sin_family = AF_INET; serv_addr.sin_addr.s_addr = INADDR_ANY; serv_addr.sin_port = htons(portno); if (bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0) error("ERROR on binding"); listen(sockfd,5); // tells the socket to listen for connections clilen = sizeof(cli_addr); newsockfd = accept(sockfd, (struct sockaddr *) &cli_addr, &clilen); if (newsockfd < 0) error("ERROR on accept"); bzero(buffer,256); n = read(newsockfd,buffer,255); if (n < 0) error("ERROR reading from socket"); printf("Here is the message: %s\n",buffer); n = write(newsockfd,"I got your message",18); if (n < 0) error("ERROR writing to socket"); return 0; }

Implementation of the protocol.

Understanding the Complexity Inherent in Distributed Applications

A Simple Client Using Sockets

(Part I)
#include #include #include #include #include <stdio.h> <sys/types.h> <sys/socket.h> <netinet/in.h> <netdb.h>

void error(char *msg){ perror(msg);exit(0);} int main(int argc, char *argv[]){ int sockfd, portno, n; struct sockaddr_in serv_addr; struct hostent *server; char buffer[256]; portno = atoi(argv[2]); sockfd = socket(AF_INET, SOCK_STREAM, 0); if (sockfd < 0) error("ERROR opening socket"); ...

Understanding the Complexity Inherent in Distributed Applications

A Simple Client Using Sockets

(Part II)
server = gethostbyname(argv[1]); bzero((char *) &serv_addr, sizeof(serv_addr)); serv_addr.sin_family = AF_INET; bcopy((char *)server->h_addr, (char *)&serv_addr.sin_addr.s_addr, server->h_length); serv_addr.sin_port = htons(portno); if (connect(sockfd,&serv_addr,sizeof(serv_addr)) < 0) error("ERROR connecting"); printf("Please enter the message: "); bzero(buffer,256); fgets(buffer,255,stdin); n = write(sockfd,buffer,strlen(buffer)); if (n < 0) error("ERROR writing to socket"); bzero(buffer,256); n = read(sockfd,buffer,255); printf("%s\n",buffer); return 0; }

Middleware

Issues When Using Sockets

Whats lacking?

Clearly we need to take care of...

establishing a channel and of all errors that might happen during this
process

... establishing a protocol

(Who sends what, when, in which order and what answer is expected.)

... message formats

(Transforming application level data to bytes that can be transmitted over the network.)

Middleware

10

Issues When Using Sockets

Whats lacking?

Clearly we need to take care of...

establishing a channel and of all errors that might happen during this We want:

improved language integration, and ... establishing a protocol generation of most of the (Who sends what, when, in which order and what answer is
expected.)

process

networking code

... message formats

(Transforming application level data to bytes that can be transmitted over the network.)

Middleware

11

Middleware as a Programming Abstraction

A software layer above the

operating system and below the application program that provides a common programming abstraction across a distributed system

Distributed Application

Distributed Application

Middleware API Middleware

Middleware API Middleware

A higher-level building block than

APIs provided by the OS (such as sockets)

Operating System API Operating System (Processes, Communication, Memory Management) Network

Operating System API Operating System (Processes, Communication, Memory Management)

Middleware

12

Middleware as a Programming Abstraction

heterogeneity =dt. Heterogenitt Ungleichartigkeit Verschiedenartigkeit

Programming abstractions offered by middleware mask some of the heterogeneity and handles some of the complexity programmers of a distributed application must deal with:

Middleware always mask heterogeneity of the underlying networks,

hardware

Most middleware mask heterogeneity of operating systems and/or

programming languages implementations of the same middleware standard
e.g., CORBA-IDL

Some middleware even mask heterogeneity among different vendor

Middleware

13

Middleware as a Programming Abstraction

Middleware provides transparency with respect to one or more of the following dimensions:

Location, Concurrency, Replication, Failures

Middleware

14

Middleware as a Programming Abstraction

Raising the Abstraction Level

An operating system (OS) is the software that makes the hardware useable
(A bare computer without an OS could be programmed with great difculty.)

Middleware is the software that makes a distributed system (DS)

programmable (Programming a DS is much more difcult without middleware.)

Middleware

15

Middleware as Infrastructure

Behind programming abstractions there is a complex infrastructure that

implements those abstractions (Middleware plattforms are very complex software systems.)

As programming abstractions reach higher and higher levels, the underlying

infrastructure implementing the abstractions must grow accordingly

Additional functionality is almost always implemented through additional

software layers
E.g. to handle errors we can have transactional RPCs

The additional software layers increase the size and complexity of the
infrastructure necessary to use the new abstractions

Middleware

16

Middleware as Infrastructure

The infrastructure is also intended to support additional functionality that makes development, maintenance, and monitoring easier and less costly:

logging, recovery, advanced transaction models (e.g. transactional RPC), language primitives for transactional demarcation, transactional le system, etc.

Middleware

17

Middleware as Infrastructure

The infrastructure also takes care of (all) the non-functional properties typically ignored by data models, programming models, and programming languages:

performance, availability, resource management, reliability, etc.

Middleware

18

Middleware as Infrastructure
Conceptual Model
client process client code development environment IDL server process server code

language specic call interface

client stub

IDL sources

language specic call interface

server stub

IDL compiler

RPC API RPC run time service library interface headers

RPC API RPC run time service library

RPC protocols

security service

... runtime environment

distributed le service

thread service

[Alonso; Web services: Concepts, Architectures and Applications; Springer Verlag, 2004]

Middleware

19

g in m n m io ra ct og tra Pr s

Understanding Middleware

Intended to hide low level details of hardware, networks, and distribution Continuing trend towards increasingly more powerful primitives that
without changing the basic concept of RPC have additional properties or allow more exibility in the use of the concept

Evolution and appearance to the programmer is dictated by the trends in

programming languages

Ab

RPC and C CORBA and C++ RMI (Corba) and Java Classical Web Services and XML RESTful Web Services and JSON

Middleware

20

Understanding Middleware
In
Comprehensive platform for developing and running complex distributed
systems

Trend is towards service oriented architectures at a global scale and

standardization of interfaces

Another important trend is towards single vendor software stacks to

minimize complexity and streamline interaction

Evolution is towards integration of platforms and exibility in the

conguration (plus autonomic behavior)

ru st fra u ct re

Developing Distributed Enterprise Applications

21

Remote Procedure Call (RPC)

Programming Language Integration Exchanging Data Inner workings of RPC Call Semantics

Remote Procedure Calls - History

22

Remote Procedure Calls - Original Motivation

Birrell and Nelson (1984)

Emphasis is on hiding network communication by allowing a process to call a procedure of which the implementation is located on a remote machine:

Removing the need for the distributed systems programmer to worry about
all the details of network programming (i.e., no more sockets)

Bridging the conceptual gap between invoking local functionality via

procedures and invoking remote functionality via sockets

Remote Procedure Calls - History

23

Remote Procedure Calls - Historic Context

The notion of distributed service invocation became a
reality at the beginning of 80s:

Procedural languages (mainly C) were dominant In procedural languages, the basic module is the
procedure (A procedure implements a particular function or service that can be used anywhere within the program.)

It seemed natural to maintain this notion when talking

about distribution:

The client makes a procedure call to a procedure that is

implemented by the server

Since the client and server can be in different machines,

the procedure is remote

Remote Procedure Calls - History

24

The Basics of Client/Server: Synchronous Communication

A server is a program that implements certain services. Clients would like to invoke those services:
Machine A (Client)

Client & server reside on different

computers and - may - run on different operating systems

Request

Machine B (Client)

Communication is by sending
messages (no shared memory, no shared disks, etc.)
Response

Some minimal guarantees are to be

provided (handling of failures, call semantics, etc.)
We want communication to be conceptually as simple as this

Remote Procedure Calls - History

25

Problems to Solve: Transparency of RPCs

(When calling remote procedures.)

How to make the service invocation part of the language in a more or less
transparent manner?

Debate: Transparent or Not transparent?

A remote call is something completely different than a local call; should the programmer be aware of this?

Remote Procedure Calls - History

26

Problems to Solve: Exchanging Data

(When calling remote procedures.)

How to exchange data between machines that might use different

representations for different data types?

Different encodings of data types

(character encoding, representations of oats, etc.)

Different ways to order bytes: Intel CPUs are little-endian Sun Sparc CPUs are big-endian

Remote Procedure Calls - History

27

Problems to Solve: Exchanging Data

(When calling remote procedures.)

Problem:
Information in running programs is stored in high-level data structures; Information in messages passed over network consists of sequences of bytes

Complex data types must be attened: Marshalling - the process of assembling data items into a form suitable
for transmission in a message

Unmarshalling - the process of disassembling them on arrival at the

destination to produce an equivalent collection of data items

Remote Procedure Calls - History

28

Problems to Solve: Exchanging Data

(When calling remote procedures.)

Problem:
Information in running programs is stored in high-level data structures; Information in messages passed over network consists of sequences of bytes

Two methods for exchanging data values: Values converted to an agreed external format before transmission
and converted to the local form on receipt

Values transmitted in senders format, together with an indication

of the format used; recipient converts values if necessary

Remote Procedure Calls - History

29

Problems to Solve: Finding / Binding Services

(When calling remote procedures.)

How to nd and bind the service one actually wants among a potentially
large collection of services and servers? The goal is that the client does not necessarily need to know where the server resides or even which server provides the service (location transparency).

Remote Procedure Calls - History

30

Problems to Solve: Dealing with Errors.

(When calling remote procedures.)

How to deal with errors in the service invocation in a more or less elegant
manner:

server is down, communication is down, server busy, duplicated requests ...

Remote Procedure Calls - History

31

Programming Language Integration?

Problems to Solve
Main program's variables

Conventional local procedure call

(read
(fd,buf,bytes)):

A. The stack before the call B. The stack while the called procedure is active

How to identify and address entities? Pointers cannot be passed as parameters Each machine has a different address space

A Main program's variables bytes buf fd return address "read's" local variables B

Remote Procedure Calls

32

How RPC Works

As far as the programmer is concerned, a remote procedure call looks
and works almost identically to a local procedure call in this way, transparency is achieved

To achieve transparency RPC introduced many concepts of middleware

systems:

Interface description language (IDL) Directory and naming services Dynamic binding Marshalling and unmarshalling Opaque references
Opaque references need to be used by the client to refer to the same data structure or entity at the server across different calls. (The server is responsible for providing these opaque references.)

Remote Procedure Calls

33

How RPC Works

Fundamentals

The procedure is split into two parts:

Client stub
Implementation of the interface on the local machine through which the remote functionality can be invoked

Server stub
Implementation of the interface on the server side passing control to the remote procedure that implements the actual functionality

Remote Procedure Calls

34

Basics of RPC - Calling a Remote Procedure

client procedure call client stub bind marshal serialize send

client process

server procedure server stub

server process

dispatcher (select stub) communication module

communication module

unmarshal deserialize receive

[Alonso; Web services: Concepts, Architectures and Applications; Springer Verlag, 2004]

Remote Procedure Calls

35

Interface Denition Language (IDL)

Overview

Protocol interfaces are described by means of an Interface Denition

Language (IDL):

SUN RPC (see RFC 1831, 1014) uses XDR CORBAs IDL is called IDL (ISO 14750) JAXRPC uses XML ... The interfaces are then compiled by an IDL compiler which generates the
necessary stubs (and skeletons)

Remote Procedure Calls

36

Developing Distributed Applications With RPC

client process client code development environment IDL server process server code

language specic call interface

client stub

IDL sources

language specic call interface

server stub

IDL compiler

interface headers

[Alonso; Web services: Concepts, Architectures and Applications; Springer Verlag, 2004]

Remote Procedure Calls

37

An Example Interface Denition (SUN RPC)

/* FileReadWrite service interface definition in file FileReadWrite.x */ const MAX = 1000; typedef int FileIdentifier; typedef int FilePointer; typedef int Length; struct Data { int length; char buffer[MAX]; }; struct writeargs { FileIdentifier f; FilePointer position; Data data; }; struct readargs { FileIdentifier f; FilePointer position; Length length; }; program FILEREADWRITE { version SIMPLERW { void WRITE(writeargs)=1; Data READ(readargs)=2; }=2; }=9999;

Remote Procedure Calls - History

38

C Client of a File Server in SUN RPC

e or m s! et No ck so
/* File S.c - server procedures for the FileReadWrite service */ #include <stdio.h> #include <rpc/rpc.h> #include"FileReadWrite.h" void * write_2(writeargs * a) { /* do the writing to the file */ } Data * read_2(readargs static Data result; result.buffer = ... result.length = ... return &result; } * a) { /* must be static */ /* do the reading from the file */ /* amount read from the file */

Remote Procedure Calls - History

39

C Client of a File Server in SUN RPC

/* File C.c - Simple client of the FileReadWrite service. */ #include <stdio.h> #include <rpc/rpc.h> #include "FileReadWrite .h

main(int argc, char ** argv) { CLIENT *clientHandle; char *serverName = "coffee"; readargs a; Data *data; /* creates socket and a client handle */ clientHandle= clnt_create(serverName, FILEREADWRITE, VERSION, "udp"); if (clientHandle != NULL){ a.f = 10; a.position = 100; a.length = 1000; /* call to remote read procedure */ data = read_2(&a, clientHandle); clnt_destroy(clientHandle); /* closes socket */ } }

e or m s! et No ck so

Remote Procedure Calls - Binding

40

Binding in RPC
Overview

Binding is the process whereby a client creates a local association for (i.e.,
a handle to) a given server in order to invoke a remote procedure (Form of handle depends on environment. Today, usually an IP address and port number. Alternatives: an Ethernet address, an X.500 address, etc.)

Static binding (local binding): the handle to the server where the
procedure resides is hard-coded in client stub

Dynamic binding (distributed): clients use a specialized service to locate

servers based on the signature of the procedure being invoked (Specialized service also called binder, or name service.)

Remote Procedure Calls - Binding

41

Dynamic Binding Using a Service

This service must be reachable by all participants; possible alternatives: predened location environment variables e.g., Apples Bonjour broadcasting to all nodes looking for the binder Uses IDL specications to perform bindings

Remote Procedure Calls - Binding

42

Dynamic Binding Using a Naming Service

client process server process

client procedure call client stub bind marshal serialize 2. nd 5. send 3. query for server implementing the procedure

server procedure server stub 0. register unmarshal deserialize 7. receive 6. invoke procedure

dispatcher (select stub) communication module 1. register server and procedure

communication module

4. address of server name and directory service (binder)

[Alonso; Web services: Concepts, Architectures and Applications; Springer Verlag, 2004]

Remote Procedure Calls - Binding

43

Static vs. Dynamic Binding

Static binding Advantages Simple and efcient, no additional
infrastructure beside client and server stub

Dynamic binding Advantages Enables what is missing with static

binding

Disadvantages Client and server tightly coupled If the server changes location, client
must be changed

Disadvantages Adds indirection and infrastructure;

name server, protocol for interacting with the directory server, primitives for registering with directory, etc.

Not possible to use redundant servers

for load balancing

Hidden in the stubs

Remote Procedure Calls

44

RPC - Call Semantics

Lets assume, a client makes an RPC to a service at a given server...

After a time-out expires, the client may decide to resend the request If after several tries there is no success, what may have happened
depends on the call semantics:

maybe: no guarantee at least once at most once exactly once

Remote Procedure Calls

45

RPC - Call Semantics

Lets assume, a client makes an RPC to a service at a given server...

Maybe: no guarantees. The procedure may have been executed (the

response message(s) lost) or may have not been executed (the request message(s) lost). It is very difcult to write programs based on this type of semantics since the programmer has to take care of all possibilities.

Remote Procedure Calls

46

RPC - Call Semantics

Lets assume, a client makes an RPC to a service at a given server...

At least-once
The procedure will be executed if the server does not fail, but it is possible that it is executed more than once

This may happen, for instance, if the client re-sends the request after a
time-out

If the server is designed so that service calls are idempotent (each call
results in the same outcome given the same input), this might be acceptable

At most-once
The procedure will be executed either once or not at all. Re-sending the request will not result in the procedure executing several times

Remote Procedure Calls

47

RPC - Call Semantics

Lets assume, a client makes an RPC to a service at a given server...

Exactly once
The system guarantees the local semantics assuming that a server machine that crashes will eventually restart. It keeps track of orphan calls, that is, calls on server machines that have crashed, and allows them to be later adopted by a new server.

Remote Procedure Calls

48

Asynchronous RPC
client wait for result request A reply server call local procedure and return results time

A. The interconnection between client and server in a traditional RPC note that blocking occurs the client waits

client

wait for acceptance request

B. The interaction using asynchronous RPC no blocking; useful when the client doesnt need or expect a result

accept request

server call local procedure time

Remote Procedure Calls

49

Asynchronous RPC - Deferred

A client and server interacting

through two asynchronous RPCs allows a client to perform other useful work - in particular sending further messages - while waiting for results

client

wait for acceptance request

interrupt client

accept request

return results acknowledge

server call local procedure time

Remote Procedure Calls

50

Stored Procedures
Based Upon RPCs

To add exibility to their servers, (database) software vendors added to them the possibility of programming procedures that will run inside the server and that could be invoked through RPC. Turned out to be very useful for databases:

(Stored) procedures could be used to hide the schema and the SQL
programming from the clients

(Stored) procedures are a common mechanism found in all database

systems (although differently implemented)

Remote Procedure Calls

51

Distributed Environments
Based Upon RPCs
Common aspects: Security Services for Authentication / Authorization, Replication, Logging, Transaction Handling,...

When designing distributed applications, there are a lot of crucial aspects

common to all of them; RPC does not address many of these issues

To support the design and deployment of distributed systems,

programming and run time environments need to be created (These environments provide, on top of RPC, much of the functionality needed to build and run a distributed application.)

The notion of distributed environment is what gave rise to middleware

Remote Procedure Calls

52

RPC Summary - Advantages

RPC provided a mechanism to implement distributed applications in a

simple and efcient manner

RPC followed the programming techniques of the time (procedural

languages) and tted quite well with the most typical programming languages (C), thereby facilitating its adoption by system designers

RPC allowed the modular and hierarchical design of large distributed

systems:

Client and server are separate entities The server encapsulates and hides the details of the back end systems
(such as databases)

Remote Procedure Calls

53

RPC Summary - Disadvantages

RPC is not a standard, it is an idea that has been implemented in many

different ways (not necessarily compatible)

RPC allows designers to build distributed systems but does not solve many
of the problems distribution creates (In that regard, it is only a low-level construct.)

Only supports procedural integration of application services

(Does not provide object abstractions, e.g., polymorphism, inheritance of interfaces, etc.)

Developing Distributed Enterprise Applications

54

Remote Method Invocation (RMI)

Introduction Problems to Solve Protocol Stack Example

Remote Method Invocation - Introduction

55

Java Remote Method Invocation (RMI)

Allows an object running in one Java Virtual Machine (VM) to invoke methods on an object running in another Java VM...

Remote objects can be treated similarly to local objects Handles marshalling, transportation, and garbage collection of the remote
objects

Not an all-purpose Object-Request Broker (ORB) architecture like

Webservices, CORBA and DCOM...

Part of Java since JDK 1.1

Remote Method Invocation - Introduction

56

RMI is Middleware

Remote Method Invocation - Introduction

57

RMI is Middleware

Remote Method Invocation - Introduction

58

RMI vs. RPC

client foo call foo ...
data

server

Basically the difference between procedure call

and
client

RPC mechanism

server object x object y foo ...

operation invocation on an object

invoke foo on object X

invoke foo on object Y

foo ...

object request broker

Remote Method Invocation - Introduction

59

Distributed Object Model

:A

Each process contains objects,

some of which can receive remote invocations, others only local invocations
(Those that can receive remote invocations are called remote objects.)
remote invocation :C

local invocations :B local invocation :D :E

Objects need to know the remote

object reference of an object in another process in order to invoke its methods
(Remote Method Invocation; Remote Object References)

remote invocation

:F

Remote Method Invocation - Introduction

60

Distributed Object Model

:A

remote invocation

:C

The remote interface species which

methods can be invoked remotely
:B

local invocations :E

Java Interfaces are used as the

Interface Description Language

local invocation :D

remote invocation

:F

Remote Method Invocation - Introduction

61

Anatomy of a Remote Method Invocation

Client computer

Server computer Server

The Proxy ... makes the RMI

transparent to client

Client

an object

implements the
remote interface
Client invokes method The same interface

marshals requests
and unmarshals results
Proxy Skeleton Client OS Server OS

forwards request
Marshalled invocation is passed across network

Remote Method Invocation - Introduction

62

Anatomy of a Remote Method Invocation

Client computer Client

Server computer Server

The Skeleton ... implements the

methods in remote interface

an object

unmarshals requests
and marshals results

Client invokes method

The same interface

invokes method in
remote object

Proxy

Skeleton

Client OS

Server OS

Marshalled invocation is passed across network

Remote Method Invocation - Introduction

63

Remote Object References

Remote object references are system-wide unique:

Can be passed freely between processes (e.g. as a parameter) The implementation of the remote object references is hidden by the
middleware (Opaque references.)

Improved distribution transparency compared to RPC

Remote Method Invocation - Foundations

64

Interface Language

No need for a dedicated language as RMI is targeted to a Java-only

environment

Uses Java interfaces extending java.rmi.Remote

Remote Method Invocation - Foundations

65

Generation of Stubs and Binding

RMI Compiler (rmic) generates stub and skeleton classes Either static binding or dynamic binding via Naming.lookup Dynamic binding is supported by the rmiregistry
Starts a registry process for registering server objects Enables binding of objects to names

No longer required to be called explicitly.

Make sure the classpath is configured appropriately!

Remote Method Invocation

66

An Example Application
Clients invoke a method getTime() on a remote object The server returns a java.util.Date instance representing the current
server time

Focus on JRMP only

Remote Method Invocation - an Example

67

RMI Development Process

1. Dene the remote interface 2. Implement the RMI server 3. (Before Java 5) Generate RMI stubs (and if you use Java 1.1 skeletons) 4. Implement a server registrar 5. Implement an RMI client

Remote Method Invocation - an Example

68

The Time Server Interface

All RMI interfaces must extend java.rmi.Remote All methods must throw java.rmi.RemoteException
import java.rmi.Remote; import java.rmi.RemoteException; import java.util.Date; public interface Time extends Remote { } public Date getTime() throws RemoteException;

Remote Method Invocation - an Example

69

The Time Server Implementation

Active JRMP servers... must extend java.rmi.UnicastRemoteObject must implement the interface
import java.rmi.RemoteException; import java.rmi.server.UnicastRemoteObject; import java.util.Date; public class TimeServer extends UnicastRemoteObject implements Time { } public TimeServer() throws RemoteException { super(); } public Date getTime() throws RemoteException { return new Date(System.currentTimeMillis()); }

Remote Method Invocation - an Example

70

Generating Stubs for the Time Server

Stubs (and skeletons) are generated from compiled code by invoking rmic
> ls rmitest/server TimeServer.class TimeServer.java > rmic rmitest.server.TimeServer > ls rmitest/server TimeServer.class TimeServer_Skel.class TimeServer.java TimeServer_Stub.class

Remote Method Invocation - an Example

71

The Time Server: Registrar

Responsible for binding a server object to a name. Server class may be the registrar itself (main method). Here: dedicated registrar class.
import java.rmi.Naming; public class TimeRegistrar { } /** @param args args[0] has to specify the hostname. */ public static void main(String[] args) throws Exception { String host = args[0]; TimeServer timeServer = new TimeServer(); Naming.rebind("rmi://" + host + "/ServerTime", timeServer); }

Remote Method Invocation - an Example

72

The Time Server: Client

import java.rmi.Naming; public class TimeClient { } public static void main(String[] args) throws Exception { } String host = args[0]; Time time = (Time) Naming.lookup("rmi://" + host + "/ServerTime"); System.err.println("Server reports: " + time.getTime().toString());

Remote Method Invocation - an Example

73

Starting the Example

1. Start rmiregistry tool on server 2. Start TimeRegistrar on server 3. Start TimeClient on client 4. The Time interface need to be available on both server and client (Code downloading is - by default - not enabled.)

Remote Method Invocation - Foundations

74

Garbage Collection (GC)

RMI uses a reference-counting garbage collection algorithm When a remote object is not referenced by any client, the RMI runtime
refers to it using a weak reference (Allows the JVM's GC to discard the object (if no other local references exist.)

Network Problems may lead to premature GC; calls then result in

Exceptions

Remote Method Invocation - Foundations

75

Failure Handling

Network Problems via Java Exceptions extending

java.rmi.RemoteException

(All methods in the remote interface have to declare that they may throw this exception.)

Call Semantics: at most once semantics for remote calls

Short-Term Persistence

76

How is the data transfered between the client and the server?
(I.e., what happens when we sent a Date object from the server to the client?)

Short-Term Persistence

77

Domain Model of a simple Auction Application

Example used for the discussion in the following.
Name String rstName String lastName name User String userName String password String email

seller

bidder auctions bids item successful bid bids Bid oat amount Date datetime

Category String description

categories items

AuctionItem String description Date ends int condition

BuyNowBid boolean buyNow

Short-Term Persistence

Java Serialization

Object serialization is the process of saving an object's state to a sequence of bytes, as well as the process of rebuilding those bytes into a live object at some future time. The Java Serialization API provides a standard mechanism for developers to handle object serialization.

[The Java API Documentation]

Short-Term Persistence

79

Java Serialization

The API denes a default protocol, which can also be customized... by implementing
readObject(ObjectInputStream in)

and
writeObject(ObjectOutputStream out),

you can do additional steps before and after default serialization.

implementing the Externalizable Interface gives you full control over

the protocol

Short-Term Persistence

80

Serializing an AuctionItem
Java Serialization - Example

Serializable classes have to implement the marker interface

java.io.Serializable (marker interfaces do not dene methods)
public class AuctionItem implements Serializable { // persistent fields private String description; private Date ends; private int condition; private List<Category> categories; private List<Bid> bids; private Bid successful_bid; private User seller; } // non-persistent fields private transient SimpleDateFormat nonPersistentField; ...

Short-Term Persistence

81

Serializing an AuctionItem
Java Serialization - Example
public class SerializationTest { } private AuctionItem item; void saveItem() throws IOException { FileOutputStream fos = null; try { fos = new FileOutputStream("AuctionItem.ser"); ObjectOutputStream out = new ObjectOutputStream(fos); out.writeObject(item); out.flush(); } finally { if (fos != null) fos.close(); } } ...

Short-Term Persistence

82

Deserializing an AuctionItem
Java Serialization - Example
public class SerializationTest { ... } AuctionItem loadItem() throws IOException, ClassNotFoundException { } ... FileInputStream fin = null; try { fin = new FileInputStream("AuctionItem.ser"); ObjectInputStream in = new ObjectInputStream(fin); item = (AuctionItem) in.readObject(); } finally { if (fin != null) fin.close(); } return item;

Short-Term Persistence

83

Java Serialization
Summary

Pros:
Built into the Java language no libraries necessary Ability to persist graph of objects, not just single ones Can also handle reference circles automatically Low implementation effort: just use the marker interface Serializable mark non-persistent elds as transient Default protocol can be overwritten (customized)

Short-Term Persistence

84

Java Serialization
Summary

Cons:
Usually, stored in binary format other (non-Java) applications cannot
access the data; not recommended for long term storage (if a class evolves the le format will break)

Only access of the whole object-graph possible; there is no mean to query

or update a single object independently
(This property makes a nave use in the context of a distributed application problematic!)

Customization requires you to write persistence code

Short-Term Persistence

85

Java Serialization
Summary

Conclusions:
Serialization can do a good job for persisting data only needed by a single
application which always needs the full data set and where the data will not be stored for long

For large-scale applications serialization lacks crucial features like partial

loading / updates, queries, storage in a DB, etc.

Short-Term Persistence

86

Java Serialization and RMI

A Short Example
package de.tud.cs.stg.ctfda.rmi import _root_.java.rmi.server.UnicastRemoteObject // The business entity. case class Customer(val id: Long, var name: String, var familyName: String) // this class is serializable; it (implicitly) inherits from Serializable // The interface of the business object. @remote // after that all methods declare to throw a java.rmi.RemoteException trait CustomerAccess { def customers(): List[Customer] } // The remote object. class CustomerAccessImpl extends UnicastRemoteObject with CustomerAccess { val customers = Customer(1l, "M.", "Eichberg") :: Nil }

Short-Term Persistence

87

Java Serialization and RMI

A Short Example - The Server
object CustomersServer extends App { import java.rmi.Naming java.rmi.registry.LocateRegistry.createRegistry(1099); val host = "localhost" // args(0); val service = "rmi://" + host + "/Customers" val remoteObject = new CustomerAccessImpl Naming.rebind(service, remoteObject); println("Server is up and running; press any key to shut down."); System.in.read Naming.unbind(service) UnicastRemoteObject.unexportObject(remoteObject, false) // TODO: in loop println("Server terminated") }

Short-Term Persistence

88

Java Serialization and RMI

A Short Example - The Client

object CustomersClient extends App { import java.rmi.Naming.lookup val host = "localhost" // args(0) val ca = lookup("rmi://" + host + "/Customers").asInstanceOf[CustomerAccess]; println("customers: " + ca.customers) }

Remote Method Invocation - Foundations

89

Marshalling via Java Serialization

Serialization refers to the activity of attening an object or a

connected set of objects into a serial form that is suitable for transmitting in a message

Both primitive data types and objects can be serialized The receiver has no prior knowledge of the types of the objects in the
serialized form

Supports reection (the ability to enquire about the properties of a class) Objects are prepared for transport with Java serialization using
java.io.Serializable

No problems with conversions - advantage of being Java-only Overhead: accounts for ~25%-50% of the time for a remote invocation

Remote Method Invocation - Foundations

90

Marshalling of Objects

Referential integrity is maintained in a remote call

If two references to an object are passed from one JVM to another JVM in parameters (or in the return value) in a single remote method call and those references refer to the same object in the sending JVM, those references will refer to a single copy of the object in the receiving JVM.

Referential integrity is not maintained across remote calls

Remote Method Invocation - Protocol Stack

91

Anatomy of an RMI-based Architecture

Remote Reference Layer
RMI-specic communication atop TCP/IP; connection initialization, server location, ; handles serialized data
RMI Client
RMI interface RMI stub

RMI Server

RMI skeleton

RMI Transport Layer (TCP)

Connection management; provision of reliable data transfer between end points

Remote Reference Layer (JRMP, IIOP)

RMI Transport Layer (TCP)

Internet Protocol
Data transfer contained in IP packets (lowest level)

Internet Protocol (IP)

Remote Method Invocation - Protocol Stack

92

Anatomy of an RMI-based Architecture

RMI Interface
Denes what operations are made available to clients; the only class the client must know

RMI Client
RMI interface RMI stub

RMI Server

RMI Stub
Implements the interface; takes calls from the client; performs marshaling / unmarshaling

RMI skeleton

Remote Reference Layer (JRMP, IIOP)

RMI Transport Layer (TCP)

RMI Skeleton
Calls the server methods; performs unmarshaling / marshaling

Internet Protocol (IP)

Remote Method Invocation - Protocol Stack

93

Anatomy of an RMI-based Architecture

RMI Client

RMI Server

RMI Server
Implements the interface; actually provides dened functionality

RMI interface RMI stub

RMI skeleton

RMI Client
Some application relying on the interface; only needs to have the interface in its class path

Remote Reference Layer (JRMP, IIOP)

RMI Transport Layer (TCP)

Internet Protocol (IP)

Remote Method Invocation - Protocol Stack

94

RMI Capabilities

Parameter passing either by reference or by value: Primitive values and serializable objects are passed by value Remote objects are passed by reference Dynamic loading of unknown classes
A serialized object is automatically annotated with a descriptor (e.g., URL) where the byte code of its class can be downloaded.

Tunneling through HTTP in case of rewall presence possible

Remote Method Invocation

95

RMI Packages
java.rmi
Core package

java.rmi.server
Core package for server-side classes and interfaces

java.rmi.registry
For interfacing with the RMI lookup service

java.rmi.activation
Classes and interfaces for implementing server objects that can be activated upon client request

java.rmi.dgc
Distributed garbage collection

Remote Method Invocation

96

RMI - Recommended Article

Understanding Java RMI Internals By Ahamed Aslam.K January 6, 2005 www.developer.com/java/ent/article.php/3455311

Developing Distributed Enterprise Applications

97

Developing Distributed Enterprise Applications

Middleware, RPC, RMI - a Summary

Developing Distributed Enterprise Applications

98

RMI vs. RPC

RMI is object-oriented: Whole objects can be passed
(normal objects by-value, remote objects by-reference)

Subtype polymorphism can be used to deal with implementation variants With RPC, basically only primitive types can be passed RMI enables behavior mobility
(Both data and code can be transferred from client to server and vice versa.)

RMI supports automatic distributed garbage collection

(In RPC the programmer has to take care of garbage collection.)

RMI has a built-in security concept

(In RPC an additional security layer is required.)

RPC can be used in many different languages and environments

(With RMI, everything needs to be Java (although ))

Developing Distributed Enterprise Applications

99

The Genealogy of Middleware

Application Servers
Object brokers Message brokers

TP-Monitors

Transactional RPC

Object oriented RPC (RMI)

Asynchronous RPC

Specialized RPC, typically with additional functionality or properties but almost always running on RPC platforms. Remote Procedure Call: hides communication details behind a procedure call and helps bridge heterogeneous platforms. Sockets: operating system level interface to the underlying communication protocols TCP, UDP: User Datagram Protocol (UDP) transports data packets without guarantees. Transmission Control Protocol (TCP) veries correct delivery of data streams. Internet Protocol (IP): moves a packet of data from one node to another

Remote Procedure Call

Sockets

TCP, UDP

Internet Protocol (IP)

Middleware

100

Historic Development
DNA enthalten in COM+ COM DCOM MTS TPM Mainframe TPM Server Mom Server ORB Server Grundlage fr CORBA Standard J2EE Standard

.NET

}
1998

zusammengefasst zu

1960

1970

1980

1990

1995

2000

2001

2002