View Source Magazine

APPLYING CORBA IN THE ENTERPRISE

PART 1: INTRODUCTION AND OVERVIEW

By Bob Schlicher

Send comments and questions about this article to View Source.

By now you've heard and read something about the Common Object Request Broker Architecture (CORBA). You may even have used it to provide an integration solution to some component of your enterprise. Depending on your perspective, you probably discovered that one of the biggest challenges to getting started and further developing a set of distributed computing skills has been overcoming a steep learning curve. This isn't a surprise, since CORBA covers a significant amount of information system technology, including such things as interface specifications, object communications, reference repositories, and business object services -- just to name a few. In this high-paced technology world, we're always learning, no matter what curve we have to face. The CORBA curve is one of many to surmount, but it's well worth your time and energy.

If you consider the information system you're familiar with, including the changes that it has undergone and will undergo (usually due to market forces and technology improvements), you'll realize that the framers of CORBA intended to solve and facilitate a significant set of the activities involved in the life cycle of an information system. These include, but are not limited to, such things as

integration with legacy systems -- protecting investments
integration with CORBA-based objects and servers
facilitating migration strategies -- making the transition from legacy to more modern systems
management and maintenance for operations
standard system interface specifications

Few are the large systems today that do not face change and some major legacy issues.

If you have some familiarity with CORBA or have used CORBA implementations (ORBs, IIOP, and so on), you probably have some understanding of where it fits in the scheme of things. CORBA is a standards-based integration technology -- "middleware" -- but it's more than that. It has the potential to be the foundation for the enterprise-wide infrastructure. It also has the potential of finally freeing application developers from having to worry about the underlying communications and the ever-so-common problems of matching data formats.

Why does CORBA have so much promise, and what are its chances of succeeding? In addition to Netscape's commitment to CORBA, many other factors are contributing to its widespread acceptance and usage. The Object Management Group (OMG), the creator of the CORBA specifications, consists of some 700 members representing software and hardware companies, government organizations, and technical interest groups. Thus, CORBA is founded on an industry consensus. But even that isn't enough to guarantee ubiquitous presence. Since it's nearly the only standard in the middleware arena, it serves as a development risk mitigation tactic for distributed system managers and developers. Furthermore, CORBA was designed to accommodate the integration of legacy systems, thus enabling a successful coexistence of multiple technologies and facilitating migration strategies and planning.

This series of articles on CORBA is for those who have some familiarity with developing distributed, object-based systems (for example, client-server systems) and would like to enhance their understanding of the role of CORBA in the enterprise -- how it's being used and how it fits in with the system development phases of the life cycle. The articles discuss how to apply CORBA, not only as a communications solution, but additionally as an infrastructure consisting of multiple, cooperating frameworks. CORBA provides specifications for quite a number of functions; it is without doubt large in scope. To effectively exploit its potential for solving your enterprise needs, it's necessary to explore the important software development activities that best lead to applying the CORBA technologies.

This article provides a discussion of general system requirements based on a summary of several real-world CORBA examples from various corporations. The article's main objective is to help you understand how CORBA is being applied in different industries and to demonstrate the common usage of CORBA across the industries -- that is, its "horizontal" character. Furthermore, this article is intended to give you an additional appreciation, if you had one before, for the architecture that CORBA specifies in its services and domains.

For those who are just starting out or who need a refresher, a cursory introduction to CORBA is provided. Since most of the CORBA literature provides detailed descriptions of CORBA's architecture and parts, this article just covers the basics and concentrates on describing what you need to know to use CORBA. For details on CORBA, see the texts Instant CORBA by Robert Orfali and Inside CORBA by Thomas Mowbray. For more details on the rationale behind CORBA and the Netscape visions, refer to CORBA: Theory and Practice by Paul Dreyfus.

Subsequent articles in the series will introduce you to a development approach, but will intentionally leave out the details you might find in a typical methodology; you'll probably find it useful to understand the phases of software development without getting too bogged down in the noise of the details. To encourage the approach, an example -- an automated billing system -- will be used to illustrate requirements and problem analysis.

Future articles will also elaborate on the analysis, design, and coding phases in the development approach. Through the same billing system example, you'll learn about useful analysis techniques and about translating the analysis results to a design and then finally to the code. One article will focus on the CORBA Transaction services and exception handling, and will stress the importance of these services in the enterprise and illustrate how to best incorporate them into your enterprise. The series will also discuss other important services, including the Persistent Object, Query, Concurrency, and Security services, and the Common Management facilities. Throughout, the series will use the billing system as the example, with the intention of reducing the learning curve you might be facing. >From this series of articles you should be able to better apply CORBA to your enterprise needs in all phases of any development cycle.

OVERVIEW OF SOME CORBA USES

CORBA is being used in most if not all vertical markets. It appears that, in general, the most widely deployed capabilities of CORBA at the present time are its communications components -- the ORB (Object Request Broker) and the Naming service. Most would agree that this is because these two services are mature enough to use; the rest of the CORBA specifications and implementations are still to come.

Nevertheless, this section describes some of the projects using CORBA in new developments and integration. Perhaps one or some of these descriptions are similar to work you're performing or will perform in the near future. The end of the section summarizes the activities into a set of general requirements and identifies some key CORBA actions that occur to support such requirements.

Finance

A financial corporation is reengineering its credit card and data processing system. CORBA technologies are being used to replace a collection of legacy systems, consisting mainly of mainframes. The target system is a distributed three-tiered architecture utilizing Java, web browsers, and ORBs. The system usage is growing at an alarming rate and has to be flexible to respond to rapidly changing business requirements. The infrastructure consists of other middleware solutions, including MQSeries Messaging from IBM and a transaction monitor, which require integration. Through a migration strategy, the legacy applications will be "wrapped," so that newly introduced CORBA-based applications can use their services.

Petroleum

A major petroleum company is using web and CORBA technologies to unify its large collection of databases consisting of geological, seismic, and drilling information. These databases consist of different types of data formats and have proven difficult to integrate and manage. There is no standard mechanism in place for unifying this data so that a client may simply access them to perform application-based analysis. Each such application must use a unique interface for each data source. Using the CORBA wrapper approach, information from each database is translated to a common format, so that a user has a consistent and reliable mechanism for obtaining the information without any concern for compatibility issues.

Health

A medical application supports the real-time interactive collaborations between physicians located remotely from one another. Physicians can simultaneously view, edit, and annotate patient data. They can engage in electronic discussions so that referrals and consultations are performed efficiently and naturally. This system is implemented with Java-based ORBs embedded in the web browsers. The application calls for full transaction processing. The ORBs are used by the client applications to obtain information from multiple data sources so that the users can view and manipulate it in one place.

Telecommunications

A telecommunications company is upgrading its existing middleware solution to CORBA while preserving its legacy components for an automated customer billing system. Much of the data and logic currently exists in the legacy mainframe components. The new architecture calls for a client-server configuration, where the server principally hosts the business logic and the client provides the presentation of information to the user. Through the use of ORBs and a wrapper strategy, the mainframe services are now integrated with the client-server implementation.

Summary of Usage Requirements

From these examples, we can summarize and extract a set of general system requirements that are not specific to any one industry; this demonstrates the commonality in the infrastructure and points out that solving these problems is what CORBA is about. Such commonality is referred to as being "horizontal" --that is, applicable to a broad range of business system problems. We can also identify the types of detailed CORBA actions that are performed to support these requirements. Here is a summary of the business requirements from the previous cases:

n-tiered, client-server architecture
business processing on the server
data visualization and reporting on the client
preservation of and integration with legacy systems
migration from legacy systems to more modern systems
consistent data interchange and formats
persistence services to and from databases
transaction services

From these brief requirements, we can infer the underlying mechanisms that may be expected of a CORBA-based environment:

client objects invoking remote object methods
client objects automatically obtaining remote object references
performing server activations
load-balancing distributed services
executing callbacks and asynchronous notifications
performing transactions
handling and propagating exceptions and errors

How did we get from the requirements to these mechanisms? This is the process of analyzing and identifying key software development activities in a project, which I'll cover in the next article. Before answering that question in any sort of detail, we must proceed with a review of CORBA.

Now you should have a general understanding of how CORBA is being used, the types of problems that some large projects are facing, and some of the detailed mechanisms that must be realized in a CORBA environment. In order to get into details about these mechanisms, it's important to understand the CORBA pieces and the functions each piece performs.

THE CORBA PIECES

CORBA includes a significant number of services beyond just communications. It's the first industry standard for a distributed, object-oriented infrastructure that's designed to have common, reusable services. CORBA is a type of middleware categorized as Distributed Object Management (DOM) -- services that provide an object-oriented interface on top of the basic distributed computing capabilities.

Much of a typical project team's concern about adopting or evaluating CORBA is that there is a significant learning curve. Indeed, there are a lot of pieces here. However, when you consider CORBA's scope and its well-planned architecture, you'll begin to appreciate that it in many ways helps you concentrate more on solving your business problems rather than spending your time on the underlying technical infrastructure problems.

Consider the example of a recent insurance project, whose purpose was to improve the processing of insurance claims, the handling of sales, and the managing of policies. However, the project committed an impressive investment into the development of a persistence framework. Not only did this development effort consume resources and time, but its unforeseen complications delayed the entire project, resulting in serious schedule slippage. As a consequence, senior management realized that the company was not in the infrastructure business, and is now evaluating commercial products so that the company can focus its resources on solving insurance problems.

As a starting point for describing the CORBA pieces, the Object Management Architecture (OMA) is illustrated in Figure 1. The OMA serves as the software reference model in a familiar layered pattern, similar to the seven-layered Open System Interconnect (OSI) model that has been successfully used by the network engineering community. The reference model is important in that it enables engineers and other professionals to communicate with some consistency and clarity about the complicated matters of the enterprise.

Figure 1. The Object Management Architecture

The OMA is the architect's tool for mapping infrastructure requirements to service specifications and addressing distributed, object-oriented challenges. The Object Request Broker (ORB) and four other parts constitute the OMA:

The Object Request Broker is responsible for transparently routing requests among distributed objects. Objects are unaware of the communications mechanisms and the physical location of the service they're using.
CORBA services are general-purpose services that can be used by any application. They're the basis for application interoperability.
CORBA facilities are common facilities that are applicable to most application domains. Such capabilities are referred to as being "horizontal" in that they are useful in solving a broad range of business requirements.
CORBA domains are services that are generalized and useful within a specific vertical market (for example, telecommunications, finance).
Application Objects are software specifically designed to solve a business problem. These objects make use of the services, facilities, and domains as required.

Some of the confusing aspects about CORBA are the use of the term itself and the apparent overlap in definitions of CORBA services, facilities, and domain. First, some professionals use the term CORBA to refer just to the ORB or its communications mechanisms. But CORBA is significantly more: It provides a business infrastructure solution. Second, while the CORBA domain is fairly straightforward -- it includes the interfaces for domain-specific use (for example, finance, insurance, telecommunications) -- the distinction between services and facilities is not very clear. The first thing to note is that the service and facilities specifications are driven from different perspectives. The service specifications attempt to address issues related to infrastructure and portability; they are the building blocks for distributed applications and can be used together to construct higher-level services. The facilities concentrate on broad technology areas such as interface management, information management, and system management. Facilities can be configured to meet the requirements of a specific business environment. The key difference between them is that services are fundamental capabilities reused not only by applications but also by facility and domain services.

At present, there are 15 CORBA services in various states of completion. Instead of describing each of them, it's best to present them as they're categorized in the Object Request Broker-Object Service (ORBOS) architecture, as shown in Table 1. In contrast to some groupings that you may have seen, which organize the services by the date at which they were adopted by the OMG, ORBOS categorizes the services by their architectural relationship and functional capabilities. (It makes more sense to organize them just as you are going to use them.) The four categories of services include infrastructure, information management, task management, and system management. The infrastructure category includes services that are closely related to the ORB functions. The information management category is for data processing, storage, and retrieval. The task management category includes services for managing events and transactions. The system management category enables the management of the object life cycle, metadata, and licensing. (For more information on the services and ORBOS, see Inside CORBA.)

**Table 1. The ORBOS architecture**
Service category	Description	CORBA services
Infrastructure	Includes services related to the ORB mechanisms	Security, Timing
Information management	Includes services with basic capabilities for retrieval and manipulation of data	Persistent Object, Externalization, Properties, Relationship, Query, Collections
Task management	Includes services to permit management of distributed object events and transactions	Event, Transaction, Concurrency
System management	Includes services for the management of metadata, licensing, and object life cycle	Naming, Trader, Lifecycle, Licensing

Note: For the purposes of this discussion, only the CORBA services are listed; however, the ORBOS includes services that are found in the ORB as well.

Are some services more important than others? To this question, you'll get many different answers depending on the problem domain, the business environment, and the requirements. However, some of the fundamental services you should expect to encounter include the Naming, Transaction, Security, and Event services. You probably already noticed some of these services in the mechanisms identified earlier in the overview of CORBA uses.

No discussion of the CORBA pieces would be complete without a mention of the Interface Definition Language (IDL) and the Internet Inter-ORB Protocol (IIOP).

IDL. Some consider IDL to be the most important part of CORBA. IDL is a universal notation for software interfaces (application programming interfaces); it's used for every specification that the OMG adopts. IDL is not implementation; however, there are many language bindings (C++, Java, Smalltalk, Ada) that translate IDL to the proper constructs for the language. Finally, IDL makes it possible for client software to be completely separated from object implementations (on the server), which greatly increases the chances for reusability. IDL has its shortcomings, which include not being able to describe meaningful relationships among objects. The OMG is addressing this problem, as evidenced in the organization's recent adoption of the Unified Modeling Language (UML), the emerging standard object-oriented modeling language.
IIOP. IIOP is the communications protocol that allows vendor ORBs to successfully interact over the Internet. As implied by the term Internet in its name, IIOP runs on top of TCP/IP and is normally transparent to the developer.

A FEW MORE CORBA TERMS

So far, this article has mentioned quite a number of CORBA terms related to the architecture; understanding the OMA and the components that constitute it is essential for designing CORBA-based enterprises. In addition to these "enterprise-level" terms, here are some terms associated with the ORB and its functions.

A client is a software entity that performs an operation on an object.
An object implementation is the code and data that implements an object whose interface is specified in IDL.

The client invokes a behavior of an object without any concern for how or where that behavior is carried out. The ORB is responsible for this "how and where" -- that is, it performs the communications routing between the client and object implementation, as well as additional services required to perform the communications. From the client's perspective, it has what is called an object reference for the object it wants to invoke and also knows its interface. It's up to the ORB to translate the object reference to the actual object implementation, locate that object implementation, and pass the request to it.

Clients invoke the object implementation through the ORB using either the Static Invocation Interface or the Dynamic Invocation Interface. These are defined as follows:

The Static Invocation Interface (SII) is the client stub interface to the ORB that is used to invoke the object implementation. Services that are accessible through the SII are defined at compile time.
The Dynamic Invocation Interface (DII) is the interface to the ORB that allows for dynamic construction (run time, rather than compile time) of object invocations.

An object implementation can access services provided by an ORB through an object adapter. Such services may include generation of object references, method invocations, object activation and deactivation, and mapping of object references to implementations. CORBA provides a basic object adapter -- a defined interface between the ORB and the object implementation -- but developers can create their own custom adapters as needed.

CORBA involves more terms, but this introduction should be sufficient for you to get around with the OMA and the interfaces to the ORB. Other terms will be defined and discussed as they emerge in later articles.

SUMMARY

At present, CORBA is primarily used as a communications mechanism that simplifies the effort of distributed computing in the networked environment. With an ORB, an object can invoke another object without any knowledge of the object's location or the mechanism for how it gets invoked. The end result is that you can view the networked set of computers (for example, computers connected via the Internet) as a single, integrated computing resource. CORBA is significantly more than a communications mechanism -- it's an infrastructure technology. This article has also described CORBA as the specification for many of those common functions that have been designed and built many times by many different vendors and software teams.

The next article will describe a simple object-oriented development process for applying CORBA and provide a real-world example to walk you through the process. You'll analyze the billing system problem by defining the problem, extracting and discovering objects and behaviors, identifying those behaviors with respect to the OMA, and exploring design implications.

FURTHER RESOURCES

Dave Curtis, "CORBACorner: Java, RMI, and CORBA," Java Developer's Journal 2, no. 6: 46-49.
Paul Dreyfus, "CORBA: Theory and Practice," View Source.
Thomas Mowbray, R. Malveau, CORBA Design Patterns (John Wiley & Sons, 1997).
Thomas Mowbray, W. Ruh, Inside CORBA, Distributed Object Standards and Applications (Addison-Wesley, 1997).
Robert Orfali, et al., Instant CORBA (John Wiley & Sons, 1997).

View Source wants your feedback! Write to us and let us know what you think of this article.

Many thanks to Mike Lee and Anne Szabla for their assistance in preparing this article.

Bob Schlicher is a principal software engineer with AlterNet Communications, a consulting firm that specializes in design, development, and integration of distributed business applications using middleware solutions. He is presently consulting and developing distributed enterprise solutions for CSX and Owens Corning.

(2.98)

DevEdge Online FAQ
Developer Response Center
Join DevEdge Program