III.1

Extensions ofClient/Server-Model:

- structural extensions- object-oriented mechanisms

III.2

RPC-extensions

• asynchronous RPCs with acknowledgments

• mass data transfer

• callbacks

• fault tolerance

• dynamic code installation

• local RPC-optimization

• object-oriented mechanisms

III.3

Asynchronous RPCs

Client

Futures f1...f3

Calls

Resultsr1...r3

c1

c2

c3

Server

• the asynchronous calls deliver to the Client a so called Future-Object• the acknowledgements (results) of the Server are delivered

transparently to the respective Future-Object• test- and receive operations on Futures enable the access of the Client

to results of asynchronous RPCs• special properties:

– full typing of Futures– immediate sending of asynchronous calls response time optimization

III.4

Futures: program example

Future fd = FInvoke_fetchDocument(&dd); // asynchronous call.... // execution of further op.if (isReady (fd, timeout)) FClaim_fetchDocument (fd, &d, &status);

// result deliveryelse ... // possibly exception handling

Discard (fd); // removing of Future

Futureset fdFutureSet; // definition of FutureSetfor (i=1; i<maxpar; i++) {

Future fd = FInvoke_fetchDocument (&dd); // asynchronous callFuturesetAdd (&fdFutureSet, fd); } // insertion of Futures to FutureSet

for (i=1; i<maxpar; i++) {Future fd; // definition of a FutureFutureSetExtractReady(fdFutureSet, &fd); // extraction of a FutureFClaim_fetchDocument(fd, &d, &status); } // result delivery etc.

III.5

Futures: example

Futureset

Futures

...ExtractReadyFClaim_...

ClientServer 1

Server 2

Server 3

FInvoke_fetchDocument

Result return

III.6

Time behavior

Basic rule:k asynchronous calls (with result) for the same Server are at most

min (1 + ts/ta; k)times faster than k synchronous calls.

ts : transfer time 1 + ts/ta large for long transfer time

ta : local execution duration

ts small 1 + ts/ta 1 no improvement

ts large significant improvement (for instance: for slower WANs)

maximum improvement for 1x message roundtrip duration per call, if ta is small, therefore factor k for k calls(messages are sent sequentially, calls are executed sequentially)

III.7

RPC and mass data transfer

Optimization of answer time

Flow-control

Limitation of server-load

Storage of state information

Protocol for connection setup

Initiation of sending processes

very important

lower importance

very important

should be avoided

nonexistent or implicit

immediately after initiation of a RPC-call

RPC

lower importance

very important

lower importance

of great importancefor optimization goals

important for an agreement of connection

paramsonly in the case of large

data volumes

Protocols for mass data transfer

III.8

Mass data transfer: synchronously embedded asynchronous calls (Casts)

cast

call

cast

cast

call

catch

call

catch

catch

pass 1

pass 2

cast 3

cast 4

cast 5

pass 6

pass 7

Client Stub ServerStubAsynchronous data exchange

• Casts do not have acknowledgments

• selective repeat of Casts is possible after synchronization

• explicit direction control via control token

III.9

Callbacks

• Principle:– Client offers call interface

– Server can initiate callbacks during running call

– continuation is possible via several hierarchy layers

• Application:– preliminary result return

– request of further data

– status messages

III.10

Principle: Distributed Up-calls

Client

Module

ServerUp-call

Abstraction

layers

III.11

Example: providing of documents

Client Server

rpc_binding_server_from_client

fetchDocument

storeDocumentstoreDocumentstoreDocument

Return tofetchDocument

III.12

Implementation in DCE RPC

extern Document *findDocumentOnDisk(); // providing of documents

void fetchDocument (rpc_binding_handle_t bh, DocumentDescription *dd)

// operation for providing of documents

// explicit Binding, i.e. : server address

{

Document *d; // created document

rpc_binding_handle_t callback_handle; // client address

rpc_binding_server_from_client(bh, &callback_handle, &status);

do {

d = findDocumentOnDisk(dd); // search for document

if (d != NULL) storeDocument(callback_handle, d); // callback to Client

} while (d != NULL);

}

III.13

Dynamic Server-Code-Installation

• REV = Remote Evaluation

• Server obtains procedure code dynamically (interpreted or binary / for homogeneous systems)

• dynamically referenced procedures must be transferred too call graph

• Application: CPU-intensive calculation services

• similar mechanism: Java Servlets (for Java Applets: Code - Installation on Client-site)

Client Server

compute (code, param, return)

III.14

Local RPC-Optimization

• Efficient RPCs within one computer

• Example: Lightweight RPC

Process 1

Parameters in the commonstorage area

Process 2Call without process exchange

III.15

Object-oriented mechanisms: Java

• object-oriented programming language, C++ -based, however simpler and clearer structure

• run-time system with Bytecode - Interpreter for Java (JVM - Java Virtual Machine) --> platform independence

• development environment JDK (Java Development Kit)

• dynamically loadable Applets, integrated with WWW; Java Web Start as alternative

• remote communication between Java-objects via RMI (Remote Method Invocation)

• interfaces to CORBA

• database interface JDBC (Java Database Connectivity)

III.16

Java Enterprise Edition

• EJB (Enterprise JavaBeans)• JDBC (Java Database Connectivity)• JMS (Java Messaging Service)• Transactions (JTA, JTS - Java Transaction Architecture/Service)• JSP (Java Server Pages), Servlet API• XML (Deployment Descriptor)• JNDI (Java Naming and Directory Service)• J2EE Connector (Interfaces for Legacy-Integration)• JWS (Java Web Start)• JDO (Java Data Objects)• CORBA (Runtime)

III.17

Java Applets: Basic principle

HTML -page

Applet

Loadingof Applets

JAVA -Interpreter

WWW Client(Browser)

WWW Server

Access (HTTP)

Alternative: Java Web Start: dynamic loading of Java-Code to the Client, but permanent caching in combination with automatic updating -> improved performance

III.18Comparison: dynamic Client-Installation

Java Applets / Java Web Start

ActiveX-Controls Script-Languages

Status vendor-independent

proprietary (Microsoft)

proprietary: Visual Basic Script

(Microsoft) vendor-independent: Javascript

Loading process

as byte code at the first call; platform-independent

as binary code; platform-dependent

as part of HTML-pages (source code)

Execution JVM with security mechanisms

in the Windows-OS without security mechanisms

via interpreter without security mechanisms

III.19

Internet/Intranet-applications: Server-site

HTTPClient

HTTPClient

Java Applet

WWWServer

WWWServer

WWWServer

Java Servlet/Application

JavaServlet

Application

• relatively inefficient parameter transfer• new process per call => inefficient

• flexible and efficient• however limited on HTTP-interaction

•extensive flexibility; however security, firewalls etc. to be taken into account •more complex interactions are possible•interactions with transactions and further services•use of component technologies (Enterprise JavaBeans)

HTTP

(Hypertext Transfer Protocol)

CGI

(CommonGatewayInterface)

1

2

3

HTTP

HTTP

RMI /SOAP

III.20

Java Servlets: procedure

Client/WWW- Browser

WWWServer

(1) HTTP

(4) Transfer of HTML-page

with dynamicallycalculated

results

Servlet

(3) Load of Java-Servletand execution:─call of application methods─call of external programs─database access─thereby Multi-Threading possible

(2) Loadof HTML-

page

with Servlets

=> sufficient for simpler applications only

III.21

• interaction with WWW-Server, dynamic requests etc. are possible (for instance for investment information)

• also server callbacks from client-objects (for instance for parameter inputs)

Server (also WWW)(for instance

account server)

Client (for instance

Point of Sale or Info - Terminal)

3. Creation of Remote Object

<name>

Remote Object(remotely callable)

1. HTTP-access toWWW-Server

2. Transfer of

Java Applet

5. Remote object call

4. Naming Lookup

Remote Object Registry(simpleDirectory Service)

Java RMI: basic principle

III.22

Java RMI: Properties

• For Applets: – as a rule communication is limited to the Server, from which the Applet is

loaded (security); however, this can be softened

• transfer of Remote Objects as reference parameters, also dynamic transfer of remote object references

• transfer of other objects (“Local Objects“) as value parameters; no migration

• dynamic loading of class information to a Remote Object, Client obtains a reference

• calls are generally synchronous; asynchronous calls are possible only via Threads

• compatible to CORBA IIOP (Internet Inter-ORB Protocol)

III.23

Example of Remote Objects as parameters

Client(for instancePoint of Sale or Info-Terminal)

Object for user interaction

Server (for instance account server)

GeneralServer-Object

Realtyinformationobject I

1. Call

2. Answer with

reference parameters

3. Load of classinformation for I

4. Call of I5. Answer

III.24Example: Interface descriptionimport java.rmi.*;public interface Bank extends java.rmi.Remote {

final long maxTransferAmount = 2000; // maximum amount to transfer float balanceQuery(AccountIdentification accountIdent) throws java.rmi.RemoteException; void transferRequest(AccountIdentification accountident, float amount, TransferOrder transOrder) throws java.rmi.RemoteException;}______________________

import java.io.Serializable;public class AccountIdentification implements Serializable // identification for a certain account{ byte accountNumber[]; // account number

long pin; // PIN of account holderString name; // name of account holderpublic AccountIdentification(byte[] account, long pin, String name) {

this.accountNumber = account;this.pin = pin;this.name = name;

}}public class TransferOrder implements Serializable{ //money transfer form

String bankname; // bank namebyte bankSortingCodeNumber[]; // bank codebyte accountNumber[]; // account numberString asPaymentFor; // purposepublic TransferOrder(...) {...}

};

III.25Example: Serverimport java.rmi.*;import java.rmi.registry.*;import java.rmi.server.UnicastRemoteObject;

public class BankImpl extends UnicastRemoteObject implements Bank{

public BankImpl() throws RemoteException {} ... public float balanceQuery(AccountIdentification accountIdent) // Inquiry of account status { float balance;

Account account; // account variableretrieveAccount (accountIdent.accountNumber, account); // retrieves account from

the databasecheckAccount(account, accountIdent.pin, accountIdent.name); //verifies access rightsgetBalance(account, balance); // inputs account status into ‘balance’return balance;

}public void transferRequest(AccountIdentification accountIdent, float amount, TransferOrder transOrder){...}public static void main(String args[])

{ System.setSecurityManager(new RMISecurityManager()); try {

BankImpl server = new BankImpl(); Registry registry = LocateRegistry.getRegistry(); registry.rebind("Bank", server);

} catch (Exception e) { System.out.println(e.getMessage()); e.printStackTrace();

} }}

III.26Example: Client-Appletimport java.rmi.*;import java.rmi.registry.*;import java.applet.Applet;import java.awt.Graphics;

public class BankAccessClient extends Applet {AccountIdentification accountIdent;float balance; // account status

Bank remoteBankServer; // Bank-Interface String remoteBankServersURL; // URL of Bank-Interface

public void init() { try { remoteBankServersURL = "rmi://" + getCodeBase() + "/" + "Bank"; remoteBankServer = (Bank) Naming.lookup(remoteBankServersURL); } catch (Exception e) {

System.out.println(e.getMessage()); e.printStackTrace(); } } public void start() { inputAccountIdentification(accountIdent); // input of account identification try { balance = remoteBankServer.balanceQuery(accountIdent);

// remote inquiry of account status } catch (Exception e) {

System.out.println(e.getMessage()); e.printStackTrace(); } } public void paint(Graphics g) { g.drawString("Kontostand=" + new Float(balance).toString(),10,10);}

public void inputAccountIdentification(AccountIdentification accountIdent) {...}}

III.27

Example: Integration in WWW

<HTML>

<HEAD>

<TITLE>Bank Access</TITLE>

</HEAD>

<BODY>

<APPLET CODE="BankAccessClient.class" width=500 height=500></APPLET>

</BODY>

</HTML>

III.28Internal system architecture

Remote Reference Layer:

• control of remote object references

• call of replicated objects

• activation of objects if required

ApplicationClient-Objects

Server-Objects

RMISystem

Stub

Remote Reference Layer

Transport Layer

III.29

Internal system architecture

Transport Layer:

• connection control (as a rule one connection between a pair of operating system processes)

• object reference = <endpoint (IP-Adresse,Port); object ID>

Multithreaded Servers:

• default-mechanism for call execution of different objects

• calls of the same clients as a rule are executed sequentially

III.30

Security aspects in Java RMI

• class load only from the computer of respective applet (exception: Signed Applets)

• verification of applets via Applet Security Manager, prohibition of local file access as well as call of foreign network connections („Sandbox“); however controlled access permission is possible

• additional digital signatures for applets

• authentication and encryption on the basis of Java Cryptographic Architecture

• implementation via Security Packages, for instance, using DES (Data Encryption Standard) or RSA

III.31Garbage Collection

• automatic storage control for distributed Java-Objects;

• handling of computer failure via test messages

Basis: Reference Counting:

• during creation of the first process reference to a remote object: “referenced”-message to Server

• increment of local counter for further references

• automatic object disposing, if no more references exist

Example:A

B

C

references (X,2)

references (A)references (C)

references (X,3)

X

III.32

Registry Service

• local flat Directory Server per Server-computer

• simply usable, but not scalable

• object export only to local Registry Service via the Server

• import is possible network-wide via specification of Server-URL and object name; however within Applets only access to Server, from which Applet is loaded

usable for simple applications, however integration of an adequate Directory Service is reasonable for large applications (for instance via JNDI- or CORBA-interfaces)

III.33

RMI via Firewalls

Problem:

• Firewall enables HTTP-calls only

• RMI normally works via direct TCP/IP-Sockets

• RMI-calls can be embedded in HTTP POST requests

• thereby controlled RMI-calls via Firewall are possible

Firewall

Client WWW-Server

2. RMI

1. HTTP

III.34

Extended RMI call-mechanisms

• basic mechanism: Unicast (Point-to-Point)

• persistent references: object referencing to external storage media, dynamic activation during calls; supported by Java RMI

Replicated object groups:

• object replication on several computers

• replicated calls

• if necessary atomic multicast: call to all replicas or to none (in error case)