Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T20:11:01Z

Schinta2: /* Advantages and Disadvantages */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<b>Data are distributed</b>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<b>Users are distributed</b>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<b>Computation is distributed</b>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<b>Difference between CORBA objects and other objects</b>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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.

==Advantages and Disadvantages==
CORBA is not a programming language, but a specification for creating and using objects. A few of the advantages that we can avail by using CORBA are,

1)CORBA allows methods on a remote object to be accessed as if they were on the Local machine

2) Using CORBA, one does not need to worry about factors like
* Packets
* Flow control
* Message loss.
3) The main advantage of CORBA is it is very scalable
* Platform and Language Independent
* Object Oriented
4) Since the functionality is partitioned, it would be very easy to update a client or a server

5) It can deal with Heterogeneous systems.

<b>Disadvantages</b>

1) Control over how information is actually sent will be less.

==Conclusion==
The CORBA OMG Common Object Services specification defines a set of event services to support asynchronous communication between potentially distributed CORBA objects. CORBA is an architecture that supports a remote method invocation paradigm by providing location transparency. It allows adding, exchange, and removing services dynamically and hides the system details from the developer. It is language independent and is one of the best architectures for Remote Method Invocation

=References=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T20:08:19Z

Schinta2: /* Advantages and Disadvantages */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<b>Data are distributed</b>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<b>Users are distributed</b>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<b>Computation is distributed</b>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<b>Difference between CORBA objects and other objects</b>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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.

==Advantages and Disadvantages==
CORBA is not a programming language, but a specification for creating and using objects. A few of the advantages that we can avail by using CORBA are,

1)CORBA allows methods on a remote object to be accessed as if they were on the Local machine

2) Using CORBA, one does not need to worry about factors like
* Packets
* Flow control
* Message loss.
3) The main advantage of CORBA is it is very scalable
* Platform and Language Independent
* Object Oriented
4) Since the functionality is partitioned, it would be very easy to update a client or a server

5) It can deal with Heterogeneous systems.

<b>Disadvantages</b>

1) Control over how information is actually sent will be less.

=References=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T20:07:24Z

Schinta2: /* Advantages and Disadvantages */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<b>Data are distributed</b>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<b>Users are distributed</b>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<b>Computation is distributed</b>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<b>Difference between CORBA objects and other objects</b>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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.

==Advantages and Disadvantages==
CORBA is not a programming language, but a specification for creating and using objects.

1)CORBA allows methods on a remote object to be accessed as if they were on the Local machine

2) Using CORBA, one does not need to worry about factors like
* Packets
* Flow control
* Message loss.
3) The main advantage of CORBA is it is very scalable
* Platform and Language Independent
* Object Oriented
4) Since the functionality is partitioned, it would be very easy to update a client or a server

5) It can deal with Heterogeneous systems.

<b>Disadvantages</b>

1) Control over how information is actually sent will be less.

=References=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T20:03:32Z

Schinta2: /* Advantages and Disadvantages */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<b>Data are distributed</b>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<b>Users are distributed</b>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<b>Computation is distributed</b>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<b>Difference between CORBA objects and other objects</b>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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.

==Advantages and Disadvantages==
CORBA is not a programming language, but a specification for creating and using objects.

1) Using CORBA, one does not need to worry about factors like
* Packets
* Flow control
* Message loss.
2) The main advantage of CORBA is it is very scalable
* Platform and Language Independent
* Object Oriented
3) Since the functionality is partitioned, it would be very easy to update a client or a server

<b>Disadvantages</b>

1) Control over how information is actually sent will be less.

=References=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T20:03:18Z

Schinta2: /* Advantages and Disadvantages */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<b>Data are distributed</b>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<b>Users are distributed</b>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<b>Computation is distributed</b>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<b>Difference between CORBA objects and other objects</b>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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.

==Advantages and Disadvantages==
CORBA is not a programming language, but a specification for creating and using objects.

1) Using CORBA, one does not need to worry about factors like
* Packets
* Flow control
* Message loss.
2) The main advantage of CORBA is it is very scalable
* Platform and Language Independent
* Object Oriented
3) Since the functionality is partitioned, it would be very easy to update a client or a server
<b>Disadvantages</b>

1) Control over how information is actually sent will be less.

=References=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:57:36Z

Schinta2: /* Need for CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<b>Data are distributed</b>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<b>Users are distributed</b>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<b>Computation is distributed</b>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<b>Difference between CORBA objects and other objects</b>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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.

==Advantages and Disadvantages==
CORBA is not a programming language, but a specification for creating and using objects.

1) Using CORBA, one does not need to worry about factors like
* Packets
* Flow control
* Message loss.
2) The main advantage of CORBA is it is very scalable
* Platform and Language Independent
* Object Oriented
<b>Disadvantages</b>

1) Control over how information is actually sent will be less.

=References=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:57:14Z

Schinta2: /* Introduction to CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<b>Data are distributed</b>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<b>Users are distributed</b>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<b>Computation is distributed</b>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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.

==Advantages and Disadvantages==
CORBA is not a programming language, but a specification for creating and using objects.

1) Using CORBA, one does not need to worry about factors like
* Packets
* Flow control
* Message loss.
2) The main advantage of CORBA is it is very scalable
* Platform and Language Independent
* Object Oriented
<b>Disadvantages</b>

1) Control over how information is actually sent will be less.

=References=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:57:00Z

Schinta2: /* Introduction to CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<b>Data are distributed</b>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<b>Computation is distributed</b>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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.

==Advantages and Disadvantages==
CORBA is not a programming language, but a specification for creating and using objects.

1) Using CORBA, one does not need to worry about factors like
* Packets
* Flow control
* Message loss.
2) The main advantage of CORBA is it is very scalable
* Platform and Language Independent
* Object Oriented
<b>Disadvantages</b>

1) Control over how information is actually sent will be less.

=References=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:56:40Z

Schinta2:

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<b>Data are distributed</b>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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.

==Advantages and Disadvantages==
CORBA is not a programming language, but a specification for creating and using objects.

1) Using CORBA, one does not need to worry about factors like
* Packets
* Flow control
* Message loss.
2) The main advantage of CORBA is it is very scalable
* Platform and Language Independent
* Object Oriented
<b>Disadvantages</b>

1) Control over how information is actually sent will be less.

=References=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:54:56Z

Schinta2: /* Advantages and Disadvantages */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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.

==Advantages and Disadvantages==
CORBA is not a programming language, but a specification for creating and using objects.

1) Using CORBA, one does not need to worry about factors like
* Packets
* Flow control
* Message loss.
2) The main advantage of CORBA is it is very scalable
* Platform and Language Independent
* Object Oriented
<b>Disadvantages</b>

1) Control over how information is actually sent will be less.

=References=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:53:39Z

Schinta2: /* Coupling */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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.

==Advantages and Disadvantages==
CORBA is not a programming language, but a specification for creating and using objects.
1) Using CORBA, one does not need to worry about factors like
* Packets
* Flow control
* Message loss.
2) The main advantage of CORBA is it is very scalable
* Platform and Language Independent
* Object Oriented
Disadvantages
1) Control over how information is actually sent will be less.

=References=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:53:18Z

Schinta2:

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:32:31Z

Schinta2: /* Interface Repository */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:31:43Z

Schinta2: /* Dynamic Invocation Interface */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:29:36Z

Schinta2: /* Dynamic Invocation Interface */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:27:46Z

Schinta2: /* Interface Definition Language */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:27:21Z

Schinta2: /* Interface Definition Language */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {

};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:18:05Z

Schinta2: /* Interface Definition Language */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

<b>Example</b>
'''
Sample functions and attributes of a product in any catalog.

module productcatalog{

struct product{

float weight;

double price;

};

exception Unknown();

interface product_details{

float get_price();

void set_price();

};

};
'''
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {

};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:10:29Z

Schinta2: /* Interface Definition Language */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:09:38Z

Schinta2: /* Interface Definition Language */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?
The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:08:35Z

Schinta2: /* ORB Core */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>

From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?
The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:05:02Z

Schinta2: /* ORB Core */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:OMG.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>

From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?
The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:04:08Z

Schinta2: /* CORBA Architecture */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.

Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>

From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?
The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-26T19:03:29Z

Schinta2: /* ORB Core */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.

Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>

From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?
The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

File:ORBs.png

2010-11-26T18:50:34Z

Schinta2:

File:ORB.png

2010-11-26T18:50:24Z

Schinta2:

File:IDL.png

2010-11-26T18:50:02Z

Schinta2:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-25T18:08:33Z

Schinta2: /* Introduction to CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-25T18:08:17Z

Schinta2: /* Need for CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-25T18:07:19Z

Schinta2: /* Need for CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-25T18:07:02Z

Schinta2: /* Introduction to CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-25T18:06:27Z

Schinta2: /* CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-25T18:05:47Z

Schinta2: /* Purpose of Distributed Applications */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-25T18:05:23Z

Schinta2: /* Need for CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-25T18:04:39Z

Schinta2: /* Need for CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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 an application present in 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 lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:36:52Z

Schinta2: /* Need for CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:36:34Z

Schinta2: /* Purpose of Distributed Applications */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:35:21Z

Schinta2: /* CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:34:56Z

Schinta2: /* CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:34:43Z

Schinta2: /* Purpose of Distributed Applications */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:34:09Z

Schinta2: /* Introduction to CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:33:32Z

Schinta2: /* Introduction to CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

<h3>Difference between CORBA objects and other objects</h3>
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:33:03Z

Schinta2: /* Difference between CORBA objects and other objects */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:32:21Z

Schinta2: /* CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

=Difference between CORBA objects and other objects=
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:30:32Z

Schinta2: /* CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

To dive into the the details of CORBA, first we need to understand the purpose of Distributed Applications

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

=Difference between CORBA objects and other objects=
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:29:17Z

Schinta2: /* CORBA */

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

=Difference between CORBA objects and other objects=
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:29:00Z

Schinta2: /* Introduction to CORBA */

=CORBA=

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

=Difference between CORBA objects and other objects=
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-23T20:26:07Z

Schinta2: /* Introduction */

=CORBA=

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

1) The data used by the application are distributed.

2) The Users of the application are distributed

3) The computation is distributed

<h3>Data are distributed</h3>

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

<h3>Users are distributed</h3>

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

<h3>Computation is distributed</h3>

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

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.

=Difference between CORBA objects and other objects=
1) CORBA objects can run on any platform.

2) CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

3) CORBA objects can be located anywhere across the network.

=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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-21T19:38:05Z

Schinta2: /* Introduction */

=CORBA=

=Introduction=

CORBA is the 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 [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two Corba based programs.
CORBA was designed by [http://www.omg.org/ 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.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ 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 [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/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 [http://en.wikipedia.org/wiki/Interface_description_language 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 [http://en.wikipedia.org/wiki/Adapter_pattern 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=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 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=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch2 S20 TT

2010-10-02T03:14:38Z

Schinta2: /* '''Dependencies and Cycles''' */

='''Code Reuse'''=

Code reuse implies the capability of software to allow the practice of reusing a part or module of the code, which saves the programmer from re-building a new application from scratch. This prevents a lot of redundancy in coding for programmers and also the time and effort spent in writing code.

This paper mainly focuses on

1) The principles that are used in designing a package, like assigning classes to a package, designing dependencies between the packages, etc.

2) Dependencies among packages and cycles.

Plug-ins, DRY principle, and mix-ins are also dealt in detail but not in greater depths.

='''Granularity'''=
Any article that comprises of large amount of information that needs to make enough sense for the reader needs to be categorized in an appropriate manner. There should be some level of categorization to organize an article in an efficient way. Similarly, for any complex software application to be understood and controlled well the developers need to implement higher level categorization to achieve the purpose.

For Example, consider an application for a store. There are different entities in the store like cart, user, cashier, etc. If we implement an entity, say cart, using a single array we cannot use attributes like iscartempty(), iscartavailable(), etc. for the cart. But, if we implement the entity as a class we can extend the usability of the class by implementing any function that makes sense.

Granularity is the level or the extent to which any system or a function can be subdivided into relatively smaller modules. For example, all the roads in U.S can be classified to rural and urban roads. All the rural roads can be further classified into arterials, collectors and local. All arterials can be still classified into principal and minor and soon. The amount of classification is different to different classes of users.

For many Object Oriented Languages and Systems, the basic unit of categorization can be termed as package (This package is not referring to the Java Package). Although Class might be a potential candidate for some cases, for large and complex applications it may not be a convenient way to categorize [1].

For such cases, a package can be used to represent data that can be imported into other applications. A package can contain a set of particular classes that are partitioned based on some criterion. For example, for a typical java application all the database classes can be grouped into one package and all the development classes can be grouped to one package. The application classes can import the package that contains all the database classes.

But this partitioning of classes into a particular package is based on several factors like

1) '''Cohesion''': Assigning a set of classes to a particular package.

2) '''Coupling''': Designing the dependencies between different packages and their design principles.

3) '''Dependency''': Denotes the package structure whether it is top-down or bottom-up [2].

='''Package Cohesion'''=
The following are a set of principles that are used to satiate the cohesion property of a package.

1) Reuse-Release Equivalence Principle

2) Common-Reuse Principle

3) Common-Closure Principle.

=='''Reuse-Release Equivalence Principle''' (REP)==
'''What is Reuse?'''

The common conception about reuse is copying the code of one class into another class. But what actually happens when the code is changed by the source? Does it get reflected in the user code too? Does a normal user can understand what exactly had happened and what had got changed?

For example, consider the following scenario. Initially the owner dispatches a piece of code to a user for some application. At some point of time the owner realized that there is a bug in the code that needs to be fixed. The owner then changes the code to fix the bug. Since the user does not know the change that was done by the owner, he tries to modify the code to fix the bug. In this process the user’s code will change gradually from the initial code. Finally he will end up with an entire new code and this doesn’t serve the point of re-usability.

The reuse of code by copy and pasting in general is not a good idea and programmers should refrain from doing so. Instead Re-usability can be achieved by using libraries. The author will create a library that consists of all his code that is needed by the user and sends it to the user. The user will simply include the library into his piece of code and can access all the information from the library. This way, the user makes changes to his code, not to the library, to satisfy his needs there by implying the convergence of the original code and the current code. So, if the author wants to change his code either for fixing bugs or renovating code to implement new functionality or to modify the existing functionality, he will change his code and sends it to the user as a new set of code (Versions are covered in the coming sections). The user will have no control over the source code of the library. Since, the user cannot control the code, it can be treated as an end product so that the customer( the user in this case) need not maintain it. So he can either accept the new code to reflect the changes in his current code and avail of the new functionality or he can reject it [1].

A special tracking system might be needed for the user to know whenever the author changes his code. Version number is useful to achieve this purpose. The new set of code is represented by the version number. Every time the author changes the code, he will release it as a new version. This practice helps users identify the version number they are handling with and correspondingly manage their code. If a user wants to use an earlier version of the code, he can get to know it by the version number.

When a bug is identified within a reused component, the exact version of the component can be identified with the use of this tracking system.

'''Principle'''

“The Granule of Reuse is the Granule of Release” [1]''

This principle suggests that the re-usability is to be done based on the granule of reuse, the package. It might be possible to use class as a granule for reuse but it would result in enormous number of classes which makes life miserable. A reusable package should consist of only reusable classes. This makes the whole unit a reusable unit so that the user can accept the version to avail of its functionality or can reject the version. So, either all the packages in the class are reusable or none of them. This avoids accidental reuse of non-reusable packages.

Even if the user accesses only one or two classes the whole granularity to be considered is the entire package.

Example:

Packaging in Eclipse JDT Core Plug-in [2]

[[Image:first_img.png]]

=='''Common Reuse Principle (CRP)'''==

The Reuse-Release Equivalency Principle sheds light on the importance of the package, its tracking mechanism and achievement of re-usability. However, one of the important parts of cohesion, that is the set of classes that can be bounded into a package, has not been determined yet. If the classes that are bounded together are not selected properly, numerous dependencies that are not needed might turn up and the whole concept of packages will fail.

The Common Reuse Principle will help in identifying the set of classes that can be grouped into a particular package.

'''Principle'''

“''The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all''” [1]

This principle states that only classes that are cohesive in nature should be grouped together. This cohesiveness is based on the user’s perspective. Generally the classes that need to be reused will belong to the same package. For example, all the applet concepts are grouped into one package and all the swing concepts into another one.

Consider the scenario where two classes are not tightly coupled in a package. The user wants to access only one particular class from the package. Every time a new version of the package release, the user has to re-validate the whole project even if the class that he is not interested in changes. This results in another reason where each and every class in a package must be tightly bound. So if every class in a package depends upon every other class in a package the user can re-validate to the newer version.

If a particular class is not tightly bound to another reusable class then those two classes must not be in the same package. This makes sure that each and every class in the package is bounded tight to each and every other process in the package. This eliminates the possibility of a class depending only on a particular class but not the other class [3].

Example:

Packaging in Eclipse JDT Core.Formatter Plug-in [2]

[[Image:second_img.png]]

=='''Common Closure Principle (CCP)'''==

“The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the changes in that package.” [1]

The above two rules will maintain the concept of reusability and the control of packages. This rule is to stress the importance of maintainability for the current package. This provides an addendum to CRP such that it achieves the concept of maintainability along with reusability.

This rule specifies that a package should not contain many reasons to change. That means the classes in the package should not have multiple reasons to change [2]. So while binding classes into packages, we need to verify this condition such that all the processes that are likely to change for a particular reason are grouped together into a single package. By confirming to this rule, we can save time in minimizing the work load related to releasing and revalidating the software.

The open closure principle states that all the packages should be closed for modification but not for extension. 100% closure cannot be attainable even if we use OCP. CCP makes the closure strategic by designing the systems such that they are closed to most common kind of changes.

Example: Packaging in the Eclipse JDT Core plug-in [2]

[[Image:Third_img.png]]

='''Dependencies and Cycles'''=

“The morning after syndrome” is a case where there would be multiple developers that are sharing the same resource and even if one develops an application that can run in all cases, there might be an interception from any other user who changes the code that it no longer works. Everyone will try to make their own code work and in the mean process they are altering others resources which leads to an inconsistent state. [1]

Dependencies between different developers code is necessary but too much of dependencies results in this problem.

Dependency cycles are the cycles where both the packages, either directly or indirectly, depend on each other. These cycles make the situation even worse.

The solution to this problem can be achieved by using the following two approaches.

1)The Weekly Build

2)Acyclic Dependency Principle (ADP)

=='''The Weekly Build'''==

This method is commonly used in medium sized projects. For the whole week, except the final day of the week, the developers will work on the classes independently and on the final day they will unite all the work they have done during the week.

Advantages:

It is relatively simple and sufficient for medium sized projects in most cases.

Disadvantages:

It works only for smaller project. If the project grows with time then this method is almost impossible to employ [2].

=='''Acyclic Dependency Principle (ADP)'''==

“The dependency structure between the packages must be a directed acyclic graph (DAG). That is, there must be no cycles in dependency structure.” [1]

As the name indicates that if a dependency graph is drawn among the users of a system, it should never have a cycle.

'''Goal'''

The main idea of this principle is to divide the project into several individual packages. The packages are created in such a way that they are independent for different users. So the interference between developers can be avoided by releasing packages as own units which will not affect the users immediately. Incremental integration needs to be done later at certain point of time to satisfy dependency.

'''Principle'''

The whole development environment is first partitioned into a set of releasable packages. These packages are initially provided as an input to a developer or a team. Once all the changes to be implemented are done by the developer he will name a valid version to the updated package and pass this version to the directory so that next member or team can use it. A developer, in the meantime or later, will work on his own private area after passing the latest version to the directory. Everyone else will use the released version.

Other teams can decide if they want to work on the new version or not. If they want to, they will accept the version otherwise they may continue to use the older version. They can use any version at any point of time since each version is specified using a unique number.
This approach seems to be very simple but for it to work the directory structure needs to be managed well. [1]

'''Package Dependencies'''

A package can depend on any number of other packages. For example a class in a particular package may include the header file of a class in a different package. This can be represented by the following diagram [1].

[[Image:ch2ttPackageDependencies1.jpg]]

The following diagram shows the typical application involving lots of packages which are dependent on each other. The dependency structure is being represented as a graph where each package is represented as a node and each dependency is shown by an edge. These edges are directional edges since they only show a unidirectional flow. No matter whatever the process you start with, you will not end with the same process. This indicates that the graph has no cycles and hence is a Directed Acyclic Graph(DAG) [1].

[[Image:diag2modi.png]]

This structure is very much useful in the following sense.

1)It is very easy to find out which package or a node is affected by changing any other package.
For example, changing database only affects “Package 4”.

2)It is very easy to test packages in isolation.
For example, to test the package “Package 2” or “Package 4”, it can be done independently. For package “package 3” it needs to be linked only with “Package 1”.

3)When the developers of a particular team want to release an updated version, we can find out the packages that are affected by the release by following the dependency arrow backwards.

For example, if the package “Package 3” has been changed “Package 5” and “Package 8”are going to be affected

4)At the time of releasing the whole system it will be done from bottom to top.

For example, the “package 1” package is compiled, tested and released first. It is followed by “Package 7” and “Package 3” which are then followed by “Package 2”, “Package 6” and “Package 4”. “Package 5” is next and finally “Package 8” will get tested and released.

Now consider the effect of cycle in the present graph. Let us consider a new edge, that is, a new dependency from “Package 3” to “Package 8”. This means that “Package 8” depends on “Package 3” indirectly and “Package 3” depends on “Package 8” directly. In the previous case, for the package “Package 5” to be compiled and released it depends on “Package 2”, “Package 4”, and “Package 3”. But since “Package 3” is dependent on “Package 8” for the current scenario which in turn depends on “Package 7”, “Package 6” and “Package 1”, it depends on all other packages in the current system. So, any developer or a team who is working on any of the above packages will experience the previous problem “the morning after syndrome”.

This is not the only problem. If we want to test any of the packages, say “Package 4”, we need to link every other package and then compile. Complete building for every package would end up in intolerable overhead.

So, our goal is to remove the cycles, if there are any, to eliminate “the morning after syndrome” problem. There are two possible solutions for this problem.

1) Dependency Inversion Principle:
This is one possible way of removing a cycle from the acyclic graph. We can design an abstract class that contains its interface that “Package 3” needs. We put this class inside the “Package 3” and make the other class “Package 8” inherit from the other class. This will break the dependency between “Package 3” and “Package 8”.

The initial dependency can be shown in the following diagram [1].
[[Image:diag3modif.png]]

This would be changed by using Dependency Inversion Principle to the following dependency [1].

[[Image:diag4modif.png]]

2)The other potential option is to create a new package that will consist of all the classes that are needed by both “Package 3” and “Package 8” package. This will break the cyclic dependency since both the packages are no longer dependent on each other.

The direction of the dependency can be changed like this [1].

[[Image:diag1modi.png]]

The second approach seems to be a simple way of breaking dependency cycles, but what exactly happens if we follow that approach? Normally, in a large project, there is greater probability for it to have large number of cycles. If we keep on breaking the dependency by creating new packages, we will end up with numerous numbers of packages [1].

='''Top-Down Design'''=

A top-down strategy for a package hierarchy means that, if we consider a package at the top of the hierarchy, that project is assumed to be created first of all other projects in the hierarchy. But what actually happens in a dependency graph s that the package at some level will be developed only after many classes have been designed.

For any application to start with, first we need to determine the functionality of the application. But package dependency will not make any sense in determining the functionality. The package dependency is a blue print of how to build the application. Initially, when determining the functionality of application, there won’t be any software to build. Hence there won’t be any use of package dependency rules. But once the software starts and it tries to accumulate more and more classes, we need to use this package dependency to build the project without “the morning after syndrome”. To build the packages that will have to bind a set of classes that are likely to change together we use Common Closure Principle. Common Reuse Principle will come into act when we start concerned about building reusable elements. This will determine the composition of packages. All these principles are needed to be followed in a specified order which, otherwise, will result in formation of cycles [1].

='''Code Reuse using Ruby on Rails:'''=
Reusability is one of the main objectives of Ruby on Rails and the Don’t Repeat Yourself (DRY) principle in Ruby suggests that any definition should occur only once [4]. Thus, the DRY principle promotes reusability and makes it easier to be used. Ruby provides two ways of reusing code namely the “concept of using methods” and the “concept of using modules”. The concept of reusing the methods relatively falls under the category of reusing small snippets of code that are encompassed in a method, which implies reusing code to a limited extent. Contrary to the concept of using methods, the concept of using modules involves reusing extensive code that is contained in a module[4].

==''' The concept of using modules'''==

Modules are defined as containers of one or more code snippets that might either be small or large depending on the requirements of the class [5]. The code snippets can contain variables, class definitions not necessarily pertinent to the class defined in the snippet and also the methods.

=='''The concept of reusing methods'''==
Ruby provides a way to reuse code in the form of methods. Methods form the smallest unit of code to be reused. This is done using the proc object [5]. Proc is an object in Ruby that contains a block of code. The block of code contained in the Proc object declares a set of local variables. When the proc object is called it will access the same variables that were bound to it during its initialization. In addition to the local variables, the proc object also contains a single method and the current state of the variable, which can be passed to methods utilizing the function calling method [5].

Ruby is a dynamically-typed language, which implies that the programmer needn’t explicitly define the type of a variable as in the case of other object-oriented languages such as Java or C++. Ruby will automatically try to figure out the type based on the usage of the variable. This is called as duck-typing in Ruby [6]. It is called so, for the reason that any bird that behaves like a duck and quacks like a duck will be automatically called a duck, where in reality it needn’t actually be a duck. In Ruby, objects called are initialized dynamically by their behavior and not by their definitions unlike other object-oriented languages, which have their objects initialized before calling them later-on in the program. Thus, Ruby leads to a kind of polymorphism minus their dependence on inheritance.

The dynamism of Ruby is further fostered by the use of “mix-ins” in modules. Mix-ins come from the amalgamation of two words “mix” and “in”. Additional classes or functionality in existing classes can be added by mixing in newer methods. Thus, mixins prove a powerful tool than classes since defining functionality in a mixin means it can be called by any class that requires the functionality and not by the class alone where the functionality has been declared [7]. Code from other modules too can be integrated within the module and called by declaring a statement that acts as if the module has been created at the time when the statement has been declared. Thus, previously defined modules can be implanted into the current modules to modify the active state of the module [7]. The structure of the modules can change dynamically along the way of using the module based on the demands and requirements of the software. Modules can be integrated along with the inheritance concept of Object-oriented language systems to reuse the code in an efficient manner. The classes created within the modules can inherit from other classes. The beauty of Ruby lies with the fact that anybody can modify the previously defined classes in the libraries along the way. Apart from the feature to modify external classes by anybody, it also provides option to make a class read-only in order to restrict the permissions of usage of certain classes, thus promoting misuse of certain important classes.

= '''Ruby plugins'''=

A plugin is a piece of code that helps garner external help for developing application using Rails. The libraries are composed into structures called plugins for enhancing reuse of rails code. Application programmers can use pre-written libraries or compose their very own libraries to be reused later. Rails provide ample support for the use of plugins [8]. There is an abundance of plugin support available from the open source community. Code reuse is furthered by the use of plugins for the reasons that the new plugins created in Rails are compatible with the older versions and thus, the newer parts injected conform to the current state of the application. Another advantage of using plugins includes the breaking up of code into small units. The small units exist on their own and hence, any modification or updating required to fix the code in the units can be done separately without altering the structure of the other units of code. Thus, rails code plugins improves the modularity of the code [9].

Plugins can be found using the following resources:

1) Technoweenie

2) Core Rails

3) Rails Wiki

4) Plugin Directory

Plugins can be used to do the following operations:
'''
Models '''

Plugins can be used to generate basic model of applications. Models are used to store information and manage the current state of the application. They are also used to notify the user of change in the state of the application immediately once the change occurs [10].

'''View Helpers'''

Views provide an interface to the users of the information stored in models. Thus, it provides the interactive medium required by users to communicate with the applications. Plugins can be used to design a user-interface for the applications. Views can be created using responses and layout structuring [10]. Response corresponds to the action taken when the input is passed on to the controller. Layout is the response form that acts as the view for the output.

'''Controllers'''

Controller acts as the point of control. When the input is issued, the controller reacts to the input by instructing the model to perform the requested operations. The plugins can be used to implement a controller to handle models and views of an application [10].

'''Rake Tasks'''

Rake tasks are used to store the session data in its correct format in the database. Rake tasks are used to automate the tasks, which promotes reuse of code. The rake tasks themselves can be generated using plugins.

'''Images, Stylesheets, Javascripts'''

Plugins can be used to generate images, stylesheets and javascripts by using a generator and copying the files into the public directory [10].

='''Conclusion'''=
A Package can be used as a basic unit of a project. The Composition of packages, like what types of classes can be embedded in a package, which classes to include and which are not to etc., is very important to avoid the cyclic dependencies which in turn reduce the complexity of the project. Robustness, Reusability and Maintainability can be achieved by using the three rules that were specified above. Cycles can be removed from the graph by using Dependency Inversion Principle that was specified above [11]. The approach in designing a package should properly be taken into account, which otherwise results in “the morning after syndrome”. Cohesion and Coupling are the most important factors in deciding the dependency of packages among each other.

='''References'''=

[1] Robert Martin, “Granularity”, http://www.objectmentor.com/resources/articles/granularity.pdf.

[2] Mira Mezini, Tom Dinkelaker, Marcel Bruch, and Ivica Aracic, "Principles of Package Design", http://www.st.informatik.tu-darmstadt.de/pages/lectures/se/ws06-07/design/lecture/10_principlesOfPackageDesign.pdf.

[3] Abhijit Nadgouda, "Common Reuse Principle", http://ifacethoughts.net/2006/04/05/common-reuse-principle.

[4] Michael Bachle and Paul Kirchberg, “Ruby on Rails”, IEEE Software, 24(6), Pages105–108, 2007.

[5] Stuart Ellis, “The Key Ideas of the Ruby Programming Language”, “2010, Creative Commons Attribution-Share Alike 3.0 , 2010, License”, http://www.stuartellis.eu/articles/ruby-language.
[6] Michael Morin, “Mixin Modules”, About.com:Ruby, http://ruby.about.com/od/beginningruby/a/mixin.html.

[7] Lars Klevan, “Does Ruby on Rails Work For Larger Engineering Teams?”, Socialcast blog, August 2010, http://blog.socialcast.com/does-ruby-on-rails-work-for-larger-engineering-teams.

[8] J. D. An, A. Chaudhuri, and J. S. Foster. Static Typing for Ruby on Rails, In Proceedings of the 24th IEEE/ACM International Conference on Automated Software Engineering, Auckland, New Zealand, Nov. 2009.

[9] Geoffrey Grosenbach, “The complete guide to Rails plugins: Part 1”, "nubyonrails.com", May 2006, http://nubyonrails.com/articles/the-complete-guide-to-rails-plugins-part-i.

[10] Benjamin Curtis, “Agile web-development”, 2010, http://agilewebdevelopment.com.

[11] Jaime Iniesta, “RailsGuide”, April 4, 2010, http://guides.rubyonrails.org/plugins.html.

='''External Links'''=
[1] ''Granularity'' - http://www.objectmentor.com/resources/articles/granularity.pdf

[2]'' Reuse Maturity Model'' - http://www.anthillpro.com/html/resources/reuse-maturity-model.html

[3] ''Measurements and Metric'' - http://web.cs.wpi.edu/~gpollice/Maps/CS4233/Week5/CS4233%20Lecture%2015/index.html

[4] ''Principles of reuse'' - http://stackoverflow.com/questions/63142/the-reuse-release-equivalence-principle-rep

[5] http://c2.com/cgi/wiki?ReuseReleaseEquivalencePrinciple

[6] http://ifacethoughts.net/2006/04/05/common-reuse-principle/

[7] http://www.st.informatik.tu-darmstadt.de/pages/lectures/se/ws06-07/design/lecture/10_principlesOfPackageDesign.pdf