CORBA--Middleware Technology

CORBA - A Middleware Technology

Rajesh.ch 1, Varun.P 2

1 (Graduate student of 1st year IT )
2 Graduate student of 1st year CIVIL)
SRK Institute of Technology, Enikepadu,Vijayawada.

ABSTRACT

Method-oriented middleware, such as Sun RPC, DCE, Java RMI, COM, and CORBA, has provided synchronous method invocation (SMI) models to applications. Although SMI works well for conventional client/server applications, it is not well-suited for high-performance or real-time applications due to its lack of scalability. To address this problem, the OMG has recently standardized an asynchronous method invocation (AMI) model for CORBA. AMI provides CORBA with many of the capabilities associated traditionally with message-oriented middleware, without incurring the key drawbacks of message-oriented middleware.

This paper provides few asynchronous invocation models for method-oriented middleware. First, we outline the key design challenges faced when developing the CORBA AMI model and describe how we resolved these challenges in TAO, which is our high-performance, real-time CORBA-compliant ORB Second, we present the results of empirical benchmarks that demonstrate the performance benefits of AMI compared with alternative CORBA invocation models. In general, AMI based CORBA clients are more scalable than equivalent SMI based designs, with only a moderate increase in programming complexity.

1. Introduction

Middleware technologies, such as CORBA, Java, EJB, Jini and Web Services, are becoming increasingly popular for building both embedded and enterprise applications. Unfortunately, a lot of the the middleware mechanisms and techniques are mostly in the practitioners' domain, and there has been very little research into the fundamental theoretical and design principles underlying the development of middleware. As middleware gains widespread adoption, it becomes essential to investigate, and to capture, the basics and the methodologies of middleware technologies.

The list of middleware solutions continues to grow. General all encompassing models such as CORBA has tried to solve all problems. But new middleware concepts keep appearing

• Asynchronous middleware (pub-sub, eventing, message queueing) (MSMQ, JMS,JavaSpaces, ...)
• Grid middleware (Legion, Globus, OGSA, ...)
• Web services (SOAP, WSDL, WSFL, ...)
• Mobility middleware (Rover, MOST, ...),
• Mobile agent systems (Tacoma, Aglets, ...)
• Peer-to-peer (JXTA, Jtella, ...)
• Real-time/ multimedia middleware (ReTINA, DIMMA, ...)

Fig. 1: Corba interface

2. Functions of Middleware
Middleware resides on top of the operating systems and communication protocols to perform the following functions .Hiding distribution, i.e. the fact that an application is usually made up of many interconnected parts running in distributed locations;

Hiding the heterogeneity of the various hardware components, operating systems and communication protocols.Providing uniform, standard, high-level interfaces to the application developers and integrators, so that applications can be easily composed, reused, ported, and made to interoperate,Supplying a set of common services to perform various general purpose functions, in order to avoid duplicating efforts and to facilitate collaboration between applications.

These intermediate software layers have come to be known under the generic name of middleware.The role of middleware is to make application development easier, by providing common programming abstractions, by masking the heterogeneity and the distribution of the underlying hardware and operating systems, and by hiding low-level programming details.

3.Designing Middleware
The function of middleware is to mediate interaction between the parts of an application, or between applications. Therefore architectural issues play a central role in middleware design. Architecture is concerned with the organization, overall structure, and communication patterns, both for applications and for middleware itself.

Besides architectural aspects, the main problems of middleware design are those pertaining to various aspects of distributed systems. Any middleware system relies on a communication layer that allows its different pieces to interoperate. In addition, communication is a function provided by middleware itself to applications, in which the communicating entities may take on different roles such as client-server or peer to peer. Middleware allows different interaction modes (synchronous invocations, asynchronous message passing, coordination through shared objects) embodied in different patterns.

The designers of future middleware systems face several challenges :

Middleware systems rely on interception and indirection mechanisms, which induce performance penalties. Adaptable middleware introduces additional indirections, which make the situation even worse.

As applications become more and more interconnected and interdependent, the number of objects, users and devices tends to increase. This poses the problem of the scalability of the communication and object management algorithms, and increases the complexity of administration.

Ubiquitous computing is a vision of the near future, in which an increasing number of devices embedded in various physical objects will be participating in a global information network. Mobility and dynamic reconfiguration will be dominant features, requiring permanent adaptation of the applications.

Managing large applications that are heterogeneous, widely distributed and in permanent evolution raises many questions, such as consistent observation, security, tradeoffs between autonomy and interdependence for the different subsystems, definition and implementation of resource management policies.

4. Elements of Middleware

Software components are component interfaces,properties,methods and events. Containers are shared context of interaction with other components and provide access to system-level services.Metadata is self-descriptive information used by a component to flexibly communicate with others.Integrated development environment e.g., VisualCafe for Java

5. CORBA (Common Object Request Broker Architecture)

A middleware platform that supports a standardized OO architecture for software applications are

• Common Object Request Broker Architecture.
• Open standard - developed by the Object Management Group.
• CORBA is a component of OMG’s Object Management Architecture.
• CORBA supports distributed object computing.

CORBA uses a broker which is an intermediary handling requests in a system and facilitates communication between clients and server objects ans also separates a component’s interface from its implementation.

5.1 Main CORBA Features

1. Object request broker (ORB)
2. OMG interface definition language (IDL)
3. Language mappings
4. Stubs and skeletons
5. Interface repository
6. Dynamic invocation and dispatch
7. Object adapters
8. Inter-ORB protocols

5.2 Distributed applications cause a lot of problems like

•Participating systems may be heterogeneous

•Access to remote services has to be location transparent

•State of objects has to be kept persistent and consistent

•Remote objects have to be found and activated

Distributed application have a lot of advantages like scalability(server replication, Thin,heterogeneous clients),Re-usability and Partitioned functionality . So we want an architecture that supports a remote method invocation paradigm,provides location transparency , allows to add, exchange, or remove services dynamically and hides system details from the developer

6. ORB–Object Request Broker

The ORB is responsible for,Data marshaling,Object location management ,Delivering request to objects,Returning output values back to client.

Fig 2. Example Corba Architecture

CORBA is a standard (not a product!) allows objects to transparently make requests and receive responses and enables interoperability between different applications on different machines and in heterogeneously distributed environments.

7. CORBA –(Common Object Request Broker Architecture)

7.1 CORBA design goals

Independence of programming language:hardware platform,operating system specific Object Request Broker,degree of object distribution,
Open Architecture: Language-neutral Interface Definition Language (IDL) andLanguage, platform and location transparent

7.2 CORBA works with interfaces

all CORBA Objects are encapsulated and Objects are accessible through interface only.
Separation of interfaces and implementation enables multiple implementations for one interface

7.3 CORBA is Location Transparent

For the client it doesn’t matter if the object he is operation on is running…
•on the same processor and even in the same process
•on the same processor, in a different process
•in different process on another processor

fig.3 corba architecture

Advantages of CORBA
CORBA allows methods on a remote object to be accessed as if they were on the local machine and is a mature technology, support and tools are widely available.Can deal with heterogeneous systems and legacy-systems can be integrated

Object Location Transparency
The client does not need to know where an object is physically located. An object can either be linked into the client, run in a different process on the same machine, or run in a server on the other side of the planet. A request invocation looks the same regardless, and the location of an object can change over time without, breaking applications.

Server Transparency
The client is, as far as the programming model is concerned, ignorant of the existence of servers. The client does not know (and cannot find out) which server hosts a particular object, and does not care whether the server is running at the time the client invokes a request.

Language Transparency
Client and server can be written in different languages. This fact encapsulates the whole point of CORBA; that is, the strengths of different languages can be utilized to develop different aspects of a system, which can interoperate through IDL. A server can be implemented in a different language without clients being aware of this.

Implementation Transparency
The client is unaware of how objects are implemented. A server can use ordinary flat files as its persistent store today and use an OO database tomorrow, without clients ever noticing a difference (other than performance).

Architecture Transparency
The idiosyncrasies of CPU architectures are hidden from both clients and servers. A little-endian client can communicate with a big-endian server with different alignment restrictions.

Operating System Transparency
Client and server are unaffected by each other's operating system. In addition, source code does not change if you need to port the source from one operating system to another.

Protocol Transparency
Clients and servers do not care about the data link and transport layer. They can communicate via token ring, Ethernet, wireless links, ATM (Asynchronous Transfer Mode), or any number of other networking technologies.

Conclusion:
In this paper ,we have demonstrated how Corba was proved as a succesful interfernce between two peers by supplying information to the platform database, and using open platform services as a temporary replacement for currently specified. CORBA allows methods on a remote object to be accessed as if they were on the local machine and is a mature technology, support and tools are widely available.I t also can deal with heterogeneous systems and legacy-systems can be integrated .