1 / 63

Case Studies

Case Studies. Chapter 9. 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.

chidi
Download Presentation

Case Studies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related