Distributed Object-Based Systems by dffhrtcv3


									Distributed Object-Based
        Chapter 9
Distributed Object-Based Systems
• Topics discussed in this chapter:
  – CORBA is an industry-defined standard for
    distributed systems.
  – Distributed COM can be viewed as a
    middleware layer implemented on top of various
    Windows operating systems.
  – Globe is a research project being developed as
    part of a research project on large-scale wide-area
    distributed systems.
  – Comparison of CORBA, DCOM, and Globe
            Overview of CORBA
• CORBA: Common Object Request Broker
• Background:
   – Developed by the Object Management Group (OMG) in
     response to industrial demands for object-based middleware
   – Currently in version #2.4 and #3
   – CORBA is a specification: different implementations of
     CORBA exist
   – Very much the work of a committee: there are over 800
     members of the OMG and many of them have a say in what
     CORBA should look like
• CORBA provides a simple distributed-object model,
  with specifications for many supporting services it
  may be here to stay (for a couple of years)
            Overview of CORBA
• Architecture of CORBA
  – The Object Request Broker (ORB) forms the core
    of any CORBA distributed system.
  – Horizontal facilities consist of general-purpose
    high-level services that are independent of
    application domains.
     •   User interface
     •   Information management
     •   System management
     •   Task management
  – Vertical facilities consist of high-level services
    that are targeted to a specific application domain
    such as electronic commerce, banking,
  Overview of CORBA

The global architecture of CORBA.
                Object Model
• CORBA has a traditional remote-object model
  in which an object residing at an object server
  is remote accessible through proxies
• All CORBA specifications are given by means
  of interface descriptions, expressed in an
  Interface Definition Language (IDL).
  – An interface is a collection of methods, and
    objects specify which interfaces they implement.
  – It provides a precise syntax for expressing methods
    and their parameters.
                   Object Model
• CORBA follows an interface-based approach to
   – Not the objects, but interfaces are the really important
   – An object may implement one or more interfaces
   – Interface descriptions can be stored in an interface
     repository, and looked up at runtime
   – Mappings from IDL to specific programming are part of the
     CORBA specification (languages include C, C++,
     Smalltalk, Cobol, Ada, and Java.
• In DCOM and Globe, interfaces can be specified at a
  lower level in the form of tables, called binary
                 Object Model
• Object Request Broker (ORB): CORBA's object
  broker that connects clients, objects, and services
• Proxy/Skeleton: Precompiled code that takes care of
  (un)marshaling invocations and results
• Dynamic Invocation/Skeleton Interface (DII/DSI):
  To allow clients to construct invocation requests at
  runtime instead of calling methods at a proxy, and
  having the server-side reconstruct those request into
  regular method invocations
• Object adapter: Server-side code that handles
  incoming invocation requests.
                Object Model
• Interface repository:
  – Database containing interface definitions and which
    can be queried at runtime
  – Whenever an interface definition is compiled, the
    IDL compiler assigns a repository identifier to
    that interface.
• Implementation repository:
  – Database containing the implementation (code, and
    possibly also state) of objects.
  – Given an object reference, an object adaptor could
    contact the implementation repository to find out
    exactly what needs to be done.
           Object Model

The general organization of a CORBA system.
                          Corba Services
       Service                                           Description
Collection        Facilities for grouping objects into lists, queue, sets, etc.
Query             Facilities for querying collections of objects in a declarative manner
Concurrency       Facilities to allow concurrent access to shared objects
Transaction       Flat and nested transactions on method calls over multiple objects
Event             Facilities for asynchronous communication through events
Notification      Advanced facilities for event-based asynchronous communication
Externalization   Facilities for marshaling and unmarshaling of objects
Life cycle        Facilities for creation, deletion, copying, and moving of objects
Licensing         Facilities for attaching a license to an object
Naming            Facilities for systemwide name of objects
Property          Facilities for associating (attribute, value) pairs with objects
Trading           Facilities to publish and find the services on object has to offer
Persistence       Facilities for persistently storing objects
Relationship      Facilities for expressing relationships between objects
Security          Mechanisms for secure channels, authorization, and auditing
Time              Provides the current time within specified error margins

                       Overview of CORBA services.
         Communication Models
• Object Invocation Models
  – Synchronous
  – One-way
  – Deferred synchronous
• Event and Notification Services
  – An event is produced by a supplier and received by a
    consumer. Events are delivered through an event channel.
  – Drawbacks of event services:
     • The event might be lost.
     • Consumers have no way to filter events.
  – Filtering capabilities have been added to the notification
          Object Invocation Models
Request type     Failure semantics              Description
Synchronous    At-most-once           Caller blocks until a response is
                                      returned or an exception is
One-way        Best effort delivery   Caller continues immediately
                                      without waiting for any response
                                      from the server
Deferred       At-most-once           Caller continues immediately
synchronous                           and can later block until
                                      response is delivered

          Invocation models supported in CORBA.
Event and Notification Services

The logical organization of suppliers and consumers
  of events, following the push-style model.
   Event and Notification Services

The pull-style model for event delivery in CORBA.
          Communication Models
• CORBA supports the message-queuing model through
  the messaging service.
   – In callback model, A client provides an object with an
     interface containing callback methods which can be called
     by the underlying communication system to pass the result
     of an asynchronous invocation.
   – In polling model, the client is offered a collection of
     operations to poll its ORB for incoming result.
• General Inter-ORB Protocol (GIOP) is a standard
  communication protocol between the client and server.
• Internet Inter-ORB Protocol (IIOP) is a GIOP on
  top of TCP

CORBA's callback model for asynchronous method invocation.

 CORBA'S polling model for
asynchronous method invocation.
  Message type     Originator                        Description
Request           Client        Contains an invocation request
Reply             Server        Contains the response to an invocation
LocateRequest     Client        Contains a request on the exact location of an object
LocateReply       Server        Contains location information on an object
CancelRequest     Client        Indicates client no longer expects a reply
CloseConnection   Both          Indication that connection will be closed
MessageError      Both          Contains information on an error
Fragment          Both          Part (fragment) of a larger message

                     GIOP message types.
• CORBA distinguishes two types of processes: clients
  and servers.
• An interceptor is a mechanism by which an
  invocation can be intercepted on its way from client to
  server, and adapted as necessary before letting it
   – It is designed to allow proxies to adapt the client-side
   – Request-level: Allows you to modify invocation semantics
     (e.g., multicasting)
   – Message-level: Allows you to control message-passing
     between client and server (e.g., handle reliability and

Logical placement of interceptors in CORBA.
          Portable Object Adaptor
• In CORBA, the Portable Object Adapter (POA) is a
  component that is responsible for making server-side
  code appear as CORBA objects to clients.
• A servant is that part of an object that implements the
  methods that clients can invoke.
• activate_object is a function used by a POA to build
  a CORBA object from a servant.
   – It takes a reference to a servant as input parameter and
     returns a CORBA object identifier as a result.
   – The object identifier is used as an index into the POA’s
     Active Object Map, which points to servants.
   – A CORBA object identifier is uniquely associated with a
          Portable Object Adaptor

Mapping of CORBA object identifiers to servants.
a) The POA supports multiple servants.
b) The POA supports a single servant (multiple instances of the
   same servant).
            Portable Object Adaptor

My_servant *my_object;           // Declare a reference to a C++ object
CORBA::Objectid_var oid;         // Declare a CORBA identifier
my_object = new MyServant;         // Create a new C++ object
oid = poa ->activate_object (my_object);
                                   // Register C++ object as CORBA OBJECT

       Changing a C++ object into a CORBA object.
             Agents in CORBA
• CORBA adopts a model in which agents from different
  kinds of systems can cooperate.
• An agent system is defined as platform as a platform
  that allows the creation, execution, transfer, and
  termination of agents.
• A place for an agent corresponds to a server where an
  agent resides.
• Agent systems can be grouped into a region which
  represents a administrative domain.
• An agent in CORBA is assumed to be constructed from
  a collection of classes.
• Each region will have an associated finder (directory
  service), which allows it to find the location of the

CORBA's overall model of agents, agent systems, and regions.
• In CORBA, it is essential to distinguish
  specification-level and implementation-level object
   – Specification level: An object reference is considered to be
     the same as a proxy for the referenced object.  Having an
     object reference means you can directly invoke methods.
     There is no separate client-to-object binding phase
   – Implementation level: When a client gets an object
     reference, the implementation ensures that, one way or the
     other, a proxy for the referenced object is placed in the
     client's address space.
• Conclusion: Object references in CORBA used to be
  highly implementation dependent. Different
  implementations of CORBA could normally not
  exchange their references.
   Interoperable Object References
• Recognizing that object references are implementation
  dependent, we need a separate referencing mechanism
  to cross ORB boundaries
• Solution: Object references passed from one ORB to
  another are transformed by the bridge through which
  they pass (different transformation schemes can be
• Passing an object reference A from ORB A to ORB B
  circumventing the A-to-B bridge may be useless if
  ORB B doesn't understand A.
• To allow all kinds of different systems to
  communicate, we standardize the reference which is
  called Interoperable Object Reference (IOR) and
  passed between two different ORBs.
              Object References

The organization of an IOR with specific information for IIOP.
   Interoperable Object References
• Each IOR comprise the following fields:
   – The repository identifier is assigned to an interface when
     that interface is stored in the interface repository.
   – The tagged profile contains the complete information to
     invoke an object.
• There are two possible IOR bindings:
   – An IOR directly referring to an object is referred to direct
   – The indirect binding request is sent to an implementation
     repository which acts as a registry. Indirect binding is used
     primarily for persistent objects.
 Object References

Indirect binding in CORBA.
              Naming Service
• CORBA offers a naming service that allows
  clients to look up object references using a
  character-based name. A name in CORBA is a
  sequence of name components with the form a
  (id, kind)-pair where id indicates its name and
  kind indicates its attribute.
• In most CORBA implementations, object
  references denote servers at specific hosts.
  Naming makes it easier to relocate objects
              Naming Service
• In the naming graph all nodes are objects.
  There are no restrictions to binding names to
  objects. CORBA allows arbitrary naming
• A naming context is an object that stores a
  table mapping name components to object
• There is no single root. An initial context node
  is returned through a special call to the ORB.
  the naming service can operate across different
  ORBs interoperable naming service.
• The two most important services that facilitate
  synchronization in CORBA are its concurrency
  control service and its transaction service.
• The two services collaborate to implement distributed
  and nested transactions using two-phase locking.
• There are two types of objects that can be part of
   – A recoverable object is an object that is executed by an
     object server capable of participating in a two-phase commit
   – The transactional objects are executed by servers that do
     not participate in a transaction’s two-phase commit
        Caching and Replication
• CORBA offers no support for generic caching and
• CASCADE is built to provide a generic, scalable
  mechanism that allows any kind of CORBA object to
  be cached.
• CASCADE offers a caching service implemented as a
  large collection of object servers referred to as a
  Domain Caching Server (DCS).
• Each DCS is an object server running on a CORBA
  ORB. The collection of DCSs may be spread across
  the Internet.
  Caching and Replication

The (simplified) organization of a DCS.
                Fault Tolerance
• In CORBA version 3, fault tolerance is addressed. The
  basic approach for fault tolerance is to replicate
  objects into object groups.
• Masking failures is achieved through replication by
  putting objects into object groups. Object groups are
  transparent to clients. They appear as normal objects.
• This approach requires a separate type of object
  reference: Interoperable Object Group Reference
• IOGRs have the same structure as IORs. The main
  difference is that they are used differently. In IORs an
  additional profile is used as an alternative. In IOGR, it
  denotes another replica.
            Object Groups

A possible organization of an IOGR for an object
       group having a primary and backups.
              Fault Tolerance
• To support object groups and to handle
  additional failure management in the Eteral
  system, it is necessary to add components to
  – A replication manager is responsible for creating
    and managing a group of replicated objects.
  – An interceptor intercepts and passes the invocation
    to a separate replicas.
• Invocation are subsequently sent to the other
  group members using reliable, totally-ordered
         An Example Architecture

An example architecture of a fault-tolerant CORBA system.
• The underlying idea is to allow the client and
  object to be mostly unaware of all the security
  policies, except perhaps at binding time. The
  ORB does the rest.
• Specific policies are passed to the ORB as
  (local) policy objects and are invoked when
  – Examples: Type of message protection, lists of
    trusted parties.
• A replaceable security service is a service
  which can be specified by means of standard
  interfaces that hide the implementation.

The general organization for secure object invocation in CORBA.
• Replaceable security service can be implemented in
  combination with two different interceptors:
   – The access control interceptor is a request-level
     interceptor that checks the access right associated with an
   – A secure invocation interceptor is a message-level
     interceptor takes care of implementing the message
• The secure invocation interceptor sets up a security
  context (security information) for the client.
• A security association will be established after the
  client is bound to the target object.
• The value object sets up the security association with
  a standardized interface.

The role of security interceptors in CORBA.
             Distributed COM
• DCOM: Distributed Component Object Model
  – Microsoft's solution to establishing inter-process
    communication, possibly across machine
  – Supports a primitive notion of distributed objects
  – Evolved from early Windows versions to current
    NT-based systems (including Windows 2000)
  – Comparable to CORBA's object request broker
            DCOM Overview
• Somewhat confused? DCOM is related to many
  things that have been introduced by Microsoft
  in the past couple of years:
• DCOM: Adds facilities to communicate across
  process and machine boundaries.
• SCM: Service Control Manager, responsible
  for activating objects (cf., to CORBA's
  implementation repository).
• Proxy marshaler: handles the way that object
  references are passed between different
          Overview of DCOM

The general organization of ActiveX, OLE, and COM.
              COM Object Model
• An interface is a collection of semantically related
• Each interface is typed, and therefore has a globally
  unique interface identifier
• A client always requests an implementation of an
   – Locate a class that implements the interface
   – Instantiate that class, i.e., create an object
   – Throw the object away when the client is done
• Note: COM+ is effectively COM plus services that were
  previously available in an ad-hoc fashion
                  Object Model

The difference between language-defined and binary interfaces.
Tape Library and Registry

The overall architecture of DCOM.
                       DCOM Services
 CORBA Service           DCOM/COM+ Service                  Windows 2000 Service
Collection        ActiveX Data Objects              -
Query             None                              -
Concurrency       Thread concurrency                -
Transaction       COM+ Automatic Transactions       Distributed Transaction Coordinator
Event             COM+ Events                       -
Notification      COM+ Events                       -
Externalization   Marshaling utilities              -
Life cycle        Class factories, JIT activation   -
Licensing         Special class factories           -
Naming            Monikers                          Active Directory
Property          None                              Active Directory
Trading           None                              Active Directory
Persistence       Structured storage                Database access
Relationship      None                              Database access
Security          Authorization                     SSL, Kerberos
Time              None                              None

Overview of DCOM services in comparison to CORBA services.
          Communication Models
• Object invocations: Synchronous remote-method calls with
  at-most-once semantics. Asynchronous invocations are
  supported through a polling model, as in CORBA.
• Event communication: Similar to CORBA's push-style model:
• Messaging: Completely analogous to CORBA messaging.
• Observation: Objects are referenced by means of a local
  interface pointer. The question is how such pointers can be
  passed between different machines:
• Question: Where does the proxy marshaler come from? Do we
  always need it?

Event processing in DCOM.

Passing an object reference in DCOM with custom marshaling.
                Naming: Monikers
• Observation: DCOM can handle only objects as tem- porary
  instances of a class. To accommodate objects that can outlive
  their client, something else is needed.
• Moniker: A hack to support real objects
   – A moniker associates data (e.g., a file), with an application
      or program
   – Monikers can be stored
   – A moniker can contain a binding protocol, specifying how
      the associated program should be ``launched'' with respect
      to the data.
       Step      Performer                      Description

   1          Client         Calls BindMoniker at moniker
                             Looks up associated CLSID and instructs SCM
   2          Moniker
                             to create object
   3          SCM            Loads class object
                             Creates object and returns interface pointer to
   4          Class object
   5          Moniker        Instructs object to load previously stored state

   6          Object         Loads its state from file

   7          Moniker        Returns interface pointer of object to client

Binding to a DCOM object by means of file moniker.
   Moniker type                           Description
File moniker          Reference to an object constructed from a file
URL moniker           Reference to an object constructed from a URL
Class moniker         Reference to a class object
Composite moniker     Reference to a composition of monikers
Item moniker          Reference to a moniker in a composition
Pointer moniker       Reference to an object in a remote process

                  DCOM-defined moniker types.
             Active Directory
• Essence: a worldwide distributed directory
  service, but one that does not provide location
• Basics: Associate a directory service (called
  domain controller) with each domain; look up
  the controller using a normal DNS query:
• Note: Controller is implemented as an LDAP
           Active Directory

The general organization of Active Directory.
              Fault Tolerance
• Automatic transactions: Each class object
  (from which objects are created), has a
  transaction attribute that determines how its
  objects behave as part of a transaction:
• Note: Transactions are essentially executed at
  the level of a method invocation.
                    Fault Tolerance

  Attribute value                           Description
REQUIRES_NEW        A new transaction is always started at each invocation
REQUIRED            A new transaction is started if not already done so
SUPPORTED           Join a transaction only if caller is already part of one
NOT_SUPPORTED       Never join a transaction
DISABLED            Never join a transaction, even if told to do so

  Transaction attribute values for DCOM objects.
• Declarative security: Register per object what
  the system should enforce with respect to
  authentication. Authentication is associated
  with users and user groups. There are different
  authentication levels:
• Delegation: A server can impersonate a client
  depending on a level:
• Note: There is also support for programmatic
  security by which security levels can be set by
  an application, as well as the required security
  services (see book).
               Declarative Security

Authentication level                        Description
NONE                   No authentication is required
CONNECT                Authenticate client when first connected to server
CALL                   Authenticate client at each invocation
PACKET                 Authenticate all data packets
PACKET_INTEGRITY Authenticate data packets and do integrity check
PACKET_PRIVACY         Authenticate, integrity-check, and encrypt data packets

           Authentication levels in DCOM.
               Declarative Security

 Impersonation level                           Description

ANONYMOUS              The client is completely anonymous to the server
                       The server knows the client and can do access control
IMPERSONATE            The server can invoke local objects on behalf of the client

DELEGATE               The server can invoke remote objects on behalf of the client

               Impersonation levels in DCOM.
                 Programmatic Security
       Service                                      Description
NONE               No authentication
DCE_PRIVATE        DCE authentication based on shared keys
DCE_PUBLIC         DEC authentication based on public keys
WINNT              Windows NT security
GSS_KERBEROS       Kerberos authentication
       Service                                      Description
NONE               No authorization
NAME               Authorization based on the client's identity
DCE                Authorization using DEC Privilege Attribute Certificates (PACs)

  a)      Default authentication services supported in DCOM.
  b)      Default authorization services supported in DCOM.
• Experimental wide-area system currently being
  developed at Vrije Universiteit

• Unique for its focus on scalability by means of
  truly distributed objects

• Prototype version up and running across
  multiple machines distributed in NL and across
  Europe and the US.
                  Object Model
• Essence: A Globe object is a physically distributed
  shared object: the object's state may be physically
  distributed across several machines
• Local object: A nondistributed object residing a single
  address space, often representing a distributed shared
• Contact point: A point where clients can contact the
  distributed object; each contact point is described
  through a contact address
• Observation: Globe attempts to separate functionality
  from distribution by distinguishing different local
            Globe Object Model

The organization of a Globe distributed shared object.
           Globe - Object Model
• Semantics subobject: Contains the methods that
  implement the functionality of the distributed shared
• Communication subobject: Provides a (relatively
  simple), network-independent interface for
  communication between local objects
• Replication subobject: Contains the implementation of
  an object-specific consistency protocol that controls
  exactly when a method on the semantics subobject
  may be invoked
• Control subobject: Connects the user-defined
  interfaces of the semantics subobject to the generic,
  predefined interfaces of the replication subobject
Globe Object Model

           The general organization
             of a local object for
             distributed shared
             objects in Globe.
                Globe Object Model
                          Document Interface

          Method                             Description

AddElement          Add an element to the current set of elements

DeleteElement       Remove an element from the Web document

AllElements         Return a list of the elements currently in the document

SetRoot             Set the root element

GetRoot             Return a reference to the root element

                           Content Interface
          Method                             Description

GetCotent           Return the content of an element as an array of bytes

PutContent          Replace the content of an element with a given array of bytes

PutAllContent       Replace the content of an entire document

    Interfaces implemented by the semantics subobject of
       a GlobeDoc object.
                Globe Object Model
                                Property Interface

        Method                                     Description

GetProperties            Return the list of (attribute, value)-pairs of an element

SetProperties            Provide a list of (attribute, value)-pairs for an element

                                  Lock Interface
        Method                                     Description

CheckOutElements         Check out a series of elements that require modification

CheckInElements          Check in a series of modified elements

GetCheckedElements       Get a list of elements that are currently checked out

                Interfaces implemented by the semantics
                      subobject of a GlobeDoc Object.
 Process-to-Object Binding

Binding a process to an object in Globe.
                             Globe Services
     Service                        Possible Implementation in Globe                      Available
Collection           Separate object that holds references to other objects               No
Concurrency          Each object implements its own concurrency control strategy          No
Transaction          Separate object representing a transaction manager                   No
Event/Notification   Separate object per group of events (as in DCOM)                     No
Externalization      Each object implements its own marshaling routines                   Yes
Life cycle           Separate class objects combined with per-object implementations      Yes
Licensing            Implemented by each object separately                                No
Naming               Separate service, implemented by a collection of naming objects      Yes
Property/Trading     Separate service, implemented by a collection of directory objects   No
Persistence          Implemented on a per-object basis                                    Yes
Security             Implemented per object, combined with (local) security services      Yes
Replication          Implemented on a per-object basis                                    Yes
Fault tolerance      Implemented per object combined with fault-tolerant services         Yes

               Overview of possible Globe implementations of typical
                             distributes-systems services.

Invoking an object in Globe that uses active replication.
                            Globe Server
          Method                                   Description
Bind                   Lets the server bind to a given object, unless it is already bound
AddBinding             Lets the server bind to an object, even if it is already bound
CreateLR               Lets the server create a local object for a new distributed object
RemoveLR               Lets the server remove a local object of a given object
UnbindDSO              Lets the server remove all local objects of a given object
ListAll                Returns a list of all local objects
ListDSO                Returns a list of all local objects for a given objects
StatLR                 Get the status of a specific local object

                   Operations on a Globe object server.
              Object References
• Observation: Globe's contact addresses correspond to
  CORBA's object references
• Essence: Globe uses location-independent object
  handles which are to be resolved to contact addresses
  (which describes where and how an object can be
• Associated with a contact point of the distributed
• Specifies (for example) a transport-level network
  address to which the object will listen
• Contains an implementation handle, specifying
  exactly what the client should implement if it wants to
  communicate through the contact point.
Object References and Contact Addresses (1)

             Field                         Description
 Protocol identifier       A constant representing a (known) protocol
 Protocol address          A protocol-specific address
 Implementation handle     Reference to a file in a class repository

The representation of a protocol layer in a stacked contact address.
Object References and Contact Addresses (2)

            Field                            Description
Implementation handle   Reference to a file in a class repository
Initialization string   String that is used to initialize an implementation

      The representation of an instance contact address.
                Naming Objects
• Observation: Objects in Globe have their own object-
  specific implementations; there is no ``standard'' proxy
  that is implemented for all clients
• Observation: Globe separates naming from locating
  objects (as described in Chapter 04). The current
  naming service is based on DNS, using TXT records
  for storing object handles
• Observation: The location service is implemented as a
  generic, hierarchical tree, similar to the approach
  explained in Chapter 04.
     Globe Naming Service

Iterative DNS-based name resolution in Globe.
        Caching and Replication
• Observation: Here's where Globe differs from
  many other systems:
  – The organization of a local object is such that
    replication is inherently part of each distributed
    shared object
  – All replication subobjects have the same interface:
  – This approach allows to implement any
    object-specific caching/replication strategy
                       Replication (1)

  Method                                Description
Start        Indicate that a new method invocation has been locally requested
Send         Pass the marshaled invocation request to the replication subobject
Invoked      Indicate that the invocation on the semantics object has completed

          The interface of the replication subobject as
            made available to the control subobject.
      Replication (2)

  The behavior of the control
subobject as a finite state machine.
Examples of Replication in Globe (1)
                                   Read method
    State                  Action to take         Method call    Next state
 START          None                              Start         INVOKE
 INVOKE         Invoke local method               Invoked       RETURN
 RETURN         Return results to caller          None          START

                                  Modify method
    State                  Action to take         Method call    Next state
 START          None                              Start         SEND
 SEND           Pass marshaled invocations        Send          INVOKE
 INVOKE         invoke local method               Invoked       RETURN
 RETURN         Return results to caller          None          START

          State transitions and actions for active replication.
Examples of Replication in Globe (2)
                                         Read method
     State                      Action to take              Method call      Next state
 START            None                                     Start            INVOKE
 INVOKE           Invoke local method                      Invoked          RETURN
 RETURN           Return results to caller                 None             START

                              Modify method at backup replica
     State                       Action to take               Method call    Next state
 START            None                                       Start          SEND
 SEND             Pass marshaled invocation                  Send           RETURN
 RETURN           Return results to caller                   None           START

                              Modify method at primary replica
     State                       Action to take               Method call    Next state
 START            none                                       Start          INVOKE
 INVOKE           invoke local method                        Invoked        RETURN
 RETURN           Return results to caller                   None           START

         State transitions and actions with primary-backup replication.
• Essence: Additional security subobject checks for
  authorized communication, invocation, and parameter
  values. Globe can be integrated with existing security
                    Security (1)

The position of a security subobject in a Globe local object.
                    Security (2)

Using Kerberos to establish
  secure distributed shared
             Issue                 CORBA              DCOM                   Globe
Design goals           Interoperability    Functionality       Scalability
Object model           Remote objects      Remote objects      Distributed objects
Services               Many of its own     From environment    Few
Interfaces             IDL based           Binary              Binary
Sync. communication    Yes                 Yes                 Yes
Async. communication   Yes                 Yes                 No
Callbacks              Yes                 Yes                 No
Events                 Yes                 Yes                 No
Messaging              Yes                 Yes                 No
Object server          Flexible (POA)      Hard-coded          Object dependent
Directory service      Yes                 Yes                 No
Trading service        yes                 No                  No

                                                              Continued …

                Comparison of CORBA, DCOM, and Globe.
           Issue                CORBA                 DCOM                  Globe
Naming service        Yes                  Yes                  Yes
Location service      No                   No                   Yes
Object reference      Object's location    Interface pointer    True identifier
Synchronization       Transactions         Transactions         Only intra-object
Replication support   Separate server      None                 Separate subobject
Transactions          Yes                  Yes                  No
Fault tolerance       By replication       By transactions      By replication
Recovery support      Yes                  By transactions      No
Security              Various mechanisms   Various mechanisms   More work needed

               Comparison of CORBA, DCOM, and Globe.

To top