My Knowledge Base

Distributed Object Middleware

Distributed objects are objects in the sense of object-oriented programming that are distributed across different address space in multiple computers connected via a network, but work together by message passing and invocation methods

The key characteristics of distributed objects is that they allow you to adopt an object oriented programming model for the development of distributed systems, and through which hide the underlying complexity of distributed programming.

Middleware based on distributed object is designed to provide a programming model based on object-oriented principles and therefore to bring the benefits of the object-oriented approach to distributed computing. In contrast to Java RMI, CORBA is a multi-language solution allowing objects written in a variety of languages to interoperate.

In this approach, communicating entities are represented by objects. Objects communicate mainly using remote method invocation, but also possibly using an alternative communication paradigm (such as distributed events). This relatively simple approach has a number of important benefits, including the following:

  • The encapsulation inherent in object-based solutions is well suited to distributed programming.
  • The related property of data abstraction provides a clean separation between the specification of an object and its implementation, allowing programmers to deal solely in terms of interfaces and not be concerned with implementation details such as the programming language and operating system used.
  • This approach also lends itself to more dynamic and extensible solutions, for example by enabling the introduction of new objects or the replacement of one object with another (compatible) object.

Component-based solutions have been developed to overcome a number of limitations that have been observed for application developers working with distributed object middleware:

  • Implicit dependencies: Object interfaces do not describe what the implementation of an object depends on, making object-based systems difficult to develop (especially for third-party developers) and subsequently manage.
  • Programming complexity: Programming distributed object middleware leads to a need to master many low-level details associated with middleware implementations.
  • Lack of separation of distribution concerns: Application developers are obliged to consider details of concerns such as security, failure handling and concurrency, which are largely similar from one application to another.
  • No support for deployment: Object-based middleware provides little or no support for the deployment of (potentially complex) configurations of objects.

Component-based solutions can best be understood as a natural evolution of objectbased approaches, building on the strong heritage of this earlier work.

Distributed Objects

Middleware based on distributed objects is designed to provide a programming model based on object-oriented principles and therefore to bring the benefits of the object-oriented approach to distributed programming.

Distributed objects as natural evolution from three strands of activity:

  • In distributed systems, earlier middleware was based on the client-server model and there was a desire for more sophisticated programming abstractions.
  • In programming languages, earlier work in object-oriented languages led to emergence of more mainstream and heavily used programming languages such as Java and C++.
  • In software engineering, significant progress was made in the development of object-oriented design methods, leading to the emergence of the Unified Modelling Language (UML) as an industrial-standard notation for specifying (potentially distributed) object-oriented software systems.

Differences between objects and distributed objects

  1. Class is a fundamental in OOP but does not feature so prominently in distributed object middleware, as it is difficult to agree upon a common interpretation of class in a heterogeneous environment where multiple language coexist.

  2. The style of inheritance is significantly different from that offered in most object oriented languages. In particular, distributed object middleware offers interface inheritance, which is a relationship between interfaces whereby the new interface inherits the method signatures of the original interface and can add extra ones. In contrast, object-oriented languages offer implementation inheritance as a relationship between implementations, whereby the new class (in this case) inherits the implementation (and hence behaviour) of the original class and can add extra behaviour.

The added complexities: Because of the added complexities involved, the associated distributed object middleware must provide additional functionality:

  1. Inter-object communication: A distributed object middleware framework must offer one or more mechanisms for objects to communicate in the distributed environment. This is normally provided by remote method invocation, although distributed object middleware often supplements this with other communications paradigms (for example, indirect approaches such as distributed events). CORBA provides an event service and an associated notification service.

  2. Lifecycle management: Lifecycle management is concerned with the creation, migration and deletion of objects, with each step having to deal with the distributed nature of the underlying environment.

  3. Activation and deactivation: In non-distributed implementations, it can often be assumed that objects are active all the time while the process that contains them runs. In distributed systems, however, this cannot be assumed as the numbers of objects may be very large, and hence it would be wasteful of resources to have all objects available at any time.

  4. Persistent: Objects typically have state, and it is important to maintain the state across possible cycles of activation and deactivation and indeed system failures. Distributed object middleware must therefore offer persistency management for stateful objects.

  5. Additional services: A comprehensive distributed object middleware framework must also provide support for the range of distributed system services, including naming, security and transaction services.

CORBA

OMG formed with a view to encouraging the adoption of distributed object systems in order to gain the benefits of object-oriented programming for software development and to make distributed systems, which were becoming widespread. To achieve its aim, the OMG advocated the use of open systems based on standard object-oriented interfaces.

These systems would be built from heterogeneous hardware, computer networks, operating systems and programming languages.

An important motivation was to allow distributed objects to be implemented in any programming language and to be able to communicate with one another.

CORBA’s object model:

The CORBA object is used to refer to remote objects, thus, a CORBA object implements an IDL interface, has remote object reference and is able to respond to invocations of methods in its IDL interface. A CORBA object can be implemented by a language that is not object-oriented – for example, without the concept of class. Since implementation languages will have different notions of class, or even none at all, the class concept does not exist in CORBA.

They introduced a metaphor, the object request broker (ORB), whose role is to help a client to invoke a method on an object following the RMI style.

Main components of CORBA’s language-independent RMI framework are the following:

  1. an interface definition known as IDL
  2. an architecture
  3. an external data representation, called CDRs, also defines specific format for the messages in a request reply protocol and messages for inquiring about the location of an object, for cancelling requests and for reporting errors
  4. a standard form for remote object references

The CORBA architecture also allows for CORBA services - a set of generic services that are useful for distributed applications.

CORBA IDL:

A CORBA IDL interface specifies a name and a set of methods that client can request. Remote invocation in CORBA has at-most-once call semantics as the default.

The interface named PersonList specifies the methods available for RMI in a remote object that implements that interface. For example, the method addPerson specifies its argument as in, meaning that it is an input argument, and the method getPerson that retrieves an instance of Person by name specifies its second argument as out, meaning that it is an output argument.

struct Person
{
	string name;
	string place;
}

interface PersonList
{
	readonly attriute string listname;
	void addPerson(in Person p);
	void getPerson(in string name, out Person p);
}

Architecture:

The CORBA architecture is designed to support the role of an object request broker that enables clients to invoke methods in remote objects, where both clients and servers can be implemented in a variety of programming languages.

CORBA provides for both static and dynamic invocations. Static invocations are used when the remote interface of the CORBA object is known at compile time, enabling client stubs and server skeletons to be used. If the remote interface is not known at compile time, dynamic invocation must be used. Most programmers prefer to use static invocation because it provides a more natural programming model.

  1. ORB core: The role of the ORB core includes all the functionality of the communication module. In addition, an ORB core provides an interface that includes the following:

    • operations to provide argument lists for requests during dynamic invocation;
    • operations enabling it to be started and stopped;
    • operations to convert between remote object references and strings;

  2. Object adapter: The role of an object adapter is to bridge the gap between CORBA objects with IDL interfaces and the programming language interfaces of the corresponding servant classes. An object has the following tasks:

    • It creates remote object references for CORBA objects.
    • It dispatches each RMI via a skeleton to the appropriate servant. An object adapter gives each CORBA object a unique object name, which forms part of its remote object references. The same name is used each time an object is activated. The object name may be specified by the application program or generated by the object adapter. Each CORBA object is registered with its object adapter, which keeps a remote object table that maps the names of CORBA objects to their servants. The CORBA standard for object adapters is called the Portable Object Adapter (POA). It is called portable because it allows applications and servants to be run on ORBs produced by different developers. Each object adapter also has its own name, which forms part of the remote object references of all of the CORBA objects it manages. This name may either be specified by the application program or generated automatically.

  3. Skeleton: Skeleton classes are generated in the language of the server by an IDL compiler. Remote method invocations are dispatched via the appropriate skeleton to a particular servant, and the skeleton unmarshals the arguments in request messages and marshals exceptions and results in reply messages.

  4. Client stubs/proxies: They are in the client language. The class of a proxy or a set of stub procedures is generated from an IDL interface by an IDL compiler for the client language.

  5. Implementation repository: An implementation repository is responsible for activating registered servers on demand and for locating servers that are currently running. The object adapter name is used to refer to servers when registering and activating them.

  6. Interface repository: The role of the interface repository is to provide information about registered IDL interfaces to clients and servers that require it. For an interface of a given type it can supply the names of the methods and, for each method, the names and types of the arguments and exceptions.

CORBA remote object references:

A remote object reference contains necessary information for a client to establish a connection and invoke methods on a remote objects, typically includes details such as the object’s identifier, the location of the object’s server, and the interface through which the object can be accessed.

CORBA specifies a format for remote object references that is suitable for use whether or not the remote object is to be activated by an implementation repository. References using this format are called interoperable object references (IORs).

CORBA services:

CORBA includes specifications for services that may be required by distributed objects. Are predefined, resuable components provided by CORBA architectures to support common distributed computing tasks and functionalities.

Examples include

  • Naming service, mapping names to remote object references within a given naming context.
  • Trading service, allows objects to be located by attribute, that is, it is a directory service.
  • Event service, allows objects of interest to communicate notifications to subscribers using ordinary CORBA remote method invocations.
  • Notification service, extends the event service with added capabilities including the ability to define filters expressing events of interest.