CSC/ECE 517 Fall 2010/ch6 6i CB

Introduction

CORBA is an acronym for Common Object Request Broker Architecture. It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses IIOP protocol to form the communication between two Corba based programs. CORBA was designed by Object Management Group to provide an object oriented interoperability of applications in a distributed systems. The use of Object Oriented Design, analysis and design using CORBA allows for great re-usability across systems. Advantages of Object Oriented Features such as inheritance, encapsulation and dynamic binding are implemented in CORBA.

Need for CORBA

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lot of advantages that make use of distributed computing.

CORBA Architecture

The Following picture depicts the major components in CORBA

ORB Core

In the OMA object model, objects provide services and clients issues requests for those services to be performed on their behalf. The purpose of ORB is to deliver requests to objects and return the results to the clients. The ORB services necessary to accomplish this are completely transparent to the client. Client need not know where on the network the object resides, how they communicate, how they are implemented etc. Before a client can issue a request to an object, he/she should hold a reference to that object. An ORB uses object references to identify and locate objects so that it can pass requests to them. As long as the referenced object exists, the ORB allows the object holder to request services from it. The Corba specifies two different ways in which client can issue requests to objects

  Static Invocation via Interface-Specific STUBS
  Dynamic Invocation via the ORB dynamic invocation interface DII

Regardless to which of these methods the client uses to make a request, the ORB locates the object, activates it and passes the request. The Object does not know whether the request came from a static stub or from a dynamic invocation interface. It just takes the request and delivers the output to the ORB.

Interface Definition Language

Even though an object reference identifies a particular object, it does not necessarily describe anything about the objects interface. Before an application makes use of an object, it should know what are all the services provided by that object. In CORBA object interfaces are defined in IDL. IDL is a declarative language, with syntax similar to c++. IDL provides basic data, constructed and template types. These are used in operation declarations to define argument types and return types. In turn operations are used in interface declarations to define the services provided by the objects. IDL also provides module construct that can hold interfaces, type definitions and other modules for name scoping purposes. Of all the types provided by IDL, interfaces are the most important. In addition to describing CORBA objects, they are also used to define object reference types. Operations can be declared to return object references and to take object references as arguments by simply using the interface names as follows :

interface MailMsg; interface Mailbox {

   MailMsg nextMessage();

}

In this example, a client of Mailbox object can use the return value of MailMsg operation to invoke operations on a MailMsg object, since the return value is an object reference.

Dynamic Invocation Interface

To invoke an operation on a CORBA object an application needs an object reference, the name of the operation and a list of the parameters. In addition the application must know whether the operation is one-way, what user-defined exceptions it may throw, any user-context strings which must be supplied, a `context' to take these values from and the type of the returned value. This information is given by the IDL interface declaration, and so is normally made available to the application via the stub code. In the DII this information is encapsulated in the CORBA::Request pseudo-object.

To perform an operation invocation the application must obtain an instance of a Request object, supply the information listed above and call one of the methods to actually make the invocation. If the invocation causes an exception to be thrown then this may be retrieved and inspected, or the return value on success.

Interface Repository

Another service supported by the object interface and hence all object references in the get_interface() operation. This operation returns an object reference to an interface definition that describes the Object's interface. The interface definition is stored in the interface repository which provides persistent storage for IDL interface declarations. The services offered by Interface Repository allow navigation of Objects inheritance hierarchy and provide description of all operations the object supports. Some of these services return references to other Interface Repository objects such as Operation Definition that describe operations and Exception definitions that describe user-defined exception types.

Interface repositories can be used for several purposes. Interface browsers can traverse Interface Repository information to help application developers locate potentially re-usable software components. ORB's could use them to check operation parameter types at run time. The primary function of the Interface Repository is to provide the type information necessary to issue requests using the dynamic invocation interface.

Object Adapters

This is where the Adapter Pattern comes into play. Objects written in a particular programming language need to interact with objects written in other languages. A basic object adapter provides the means by which various objects can interact with the ORB. For example it provides Object reference generation, Object method invocation, security, activation and deactivation of objects and implementations. Object Adapter can either choose to provide these services by delegating them to the ORB or it can provide them by itself. In any case Objects does not know about the differences between other objects as they interface only to the Object Adapter. Each ORB provides a basic object adapter. It supports objects implemented as separate programs. It is expected that most object implementations can work with Basic Object Adapter because it supports various object implementations.

Cohesion and Coupling in Distributed Systems

Cohesion and Coupling are two of the important concepts that have to be taken care of while designing an object oriented system.

Cohesion

The Distributed system that we build consists of a set of subsystems. Each subsystem consists of a set of distributed objects to support the functionality of that subsystem. Those objects that are present on different systems but belong to a same subsystem interact through CORBA. To come up with a good design a set of guiding principles have to be followed. By design, the subsystem should be cohesive. When we produce a cohesive distributed object model, we find that each of the interface represents essential concepts. Each object is easier to understand and the system is more maintainable, and the components that comprise the system are easy to reuse. All of this contributes to reducing the overall cost of the system. In order to build a distributed object model comprising of functionally cohesive interfaces, the following guidelines should be followed.

1 . Each interface should represent a concept and all elements should be strongly related to that abstraction.

2 . Every method should perform a single coherent task.

3 . Each of the subsystems of the distributed architecture should themselves be cohesive. For a subsystem to be cohesive, all the interfaces that comprise that subsystem should also be cohesive.

Coupling

Coupling is a measure of the strength of dependency between different software modules. The stronger the coupling, the stronger the inter dependency between the modules in the system. A design is considered to be bad when there is strong coupling between different modules. It is not possible to completely eliminate coupling, but we should try to minimize it as much as possible. Strongly coupled distributed objects affects the flexibility of our system. In an object oriented system, four types of coupling can occur.

NIL Coupling - No dependency between two classes

Export Coupling - A class is dependent on only the public interface of an other class

Overt Coupling - A class is dependent on implementation details of other class but with permission

Covert Coupling - A class is dependent on implementation details of other class but no permission was given

It is not possible to build a distributed system without Export Coupling as an object will need to interact with another object on a distributed system by making use of the semantics defined by the object interfaces. It is the other types of couplings that prevent us from building a loosely coupled system. However in a distributed system Covert Coupling cannot take place as Interface Definition Language only expresses the public interface of a distributed object and internals are not exposed. We can also avoid Overt Coupling by defining all the interfaces in a subsystem at the same level of abstraction.

References

[1] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[2] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[3] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[4] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[5] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[6] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again