• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
EMOS - Lecture 8.ppt
 

EMOS - Lecture 8.ppt

on

  • 54,180 views

 

Statistics

Views

Total Views
54,180
Views on SlideShare
54,180
Embed Views
0

Actions

Likes
0
Downloads
10
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    EMOS - Lecture 8.ppt EMOS - Lecture 8.ppt Presentation Transcript

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