globe distributed shared object. introduction globe stands for global object based environment. ...
TRANSCRIPT
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.