EMOS - Lecture 8.ppt

78,510 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
78,510
On SlideShare
0
From Embeds
0
Number of Embeds
22,181
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

EMOS - Lecture 8.ppt

  1. 1. Modern Operating Systems Lecture 8/9 Distributed Computing & CORBA
  2. 2. From Mainframe Applications... Mainframe Data and Applications Terminal Access
  3. 3. ...to Client/Server Applications... Fat Client Unix Client Mac Client Windows Client Oracle, DB2, MS SQL, Informix, Sybase, etc. Back-end Data Corporate Data
  4. 4. …to Multi-tier Distributed Applications Back-end Data Middle Tier (NT/Unix) Thin Client Windows Client Java Client Browser Client Mobile Client Middle-Tier Services Business Processes Oracle, DB2, MS SQL, Informix, Sybase Application Server: Corporate Data
  5. 5. Enterprise Computing <ul><li>Enterprises have a variety of computing platforms </li></ul><ul><ul><li>Unix, 95/98/NT, AS/400, VMS, Macintosh etc. </li></ul></ul><ul><li>Enterprises write applications in a variety of programming languages </li></ul><ul><ul><li>C, C++, Java, COBOL, Basic, Perl, Smalltalk, etc. </li></ul></ul><ul><li>Enterprises need an open architecture to support the heterogeneous environment </li></ul>
  6. 6. Object-Oriented Computing for the Enterprise <ul><li>Enterprise applications are being written in terms of objects - reusable components that can be accessed over the enterprise network </li></ul><ul><li>CORBA supplies the architecture for distributed applications based on open standards </li></ul>
  7. 7. Distributed Application Advantages <ul><li>Scalability </li></ul><ul><ul><li>Server replication </li></ul></ul><ul><ul><li>Thin, heterogeneous clients </li></ul></ul><ul><li>Re-usability </li></ul><ul><li>Partitioned functionality = easy updating of either clients or servers </li></ul>
  8. 8. Competing Technologies for Distributed Objects <ul><li>Open standards based solutions </li></ul><ul><ul><li>Java, CORBA, EJB, RMI, IIOP, JTS/OTS, JNDI, JDBC,, Servlets, JSP, Java Security </li></ul></ul><ul><li>The All-Microsoft solution </li></ul><ul><ul><li>COM, COM+, ActiveX, Visual C++, MTS, ASP, IIS, etc. </li></ul></ul><ul><li>Other proprietary solutions </li></ul><ul><ul><li>Message oriented middleware (MOMs - MQSeries, etc.) </li></ul></ul><ul><ul><li>TP monitors </li></ul></ul>
  9. 9. TP Monitors, Web Front-Ends <ul><li>Quickly extends an existing application for access from the web </li></ul><ul><li>Client context maintained by server </li></ul><ul><li>Limited to single process, single machine </li></ul><ul><li>Not object oriented or truly distributed </li></ul><ul><li>Jolt server consumes an additional process </li></ul><ul><li>Jolt client classes must be either pre-installed or downloaded </li></ul>
  10. 10. COM/DCOM, COM+ <ul><li>Rich, well-integrated platform </li></ul><ul><li>Object-oriented </li></ul><ul><li>Web client access via: </li></ul><ul><ul><li>ActiveX controls & COM/DCOM </li></ul></ul><ul><ul><li>Active Server Pages, HTTP and IIS </li></ul></ul><ul><li>Distributed - as long as its Windows </li></ul><ul><li>NT only </li></ul><ul><li>Firewall issue </li></ul><ul><li>Limited flexibility </li></ul><ul><li>Security </li></ul>
  11. 11. CORBA vs. Ad-hoc Networked Applications <ul><li>Technical considerations: </li></ul><ul><li>CORBA/EJB implementations have integration with object databases, transaction services, security services, directory services, etc. </li></ul><ul><li>CORBA implementations automatically optimize transport and marshalling strategies </li></ul><ul><li>CORBA implementations automatically provide threading models </li></ul>
  12. 12. CORBA vs. Ad-hoc Networked Applications <ul><li>Business considerations: </li></ul><ul><li>Standards based </li></ul><ul><li>Multiple competing interoperable implementations </li></ul><ul><li>Buy vs. build tradeoffs </li></ul><ul><li>Resource availability </li></ul><ul><ul><li>software engineers </li></ul></ul><ul><ul><li>tools </li></ul></ul>
  13. 13. CORBA <ul><li>Product of consortium - Object Management Group (OMG) with more 800 members. </li></ul><ul><li>Accepted proposals for the various specifications put forth to define: </li></ul><ul><ul><li>Communications infrastructure </li></ul></ul><ul><ul><li>Standard interface between objects </li></ul></ul><ul><ul><li>Object services </li></ul></ul><ul><li>Developed the spec for the Common Object Request Broker Architecture (CORBA) </li></ul>
  14. 14. CORBA Design Goals <ul><li>Transparency: </li></ul><ul><ul><li>The programming language </li></ul></ul><ul><ul><li>The hardware platform </li></ul></ul><ul><ul><li>The operating system </li></ul></ul><ul><ul><li>The specific object request broker </li></ul></ul><ul><ul><li>The degree of object distribution </li></ul></ul><ul><li>Open Architecture: </li></ul><ul><ul><li>Language-neutral Interface Definition Language (IDL) </li></ul></ul><ul><ul><li>Language, platform and location transparent </li></ul></ul><ul><li>Objects could act as clients, servers or both </li></ul><ul><li>The Object Request Broker (ORB) handles interaction between client and object </li></ul>
  15. 15. CORBA Design Goals <ul><ul><li>Transparency: </li></ul></ul><ul><ul><ul><li>Language - can be used by any programming language for which there is an IDL mapping. </li></ul></ul></ul><ul><ul><ul><li>Hardware platform - independent of processor data type formats </li></ul></ul></ul><ul><ul><ul><li>Operating system - not embedded in O/S, does not rely any O/S specific APIs. </li></ul></ul></ul><ul><ul><ul><li>Object request broker - ORBs can be implemented by any vendor, ORBs should be able to interface to each other. Not tied to one vendor. </li></ul></ul></ul><ul><ul><ul><li>Degree of object distribution - all objects may be local or remote or any combination. May be provided by in-process server or process based server.or </li></ul></ul></ul><ul><ul><ul><li>Objects can act as clients, servers or both. </li></ul></ul></ul>
  16. 16. CORBA Objects <ul><li>OMG definition - encapsulated entity with an immutable distinct identity whose services are accessed only through well defined interfaces. </li></ul><ul><li>Binary components on various hosts that remote clients can access via method invocation. </li></ul><ul><li>How object implemented is completely transparent to client. </li></ul><ul><ul><li>O/S, language, compiler .. </li></ul></ul><ul><li>Client does not need to know where object is or which O/S it runs under. </li></ul><ul><li>Interface defined by IDL. </li></ul>
  17. 17. OMG Interface Definition Language <ul><li>Client must know interface offered by object before invoking an operation </li></ul><ul><li>Objects interface: </li></ul><ul><ul><li>operations </li></ul></ul><ul><ul><li>types of data that can be passed to/from operations </li></ul></ul><ul><li>Object interface defined using IDL. </li></ul>
  18. 18. Language Mappings <ul><li>Specifies how IDL translated into different programming languages. </li></ul><ul><li>Language support varies between suppliers of ORBs. </li></ul><ul><li>Example - C++ </li></ul><ul><ul><li>Interfaces mapped to classes </li></ul></ul><ul><ul><li>Operations mapped to member functions of classes </li></ul></ul><ul><ul><li>Object references map to the operator-> function </li></ul></ul>
  19. 19. A CORBA ORB (Client) Object Request Broker Core (IIOP) Interface Repository Protocol Stack Network ORB Interface Dynamic Invocation Client IDL Stubs Client
  20. 20. A CORBA ORB (Server) Implementation Repository ORB Interface Object Request Broker Core (IIOP) Dynamic Skeleton Invocation Server Protocol Stack Network Static Skeletons Object Adaptor
  21. 21. General Request Flow Client ORB Core Network Object Adaptor Server ORB Core Request ORB Interface Client IDL Stubs Client Static Skeletons Server
  22. 22. General Request Flow <ul><li>Client makes request and server receives and acts on it. </li></ul><ul><li>Flow: </li></ul><ul><ul><li>1. Client makes request using static stubs (IDL) or Dynamic Invocation Interface (DII) into ORB core linked to process. </li></ul></ul><ul><ul><li>2. Client ORB transmits request to ORB core linked with server. </li></ul></ul><ul><ul><li>3. Server ORB core dispatches request to object adapter (OA) that created target object. </li></ul></ul><ul><ul><li>4. OA dispatches request to servant (class instance in C++) that implements target object using static skeletons or Dynamic Skeleton Interface (DSI). </li></ul></ul><ul><ul><li>5. Servant returns response to client. </li></ul></ul>
  23. 23. Interface Repository <ul><li>Produced by IDL compiler. </li></ul><ul><li>Distributed database containing machine readable version of IDL defined interfaces. </li></ul><ul><li>Contains information describing: </li></ul><ul><ul><li>Operations supported by server </li></ul></ul><ul><ul><li>Parameters to operations </li></ul></ul><ul><li>Used for dynamic invocation of operations </li></ul><ul><li>Clients can query repository to find out how to invoke operation at run-time. </li></ul>
  24. 24. Implementation Repository <ul><li>Used client ORB to locate servers for requested class/operation. </li></ul><ul><li>Run-time repository </li></ul><ul><ul><li>classes supported by server </li></ul></ul><ul><ul><li>instantiated objects IDs </li></ul></ul>
  25. 25. Object Request Broker - ORB <ul><li>Transports a client request to a local or remote object and returns the result. Implemented as: </li></ul><ul><ul><li>a set of client and server side libraries </li></ul></ul><ul><ul><li>zero or more daemons in between, depending on ORB implementation </li></ul></ul><ul><li>ORB transparently activates objects that are not running. </li></ul><ul><li>Provides: </li></ul><ul><ul><li>Static method invocation - defined at compile-time </li></ul></ul><ul><ul><li>Dynamic method invocation - find objects at run-time </li></ul></ul>
  26. 26. Operation Invocation <ul><li>Static invocation: </li></ul><ul><ul><li>Client IDL stubs and server IDL skeletons created from IDL </li></ul></ul><ul><ul><li>Compiler knows at compile time name and parameters of operations - strong typing. </li></ul></ul><ul><li>Dynamic invocation: </li></ul><ul><ul><li>Operation invocation built at run-time. </li></ul></ul><ul><ul><li>No compile info - weak typing </li></ul></ul><ul><ul><li>Requires access to Interface Repository service to build request </li></ul></ul><ul><ul><ul><li>contains details of interfaces and types </li></ul></ul></ul><ul><ul><ul><li>generated from IDL </li></ul></ul></ul>
  27. 27. Object Adapter (OA) <ul><li>An abstract specification </li></ul><ul><ul><li>Part of the server-side library - the interface between the ORB and the server process </li></ul></ul><ul><ul><li>Once server registers with ORB, listens for client connections and requests </li></ul></ul><ul><ul><li>Maps the inbound requests to the desired target object instance - makes the operation call and handles return data </li></ul></ul><ul><li>Real OAs: </li></ul><ul><ul><li>Basic Object Adapter (BOA) </li></ul></ul><ul><ul><ul><li>requires proprietary extensions to be useful </li></ul></ul></ul><ul><ul><li>Portable Object Adapter (POA) </li></ul></ul><ul><ul><ul><li>Permits server-side ORB-neutral code </li></ul></ul></ul>
  28. 28. IIOP - Internet Inter-ORB Protocol <ul><li>General Inter-ORB Protocol (GIOP) </li></ul><ul><ul><li>Abstract protocol, specifies transfer syntax and message formats. </li></ul></ul><ul><li>IIOP - implementation of GIOP using TCP/IP </li></ul><ul><li>Developers don’t need to “learn” IIOP </li></ul><ul><ul><li>the ORB handles this for them </li></ul></ul><ul><li>Specifies common format for: </li></ul><ul><ul><li>object references, known as the Interoperable Object Reference (IOR) </li></ul></ul><ul><ul><li>Messages exchanged between a client and the object </li></ul></ul>
  29. 29. Request Invocation <ul><li>Clients manipulate objects by asking its ORB to send message to object via server ORB. </li></ul><ul><li>How does client uniquely identify object? </li></ul><ul><li>Client needs object reference before sending messages. </li></ul><ul><li>Object reference - handle that uniquely identifies target object. </li></ul>
  30. 30. Client Invokes Operation via Object Reference <ul><li>Client ORB: </li></ul><ul><ul><li>Locates target object </li></ul></ul><ul><ul><li>Activates server application if not running </li></ul></ul><ul><ul><li>Transmits arguments for call to object </li></ul></ul><ul><ul><li>Activates instance for object if necessary </li></ul></ul><ul><ul><ul><li>Instance could be generated by factory object if used. </li></ul></ul></ul><ul><ul><li>Waits for request to complete </li></ul></ul><ul><ul><li>Returns out and inout parameters and return value to client. </li></ul></ul><ul><ul><li>Returns an exception if call fails </li></ul></ul><ul><li>All this is transparent to client! </li></ul>
  31. 31. Request Invocation Characteristics <ul><li>Location transparency </li></ul><ul><ul><li>Client does not know or care whether target object is local to its own address space, in a different process on the same machine or in a process on a different machine. </li></ul></ul><ul><li>Server transparency </li></ul><ul><ul><li>Client does not need to know which server implements which objects. </li></ul></ul><ul><li>Language independence </li></ul><ul><ul><li>Implementation language for client and sever objects can be different. </li></ul></ul><ul><li>Implementation independence </li></ul><ul><ul><li>Client does not know how server implements object. </li></ul></ul><ul><li>Architecture independence </li></ul><ul><ul><li>CPU architecture hidden from client </li></ul></ul><ul><li>Operating system </li></ul><ul><ul><li>Server could be implemented under UNIX, NT or real-time OS. </li></ul></ul><ul><li>Protocol independence </li></ul><ul><ul><li>Client does not know how messages are sent to object. </li></ul></ul>
  32. 32. Object References <ul><li>Only way to access an object </li></ul><ul><li>Also called Interoperable Object Reference (IOR) </li></ul><ul><li>Distributed computing equivalent of a pointer </li></ul><ul><li>Analogous to C++ class instance pointers </li></ul><ul><ul><li>class name </li></ul></ul><ul><ul><li>{ </li></ul></ul><ul><ul><ul><li>void amethod(); </li></ul></ul></ul><ul><ul><ul><li>.... </li></ul></ul></ul><ul><ul><li>}; </li></ul></ul><ul><ul><li>name * pname = new name; </li></ul></ul><ul><ul><li>.... </li></ul></ul><ul><ul><li>pname->amethod(); </li></ul></ul><ul><li>Object References are opaque </li></ul><ul><ul><li>Implementation - not real pointers! </li></ul></ul>
  33. 33. <ul><li>Published by server somehow. </li></ul><ul><ul><li>Return a reference as result of invoking an operation </li></ul></ul><ul><ul><li>Advertise reference in well-known service </li></ul></ul><ul><ul><ul><li>Naming Service, Trader Service </li></ul></ul></ul><ul><ul><li>Convert object reference to string and write to file </li></ul></ul><ul><ul><li>Transmit object reference using out-of-band mechanism </li></ul></ul><ul><ul><ul><li>Email </li></ul></ul></ul><ul><ul><ul><li>Web page </li></ul></ul></ul><ul><li>Result of invoking an operation is the normal way. </li></ul><ul><li>Others used to get first object reference. </li></ul>Reference Acquisition
  34. 34. <ul><li>Repository ID - used to locate detailed description of interface in Interface Repository </li></ul><ul><li>Endpoint Info - info required to make physical connection to server, includes: </li></ul><ul><ul><li>protocol </li></ul></ul><ul><ul><li>address data - IP/port if IIOP is used (TCP) </li></ul></ul><ul><ul><ul><li>or </li></ul></ul></ul><ul><ul><li>address of implementation repository that contains location of server </li></ul></ul>Interoperable Object Reference (IOR) Repository ID Endpoint Info Object Key ••••
  35. 35. <ul><li>Object key - includes object identifier </li></ul><ul><ul><li>Used by server Orb/OA to identify target object in sever for each request </li></ul></ul><ul><ul><li>Server creates identifier when server creates object reference </li></ul></ul><ul><li>IORs can be converted from raw reference to string form, and back </li></ul><ul><li>Stringified IORs can be stored and retrieved by clients and servers using other ORBs </li></ul>Interoperable Object Reference (IOR) Repository ID Endpoint Info Object Key ••••
  36. 36. Interoperable Object Reference (IOR) <ul><li>A stringified IOR </li></ul><ul><li>IOR:010000000e00000049444c3a48656c6c6f3a312e3000000001000000000000003000000001010000100000003132382e3130302e3130302e313032008a040000100000000000000006a33c37c0aa080000000000 </li></ul>
  37. 37. Simple Example <ul><li>IDL </li></ul><ul><ul><li>interface Add </li></ul></ul><ul><ul><li>{ </li></ul></ul><ul><ul><li>short add(in short a, in short b); </li></ul></ul><ul><ul><li>}; </li></ul></ul><ul><li>Server implements operation add() </li></ul><ul><li>Client uses remote object to add two numbers </li></ul>
  38. 38. Simple Example - Server <ul><li>Create/initialise ORB and BOA </li></ul><ul><li>Create implementation object and tell ORB about it </li></ul><ul><li>Save object reference as string in file for client </li></ul><ul><li>Run implementation </li></ul>
  39. 39. Simple Example - Client <ul><li>Create/initialise ORB </li></ul><ul><li>Read in IOR from file for add object </li></ul><ul><li>Convert string version of IOR to object reference </li></ul><ul><ul><li>Read in two numbers </li></ul></ul><ul><ul><li>Invoke add operation on add object </li></ul></ul><ul><ul><li>Print result </li></ul></ul>
  40. 40. CORBA Services <ul><li>Collection of system-level services with IDL specified interfaces. </li></ul><ul><li>Provide functionality required by most distributed applications. </li></ul><ul><ul><li>Effectively augment functionality of ORB. </li></ul></ul><ul><li>Independent of application domain. </li></ul><ul><li>Designed according to principle: </li></ul><ul><ul><li>A service does only one thing but does it well! </li></ul></ul>
  41. 41. CORBA Services <ul><li>Naming Service </li></ul><ul><ul><li>Allows local or remote objects to be located by name. </li></ul></ul><ul><li>Event Service </li></ul><ul><ul><li>Allows objects to dynamically register/unregister their interest in specified events. Object will be notified when event occurs. </li></ul></ul><ul><li>Many more including: </li></ul><ul><ul><li>Trader, Life Cycle, Persistence, Transaction, Query, Security </li></ul></ul>
  42. 42. Naming Services <ul><li>Maps human readable names to object references. </li></ul><ul><ul><li>Given a name the service returns an object reference. </li></ul></ul><ul><ul><li>Object reference can be used to invoke operations on object. </li></ul></ul><ul><li>Objects referenced by compound name </li></ul><ul><ul><li>Sequence of names forming a hierarchical naming tree </li></ul></ul><ul><ul><li>Analogous to directory structure </li></ul></ul>
  43. 43. Naming Services context name simple name Humans Animals Canine Alsatian Students Animals Canine Alsatian Compound Name
  44. 44. Naming Services <ul><li>Advantage over stringified references: </li></ul><ul><ul><li>Client uses meaningful names instead of stringified object references. </li></ul></ul><ul><ul><li>Old version of object can be replaced by new version by updating Name Service entry IOR for object. </li></ul></ul><ul><ul><li>Solves problem of getting initial references to objects. </li></ul></ul>
  45. 45. Event Services <ul><li>Allows objects ( consumer) to dynamically register and unregister interest in events occurring in an object </li></ul><ul><li>Event - occurrence in an object ( supplier ) of interest to one or more objects </li></ul><ul><ul><li>signal a change of state of object, typically data </li></ul></ul><ul><li>Notification - message sent to notify event occurred </li></ul><ul><li>Two ways of handling events: </li></ul><ul><ul><li>Event channel - standard CORBA object </li></ul></ul><ul><ul><li>Point-to-point </li></ul></ul><ul><li>Two models - push and pull </li></ul>
  46. 46. Push Style Event Channel Consumer Supplier Consumer Push Push Object Request Broker Event : house is on fire Event channel handles pushes to consumers Oh the house is on fire
  47. 47. Pull Style Event Channel Consumer Supplier Consumer Pull Pull Object Request Broker Event: house is on fire <ul><li>Event channel handles pull from supplier. </li></ul><ul><li>Event manages suppliers & consumers. </li></ul>What is happening?
  48. 48. Point-to-Point Push Object Request Broker <ul><li>Disadvantage: </li></ul><ul><li>Supplier must keep track of all consumers. </li></ul><ul><li>Consumer must keep track of all supplier. </li></ul>Supplier Consumer

×