Solving the Integration Problem

The challenge of achieving smooth integration (both internal and external) is a continually evolving task. As new technology evolves, there are more and more technologies that require integration. There have been many technologies that have attempted to provide solutions to integration challenges. Most of these technologies have evolved from the idea of determining a common denominator between all the systems that require integration. We will take a brief tour of some of these integration technologies.

Remote Procedure Calls (RPC)

Remote procedure calls have been used for many years for communicating between programs in different address spaces that are executing on separate machines. RPC utilizes an architecture based on stubs and skeletons, which work in tandem to marshal and unmarshal invocation packets to and from remote services. Common technologies that utilize RPC are the Distributed Computing Environment (DCE) and Tuxedo. Standard interfaces are developed using a pseudolanguage, which is in turn mapped to various supported languages that can either invoke or be invoked remotely. With RPC-based technologies we can begin to integrate our systems, although sometimes proprietary and expensive products have been a requirement, and the developed code and architecture have been largely procedural.

Common Object Request Broker Architecture (CORBA)

The Common Object Request Broker Architecture (CORBA) is a distributed object standard that has essentially brought popular object-oriented methodologies and designs to the RPC architecture. It is also a relatively standardized technology. CORBA was authored by the Object Management Group (OMG). The OMG is a consortium of hundreds of companies, including Sun Microsystems, IBM, Oracle, Borland, and BEA Systems. The OMG has also delivered the specification for the Unified Modeling language (UML), which is used for modeling object-oriented systems.

CORBA defines an object bus, commonly known as an ORB (Object Request Broker), and object services that "plug" into the orb to provide distributed services to applications. Common Object Services (COS) includes naming, transactions, events/notifications, and security. With CORBA, interface contracts are written in a standard pseudolanguage called IDL (Interface Definition Language). IDL is part of the CORBA standard and is a subset of C++.

A further portion of the CORBA specification is mappings of IDL into various different languages, including C++, Java, Smalltalk, and COBOL. IDL is related closely to a standard protocol called IIOP (Internet, Inter-ORB Protocol), which is a protocol that layers on TCP/IP and is used for inter-ORB and CORBA application communication.

It is IDL and IIOP that give CORBA its language independence. Language independence in CORBA allows distributed objects to be written in a wide variety of languages that have mappings, including Java, C++, and COBOL. Objects written in these different languages are able to communicate with each other. Objects can be written to encapsulate some existing functionality of a legacy system. This functionality is now brought into the new object world, and the object is now reusable. Other applications that use this object do not know or care what language the component is written in.

An example scenario is an IDL interface that is implemented by a COBOL application, which "wrappers" some existing mainframe code. A Java Client application could use the CORBA interface and call the COBOL code. CORBA assisted greatly in the development of distributed components and internal integration. Because CORBA is an open standard, it was implemented by many vendors, and it provided some interoperability, although there existed (and still do exist) many incompatibilities among various CORBA products.

Another item to consider when one is creating transactions that are to run over the Internet is security. With today's vast array of network-based viruses, most network administrators have strict network firewall policies that restrict a great deal of traffic that flows through a corporate firewall into an enterprise. IIOP is a protocol that is not accepted by most firewalls.

CORBA gave us integration between languages but introduced some product-related protocol compatibility problems. It also required that everyone adopt and potentially pay for a potentially expensive CORBA ORB, and the required manipulation of the corporate firewall could also be a significant factor to consider.