GLOBE DISTRIBUTED SHARED OBJECT

INTRODUCTION

Globe stands for GLobal Object Based Environment.

Globe is different from CORBA and DCOM that it supports a huge number of users across the Internet and still provides distribution transparency.

The most important design goal of Globe is scalability.

Each object is in full control of its distribution strategies across its own replicas.

Hence, such a middleware platform of distributed shared objects is best suited for large scale applications of the future.

ARCHITECTURE

A local object consists of at least four subobjects:

Semantics subobject. This is a local subobject that implements the

actual semantics of the distributed object. For example: GlobeDoc.

Communication subobject. It is responsible for handling communication

between parts of the distributed object that reside in different address spaces.

It may offer messaging passing primitives for connection oriented and connectionless communication, multicast facilities.

Replication subobject. It implements the actual distribution strategy for

an object. The replication subobject has a standard

interface.

Control subobject. It bridges the gap between the user defined

interfaces of the semantics subobject, and the standard interfaces of the replication subobject.

It takes care of method invocations from client processes.

PROCESS TO OBJECT BINDING

The procedure takes place as follows:

1. To bind to an object, a process must pass the name of that object to a naming service.

2. The naming service returns an object handle which is globally unique and location independent. It can be used as a systemwide object reference.

3. The object handle is given to location service which returns a set of contact addresses for a single object.

4. The protocol information is used to load and instantiate classes from a (trusted) class repository.

5. The local object is initialized and through this local object, other local objects are contacted that form a part of the DSO.

COMMUNICATION To communicate, both parties first bind to some

common DSO, and then perform operations on it.

The user just invokes a method on a local object and the object itself manages the replication transparently.

When an invocation completes, no more activity will take place in the DSO, except the activity caused by other invocations.

Hence, Globe objects are said to be passive.

NAMING

The naming service in Globe is based on DNS. To make use of DNS, a Globe name is first

transformed into a DNS name. For example: we transform a name such as

globe://nl/vu/cs/object/foo into foo.object.cs.vu.nl. which is then passed to the local DNS name resolver. The resolution eventually reaches a Globe name server that can handle that part of a name that has not yet been resolved.

LOCATION

The location service stores every DSO’s contact addresses and maintains a mapping of every object handle to a set of contact addresses.

To ensure scalability, the location service should exploit locality.

REPLICATION

Globe incorporates a replication subobject in each local object.

Interfaces of a replication subobject are standardized which results in high degree of flexibility.

FAULT TOLERANCE Fault tolerance in Globe is achieved mainly

through replication. To recover after a failure, globe object server

ensures that all local objects are made persistent.

SECURITY

It concentrates on protecting a single DSO against security attacks.

Security is partly handled by a separate security subobject. It communicates with local security services like Kerberos, SESAME and considers various security issues with respect to communication, invocation of semantics subobject and replication.