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. ServiceDescription CollectionFacilities for grouping objects into lists, queue, sets, stacks, etc. QueryFacilities for querying collections of objects in a declarative manner; various collections possible ConcurrencyFacilities to allow concurrent access to shared objects TransactionFlat and nested transactions on method calls over multiple objects EventFacilities for asynchronous communication through events NotificationAdvanced facilities for event-based asynchronous communication (e.g. filtering) ExternalizationFacilities for marshaling and unmarshaling of objects (like Java’s serialization) Life cycleFacilities for creation, deletion, copying, and moving of objects LicensingFacilities for attaching a license to an object NamingFacilities for systemwide name of objects PropertyFacilities for associating (attribute, value) pairs with objects TradingFacilities to publish and find the services an object has to offer based on constraints PersistenceFacilities for persistently storing objects; persistence transparency is provided RelationshipFacilities for expressing relationships between objects (compare database schemes) SecurityMechanisms for secure channels, authorization, and auditing TimeProvides the current time within specified error margins

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. Request typeFailure semanticsDescription SynchronousAt-most-onceCaller blocks until a response is returned or an exception is raised One-wayBest effort deliveryCaller continues immediately without waiting for any response from the server Deferred synchronous At-most-onceCaller continues immediately and can later block until response is delivered

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: int add(in int i, in int j, out int k); 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

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: int add(in int i, in int j, out int k); void sendpoll_add(in int i, in int j); // called by client void replypoll_add(in int ret_val, in int k); // the same

12. CORBA: Communication Message typeOriginatorDescription RequestClientContains an invocation request ReplyServerContains the response to an invocation LocateRequestClientContains a request on the exact location of an object LocateReplyServerContains location information on an object CancelRequestClientIndicates client no longer expects a reply CloseConnectionBothIndication that connection will be closed MessageErrorBothContains information on an error FragmentBothPart (fragment) of a larger message 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. fragmentation e.g. access control

14. Mapping of CORBA object identifiers to servants. a)Policy 1: One servant for each objects. b)Policy 2: One servant for multiple objects. 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

15. CORBA's overall model of agents, agent systems, and regions. 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.

16. CORBA: Naming 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): 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 1 2 3 4

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. Direct binding Indirect 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. 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: CORBA: Consistency and Replication

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. An example architecture of a fault-tolerant CORBA system. CORBA: Fault tolerance (Message-level)

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. World Wide Web (WWW): Document-based distributed system. Started at CERN (European Particle Physics Lab). Popularity increased in the early 1990s. WWW: Overview Overall organization of the Web.

25. 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: WWW: Overview Hello World/H1> document.writeln (" Hello World ; // Write a line of text “Hello World” displayed twice, directly and using a script.

26. 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: WWW: Overview (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) article.dtd An XML definition for referring to a journal article.

27. (1) (2) (3) (4) Prudent Engineering Practice for Cryptographic Protocols (5) M. Abadi (6) R. Needham (7) (8) IEEE Transactions on Software Engineering (9) 22 (10) 12 (11) January (12) 6 – 15 (13) 1996 (14) (15) An XML document using the definitions in file article.dtd: WWW: Overview

28. Six top-level MIME types and some common subtypes. TypeSubtypeDescription Text PlainUnformatted text HTMLText including HTML markup commands XMLText including XML markup commands Image GIFStill image in GIF format JPEGStill image in JPEG format Audio BasicAudio, 8-bit PCM sampled at 8000 Hz ToneA specific audible tone Video MPEGMovie in MPEG format PointerRepresentation of a pointer device for presentations Application Octet-streamAn uninterrupted byte sequence PostscriptA printable document in Postscript PDFA printable document in PDF Multipart MixedIndependent parts in the specified order ParallelParts must be viewed simultaneously

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 An HTML document containing a JavaScript to be executed by the server (1) (2) (3) The current content of /data/file.txt is: (4) (5) (13) (14) Thank you for visiting this site. (15) (16) Using Server-side scripts: Executed by server prior to reply (User will see in this example a text document generated dynamically by the server)

31. WWW: Overview Architectural details of a client and server in the Web. Applets: precompiled code executed by clients; e.g.: Servlets: An alternative to CGI, code is executed in address space of server.

32. WWW: Communication a)Using nonpersistent connections: early versions. b)Using persistent connections: newer ones. 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.

33. WWW: Communication Operations supported by HTTP. OperationDescription Head Request to return the header of a document e.g. get information on last modification time, etc, GetRequest to return a document to the client Put Request to store a document (name and document are parameters) Post Provide data that is to be added to a document collection e.g. post an article in a news group (group name and article are parameters) DeleteRequest to delete a document

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. HeaderSourceContents AcceptClientThe type of documents the client can handle Accept-CharsetClientThe character sets are acceptable for the client Accept-EncodingClientThe document encodings the client can handle Accept-LanguageClientThe natural language the client can handle AuthorizationClientA list of the client's credentials WWW-AuthenticateServerSecurity challenge the client should respond to DateBothDate and time the message was sent ETagServerThe tags associated with the returned document ExpiresServerThe time how long the response remains valid FromClientThe client's e-mail address HostClientThe TCP address of the document's server If-MatchClientThe tags the document should have If-None-MatchClientThe tags the document should not have If-Modified-SinceClient Tells the server to return a document only if it has been modified since the specified time If-Unmodified-SinceClient Tells the server to return a document only if it has not been modified since the specified time Last-ModifiedServerThe time the returned document was last modified LocationServer A document reference to which the client should redirect its request RefererClientRefers to client's most recently requested document UpgradeBothThe application protocol the sender wants to switch to WarningBothInformation about the status of the data in the message

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 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. 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

46. WWW: Naming Examples of URLs. NameUsed forExample httpHTTPhttp://www.cs.vu.nl:80/globe ftpFTPftp://ftp.cs.vu.nl/pup/minx/README fileLocal filefile:/edu/book/work/chp/11/11 dataInline datadata:text/plain;charset=iso-8859-7,%e1%e2%e3 telnetRemote logintelnet://flits.cs.vu.nl telTelephonetel:+31201234567 modemModemmodem:+31201234567;type=v32

47. WWW: Naming 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 urn: ietf : rfc:2648 urn: isbn : 0-13-088893-1

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

51. WWW: Caching and Replication Replication: Using horizontal distribution (as mentioned earlier)  transparent for clients Mirroring:  nontransparent Recently, forms of server-initiated replica placement have emerged. Example: RaDaR Web hosting service A collection of servers are able to analyze client traffic. Servers in the proximity of a client are observed as originator of that traffic. Following some policy (e.g. after a frequency threshold is reached), a document is moved/copied to the corresponding server. Fault tolerance: No special mechanisms are used in the Web. Only replication and caching as explained (even if the intention of their use was originally to enhance performance). However, achieved fault tolerance in the Web is based on the use of highly available and fault tolerant services such as DNS.

52. WWW: Security The position of TLS in the Internet protocol stack. HTTP supports security. However, in practice security is dealt with at the transport level. SSL: Secure Socket Layer is generally used for secure communication in the Web. Newest version of SSL is called TLS (Transport Layer Security) protocol.

53. WWW: Security TLS with mutual authentication. Setting up a secure channel using TLS (see figure): 1. Client sends a set of possible cryptographic/compression methods it can handle. 2. Server chooses one of them. 3. Server sends a certificate (encrypted by a certification authority, CA) to client.  now server is authenticated with client. 4. Client authenticates itself with client. 5. Client sends a random number, which is used to construct a session key.