Date post: | 03-Jan-2016 |
Category: |
Documents |
Upload: | rosaline-woods |
View: | 221 times |
Download: | 0 times |
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)