Extensions of Client/Server-Model: structural extensions object-oriented mechanisms

1. Extensions of • Client/Server-Model: • structural extensions • object-oriented mechanisms

2. RPC-extensions • asynchronous RPCs with acknowledgments • mass data transfer • callbacks • fault tolerance • dynamic code installation • local RPC-optimization • object-oriented mechanisms

3. Asynchronous RPCs Calls c1 Client Server c2 • 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 c3 Results Futures f1...f3 r1...r3

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.

5. Futures: example FInvoke_fetchDocument Server 1 Client Futureset Result return Futures Server 2 ...ExtractReady FClaim_... Server 3

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)

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 of great importance for optimization goals Protocol for connection setup nonexistent or implicit important for an agreement of connection params Initiation of sending processes immediately after initiation of a RPC-call only in the case of large data volumes

8. Mass data transfer: synchronously embedded asynchronous calls (Casts) pass 1 call pass 2 call cast 3 cast catch cast cast 4 catch cast 5 cast catch pass 6 call pass 7 Asynchronous data exchange Client Stub Stub Server • Casts do not have acknowledgments • selective repeat of Casts is possible after synchronization • explicit direction control via control token

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

10. Principle: Distributed Up-calls Abstraction layers Server Client Up-call Module

11. Example: providing of documents Client Server fetchDocument rpc_binding_ server_from_client storeDocument storeDocument storeDocument Return to fetchDocument

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); • }

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

14. Local RPC-Optimization • Efficient RPCs within one computer • Example: Lightweight RPC Process 1 Process 2 Call without process exchange Parameters in the common storage area

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)

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)

17. Applet HTML - page Java Applets: Basic principle WWW Client (Browser) WWW Server Access (HTTP) Loading of Applets JAVA -Interpreter Alternative: Java Web Start: dynamic loading of Java-Code to the Client, but permanent caching in combination with automatic updating -> improved performance

18. Comparison: dynamic Client-Installation

19. Internet/Intranet-applications: Server-site 1 • relatively inefficient • parameter transfer • new process per call => inefficient CGI HTTP WWWServer HTTP Client Appli cation (CommonGatewayInterface) (Hypertext Transfer Protocol) 2 HTTP HTTP Client WWWServer JavaServlet • flexible and efficient • however limited • on HTTP-interaction 3 HTTP Java Applet WWWServer • 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) RMI / SOAP Java Servlet/Application

20. Java Servlets: procedure (2) Load of HTML- page (1) HTTP WWWServer Client/ WWW- Browser with Servlets (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 => sufficient for simpler applications only

21. <name> Java RMI: basic principle 1. HTTP-access to WWW-Server Client (for instance Point of Sale or Info - Terminal) 3. Creation of Remote Object Server (also WWW) (for instance account server) 2. Transfer of Java Applet Remote Object Registry(simple Directory Service) 4. Naming Lookup 5. Remote object call 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)

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)

23. Example of Remote Objects as parameters Client (for instance Point of Sale or Info-Terminal) Object for user interaction Server (for instance account server) General Server-Object 1. Call 2. Answer with reference parameters 3. Load of class information for I Realty information object I 4. Call of I 5. Answer

24. 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(...) {...} • };

25. Example: Server • import 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 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(); • } • } • }

26. Example: Client-Applet • import 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) {...} • }

27. Example: Integration in WWW • <HTML> • <HEAD> • <TITLE>Bank Access</TITLE> • </HEAD> • <BODY> • <APPLET CODE="BankAccessClient.class" width=500 height=500></APPLET> • </BODY> • </HTML>

28. Internal system architecture Application Client- Objects Server- Objects 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

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

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

31. A C Example: B X references (X,2) references (X,3) references (A) references (C) 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

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)

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

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)