1. Distributed Object-Based Systems Chapter 9

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

3. Overview of CORBA CORBA: Common Object Request Broker Architecture 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)

4. 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, manufacturing.

5. Overview of CORBA The global architecture of CORBA.

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

7. Object Model CORBA follows an interface­based approach to objects: –Not the objects, but interfaces are the really important entities –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 interfaces.

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

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

10. Object Model The general organization of a CORBA system.

11. Corba Services Overview of CORBA services. ServiceDescription CollectionFacilities for grouping objects into lists, queue, sets, etc. QueryFacilities for querying collections of objects in a declarative manner ConcurrencyFacilities to allow concurrent access to shared objects TransactionFlat and nested transactions on method calls over multiple objects EventFacilities for asynchronous communication through events NotificationAdvanced facilities for event-based asynchronous communication ExternalizationFacilities for marshaling and unmarshaling of objects Life cycleFacilities for creation, deletion, copying, and moving of objects LicensingFacilities for attaching a license to an object NamingFacilities for systemwide name of objects PropertyFacilities for associating (attribute, value) pairs with objects TradingFacilities to publish and find the services on object has to offer PersistenceFacilities for persistently storing objects RelationshipFacilities for expressing relationships between objects SecurityMechanisms for secure channels, authorization, and auditing TimeProvides the current time within specified error margins

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

13. Object Invocation Models Invocation models supported in CORBA. Request typeFailure semanticsDescription SynchronousAt-most-onceCaller blocks until a response is returned or an exception is raised One-wayBest effort deliveryCaller continues immediately without waiting for any response from the server Deferred synchronous At-most-onceCaller continues immediately and can later block until response is delivered

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

15. Event and Notification Services The pull-style model for event delivery in CORBA.

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

17. Messaging CORBA's callback model for asynchronous method invocation.

18. Messaging CORBA'S polling model for asynchronous method invocation.

19. Interoperability GIOP message types. Message typeOriginatorDescription RequestClientContains an invocation request ReplyServerContains the response to an invocation LocateRequestClientContains a request on the exact location of an object LocateReplyServerContains location information on an object CancelRequestClientIndicates client no longer expects a reply CloseConnectionBothIndication that connection will be closed MessageErrorBothContains information on an error FragmentBothPart (fragment) of a larger message

20. Processes 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 continue. – It is designed to allow proxies to adapt the client-side software. –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 fragmentation)

21. Clients Logical placement of interceptors in CORBA.

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

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

24. Portable Object Adaptor Changing a C++ object into a CORBA object. 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

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

26. Agents CORBA's overall model of agents, agent systems, and regions.

27. Naming In CORBA, it is essential to distinguish specification­ level and implementation­level object references –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.

28. 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 implemented). 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.

29. Object References The organization of an IOR with specific information for IIOP.

30. 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 binding. –The indirect binding request is sent to an implementation repository which acts as a registry. Indirect binding is used primarily for persistent objects.

31. Object References Indirect binding in CORBA.

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

33. Naming Service In the naming graph all nodes are objects. There are no restrictions to binding names to objects. CORBA allows arbitrary naming graphs A naming context is an object that stores a table mapping name components to object references. 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.

34. Synchronization 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 transaction: –A recoverable object is an object that is executed by an object server capable of participating in a two-phase commit protocol. –The transactional objects are executed by servers that do not participate in a transaction’s two-phase commit protocol.

35. Caching and Replication CORBA offers no support for generic caching and replication. 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.

36. Caching and Replication The (simplified) organization of a DCS.

37. 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 (IOGR). 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.

38. Object Groups A possible organization of an IOGR for an object group having a primary and backups.

39. Fault Tolerance To support object groups and to handle additional failure management in the Eteral system, it is necessary to add components to CORBA: –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 multicasting.

40. An Example Architecture An example architecture of a fault-tolerant CORBA system.

41. Security 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 necessary. –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.

42. Security The general organization for secure object invocation in CORBA.

43. Security 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 invocation. –A secure invocation interceptor is a message-level interceptor takes care of implementing the message protection. 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.

44. Security The role of security interceptors in CORBA.

45. COM: Component Object Model Technologies Microsoft COM (Component Object Model) technology in the Microsoft Windows-family of Operating Systems enables software components to communicate. COM is used by developers to create re-usable software components, link components together to build applications, and take advantage of Windows services. The family of COM technologies includes COM+, Distributed COM (DCOM) and ActiveX® Controls. For new development, Microsoft recommends.NET as a preferred technology because of its powerful managed runtime environment and services.

46. How are COM and.NET related? COM and.NET are complimentary development technologies. COM and.NET applications and components can use functionality from each system. This protects your existing investments in COM applications while allowing you to take advantage of.NET at a controlled pace. COM and.NET can achieve similar results. The.NET Framework provides developers with a significant number of benefits including a more robust, evidence- based security model, automatic memory management and native Web services support.

47. What is COM+? COM+ is the name of the COM-based services and technologies first released in Windows 2000. –COM+ brought together the technology of COM components and the application host of Microsoft Transaction Server (MTS). COM+ automatically handles difficult programming tasks such as resource pooling, disconnected applications, event publication and subscription and distributed transactions. COM+ infrastructure also provides services to.NET developers and applications through the System.EnterpriseServices namespace of the.NET Framework.

48. Distributed COM DCOM: Distributed Component Object Model –Microsoft's solution to establishing inter­process communication, possibly across machine boundaries. –DCOM uses the RPC mechanism to transparently send and receive information between COM components (i.e., clients and servers) on the same network. –Supports a primitive notion of distributed objects –Evolved from early Windows versions to current NT­ based systems (including Windows 2000/XP) –Comparable to CORBA's object request broker (Microsoft’s CORBA).

49. DCOM Overview 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 machines.

50. Overview of DCOM The general organization of ActiveX, OLE, and COM.

51. COM Object Model An interface is a collection of semantically related operations Each interface is typed, and therefore has a globally unique interface identifier A client always requests an implementation of an interface: –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

52. Object Model The difference between language-defined and binary interfaces.

53. Tape Library and Registry The overall architecture of DCOM.

54. DCOM Services Overview of DCOM services in comparison to CORBA services. CORBA ServiceDCOM/COM+ ServiceWindows 2000 Service CollectionActiveX Data Objects- QueryNone- ConcurrencyThread concurrency- TransactionCOM+ Automatic TransactionsDistributed Transaction Coordinator EventCOM+ Events- NotificationCOM+ Events- ExternalizationMarshaling utilities- Life cycleClass factories, JIT activation- LicensingSpecial class factories- NamingMonikersActive Directory PropertyNoneActive Directory TradingNoneActive Directory PersistenceStructured storageDatabase access RelationshipNoneDatabase access SecurityAuthorizationSSL, Kerberos TimeNone

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

56. Events Event processing in DCOM.

57. Clients Passing an object reference in DCOM with custom marshaling.

58. Naming: Monikers Observation: DCOM can handle only objects as temporary instances of a class. To accommodate objects that can outlive their client, something else is needed. Moniker: A name that uniquely identifies a Microsoft's COM (persistent) object similar to a directory path name. –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.

59. Monikers Binding to a DCOM object by means of file moniker. StepPerformerDescription 1ClientCalls BindMoniker at moniker 2Moniker Looks up associated CLSID and instructs SCM to create object 3SCMLoads class object 4Class object Creates object and returns interface pointer to moniker 5MonikerInstructs object to load previously stored state 6ObjectLoads its state from file 7MonikerReturns interface pointer of object to client

60. Monikers DCOM-defined moniker types. Moniker typeDescription File monikerReference to an object constructed from a file URL monikerReference to an object constructed from a URL Class monikerReference to a class object Composite monikerReference to a composition of monikers Item monikerReference to a moniker in a composition Pointer monikerReference to an object in a remote process

61. Active Directory Essence: Active Directory is a hierarchical collection of network resources that can contain users, computers, printers, and other Active Directories. 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 server.

62. Active Directory The general organization of Active Directory.

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

64. Fault Tolerance Transaction attribute values for DCOM objects. Attribute valueDescription REQUIRES_NEWA new transaction is always started at each invocation REQUIREDA new transaction is started if not already done so SUPPORTEDJoin a transaction only if caller is already part of one NOT_SUPPORTEDNever join a transaction DISABLEDNever join a transaction, even if told to do so

65. Security 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).

66. Declarative Security Authentication levels in DCOM. Authentication levelDescription NONENo authentication is required CONNECTAuthenticate client when first connected to server CALLAuthenticate client at each invocation PACKETAuthenticate all data packets PACKET_INTEGRITYAuthenticate data packets and do integrity check PACKET_PRIVACYAuthenticate, integrity-check, and encrypt data packets

67. Declarative Security Impersonation levels in DCOM. Impersonation levelDescription ANONYMOUSThe client is completely anonymous to the server IDENTIFY The server knows the client and can do access control checks IMPERSONATEThe server can invoke local objects on behalf of the client DELEGATEThe server can invoke remote objects on behalf of the client

68. Programmatic Security a)Default authentication services supported in DCOM. b)Default authorization services supported in DCOM. ServiceDescription NONENo authentication DCE_PRIVATEDCE authentication based on shared keys DCE_PUBLICDEC authentication based on public keys WINNTWindows NT security GSS_KERBEROSKerberos authentication (a) ServiceDescription NONENo authorization NAMEAuthorization based on the client's identity DCEAuthorization using DEC Privilege Attribute Certificates (PACs) (b)

69. Introducing the Microsoft.NET.NET (dot-net) is the name Microsoft gives to its general vision of the future of computing, the view being of a world in which many applications run in a distributed manner across the Internet. We can identify a number of different motivations driving this vision. –Object-oriented programming –Compiled once and run everywhere. –Service-oriented application.NET is Microsoft JVM?.NET has been built upon open standard technologies like XML and SOAP and is towards more open standards rather than Microsoft its proprietary tendencies.

70. Introducing the Microsoft.NET.NET Infrastructure –.NET Framework: The.NET framework is a programming environment –Web Services:.NET provides a standard syntax for input and output language that is defined for sites providing 'web services'. –.NET Servers: Severs that work with.NET such as SQL Server 2000 is described as '.NET enabled'..NET implementation –Windows: Microsoft.NET –Linux: Mono, DotGNU

71. Introducing the Microsoft.NET Framework At the development end of the.NET vision is the.NET Framework (Microsoft JDK?) that contains: –The Common Language Runtime, –The.NET Framework Classes, and –higher-level features like ASP.NET and WinForms for developing desktop applications. The Common Language Runtime (CLR) (Microsoft JRE?) manages the execution of code compiled for the.NET platform. The CLR has two features: –Its specification has been opened up so that it can be ported to non-Windows platforms. –Any number of different languages can be used to manipulate the.NET framework classes, and the CLR will support them.

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

73. 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 object 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 subobjects:

74. Globe Object Model The organization of a Globe distributed shared object.

75. Globe - Object Model Semantics subobject: Contains the methods that implement the functionality of the distributed shared object 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

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

77. Globe Object Model Interfaces implemented by the semantics subobject of a GlobeDoc object. Document Interface MethodDescription AddElementAdd an element to the current set of elements DeleteElementRemove an element from the Web document AllElementsReturn a list of the elements currently in the document SetRootSet the root element GetRootReturn a reference to the root element Content Interface MethodDescription GetCotentReturn the content of an element as an array of bytes PutContentReplace the content of an element with a given array of bytes PutAllContentReplace the content of an entire document

78. Globe Object Model Interfaces implemented by the semantics subobject of a GlobeDoc Object. Property Interface MethodDescription GetPropertiesReturn the list of (attribute, value)-pairs of an element SetPropertiesProvide a list of (attribute, value)-pairs for an element Lock Interface MethodDescription CheckOutElementsCheck out a series of elements that require modification CheckInElementsCheck in a series of modified elements GetCheckedElementsGet a list of elements that are currently checked out

79. Process-to-Object Binding Binding a process to an object in Globe.

80. Globe Services Overview of possible Globe implementations of typical distributes-systems services. ServicePossible Implementation in GlobeAvailable CollectionSeparate object that holds references to other objectsNo ConcurrencyEach object implements its own concurrency control strategyNo TransactionSeparate object representing a transaction managerNo Event/NotificationSeparate object per group of events (as in DCOM)No ExternalizationEach object implements its own marshaling routinesYes Life cycleSeparate class objects combined with per-object implementationsYes LicensingImplemented by each object separatelyNo NamingSeparate service, implemented by a collection of naming objectsYes Property/TradingSeparate service, implemented by a collection of directory objectsNo PersistenceImplemented on a per-object basisYes SecurityImplemented per object, combined with (local) security servicesYes ReplicationImplemented on a per-object basisYes Fault toleranceImplemented per object combined with fault-tolerant servicesYes

81. Communication Invoking an object in Globe that uses active replication.

82. Globe Server Operations on a Globe object server. MethodDescription BindLets the server bind to a given object, unless it is already bound AddBindingLets the server bind to an object, even if it is already bound CreateLRLets the server create a local object for a new distributed object RemoveLRLets the server remove a local object of a given object UnbindDSOLets the server remove all local objects of a given object ListAllReturns a list of all local objects ListDSOReturns a list of all local objects for a given objects StatLRGet the status of a specific local object

83. 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 contacted). Associated with a contact point of the distributed object. 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.

84. Object References and Contact Addresses (1) The representation of a protocol layer in a stacked contact address. FieldDescription Protocol identifierA constant representing a (known) protocol Protocol addressA protocol-specific address Implementation handleReference to a file in a class repository

85. Object References and Contact Addresses (2) The representation of an instance contact address. FieldDescription Implementation handleReference to a file in a class repository Initialization stringString that is used to initialize an implementation

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

87. Globe Naming Service Iterative DNS-based name resolution in Globe.

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

89. Replication (1) The interface of the replication subobject as made available to the control subobject. MethodDescription StartIndicate that a new method invocation has been locally requested SendPass the marshaled invocation request to the replication subobject InvokedIndicate that the invocation on the semantics object has completed

90. Replication (2) The behavior of the control subobject as a finite state machine.

91. Examples of Replication in Globe (1) State transitions and actions for active replication. Read method StateAction to takeMethod callNext state STARTNoneStartINVOKE Invoke local methodInvokedRETURN Return results to callerNoneSTART Modify method StateAction to takeMethod callNext state STARTNoneStartSEND Pass marshaled invocationsSendINVOKE invoke local methodInvokedRETURN Return results to callerNoneSTART

92. Examples of Replication in Globe (2) State transitions and actions with primary-backup replication. Read method StateAction to takeMethod callNext state STARTNoneStartINVOKE Invoke local methodInvokedRETURN Return results to callerNoneSTART Modify method at backup replica StateAction to takeMethod callNext state STARTNoneStartSEND Pass marshaled invocationSendRETURN Return results to callerNoneSTART Modify method at primary replica StateAction to takeMethod callNext state STARTnoneStartINVOKE invoke local methodInvokedRETURN Return results to callerNoneSTART

93. Security Essence: Additional security subobject checks for authorized communication, invocation, and parameter values. Globe can be integrated with existing security services:

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

95. Security (2) Using Kerberos to establish secure distributed shared objects.

96. Comparison Comparison of CORBA, DCOM, and Globe. IssueCORBADCOMGlobe Design goalsInteroperabilityFunctionalityScalability Object modelRemote objects Distributed objects ServicesMany of its ownFrom environmentFew InterfacesIDL basedBinary Sync. communicationYes Async. communicationYes No CallbacksYes No EventsYes No MessagingYes No Object serverFlexible (POA)Hard-codedObject dependent Directory serviceYes No Trading serviceyesNo Continued …

97. Comparison Comparison of CORBA, DCOM, and Globe. IssueCORBADCOMGlobe Naming serviceYes Location serviceNo Yes Object referenceObject's locationInterface pointerTrue identifier SynchronizationTransactions Only intra-object Replication supportSeparate serverNoneSeparate subobject TransactionsYes No Fault toleranceBy replicationBy transactionsBy replication Recovery supportYesBy transactionsNo SecurityVarious mechanisms More work needed