Download 03_RPC-Extensions

III.1
Extensions of
Client/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
c1
c2
c3
Server
Results
r1...r3
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 delivery
else ...
// possibly exception handling
Discard (fd);
// removing of Future
Futureset fdFutureSet;
// definition of FutureSet
for (i=1; i<maxpar; i++) {
Future fd = FInvoke_fetchDocument (&dd); // asynchronous call
FuturesetAdd (&fdFutureSet, fd); }
// insertion of Futures to FutureSet
for (i=1; i<maxpar; i++) {
Future fd;
// definition of a Future
FutureSetExtractReady(fdFutureSet, &fd); // extraction of a Future
FClaim_fetchDocument(fd, &d, &status); } // result delivery etc.
III.5
Futures: example
FInvoke_fetchDocument
Server 1
Client
Futureset
Result return
Futures
Server 2
...ExtractReady
FClaim_...
Server 3
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
ta : local execution duration
1 + ts/ta large for long transfer time
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
RPC
Protocols for
mass data transfer
Optimization of
answer time
very important
lower importance
Flow-control
lower importance
very important
Limitation of
server-load
very important
lower importance
Storage of state
information
should be avoided
Protocol for
connection setup
nonexistent or implicit
Initiation of sending
processes
immediately after
initiation of a RPC-call
of great importance
for optimization goals
important for an
agreement of connection
params
only in the case of large
data volumes
III.8
Mass data transfer: synchronously embedded
asynchronous calls (Casts)
pass 1
call
call
pass 2
cast
cast 3
cast
cast
cast 4
cast 5
call
pass 6
catch
catch
catch
pass 7
Client
Stub
Asynchronous
data exchange
Stub
Server
• 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
Abstraction
layers
Client
Module
Server
Up-call
III.11
Example: providing of documents
Client
Server
fetchDocument
storeDocument
storeDocument
storeDocument
Return to
fetchDocument
rpc_binding_
server_from_client
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)
compute (code, param, return)
Client
Server
III.14
Local RPC-Optimization
• Efficient RPCs within one computer
• Example: Lightweight RPC
Process 1
Call without
process exchange
Parameters in the common
storage area
Process 2
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
WWW Client
(Browser)
WWW Server
Access (HTTP)
Loading
of Applets
HTML -
Applet
page
JAVA -Interpreter
Alternative: Java Web Start: dynamic loading of Java-Code to the
Client, but permanent caching in combination with automatic
updating -> improved performance
Comparison: dynamic Client-Installation
III.18
Java Applets / ActiveX-Controls Script-Languages
Java Web Start
Status
vendorindependent
proprietary
(Microsoft)
Loading
process
as byte code at
the first call;
platformindependent
JVM with
security
mechanisms
as binary code;
platformdependent
Execution
in the WindowsOS without
security
mechanisms
proprietary:
 Visual Basic Script
(Microsoft)
vendor-independent:
 Javascript
as part of HTMLpages (source code)
via interpreter without
security mechanisms
III.19
Internet/Intranet-applications: Server-site
1
HTTP
Client
2
HTTP
Client
CGI
WWW
Appli
(Hypertext Server (Common cation
HTTP
Gateway
Interface)
Transfer
Protocol)
HTTP
WWW
Server
3
Java
Applet
HTTP
RMI /
SOAP
WWW
Server
Java Servlet/
Application
Java
Servlet
• 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)
III.20
Java Servlets: procedure
(2) Load
of HTMLpage
(1) HTTP
Client/
WWWBrowser
WWW
Server
(4) Transfer of
HTML-page
with dynamically
calculated
results
=> sufficient for simpler applications only
with
Servlets
Servlet
(3) Load of Java-Servlet
and execution:
─call of application methods
─call of external programs
─database access
─thereby Multi-Threading possible
III.21
Java RMI: basic principle
Client
(for instance
Point of Sale or
Info - Terminal)
1. HTTP-access to
WWW-Server
Server (also WWW)
(for instance
account server)
Remote
<name>
Object
Registry
(simple
Directory
Service)
4. Naming Lookup
3. Creation of
Remote Object
Remote Object
(remotely callable)
• 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)
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
Server (for instance
(for instance
Point of Sale or
Info-Terminal)
account server)
Object for
user
interaction
General
Server-Object
3. Load of class
information for I
Realty
information
object I
Example: Interface description
import 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 holder
String name;
// name of account holder
public 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 name
byte bankSortingCodeNumber[];
// bank code
byte accountNumber[];
// account number
String asPaymentFor;
// purpose
public TransferOrder(...) {...}
};
III.24
import java.rmi.*;
import java.rmi.registry.*;
import java.rmi.server.UnicastRemoteObject;
Example: Server
III.25
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 variable
retrieveAccount (accountIdent.accountNumber, account); // retrieves account from the database
checkAccount(account, accountIdent.pin, accountIdent.name); //verifies access rights
getBalance(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();
}
}
}
import java.rmi.*;
import java.rmi.registry.*;
import java.applet.Applet;
import java.awt.Graphics;
Example: Client-Applet
public class BankAccessClient extends Applet {
AccountIdentification accountIdent;
float balance;
Bank remoteBankServer;
String remoteBankServersURL;
// account status
// Bank-Interface
// 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.26
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>
Internal system architecture
Application
ClientObjects
ServerObjects
Stub
RMI
System
Remote Reference Layer
Transport Layer
Remote Reference Layer:
• control of remote object references
• call of replicated objects
• activation of objects if required
III.28
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.31
Garbage 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
C
B
X
references (X,2)
references (X,3)
references (A)
references (C)
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 ServerURL 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
Firewall
Client
WWW-Server
1. HTTP
2. RMI
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
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)