In-Depth

Integrating CORBA

• 08/01/1999

Integration of databases, applications and legacy systems in real-time and batch is one of the biggest challenges facing IT managers today. Issues related to mergers and acquisitions, packaged applications and the transition to process-centric computing drive integration.

Numerous approaches to address the $4 billion application integration challenge have been suggested. Solutions vary from implementing packaged applications, like enterprise resource planning (ERP) systems, via greenfield development to host-based screen scraping. In most approaches mainframe systems are considered old, redundant, costly and inflexible. This is strange, considering that mainframe applications are at the heart of most large-scale mission-critical systems.

This article provides information on how organizations can integrate and leverage an organization’s most valuable enterprise IT resource: mainframe applications. After reviewing the rationale behind application integration, the business and technology benefits of using CORBA, a comprehensive standards-based solution, are described and compared to two other approaches: remote data access and MQSeries.

Most business applications have been written. Is there a need to build yet another mortgage calculation program? Do you really have to rebuild an accounts receivable application from scratch? The processes for performing such tasks are well understood, optimized and captured in applications. True the application may not be perfect, an attractive graphical user interface may be missing, Internet connectivity may be unavailable or the skills needed to maintain the application might be hard to find. However, the logic – the heart of the application – is just as valid today as it was yesterday.

Information technology is a core element to the success of any business, and often used as a competitive advantage. Rapid changes in the business climate are forcing IT organizations to adapt quickly to this continually evolving environment. From a business perspective IT is not only viewed as an opportunity but also as a liability. Mainframe application development is often used to illustrate the slow speed of change, inflexibility and high costs associated with IT.

Information is a perishable item. Hardware and software age and become obsolete quickly. Aging is especially critical for applications, since these are the core of IT and hard to replace. Hardware facilitates running applications, but has limited influence on the fundamental business processes of a company.

To stay competitive companies must be able to make application changes quickly. They must do so in a cost-effective manner, and preferably leverage existing systems. Reusing an existing system, perhaps with some extensions or modifications, is preferred over greenfield development. This leverages the initial investment, reduces test time and shortens time to market. Middleware is the way to achieve these goals.

Middleware is a general term for any tool that serves to "glue together," mediate between or enhance distinct, existing programs. Middleware is such a generic term that it is difficult to apply a concrete definition to the category. There is consensus that middleware is the key element in meeting the challenges of application integration and distributed computing.

From a technical perspective, middleware provides an isolation layer that shields application developers from different network protocols and application programming interfaces (API) by presenting its own consistent layer of APIs. In effect, middleware decouples applications from any platform or language-specific APIs.

On a business level, middleware can increase the value of IT for organizations as follows:

• "Future Proofing" applications. Build applications today that can be used tomorrow, a year from now and beyond. To realize this potential, applications should be based on an open standard, not on the product of one vendor.

• Best of Breed. There is not one technology or package that will satisfy the information technology needs of a company now or in the future. Companies need to have the flexibility to select and use the best technology for the job.

• Combine new and existing systems. This includes mixing and matching "plug-and-play" software.

• Leverage investments. The benefits listed above leverage the investment in technology and people, which in turn positively affect both the top and the bottom line.

Myriad approaches to linking applications together have been devised. When mainframe applications are involved, methods like (host-based) screen scraping, remote data access and MQSeries are popular. The last two approaches are compared to a CORBA solution.

Remote Data Access. Remote data access (RDS) is a general term for an approach where commands, usually SQL, are sent from a client process to a remote database. Applications in this category often use Open Database Connectivity (ODBC) to provide standardized access to datastores. Using ODBC, or the Java equivalent (JDBC), an application can access in a standard manner a wide variety of file formats including flat, sequential and indexed. It can also similarly access databases such as DB2, Oracle and Sybase. The ODBC driver hides the implementation of the datastore from the application.

Implementing RDS results in applications that can be characterized as two-tiered and tightly coupled. Client applications are rather "fat" – they contain all the presentation and business logic, as well as all the components necessary to access the datastore.

Two-tier applications can be generated quickly and the skills needed for such projects are readily available. However, this type of application can be inflexible because of the tight relationship to the underlying datastore. Software distribution becomes a major task, while scalability is lacking because of point-to-point connections. Lastly, this approach is focused solely on accessing data and not on reusing the valuable business logic that is contained in applications.

Data is only one of the application components. The application logic, the process that creates and manipulates data, is not a part of an RDS approach and therefore must be re-implemented in the client application. For example, when a CICS program puts data in DB2, the data is the result of actions executed in the CICS applications. Providing remote access to the data in DB2 ignores any business logic in the CICS program. You will have to replicate or re-implement all this logic in another place, usually in the client application.

MQSeries. MQSeries (MQ) belongs to the middleware subcategory of messaging. Especially on OS/390, MQ is a popular way to integrate applications. MQ is a messaging-based transport that moves binary data from point A to point B. It has two basic properties: guaranteed message delivery and the ability to send a single message to multiple receivers.

Message queuing makes it possible to interconnect applications. For example, applications can send messages; however, maintaining a map of all possible connections is complicated, and MQ by itself does not integrate applications.

The OSI model illustrates the role and place of MQ. (Editors Note: the OSI Model is comprised of the following seven levels: 1 - Physical; 2 - Datalink; 3 - Network; 4 - Transport; 5 - Session; 6 - Presentation; 7 - Application.) Message queuing systems like MQ fit in at the transport (level 4). To integrate applications (level 7) developers must do additional work. For example, MQ developers must decide on which message format to use. Utilities, like parsers and converters, are required for all the different platforms and languages that are part of the configuration.

Neither remote data access nor MQSeries provide a solution that leverages business knowledge contained in applications. While both approaches can be qualified as middleware and provide partial solutions, neither fully addresses the need for application integration.

In 1989, the Object Management Group (OMG), a consortium of more than 800 independent vendors, was established. From the beginning, the goal of the OMG has been to provide an infrastructure for the interaction of applications in a heterogeneous environment. The term heterogeneous refers not only to the diversity of networking and operating systems, but also applies to the diversity in programming languages used today.

The OMG developed the Object Management Architecture (OMA) to achieve the goal of application integration. Within the architecture the object request broker (ORB) plays a central role. The ORB allows clients and servers to interact in a standardized fashion. Since the ORB is key within the architecture, it was standardized first and is known as the Common Object Request Broker Architecture, or CORBA.

An ORB is a software component that mediates the transfer of messages between programs. The role of the ORB is to hide the underlying complexity of network communications from the programmer. The ORB allows the creation of standard software objects whose member functions can be invoked by client programs located anywhere in a network. A program that contains instances of CORBA objects is often known as a server.

When a client invokes a member function on a CORBA object, the ORB intercepts the function call. The ORB redirects the function call across the network to the target object. The ORB then collects results from the function call and returns these to the client.

CORBA can be described as the "Middleware that is everywhere." Key benefits CORBA delivers are independence of language, location and platform. For example, a COBOL application running on OS/390 can seamlessly communicate with a hand-held device running a Java applet. CORBA allows for application integration, and subsumes transport mechanisms, like MQ, or any remote data access approach, thus allowing developers to focus on business applications.

Technically, two concepts are at the heart of CORBA, the interface definition language (IDL) and the Internet Inter-ORB Protocol (IIOP). IDL specifies a contract between applications. The service an application provides is expressed in IDL. For example, an application that handles bank accounts provides the service of creating, deleting, and modifying accounts and offers options to deposit or withdraw money, given the account number. In IDL this service is expressed as:

//

// a simple description of a bank account

//

interface account {

};

//

// a simple description of a bank current

account

//

interface currentAccount : account {

readonly attribute float overdraftLimit;

};

//

// a bank simply manufactures accounts

//

// bank::reject is raised if a duplicate

// account name is seen

//

interface bank {

exception reject {string reason;};

account newAccount (in string name)

raises (reject);

currentAccount newCurrentAccount (in

string name, in float limit) raises (reject);

void deleteAccount (in account a);

};

Essential to IDL is the separation between interface and implementation. IDL specifies what service is provided, but not how this is implemented, or where the service is located. This provides freedom to select the appropriate programming language, platform and location within the network to run the application. Using these features IDL enables modification, or even rehosting of applications without changing the clients that access the application.

Building interfaces using IDL is the first step in developing a CORBA application. Depending on the type of IDL compiler, C++, Java or COBOL is then generated from IDL definitions. The generated code includes client stub code, which allows for the development of client programs and skeleton code used to build the server component.

IIOP, a layer on top of TCP/IP, ensures that data is represented in a uniform way when it travels over a network. As a result, developers do not have to worry about formatting, parsing or converting data when it is sent between machines.

CORBA is an architecture that can run on any platform. An ORB on OS/390 then allows for the rapid seamless integration of existing, proven, mission-critical applications with emerging technologies. The ORB allows for quick adaptation of existing, proven systems to changing business requirements and can also be the starting point for internal process redesign, Web-enabling applications or rehosting applications on alternative platforms. Having an ORB on OS/390 allows for the building of modular, scalable and extensible systems.

Vendors like IBM (ComponentBroker), Inprise (VisiBroker for OS/390) and IONA (Orbix for OS/390) provide ORBs on OS/390. The products differ in maturity and support for mainframe languages and environments. To maximize the benefits of CORBA on OS/390, an ORB must support the following functional characteristics:

• COBOL, C++ and, optionally, PL/1. COBOL is, by far, the most widely used language on OS/390. Using familiar programming paradigms flattens the learning curve and leverages existing development skills. Note that in order to use COBOL and CORBA together, the COBOL application elements are objectified.

• UNIX System Services (USS) and native environment. Most existing applications run in the native environment (batch, TSO). However, increasingly new applications are developed to run in USS. The ORB must fully support both environments.

• Integration with CICS and IMS. The ORB should provide options to allow easy integration of existing and new CICS and IMS applications.

Four distinctly different environments (USS, native, IMS and CICS) can be identified on OS/390. The ORB can support USS and native environments with the appropriate language bindings; for example, C++ for USS and COBOL for native. Key to most applications in OS/390 is access and reliance on the facilities offered by IMS and CICS. Both environments are key to transactional systems, and are responsible for some of the largest high-performance applications.

The ability to seamlessly include existing transactional systems in a CORBA infrastructure is a key requirement for an ORB. In that scenario, for example, a CICS transaction can be accessed through an IDL interface. This allows any client process to access CICS as if it were a regular CORBA service.

Including IMS and CICS in a CORBA infrastructure is done via a special adapter or plug-in, which shields the client from being aware that the server is implemented under IMS or CICS. The client application simply deals with the IDL interface as before. For example, a CICS adapter can forward a client request to CICS. This type of adapter usually runs in a separate address space and maps IDL operations to a CICS program in a particular region.

Communication between the adapter and the CICS application is handled using the external call interface, and input data is provided via the COMMAREA. A round trip remote invocation from client to CICS in CORBA would follow these steps:

• The client application is a regular CORBA application, and is usually not aware that the server is implemented as a CICS COBOL program.

• The client invokes an operation on the CICS adapter.

• The CICS adapter maps the interface and operation name to a CICS program.

• A COMMAREA is used to communicate with the CICS program; the CICS program executes and returns results to the Orbix CICS adapter.

• The CICS adapter returns the results back to the client.

Clients accessing IMS transactions would follow similar steps.

Many CICS systems are essential to organizations, which makes code changes difficult. Using an adapter, it is possible to make existing CICS and IMS programs function as CORBA applications without code changes. For example, adapters can export special IDL interfaces to allow either a client or an intermediate object-wrapper server to build a CICS COMMAREA and pass it directly to a CICS program.

Adapters can be viewed as specialized CORBA servers that remove the need to build low-level application infrastructure. Adapters add CORBA functionality to existing applications, while maintaining key features like scalability, reliability and performance.

About the Author: Dirk Hamstra partners with DOOSYS IT Consultants. He can be reached at dhamstra@doosys.com.