Case Studies

1. Case Studies Chapter 9

2. CORBA: Overview • CORBA: Common Object Request Broker Architecture. • Example for an object-based distributed system. • Rather a specification and not a system. • Originates from OMB (Object Management Group). • First specification in early 1990s. • Currently in version 3. The global architecture of CORBA.

3. CORBA: Overview • ORB: Object Request Broker: • Glue between applications. • Main part of the middleware. • Provides communication between objects. • Supports access and location transparency. • Corba facilities: • Compositions of object services (see below). • Horizontal facilities: independent of application domains e.g. services for user interfaces, information management, system management, etc. • Vertical facilities: include services for specific application domains e.g. e-commerce, banking, etc. • Corba services: • What the Corba middleware provides for its applications in addition to basic communication. • Generic services with different functionalities (compare: OS services).

4. CORBA: Overview Overview of CORBA services.

5. CORBA: Overview • The general organization of a CORBA system. • Object Model: • Rather “remote object” model (not “distributed objects”). • IDL for interface definitions (syntax only). • ORB: communication, marshalling/unmarshalling and comparing object references, finding available services. • Clients: Static/ dynamic invocation interface. DII provides a generic invoke-method interface. • Servers: Object adapters (request forwarding, activation policy), DSI provides implementation of invoke-methods.

6. CORBA: Communication • Invocation models supported in CORBA.

7. CORBA: Communication • Corba Event and Notification Services: • Many applications need event-based communication in addition to object invocations. • Corba event model: • Events corresponds to data items (e.g. object references) • Events are produced by suppliers. • Events are used by consumers. • Two models: • Push model: • Supplier delivers event to consumers. • Consumers are interrupted when supplied events arrive (passive waiting). • Pull model: • Consumer polls event channel for events (active waiting). • Event channel polls suppliers for events.

8. CORBA: Communication • Push-style (top) and pull-style (bottom) event models.

9. CORBA: Communication • Characteristics of the event model: • Persistent event-based communication is not supported. For example, if a consumer connects to the event channel after the supply of an event, that event will be lost. • Event filtering was initially not supported. A consumer attached to an event channel will receive all events supplied to that channel. Different types of events can be distinguished by providing different event channels. • However, filtering capabilities have been added as a part of the Notification Service. • Notification Service is also able to prevent propagation of events to channels that are not attached to consumers. • Event propagation is unreliable. Corba does not guarantee event delivery.

10. CORBA: Communication • CORBA's callback model for asynchronous method invocation. • Asynchronous communication in Corba is object-based. • Two models: callback model (see figure) and polling model. • Example for the use of the callback model: void sendcb_add(in int i, in int j); // called by client void replycb_add(in int ret_val, in int k); // called by ORB int add(in int i, in int j, out int k);

11. CORBA: Communication • CORBA'S polling model for asynchronous method invocation. • In both models the object implementation (server-side) is not changed. •  server retains the synchronous model. • Also, persistent communication is possible using both models. • Example for the use of the polling model: void sendpoll_add(in int i, in int j); // called by client void replypoll_add(in int ret_val, in int k); // the same int add(in int i, in int j, out int k);

12. CORBA: Communication • For interoperability, the protocol between ORBs is standardized. • The Corba protocol therefor is GIOP:General Inter-ORB Protocol. • GOIP requires the use of a transport protocol that is reliable, connection-oriented, and supporting byte streams (e.g. TCP). • Realization of GIOP on top of TCP is called IIOP: Internet Inter-ORB Protocol. • GIOP (and thus IIOP) message types are:

13. CORBA: Processes • Processes in Corba are clients and servers (components). • Clients are kept simple: proxy marshals invocationw into IIOP requests and unmarshals corresponding reply messages. • If an object needs a specific implementation of the proxy (e.g. one with caching), interceptors are used. Interceptors are hardly seen by applications (rather part of ORB). • Two levels of interceptors are possible (both can be used at the same time): e.g. access control e.g. fragmentation

14. CORBA: Processes • Servers are based on Portable Object Adapters (POA). • POA may support activation policies, transient/persistent objects, and wrappers. • Possible policies for wrapping the objects: Object state • Mapping of CORBA object identifiers to servants. • Policy 1: One servant for each objects. • Policy 2: One servant for multiple objects.

15. CORBA: Processes • Corba also supports agents: it provides a framework for cooperation between agent systems. • Agent system should provide: creation, execution, transfer, and termination of agents. • An agent is always located in a place (i.e. server in an agent system). • Multiple agent systems may form a region (i.e. administrative domain). • Each region has a finder service, which allows it to find the location of agents, places, and agent systems. • CORBA's overall model of agents, agent systems, and regions.

16. CORBA: Naming 2 1 • 1. To check interface spec. at runtime • (in Interface Repository). • 2. E.g. IIOP • 3. Object spec. at server • 4. E.g. what to do if server unavailable 4 3 • Names: Object references and Character-based names. • Object references: • Clients work with language-dependent representations of references (e.g. pointers). • ORBs work with language-independent representations of references:  IOR : Interoperable Object Reference • Mapping between IORs and “pointers” is done by ORB. • Structure of IOR (here using IIOP):

17. CORBA: Naming • Binding: direct or indirect (see figures). • Character-based names: • Based on the Corba naming service • Names: sequence of (id, kind)-pairs (e.g. (shopping, dir) (server, class)) • No restrictions on the name space (tree, cycles, …) • An initial naming context (i.e. a directory node) is required to resolve names. Indirect binding Direct binding

18. CORBA: Synchronization • Services: Concurrency control service and transaction service. • Concurrency control service: • Based on locks (in general a central lock manager). • Read/Write locks are distinguished. • Different granularities are possible (entire table, one row, etc.). • Transaction service: • Based on 2PC. • Corba distinguishes: • Transactional objects: e.g. read-only ones for which no recovery is necessary. • Recoverable objects: For which roll-back and recovery are necessary.

19. CORBA: Consistency and Replication • No direct support for caching and replication in Corba, except for fault tolerance. • But applications can provide that as services: e.g. CASCADE is a Corba caching service. • CASCADE features: • Different client-centric consistency models are supported. • Total ordering of updates. • Each object may have its own consistency model. • Caching is quasi implicit for clients. • Implementation is based on interceptors:

20. CORBA: Fault tolerance • Corba version 3 provides mechanisms for fault-tolerance based on replication. • Replication is transparent for clients. • Instead of IORs, IOGRs (Interoperable Object Group Reference) are used. • Structure of IOGR: Example for the use of the Components field to specify the role of a replica

21. CORBA: Fault tolerance (Message-level) • An example architecture of a fault-tolerant CORBA system.

22. CORBA: Security • The general organization for secure object invocation in CORBA. • Security services: What services can be used for security (e.g. authorization, authentication) depends on the administrative domain (or client policies). • Policies: client(or server)-specific information (e.g. how to protect messages, what are trusted parties).

23. CORBA: Security • Implementation of security services using interceptors. • Access control interceptor: request-level interceptor for authorization. • Access objects: actual authorization methods. • Secure invocation interceptor: message-level interceptor for secure communication. • Security context object: offers, for example, methods for encryption and decryption. • Vault objects: called by invocation interceptor to create a security context (policy information may be also used at creation time).

24. WWW: Overview Overall organization of the Web. • World Wide Web (WWW): Document-based distributed system. • Started at CERN (European Particle Physics Lab). • Popularity increased in the early 1990s.

25. WWW: Overview • Documents include: • Text and multimedia information, scripts, … • Hyperlinks: references to other documents. • Languages: • HTML: Hypertext Markup Language • XML: Extensible Markup Language • An example for an HTML document: “Hello World” displayed twice, directly and using a script. <HTML> <!- Start of HTML document --><BODY> <!- Start of the main body --><H1>Hello World/H1> <!- Basic text to be displayed --><P> <!- Start of a new paragraph --><SCRIPT type = "text/javascript"> <!- identify scripting language -->document.writeln ("<H1>Hello World</H1>; // Write a line of text</SCRIPT> <!- End of scripting section --></P> <!- End of paragraph section --></BODY> <!- End of main body --></HTML> <!- End of HTML section -->

26. WWW: Overview • An example for an XML document: • Unlike HTML which emphasizes the layout of documents (e.g. font, font size, etc.), • XML emphasizes the structure of the document’s data. • XML is typically embedded in HTML documents or a special formatting language • XSL (Extensible Style Language) is used. • Following example reflects the structure of a library document: (1) <!ELEMENT article (title, author+,journal)>(2) <!ELEMENT title (#PCDATA)>(3) <!ELEMENT author (name, affiliation?)>(4) <!ELEMENT name (#PCDATA)>(5) <!ELEMENT affiliation (#PCDATA)>(6) <!ELEMENT journal (jname, volume, number?, month? pages, year)>(7) <!ELEMENT jname (#PCDATA)>(8) <!ELEMENT volume (#PCDATA)>(9) <!ELEMENT number (#PCDATA)>(10) <!ELEMENT month (#PCDATA)>(11) <!ELEMENT pages (#PCDATA)>(12) <!ELEMENT year (#PCDATA)> article.dtd An XML definition for referring to a journal article.

27. WWW: Overview • An XML document using the definitions in file article.dtd: (1) <?xml = version "1.0">(2) <!DOCTYPE article SYSTEM "article.dtd“>(3) <article>(4) <title> Prudent Engineering Practice for Cryptographic Protocols</title>(5) <author><name>M. Abadi</name></author>(6) <author><name>R. Needham</name></author>(7) <journal>(8) <jname>IEEE Transactions on Software Engineering</jname>(9) <volume>22</volume>(10) <number>12</number>(11) <month>January</month>(12) <pages>6 – 15</pages>(13) <year>1996</year>(14) </journal>(15) </article>

28. WWW: Overview Six top-level MIME types and some common subtypes.

29. WWW: Overview • Architecture: • Simple Client/Server interactions were later enhanced. • Added: CGI, Server-side scripts, Applets, Servlets • The principle of using server-side CGI programs: e.g. form data from browser

30. WWW: Overview • Using Server-side scripts: (1) <HTML>(2) <BODY>(3) <P>The current content of <pre>/data/file.txt</PRE>is:</P>(4) <P>(5) <SERVER type = "text/javascript");(6) clientFile = new File("/data/file.txt");(7) if(clientFile.open("r")){(8) while (!clientFile.eof())(9) document.writeln(clientFile.readln());(10) clientFile.close();(11) }(12) </SERVER>(13) </P>(14) <P>Thank you for visiting this site.</P>(15) </BODY>(16) </HTML> Executed by server prior to reply (User will see in this example a text document generated dynamically by the server) An HTML document containing a JavaScript to be executed by the server

31. WWW: Overview • Applets: precompiled code executed by clients; e.g.: • <OBJECT codetype = “application/java” classid = “java.welcome.class”> • Servlets: An alternative to CGI, code is executed in address space of server. Architectural details of a client and server in the Web.

32. WWW: Communication • Communication in WWW is based on HTTP: Hypertext Transfer Protocol • HTTP is based on TCP and is stateless. • Connections: • Nonpersistent: a new connection for each request. • Persistent: different requests share same connection. • Using nonpersistent connections: early versions. • Using persistent connections: newer ones.

33. WWW: Communication Operations supported by HTTP.

34. WWW: Communication HTTP request message  Operation: e.g. get, put, …  Reference: e.g. URL  Version: Client HTTP version  Message headers: optional

35. WWW: Communication HTTP response message.  Version: Server’s HTTP version  Status code / Phrase: e.g. 200 / OK 400 / Bad Request 403 / Forbidden  Message headers: optional

36. WWW: Communication Some HTTP message headers.

37. WWW: Processes • Using a plug-in in a Web browser. • Clients: Most important part is the browser. • Browsers use plug-in programs in order to cope with different document types. • Plug-in: small program dynamically loaded by the browser. • Examples: plug-ins to handle Java applets, scripts, XML, etc.

38. WWW: Processes • Using a Web proxy when the browser does not speak FTP. • Web proxy: A client-side process used by the browser to handle application-level protocols like FTP. • Web proxy acts as gateway that translates messages between different protocol worlds. • However: Current browsers do not need such proxies; they are able to understand different protocols by themselves. • Instead: Proxies are currently used for caching.

39. WWW: Processes • General organization of the Apache Web server. • Web servers: Analyze incoming HTTP messages and perform appropriate operations. • Example: Apache Web server: • Highly configurable Web server with different modules. • Each module may include different handlers for different types of requests. • Request processing is divided in phases, and each handler can perform operations of a single phase

40. WWW: Processes • Phases of Apache: • Resolving the document reference to a local file name/program • Client authentication • Client access control • Request access control • MIME type determination of the response • Handling “leftovers” (parse request, …) • Transmission of the response • Logging data on the processing of the request • In general: Core module spawns a new process for each request. • Simplest configuration of Apache: • Without any module • Core module does everything • But only HTML files are supported

41. WWW: Processes • Principle of using a cluster of workstations to implement a Web service. • For efficiency, Web servers are replicated in a LAN. •  horizontal distribution • Problem: Front end may become a bottleneck. • Solutions: Transport-level front ends or application-level front ends.

42. WWW: Processes • Transport-level front ends: • Do as few work as possible at front end in order to avoid overloads. • Front end’s server selection is not based on the message contents. • Server selection is based on actual load on servers or a hardwired policy is used (e.g. Round Robin) in order to achieve load balancing. • Application-level front ends: • Front end inspects HTTP messages and decides which server to use based on the message contents. • Advantages: • Higher throughput of server is achievable. For example, if a document request is always forwarded to a server that handled it before, effectively document caching at the server is possible. • Distribution instead of replication can be used. This approach can reduce storage capacity without entirely loosing fault tolerance advantages of replication. •  Example: Dedicated servers for audio, video, or text data.

43. WWW: Processes • The principle of TCP handoff. • Main problem of application-level front ends is that they have to do a lot of work ( bottleneck). • Remedy: Use of TCP handoffs (see figure) •  Front end only handles requests and delegates responses to the server. •  Client sees only one TCP connection. •  Sufficient for non-persistent connections.

44. WWW: Processes • A scalable content-aware cluster of Web servers. • A hybrid solution: • On the application level, a dispatcher selects a server based on request contents. • On the transport level, a switch forwards messages to previously selected server. • Better suited for persistent connections.

45. WWW: Naming • WWW names are called: URI (Uniform Resource Identifiers) • URL (Uniform Resource Locator):  Location-dependent (in practice, you need only URLs) • URN (Uniform Resource Name): •  True identifiers Often-used structures for URLs. a) Using only a DNS name. b) Combining a DNS name with a port number. c) Combining an IP address with a port number.

46. WWW: Naming Examples of URLs.

47. WWW: Naming urn : ietf : rfc:2648 urn : isbn : 0-13-088893-1 • The general structure of a URN • URNs • Scheme: “urn” • Name space: Gives structure of names • e.g. isbn or ietf structure etc. • Name of resource: actual identifier of resource • e.g. actual RFC article identifier

48. WWW: Synchronization • Synchronization is not really supported because: • Strict client/server orientation (no inter-server/client-communication). • Updates are rare and done mostly by a single person. • However, more support for cooperative Web authoring is emerging. • WebDAV (Web Distributed Authoring and Versioning): • An extension of HTTP towards synchronization. • Locks: •  Exclusive write locks •  Shared write locks • Granularity of locks: Whole document •  if shared, writers should modify different parts. • Locks are implemented using tokens that servers gives to clients. • Clients provide server with tokens when they perform updates. • Tokens may survive connection breakdowns and disconnections.

49. WWW: Caching and Replication • Both caching and replication are main issues in the WWW. • Caching: • Small cache at browser machine. •  e.g. one cache per client • More important proxy caches •  a proxy cache in a LAN (flat) or multiple hierarchical proxies (multi-level). • Protocols in general pull-based: • Proxy sends “if-modified-since” header in a GET-request. •  doubles number of messages but reduces amount of transferred data. • Acceptable weaker consistency can be achieved with less number of messages. • Active caches: • Server replies with an applet to the proxy. • Applet does the actual document transfer, if need be. • Applet is cached and activated, when same document is accessed again. • Cooperative caching (see next slide) • Strict client/server orientation (no inter-server/client-communication). • Updates are rare and done mostly by a single person. • However, more support for cooperative Web authoring is emerging. • WebDAV (Web Distributed Authoring and Versioning) • An extension of HTTP towards synchronization. • Locks: •  Exclusive write locks •  Shared write locks • Granularity of locks: Whole document •  if shared, writers should modify different parts. • Locks are implemented using tokens that servers gives to clients. • Clients provides server with tokens when they perform updates. • Token may survive connection breakdowns and disconnections.

50. WWW: Caching and Replication The principle of cooperative caching