Distributed Object-Based
Systems
Chapter 9
Distributed ObjectBased 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
Architecture
• Background:
– Developed by the Object Management Group (OMG) in
response to industrial demands for objectbased 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 distributedobject 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, manufacturing.
Overview of CORBA
The global architecture of CORBA.
Object Model
• CORBA has a traditional remoteobject 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 interfacebased 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.
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 serverside reconstruct those request into
regular method invocations
• Object adapter: Serverside 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
service.
Object Invocation Models
Request type
Failure semantics
Description
Synchronous
At-most-once
Caller blocks until a response is
returned or an exception is
raised
One-way
Best effort delivery
Caller continues immediately
without waiting for any response
from the server
Deferred
synchronous
At-most-once
Caller continues immediately
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
Messaging
CORBA's callback model for asynchronous method invocation.
Messaging
CORBA'S polling model for
asynchronous method invocation.
Interoperability
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.
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.
– Requestlevel: Allows you to modify invocation semantics
(e.g., multicasting)
– Messagelevel: Allows you to control messagepassing
between client and server (e.g., handle reliability and
fragmentation)
Clients
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
POA.
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;
CORBA::Objectid_var oid;
// Declare a reference to a C++ object
// 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
agents.
Agents
CORBA's overall model of agents, agent systems, and regions.
Naming
• In CORBA, it is essential to distinguish specificationlevel and implementationlevel 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 clienttoobject 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
implemented).
• Passing an object reference A from ORB A to ORB B
circumventing the AtoB 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
binding.
– 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
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.
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.
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.
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
(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.
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
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.
An Example Architecture
An example architecture of a fault-tolerant CORBA system.
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.
Security
The general organization for secure object invocation in CORBA.
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.
Security
The role of security interceptors in CORBA.
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.
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, evidencebased security model, automatic memory management
and native Web services support.
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.
Distributed COM
• DCOM: Distributed Component Object Model
– Microsoft's solution to establishing interprocess
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 NTbased systems (including Windows 2000/XP)
– Comparable to CORBA's object request broker
(Microsoft’s CORBA).
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.
Overview of DCOM
The general organization of ActiveX, OLE, and COM.
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 adhoc 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 remotemethod calls
with atmostonce semantics. Asynchronous invocations
are supported through a polling model, as in CORBA.
• Event communication: Similar to CORBA's pushstyle
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?
Events
Event processing in DCOM.
Clients
Passing an object reference in DCOM with custom marshaling.
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.
Monikers
Step
Performer
Description
1
Client
Calls BindMoniker at moniker
2
Moniker
Looks up associated CLSID and instructs SCM
to create object
3
SCM
Loads class object
4
Class object
Creates object and returns interface pointer to
moniker
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.
Monikers
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: 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.
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.
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).
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
IDENTIFY
The server knows the client and can do access control
checks
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
(a)
Service
Description
NONE
No authorization
NAME
Authorization based on the client's identity
DCE
Authorization using DEC Privilege Attribute Certificates (PACs)
(b)
a)
b)
Default authentication services supported in DCOM.
Default authorization services supported in DCOM.
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.
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
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.
Globe
• Experimental widearea 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
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:
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
object
• Communication subobject: Provides a (relatively
simple), networkindependent interface for
communication between local objects
• Replication subobject: Contains the implementation of
an objectspecific consistency protocol that controls
exactly when a method on the semantics subobject
may be invoked
• Control subobject: Connects the userdefined 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.
Communication
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 locationindependent 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 transportlevel 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 objectspecific 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.
Security
• Essence: Additional security subobject checks for
authorized communication, invocation, and parameter
values. Globe can be integrated with existing security
services:
Security (1)
The position of a security subobject in a Globe local object.
Security (2)
Using Kerberos to establish
secure distributed shared
objects.
Comparison
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.
Comparison
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.