Distributed Objects and Application Integration

Distributed object technology has been around for nearly a decade. It creates an infrastructure for sharing methods by providing an additional location for application processing and for interoperability among processes. In addition, it provides a standard mechanism to access shared objects, objects that run on any number of servers. As a result, its usefulness to method-oriented application integration should be clear.

As part of the application integration solution set, distributed objects enable architects to create both applications that share common methods and composite applications that support method-oriented application integration. The integration of applications by sharing a common business logic "application integration nirvana" lies along this path. But it is hardly a smooth path. As we have already suggested in any number of contexts, the path is always risky and studded with expensive obstacles.

Moreover, take note that Web services, at their core, are distributed objects. Thus, the information discussed in this section is a good primer for our detailed discussion of Web services later in the book. Note the similarities.

What Works?

Distributed objects work best in application integration problem domains where a distributed computing model is in use and a large number of common methods need to be shared. For example, an enterprise may have the following four major applications:

• Customer tracking system (Company A)

• Logistics system (Company A)

• Sales database application (Company B and Company C)

• Inventory planning system (Company C)

Although each of these applications functions independently, they have a number of methods in common, methods that may include

 Add_Customer() Edit_Customer() Delete_Customer() 

For these methods to be shared, an additional shared application layer must be created (physical or virtual). This layer must possess the enabling technology that allows applications to share methods over the Internet. Application servers, TP monitors, or distributed objects are the best options for such a layer. As we suggested earlier, each has advantages and disadvantages that need to be evaluated.

If method-oriented application integration is the chosen approach, then the application integration architect and developer may seek to create a set of distributed objects that house these common methods. Using a common structure, interface, and communication mechanism (e.g., IIOP or RPCs, which are discussed later in this section), distributed objects provide the enabling technology for sharing these methods (see Figure 7.12).

Figure 7.12. Using distributed objects.

What's So Difficult?

Because we have become familiar with the workings of the marketplace, it should come as no surprise that distributed object vendors are quick to suggest that using distributed objects is easy. According to them, it's simply a matter of changing several applications and exposing application methods using distributed object technology for access by other applications or, more commonly, among the distributed objects themselves. What could be simpler? Plenty. For this method to be successful in an application similar to the previous example, the common methods would have to be stripped from all the enterprise applications and redeployed within some sort of distributed object technology. Code would have to be changed everywhere. Each application would need to be tested and then redeployed.

This is a monumental task. It may be worth the effort if it ultimately achieves the business objectives, but it is hardly simple. And it is not a good fit for most application integration problem domains. Distributed object-based application integration is an invasive integration approach. Many changes must be made to accommodate this technology. As a rule of thumb, invasive middleware doesn't cut it when it comes to application integration. But as in all things, there are no absolute rules, and in some cases, this is the right solution.

Before moving forward, however, consider this truism: A solid business case must be made to justify leveraging method-oriented application integration and enabling technology such as distributed objects. Distributed object technology might or might not be simple or worthwhile. The only "objective" way to be sure is to use this calculus: assess what is to be gained from the application integration project against the resources necessary to complete the project. If the resources required far exceed the gain, then other application integration levels are likely to be better approaches. However, if it appears that the return on investment is there, then method-oriented application integration is the most elegant of application integration solutions.

The failure in too many organizations is the absence of strict candor and realism in making such an assessment. Organizations that talk themselves into application integration projects using distributed objects based on exaggerated claims by the media or by vendors are very often in for a rude awakening. Failed distributed object projects outnumber the successes. That's the reality. No hype.

What's So Easy?

Once we understand the disadvantages of distributed objects, we should focus on the many advantages. The greatest advantage of distributed objects is their adherence to an application development and interoperability standard. CORBA, COM+, and Web services (we discuss only CORBA and COM+ in this chapter) are specifications, not technologies. Vendors adhere to the established standard and therefore provide a set of technologies that can interoperate. Because the standard is open and the interfaces well defined, vendors discover that interacting with distributed objects is not difficult.

As distributed object technology continues to mature, vendors add new features that address previously acknowledged shortcomings, such as scalability, interoperability, and communication mechanisms. Distributed objects now provide better scalability through the ability to support transactions. As a result, they offer the same scaling tricks as application servers and TP monitors. OMG now endorses CORBA's Object Transaction Services (OTS). Microsoft expects AppCenter to bring transactionality to COM+. Interoperability continues to improve as common protocols are defined, including CORBA's IIOP and Microsoft's COM+ RPC (loosely based on the DCE RPC). Objects created by different vendors can share information by using a common object-to-object protocol as the least-common denominator. Finally, where traditional distributed objects leverage simple, synchronous communication mechanisms based on the RPC (as is the case with both CORBA and Microsoft), they now provide asynchronous messaging mechanisms, as well. (CORBA provides its own message service as part of the standard, while Microsoft is learning to leverage MSMQ as a way to bring messaging to COM.)

Thus, distributed objects, which were once difficult to deploy and provided few advantages over more traditional alternatives, are now easier to use and provide many more features that benefit an enterprise development technology. In short, distributed objects have become a key enabling technology (in addition to transactional middleware) for method-oriented application integration.

What's a Distributed Object?

Several trends contribute to the potential benefit of distributed objects for application integration.

• The move toward multitier application development. Developers are beginning to realize that the enabling technology of distributed objects "gets them there." Distributed objects give application integration architects and developers the ability to create portable objects that can run on a variety of servers objects that can communicate using a predefined and standard messaging interface over the Internet. This aspect of distributed objects has remarkable potential for application integration.

• In the recent past, CORBA was the only real standard available (see the "CORBA Internals" tidbit later in this chapter). Microsoft's entry into the distributed object marketplace with COM+ provides a distributed object infrastructure and the ability to tie applications created with traditional tools with a Windows-based operating system. (The Object Request Broker, or ORB, is part of the operating system and therefore a give-away.)

• We learned to bring ORBs to the desktop through the use of application components, such as ActiveX. By mixing and matching components, developers can piece together an application like a jigsaw puzzle. This is the nirvana of application development: the ability to assemble applications the way the Ford Motor Company assembles Mustangs from prebuilt component parts.

• The rise of the Web renewed interest in distributed objects. Technologies and standards, such as CORBA's IIOP, promise to provide both an enabling technology for dynamic application development and a better application-to-application, object-to-object transport layer. Now that powerhouse Web companies such as Netscape have put their weight behind ORBs, Web developers will increase their rush to ORBs.

The General Idea of ORBs

With so much depending on ORBs, it seems particularly appropriate to address the question, What exactly is an ORB?

Object Request Brokers provide developers with standard objects to communicate with other standard objects, using a standard interface and line protocol. Like traditional objects (such as those found with C++, Java, or Smalltalk), ORBs can access the methods of other ORBs either locally or over a network (see Figure 7.13). ORBs can also exchange data and are platform independent.

Figure 7.13. ORBs can access methods of other ORBs locally or over a network.

A CORBA ORB can pass requests from object to object. One invocation method is for the client to invoke ORB services through the ORB core and the Interface Definition Language (IDL) stub. Another method is through a Dynamic Invocation Interface (DII) stub. A stub provides mapping between the language binding (e.g., C++ and Java) and the ORB services. Specific instructions are given to the ORBs through this process.

At this point, the ORB core moves the request to the object implementation, which receives the message through an up-call, using an IDL skeleton or a dynamic skeleton.

CORBA Internals

My goal is not to add to the already voluminous information available about CORBA. Instead, I hope to provide an overview of distributed objects and their application-to-application integration. If you are considering CORBA (or COM) as the enabling technology for an application integration project, this information should help you.

A CORBA ORB contains four main parts (also see Figure 7.14):

• ORB

• Object services

• Common facilities

• Application objects

Figure 7.14. Four parts of the CORBA ORB.

These same features exist in other ORBs, such as Microsoft's COM+ and proprietary ORBs.

ORB

The ORB is an engine that shares information with other ORBs. Together, these "engaged" ORBs create a distributed object. ORBs exist as background objects, functioning behind the application. Applications are also layered on top of ORBs, providing the distributed infrastructure. This is the reason ORBs make such effective middleware layers many communication services already exist in ORB services (such as CORBA-compliant ORBs). Layering also provides heterogeneous application portability and interoperability, the feature that makes ORBs most valuable to application integration.

Object Services

CORBA mandates object services, which are groups of services that leverage object interfaces for communication between services. The basic services that developers expect in an ORB are security, transaction management, and data exchange. Developers use object services as a base class upon which to build applications.

Common Facilities

Common facilities, optional for CORBA, are a collection of services that link with the client. Common facilities allow developers to build component characteristics in CORBA-compliant ORBs. Developers consider common facilities whenever they need to implement CORBA-compliant component-based objects.

Application Objects

Application objects support the application development features of a CORBA ORB, as defined by the ORB developer or application developer. Here "the rubber meets the road" in ORB development ORBs can be turned into something useful. These features are built into ORB with the IDL, which ensures interoperability with other CORBA-compliant ORBs.

COM+

The dynamic that currently drives the distributed object world and complicates it is the emergence of Microsoft's COM+, along with the further development of Microsoft's ORB into COM+. And Microsoft being Microsoft, emotion and power plays are in full view. Although a great ORB debate is raging with high emotion on either side, the bottom line is that COM is as much an ORB as CORBA. Microsoft very effectively devised COM, using its existing Object Linking and Embedding (OLE) model as its basis of design.

ORB provides an object standard that really isn't object oriented (e.g., that has the ability to support inheritance), but then, neither is CORBA. It also provides a common mechanism for inter-ORB communication. COM+ is based on automation (using the COM model), a standard on most Windows desktops and a feature of most Windows-based development tools.

The Realities

As in most things, there is both good news and bad news when considering the role of distributed objects in application integration. Distributed objects do provide application integration developers with an advanced distributed architecture to develop and deploy distributed applications. At the same time, issues remain that make them unsuitable for mission-critical application integration computing. A primary issue is the simple fact that most commercial ORBs don't perform well, even with the transaction and messaging extensions.

When thinking about distributed objects, we must also consider middleware. Most ORBs, both COM and CORBA, use the synchronous communication model. They continue to lack support for asynchronous messaging (although CORBA and COM+ now provide some asynchronous capabilities). And the ORB code is still not completely portable from platform to platform, especially COM+. (As with other shortcomings, vendors and standards bodies plan to address these problems in new releases of specifications and products.)

So, what can we conclude about distributed objects and application integration? Can they work together? Absolutely. However, as with all things, careful consideration must be employed to make a wise decision. The marriage of technology and application integration is like any other marriage it's a long-term commitment, and partners have to mesh well to prosper over the long haul. In application integration, the ability to mesh well over the long haul may well be intrinsic to the architecture. Now that we are moving to the next destination of distributed objects, Web services, we have another chance to be successful. Only time will tell.