MODULE 3

CORBA – Introduction – Features – Fundamental concepts in Distributed objects – CORBA IDL – stub & Skeleton - implementing a simple CORBA server and CORBA client with C++.

Fundamental concepts in Distributed System

i) Single tier architecture

A single computer that contains the database and front end to access the database. Generally these are found in small business. There is a single computer which stores all the company’s data in a single database. The interface used to interact with the database may be part of the database or another program which ties into the database itself.

Advantages:

Cost-effective system

Disadvantages

Impractical for the large organizations which requires the interactions among more users.

ii)Two-tier architecture

In this the client/server describes the relationship between two computer in which one program(Client) makes a service request from another program(Server),which fulfills its request.

Why we need this model?

Early computer systems are monolithic systems in which all the processing is occurred on the same machine. But its very time consuming processes. So we adopt this client server model.

Using Client/server model we can

Split work among multiple machines.

Maintain a database on server that separates from clients provide more security.

Clients’ access data from the data base which is in the server. How they access this data?

They use some non procedural language.SQL (Structured Query Language) is an example. They didn’t allow the user to specify processing semantics within a query. This meant that large amounts of data often needed to be transferred to the client to be processed even if the result after processing was very small. Network congestion was inevitable. So the vendors of the database needed a way to move some of the processing back to the database server. So they offered some stored procedures which is a code that executes on the server side within the database management system. The stored procedure can be used to access data within the database and process it before sending the result to the client. Since the result is much smaller than the data being processed, the traffic between the client and server is substantially reduced. The stored procedures can also be shared between multiple clients. But its downside is that stored procedures are inherently non portable because they are vendor-specific.

In Two-tier architecture management of database occurred on the server tier and all other processing occurred on the client tier. So each client was required to posses a significant processing power.

In the two tier architecture the client has to do a lot of processing work. In order to minimize the processing work we need a model that will distribute the work. So the client side processing was possible to separate into application presentation and business logic processing resulted in three tiers: a client tier for visual presentation, a middle tier for processing based on business logic and a data tier for persistent data management.

  • Presentation logic = User Interface, displaying data to the user, accepting input from the user.
  • Business logic = Data Validation, ensuring the data is kosher before being added to the database.
  • Data Access Logic = Database Communication, accessing tables and indices, packing and unpacking data

iii)Three-Tier Client/Server Architectures

In a three-tier or multi-tier environment, the client implements the presentation logic (thin client). The business logic is implemented on an application server(s) and the data resides on database server(s).

A Multi-tier architecture is thus defined by the following three component layers:

  1. A front-end component, which is responsible for providing portable presentation logic;
  2. A back-end component, which provides access to dedicated services, such as a database server.
  3. A middle-tier component, which allows users to share and control business logic by isolating it from the actual application;

Advantages of Multi-Tier Client/Server architectures

  1. Network bottlenecks are minimized because the application layer does not transmit extra data to the client, only what is needed to handle a task.
  1. When business logic changes are required, only the server has to be updated. In two-tier architectures, each client must be modified when logic changes.
  1. The client is insulated from database and network operations. The client can access data easily and quickly without having to know where data is or how many servers are on the system.
  1. Database connections can be 'pooled' and thus shared by several users, which greatly reduces the cost associated with per-user licensing.
  1. The organization has database independence because the data layer is written using standard SQL which is platform independent. The enterprise is not tied to vendor-specific stored procedures.
  1. Changes to the user interface or to the application logic are largely independent from one another, allowing the application to evolve easily to meet new requirements.
  2. The application layer can be written in standard third or fourth generation languages, such as Java, C or COBOL, with which the organization's in-house programmers are experienced

How communication between tiers is possible?

Client/Server applications spread on multiple computers, so they need to communicate with each other.

How they communicate with each other?

For this they rely on a networking infrastructure such as TCP/IP or IPX.But if we implement such a low level communication the transaction to multi-tier systems would not have been possible.

In two tier system the task of abstracting the network protocols can easily be done. The database vendors provided specialized libraries and drivers to access the database that abstracted the various n/w protocols. Client-tier applications could be written without regard for the actual location of the database. The client –tier applications were able to link in the appropriate library (either statically or dynamically) that allowed the communication with the data tier. Since the relational model provide a very structured and generic means for accessing the database, abstracting the networking code was not overly difficult.

But the communication between the client applications and middle tier services can’t be done in a generic and structured way as had be done in two-tier systems. Because client needs a model of communication that blends in with the development platform being used to implement the client applications. So standardization began to emerge.

So what actually a middle ware is?

Middleware is connectivity software that consists of a set of enabling services that allow multiple processes running on one or more machines to interact across a network.

Middleware is essential to migrating mainframe applications to client/server applications and to providing for communication across heterogeneous platforms. Middleware services are sets of distributed software that exist between the application and the operating system and network services on a system node in the network.

Do you know which is the first middle ware technology that gain the wide acceptance?

Middleware services provide a more functional set of Application Programming Interfaces(API) than the operating system and network services to allow an application to

  • locate transparently across the network, providing interaction with another application or service
  • be independent from network services
  • be reliable and available
  • scale up in capacity without losing function

Middleware can take on the following different forms:

  • Transaction processing (TP) monitors which provide tools and an environment for developing and deploying distributed applications.
  • Remote Procedure Calls (RPCs), which enable the logic of an application to be distributed across the network. Program logic on remote systems can be executed as simply as calling a local routine.
  • Message Oriented Middleware (MOM), which provides program-to-program data exchange, enabling the creation of distributed applications. MOM is analogous to email in the sense it is asynchronous and requires the recipients of messages to interpret their meaning and to take appropriate action.
  • Object Request Brokers (ORBs), which enable the objects that comprise an application to be distributed and shared across heterogeneous networks.

What is RPC? ( The first middle ware technology that gain the wide acceptance)

Remote Procedure Call (RPC) is a client/server infrastructure that increases the interoperability, portability and flexibility of an application by allowing the application to be distributed over multiple heterogeneous platforms. It reduces the complexity of developing applications that span multiple operating systems and network protocols by insulating the application developer from the details of the various operating system and network interfaces-function calls are the programmer's interface when using RPC.

Why we choose ORB instead of RPC?

RPC is appropriate for client/server applications in which the client can issue a request and wait for the server's response before continuing its own processing. Because most RPC implementations do not support peer-to-peer, or asynchronous, client/server interaction, RPC is not well-suited for applications involving distributed objects or object-oriented programming.

What is ORB?

An object request broker (ORB) is a middleware technology that manages communication and data exchange between objects. ORBs promote interoperability of distributed object systems because they enable users to build systems by piecing together objects- from different vendors- that communicate with each other via the ORB. The implementation details of the ORB are generally not important to developers building distributed systems. The developers are only concerned with the object interface details.

ORB technology promotes the goal of object communication across machine, software, and vendor boundaries. The relevant functions of an ORB technology are

  • interface definition
  • location and possible activation of remote objects communication between clients and object.

An ORB allows objects to hide their implementation details from clients. This can include programming language, operating system, host hardware, and object location. Each of these can be thought of as a "transparency, and different ORB technologies may choose to support different transparencies, thus extending the benefits of object orientation across platforms and communication channels.

There are many ways of implementing the basic ORB concept; for example, ORB functions can be compiled into clients, can be separate processes, or can be part of an operating system kernel. These basic design decisions might be fixed in a single product; or there might be a range of choices left to the ORB implementer.

There are two major ORB technologies:

  • The Object Management Group's (OMG) Common Object Request Broker Architecture(CORBA) specification
  • Microsoft's Component Object Model (COM).

CORBA INTRODUCTION

CORBA products provide a framework for the development and execution of distributed applications. But why would one want to develop a distributed application in the first place? As you will see later, distribution introduces a whole new set of difficult issues. However, sometimes there is no choice; some applications by their very nature are distributed across multiple computers because of one or more of the following reasons:

  • The data used by the application are distributed
  • The computation is distributed
  • The users of the application are distributed
Data are distributed

Some applications must execute on multiple computers because the data that the application must access exist on multiple computers for administrative and ownership reasons. The owner may permit the data to be accessed remotely but not stored locally. Or perhaps the data cannot be co-located and must exist on multiple heterogeneous systems for historical reasons.

Computation is distributed

Some applications execute on multiple computers in order to take advantage of multiple processors computing in parallel to solve some problem. Other applications may execute on multiple computers in order to take advantage of some unique feature of a particular system. Distributed applications can take advantage of the scalability and heterogeneity of the distributed system.

Users are distributed


Some applications execute on multiple computers because users of the application communicate and interact with each other via the application. Each user executes a piece of the distributed application on his or her computer, and shared objects, typically execute on one or more servers. A typical architecture for this kind of

Distributed Object Systems

Distributed object systems are distributed systems in which all entities are modeled as objects. Distributed object systems are a popular paradigm for object-oriented distributed applications. Since the application is modeled as a set of cooperating objects, it maps very naturally to the services of the distributed system.

what is CORBA?

CORBA, or Common Object Request Broker Architecture, is a standard architecture for distributed object systems. It allows a distributed, heterogeneous collection of objects to interoperate.

The OMG

The Object Management Group (OMG) is responsible for defining CORBA. The OMG comprises over 700 companies and organizations, including almost all the major vendors and developers of distributed object technology, including platform, database, and application vendors as well as software tool and corporate developers

What is CORBA good for?

CORBA is useful in many situations. Because of the easy way that CORBA integrates machines from so many vendors, with sizes ranging from mainframes through minis and desktops to hand-held and embedded systems, it is the middleware of choice for large (and even not-so-large) enterprises. One of its most important, as well most frequent, uses is in servers that must handle large number of clients, at high hit rates, with high reliability. CORBA works behind the scenes in the computer rooms of many of the world's largest websites; ones that you probably use every day. Specializations for scalability and fault-tolerance support these systems. But it's not used just for large applications; specialized versions of CORBA run real-time systems, and small embedded systems.

CORBA ARCHITECTURE

The picture below shows the main components of the ORB architecture and their interconnections

Figure : CORBA ORB Architecture

The central component of CORBA is the Object Request Broker (ORB). It consists all of the communication infrastructure necessary to identify and locate objects, handle connection management and deliver data. In general, the ORB is not required to be a single component; it is simply defined by its interfaces. The ORB Core is the most crucial part of the Object Request Broker; it is responsible for communication of requests.

The basic functionality provided by the ORB consists of passing the requests from clients to the object implementations on which they are invoked. In order to make a request the client can communicate with the ORB Core through the IDL stub or through the Dynamic Invocation Interface (DII). The stub represents the mapping between the language of implementation of the client and the ORB core. Thus the client can be written in any language as long as the implementation of the ORB supports this mapping. The ORB Core then transfers the request to the object implementation which receives the request as an up-call through either an IDL skeleton, or a dynamic skeleton.

The components of CORBA and their functional role.

  • Object -- This is a CORBA programming entity that consists of an identity, an interface, and an implementation, which is known as a Servant.
  • Servant -- This is an implementation programming language entity that defines the operations that support a CORBA IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada.
  • Client -- This is the program entity that invokes an operation on an object implementation. Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args). The remaining components in Figure 2 help to support this level of transparency.
  • Object Request Broker (ORB) -- The ORB provides a mechanism for transparently communicating client requests to target object implementations. The ORB simplifies distributed programming by decoupling the client from the details of the method invocations. This makes client requests appear to be local procedure calls. When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if necessary, delivering the request to the object, and returning any response to the caller.
  • ORB Interface -- An ORB is a logical entity that may be implemented in various ways (such as one or more processes or a set of libraries). To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB. This interface provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface described below.
  • CORBA IDL stubs and skeletons -- CORBA IDL stubs and skeletons serve as the ``glue'' between the client and server applications, respectively, and the ORB. The transformation between CORBA IDL definitions and the target programming language is automated by a CORBA IDL compiler. The use of a compiler reduces the potential for inconsistencies between client stubs and server skeletons and increases opportunities for automated compiler optimizations.
  • Dynamic Invocation Interface (DII) -- This interface allows a client to directly access the underlying request mechanisms provided by an ORB. Applications use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in. Unlike IDL stubs (which only allow RPC-style requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) and oneway (send-only) calls.
  • Dynamic Skeleton Interface (DSI) -- This is the server side's analogue to the client side's DII. The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing. The client making the request has no idea whether the implementation is using the type-specific IDL skeletons or is using the dynamic skeletons.
  • Object Adapter -- This assists the ORB with delivering requests to the object and with activating the object. More importantly, an object adapter associates object implementations with the ORB. Object adapters can be specialized to provide support for certain object implementation styles (such as OODB object adapters for persistence and library object adapters for non-remote objects).

Corba has the versatility of