Computers are useless. They can only give you answers. | ||
| --Pablo Picasso | ||
Those concerned with the EAI problem and solution define EAI at either the data model level or the business model level. They further break the business model level into three distinct types: the application interface level, the method level, and the user interface level. These distinctions result from the dynamic nature of application interfaces and the range of features and/or functions that each interface provides, as well as the design patterns they employ.
In addition to considering the two model levels, this chapter must also address the work that has been devoted to creating and using application interfaces. The simple fact is that lately, application interfaces have received a great deal of attention.
There was a time, not so very long ago, when applications were built as true monolithic stovepipes that addressed very narrow problem domains. Today, applications invariably are little more than a set of services and data that provide value to other applications. In other words, applications are no longer designed to stand alone, neither giving to nor taking from other applications.
It's about time.
The world of application interfaces is evolving rapidly. While application interfaces were once almost exclusively proprietary, APIs now use such standard mechanisms as Java's RMI (Remote Method Invocation), CORBA's (Common Object Request Broker Architecture) IIOP (Internet Inter-ORB Protocol), and Microsoft's DCOM (Distributed Component Object Model). This evolution presents today's developers with a tremendous advantage over their counterparts in the past. They can familiarize themselves with standard interfaces, no longer having to learn and implement interfaces that are not portable to other applications. Moreover, the language bindings exist from tool to tool.
Once standard interfaces are universal, integration will no longer pose such a difficult challenge for developers and architects. While development tools almost never communicate with an application using a proprietary interface, they may communicate with an application using a standard interface, making them better able to link with once-monolithic applications.
Simply put, application interfaces are interfaces that developers expose from a packaged or custom application to gain access to various levels or services of the application. Some interfaces are limited in scope while many are "feature rich." Sometimes these interfaces allow access to business processes; sometimes they allow access directly to the data. Sometimes they allow access to both.
Developers expose these interfaces for two reasons. The first is to provide access to business processes and data encapsulated within the applications they have created without forcing other developers to invoke the user interface (as outlined in Chapter 5) or to go directly to the database. Such interfaces allow external applications to access the services of these packaged or custom applications without actually making any changes to the packages or applications themselves. The second reason for exposing these types of interfaces is to provide a mechanism that allows encapsulated information to be shared. For example, if SAP data is required from Excel, SAP exposes the interfaces that allow the user to invoke a business process and/or gather common data. (SAP R/3 interfaces are dealt with in detail in Chapter 14.)
Application interfaces as a distinct type of EAI result from the fact that these scenarios are distinct from either method-level EAI or user interface-level EAI. (In the next chapter, we will discuss method-level EAI as the mechanism that allows the sharing of business logic among various applications.) While it is possible to distribute the methods that exist within enterprises among various applications, typically they are shared using a common business logic-processing mechanism, such as an application server or a distributed object. User interface-level EAI is similar to application interface-level EAI in that both make available business processes and data through an interface exposed by the packaged or custom application. However, the design pattern of the user interface-level scenario is contingent on user interaction. Traditional application interfaces, such as those provided by most popular applications, are true data- and method-sharing mechanisms utilizing traditional application interfaces. In other words, user interface-level EAI bypasses the lack of application interface by utilizing the existing user interface.
This difference in approach distinguishes application interface-level EAI from other types of EAI. The potential complexities of the application interfaces, as well as the dynamic nature of the interfaces themselves, add to the difference. Because interfaces vary widely in the number and quality of the features and functions they provide, it is nearly impossible to know what to expect when invoking an application interface. Packaged applications are "all over the board" when it comes to the types of interfaces exposed, as later chapters will make clear.
An understanding of application programming interfaces (APIs) is essential to understanding application interfaces. APIs are well-defined mechanisms that are built to connect to some sort of resource, such as an application server, middleware layer, or database (see Figure 3.1). APIs allow developers to invoke the services of these entities in order to obtain some value. For example, accessing customer information may require invoking the native middleware API for that database.
Programmers write APIs, so it should come as no surprise that they vary widely in the features and functions they provide as well as in the depth of their service offering. The best APIs can access real-time data such as information gathered from the floor of an industrial plant or draw information residing on mainframes—either by invoking a screen interaction interface, going directly to a resource, or going directly to the data.
The best way to understand how interfaces function in an EAI solution is to walk through an example. Let's say that a company maintains two systems: an ERP system that was just configured and installed and a custom COBOL system that has been functioning for years—a not atypical scenario. Each system exists on its own processor, connected by the corporate network.
Assume that the data-level EAI solution won't work due to the complexity of the databases and the binding of logic to the data. Thus, in order to integrate the old and new applications, the natural point of integration should be application interfaces.
Fortunately, the ERP vendor understands the need to integrate its business processes and data with the outside world and provides an API to access both. The API works within C++, C, and Java environments, with the libraries that drive the API downloadable from the company's Web site. For instance, from a C application with the appropriate API libraries existing, the function.
GetInvoiceInformation("12345");
would produce:
<BOM> John Smith 222 Main Street Smalltown, VA 88888 Invoice Number: 12345 001 Red Bricks 1000 .50 500.00 <EOM>
The information returning from the API call is generated by invoking an API and passing in an invoice number as an argument. This information would have to be placed in an array or another location in memory (within the application program) for processing. From this point, we may place this information within a middleware layer, such as a message broker, for transmission to other systems. Understand that the database itself was not accessed directly, and the data is already bound to a business entity—namely an invoice. Using this same interface, we can also get at customer information:
GetCustomerInformation("cust_no");
or inventory information:
QuantityAvailable("product_no");
On the COBOL side, things are not quite so cut and dry. The developer and application architect who built the application did not build in an API to access the encapsulated business processes. Therefore, the application must be redesigned and rebuilt to expose an API in order that the processes of the application may be cohesively bound with the processes of the remote ERP application.
Due to the development and testing costs, building interfaces into existing applications is generally very expensive. Other options are to employ user interface-level EAI, where the user interface (screens) is the point of integration. These implementations generally don't require the redevelopment and redeployment of the application. (See Chapter 5.) Method-level EAI is an option as well. But, once again, we're going to have to redevelop the application to support that approach. Let's assume, for our example here, that application interface-level EAI is the best solution.
Once the interface is built into the COBOL application, it's really just a matter of selecting the right middleware to bind to the ERP API on one side and the custom application API on the other. This allows the EAI developer to extract business information (e.g., credit information) out of one and place it in another. Middleware that would work in this scenario might include message brokers, message queuing middleware, and application servers.
Note that the interfaces in this example, unlike data-level EAI, are able to provide access to both data and business processes. They are the reason we employ application interface-level API. However, the type of business information accessible is limited by the features and functions of the interface. That's the tradeoff with application interface-level EAI, as will become more evident as you continue through this chapter.
Packaged applications (which are most often present in a typical EAI problem domain) are only now beginning to open up their interfaces to allow for outside access and, consequently, integration. While each application determines exactly what these interfaces should be and what services they will provide, there is a "consensus" in providing access at the business model, data, and object levels.
In accessing the business model, or the innate business processes, a set of services are typically invoked through user interfaces. For example, credit information for a particular individual can be accessed through the user interface by driving the screens, menus, and/or windows. This same information can be accessed by invoking an API provided by the packaged application vendor, if one exists.
In the world of custom applications, anything is possible. With access to the source code, it is possible to define a particular interface or simply to open the application with standard interfaces such as CORBA, COM, or Java. For example, rather than accessing the user interface (scraping screens) in order to access an existing COBOL application residing on mainframes, it is possible to build an application programming interface for that application by simply exposing its services through an API. In most cases, this requires mapping the business processing, once accessible only through screens and menus, directly to the API.
If the world were a perfect place, all the features and functions provided by packaged applications would also be accessible through their "well-defined" application programming interfaces. However, the world is not a perfect place, and the reality is a bit more sobering. (See our discussion of interface service levels in the section "Types of Services," later in this chapter.) While almost all packaged applications provide some interfaces, they are, as we have mentioned previously, uneven in their scope and quality. While some provide open interfaces based on open interface standards such as Java APIs (e.g., JavaBeans) or ORBs, many provide more proprietary APIs that are useful only in a limited set of programming languages (e.g., COBOL and C).
Most disturbing is that many packaged applications offer no interface whatsoever. With these applications, there is no opportunity for an application or middleware layer to access the services of that application cleanly. As a result, the business processes and data contained within the application remain "off limits." In these cases, half the cost must be dedicated to resorting to more traditional mechanisms, such as leveraging user interface-level or data-level EAI.
As we discussed in Chapter 1, packaged applications are natural stovepipes for the enterprise. As such, not only are packaged applications typically within the problem domain of most EAI projects, but they are often the most challenging to integrate. Enterprises need to access the information, and in many cases, they need to share the business logic locked up within packaged applications.
SAP, PeopleSoft, Oracle, and Baan dominate the many packaged applications on the market today. They offer certain advantages over their competitors. However, before taking advantage of what they offer, it is important to remember that, over the years, hundreds of packaged applications have entered the enterprise. Many of these no longer enjoy the support of their vendors, or, just as likely, the vendors are out of business. These represent special challenges for EAI.
Packaged applications come in all shapes and sizes. The majority of large packaged applications that exist within the enterprise are "business critical". SAP, for example, provides modules for accounting, inventory, human resources, manufacturing, and many other vital functions. PeopleSoft and Baan provide many of the same types of services and modules.
Vendors, such as Lawson Software, JD Edwards, and others, some with less than a dozen installations, offer packaged applications. There are packaged applications such as Scopus, a call-center management application, which are limited to highly selected and specialized applications. Siebel, a sales-force automation package, is designed to allow sales organizations to function more effectively.
Packaged applications found in enterprises today tend to use one of three distinct architectures: centralized, two-tier, and three-tier.
Centralized architecture is most traditional and, as such, is easiest to follow. Centralized architecture places both data application logic and user interfaces within the same machine, generally a mainframe or large minicomputer that houses a packaged application accessible by dumb terminals (see Figure 3.2).
There are a number of advantages to centralized architecture. First, because the data, process logic, and user interface all exist together on the same processor, maintenance is much easier than in traditional distributed environments. Second, integration is more easily accomplished within one machine than among several. In an EAI scenario, encapsulated services and data that reside on a central computer can be accessed by a single gateway.
Even while acknowledging these advantages, the industry is moving away from the centralized structure and toward the distributed model. Although this model doesn't possess all of the advantages of centralized architecture, it does bring some real strengths to the table. The distributed model has the ability to tailor equipment, databases, and operating systems to the specifications of the enterprise. Moreover, the graphical user interface, now a staple in the world of computing, is innate to traditional distributed type architectures.
The evolution toward the distributed model can be measured by the evolution of SAP. The previous generation of SAP, SAP R/2, leveraged this centralized architecture and was found on traditional mainframe-type environments. The latest SAP generation, SAP R/3, uses a three-tier distributed model.
Two-tier architecture (see Figure 3.3) is drawn from the traditional, two-tier client/server model where the application is separated into three distinct "pieces" or layers: the user interface layer, the business logic layer, and the data layer. (This is also the case in three-tier architecture, the difference being in the distribution of the layers). Despite being divided into three logical pieces, two-tier architecture is physically and logically separated onto just two layers (tiers), the client and the server. These two tiers are connected by a network. The client always contains the user interface, but it may or may not also contain the business logic. Obversely, the database always contains the data, but it may or may not contain business logic.
Placing the business logic on the client means having a "fat" client. Placing the business logic on the database (or a middle tier, as in the three-tier architecture) means having a "thin" client. Most client/server systems opt for the "fat" client approach.
It's important to note that with the two-tier approach, the difference is not necessarily the physical distribution of the application, between the client and the server, but the fact that the logic is bound to the user interface.
The three-tier architecture is, as we have noted, very similar to the two-tier architecture. The significant difference is the placement of an application server between the client and the database to provide a location for the business logic (see Figure 3.4). Thus, in the three-tier system, the client only deals with the interactions with the user, while the database only deals with the processing of the data. The middle tier, or application server, provides almost all application logic-processing services. The client, while interacting with the user, is able to invoke application services on the application server; the application server, in turn, is able to access information residing on a database on behalf of the client.
For good reason, the three-tier architecture is the most popular architecture among packaged applications. The three-tier structure provides a clean separation between the user interface, the business logic, and the data. It also provides enhanced scalability. The number of database connections increase in direct proportion to the increase in the number of clients. With a finite number of connections available to the database, two-tier architecture is self-limiting vis-à-vis scalability, because there is a one-client/one-database connection limitation. Three-tier architecture circumvents this restriction because the application server is able to multiplex the database connections. This process is known as database funneling or connection pooling. Rather than the direct proportionality of the two-tier architecture, 100 clients in three-tier architecture might require only ten connections to the back-end database.
While most of the major packaged applications today use the three-tier architecture, the enabling technology they use to implement the architecture varies considerably from vendor to vendor. Where SAP uses a proprietary application server to process its business logic, PeopleSoft leverages the Tuxedo TP monitor from BEA.
What does architecture have to do with interfaces? The long and short answer is, everything. When invoking application interfaces, it is extremely helpful to understand which portions of the packaged applications are being accessed. Interfaces allow access to the user interface and application as well as to the data (many allow access only to one or two tiers). Many packaged applications allow direct access to the database with the caveat, based on the fact that the business logic controls the database integrity, that the user do so only by using a business logic or application layer. To do otherwise could damage database integrity and thus produce erroneous results.
Understanding the architecture as well as the enabling technology also presents opportunities for integration. Many packaged applications use open technologies such as message-oriented middleware, application servers, and TP monitors. In certain instances, it may make sense to go directly to those layers, bypassing the interfaces provided by the packaged application vendors (see Figure 3.5). In PeopleSoft, invoking the Tuxedo interface allows access to its business logic. Just as Tuxedo is a major middleware technology, other third-party tools may be available that allow the same result.
As we've noted, some, but not all, packaged applications expose interfaces or APIs that allow other applications to access encapsulated services and data. While these interfaces vary widely in features and function, categorizing some types may clarify what is available. There are three types of services available to these interfaces—business service, data service, and objects.
Business services, as the name implies, include interfaces to any piece of business logic that may exist within the packaged application (see Figure 3.6). For example, if the user wants to use the packaged application interface to update the customer database with a new customer from another application, it would be possible to invoke the customer update business service from the API and pass along the new information. The interface would invoke that particular business service as if a user was invoking the same business service through the user interface of the packaged application.
There may exist as many as 10,000 business services available within a single packaged application. Each business service, when invoked by the application interface or user interface, carries out preprogrammed functions. The EAI architect must understand what each of these business services does, what the required information for each service is, and what the expected outcome is.
In addition to providing access to business logic, business services provide a virtual gateway to the data that resides within packaged applications. As such, the business services stand as sentry to the data by providing integrity controls. For example, adding a sales transaction to the database directly could circumvent integrity controls set up by the developers. For this reason, the application will almost always require going through the business logic in order to access the data.
Accessible by application interfaces, data services are direct routes to the logical or physical database, sometimes both (see Figure 3.8). These interfaces are not unlike traditional data-level access tools; however, the ERP vendor provides them as a verified mechanism to access the ERP data. Of course, each vendor varies greatly in features provided.
As we have noted, use of this interface is generally for extraction only. However, some data service interfaces offer database update services as well, either with or without integrity checks.
While most application interfaces provide data services, the EAI architect has the option of going directly to the database by utilizing database-oriented middleware. (However, doing so means bypassing all the integrity controls that the packaged application may have put in place.) In the case of Oracle, this is simply a matter of accessing the Oracle database using native middleware from Oracle or other solutions such as JDBC, ODBC (Open Database Connectivity), or OLE DB (Object Linking and Embedding Database). We will discuss the details of database-oriented middleware later in the book.
Objects are simply data and business services bound as objects. Just as in the world of object-oriented development, the object inside packaged applications is the encapsulation of both data and methods that act upon the data (see Figure 3.9).
The advantage of objects rests in the fact that there is never a concern regarding bypassig the intergity checks set up by the packaged applications, because data cannot be accessed without invoking the method. However, these objects are not typically standard distributed objects. They are proprietary objects defined by the packaged application vendor that, therefore, might not fit directly into every development or reporting environment.
Many packaged application vendors are recognizing the need to expose these objects using a standard interface such as CORBA or Java. SAP, PeopleSoft, Oracle, and Baan all have initiatives to provide standard object interfaces to existing packaged applications. The difficulty rests in the fact that many packaged applications were never designed to be distributed objects.
Knowing the types of services available through an interface, it is now useful to explore the various types of interfaces themselves that exist within packaged applications. As in other contexts, there is a broad spectrum of possibilities that can be grouped into three convenient types: full-service, limited-service, and controlled.
Full-service interfaces, as the name implies, afford a wide range of benefits. They provide access to the business services level, the data services level, and the object level (see Figure 3.10). While most packaged applications promote their interfaces as being full-service interfaces, the reality is often a bit less promising. For the most part, interfaces in packaged applications were an afterthought. As such, they tend to be somewhat limited. For example, within the SAP interface infrastructure, many types of interfaces need to be invoked in order to access information and services. The same is true for PeopleSoft and Oracle.
Limited-service interfaces are the most common interfaces, typically allowing access to only one level (e.g., business services level, data services level , or object level—see Figure 3.11). In addition to being "access limited," these interfaces generally provide only a limited set of services at those levels.
As application interfaces become the "next, greatest" thing for packaged applications, they will expand to include more levels and features and functions within those levels, and, perhaps in an effort to live up to their promotional billing, they will provide genuine full-service interfaces in the near future.
Controlled interfaces provide only a bare minimum of features and functions (see Figure 3.12). These are limited not because of the limitations of technology but, rather, because of the marketing and/or economic decisions of the vendor. Controlled interfaces are very proprietary and closed, providing controlled access to business logic and data.
While packaged application APIs represent the lion's share of application interfaces that an organization will confront, other standard application interfaces should be recognized. These exist for the same purpose as packaged application interfaces—to provide access to information that may be required from other remote applications.
There are thousands of application interface types, many more than we can discuss here. We will confine our review to major categories, including vertical market application interfaces and application interfaces built into custom applications.
Vertical market application interfaces provide access to industry-specific applications—industrial, health care, and finance, to mention just three. Vertical market application interfaces take into account the specific needs of a particular type of vertical. This may include the manner in which the information is formatted, processed, or moved from application to application. For example, in the banking industry, security is paramount. Therefore, interfaces that are used within banking applications place security high on their priority list.
SWIFT (Society for Worldwide Interbank Financial Telecommunications) is really a messaging standard and a cooperative organized under Belgian law. It began operations in 1977 and is owned by member banks, including the central banks of most countries. SWIFT provides communication services to the international banking industry, which include payment and common administrative tasks. It also supports security settlements. Most message brokers that support the financial community, including NEON, SAGA Software, and Active Software, also support SWIFT. An integral part of the international financial community, SWIFT provides a rapid, cost-effective, secure, and reliable transmission service. In addition to message processing, the worldwide network, and the availability of an increasing number of message standards to support new financial instruments, this technology provides a variety of specialized financial services as well as software network-compatible interfaces.
Organizations in the financial community will likely deal with SWIFT. In 1977, over 6,153 institutions used SWIFT to communicate with one another in a 7x24 environment. Today, SWIFT operates in 174 countries and processes more than 800 million messages each year. A typical SWIFT message load is 1.6 million messages daily.
SWIFT is obviously not the only application interface supporting the world of finance. The Financial Information Exchange (FIX) protocol is a messaging standard developed specifically for the real-time electronic exchange of securities transactions. FIX is a public domain specification maintained by the FIX organization, a cooperative effort of principal asset management and brokerage firms in the United States and Europe.
The advantages to FIX include shorter settlement dates, providing a straight-through processing package for the financial community. The FIX protocol specifications are maintained by the FIX Technical Committee. Information regarding FIX can be obtained by visiting its Web site located at http://www.fixprotocol.org.
The technical aspect of FIX is quite straightforward. FIX uses a flexible tag value message format, which imposes no structural constraints on a message. This forces all validation to occur at the application level, a problem that FIX is addressing by evolving FIX into FIXML—a structured, validated XML-derived grammar that is encapsulated within the standard FIX message. FIX, along with many other interfaces, is discovering that XML has the potential to provide a "least common denominator" approach. It certainly has proven successful for metadata.
HL7, or Health Level 7, is a standard for electronic data exchange in a health care environment. HL7 emphasizes inpatient, acute care facilities such as hospitals. A committee of health care providers, vendors, and consultants established in March 1987 are responsible for the creation of HL7.
While HL7 is primarily limited to hospitals and clinics (it is most useful when moving information in and out of MUMPs environments), it also exists within the pharmaceutical and biomedical industries.
That there exist application interfaces that have been standardized by committees or vendors is useful. But what about creating interfaces for custom applications? As we saw in our preceding examples, while interfaces may exist for many packaged applications and technologies, custom applications are yet another challenge.
Truth be told, few build a custom application with the goal of providing an application interface for other applications. Why not? Because most applications were considered monolithic beasts or were created as stovepipes to serve a single purpose within the enterprise, not to share information.
It has become obvious that the underlying assumptions here—that anything in an enterprise could, or should, exist in such a proprietary manner—were terribly incorrect.
One might believe that building application interfaces for custom applications is a difficult proposition. However, if thought through correctly, the task is not nearly as difficult as it might first appear. First, no one needs to reinvent the wheel. Building an application interface to a custom application basically means exposing business processes that already exist within the application through another mechanism, namely an API (see Figure 3.14). Access to those business processes is already being exposed through the user interface. This is simply another mechanism to obtain the same service.
While some organizations consider building application interfaces an expensive proposition, a luxury item beyond their reach, the fact is that applications are going to be changed in order to provide an application interface, and any change can range from very minor to very major. What's more, as we've mentioned, applications that are not designed from the ground up to utilize an application interface may need a new architecture in any case. In these situations, it may make more sense to rebuild the application from the first line of code. The prospect of rebuilding from the first line of code up is a prospect most organizations shy away from. It is the reason they integrate applications using other, less sophisticated approaches such as user interface-level and data-level EAI mechanisms.
An even more sophisticated option is application wrapping. This is the process of changing an existing application so that it appears as a distributed object to other, external applications (see Figure 3.15). Put another way, application wrapping requires going through the entire application and exposing its business processes as methods within a distributed object standard such as CORBA or COM.
There are many advantages to application wrapping. First, because it requires leveraging a standard distributed object infrastructure, the application can be exposed to many more types of applications than if a proprietary application interface was built. Many of these applications don't need to change in order to use the remote application services, because they are wrapped using an available distributed object standard. Second, because the process for taking an existing application and rebuilding it as a distributed object is well defined, there are many tools, techniques, and technologies available that support application wrapping.
The downside to application wrapping is time. It takes many man-months to wrap an existing application, and man-months inevitably translate into money, money that an organization might be unwilling to spend on an existing solution. Moreover, many applications have to be rebuilt from the ground up and may need a new application architecture. For these reasons, application wrapping should not be considered as a "stop gap" measure but rather as a mechanism that significantly extends the life of existing applications and supports the integration of those applications within the infrastructure of the enterprise.
There are many ways to wrap existing applications, but COM and CORBA are the most popular. Arguing the viability of either of these distributed object standards is beyond our scope here. However, the following are some general guidelines to consider.
CORBA is the better fit for applications that have to exist in a heterogeneous environment. If the enterprise supports UNIX, NT, mainframes, and a variety of other platforms, CORBA is probably the best choice because CORBA solutions exist on a wide variety of platforms. What's more, there are many proven CORBA applications in existence along with the tools and technology that contributed to its success.
Of the two standards, COM is the more Windows platform-centric, which is not to suggest that it is not a powerful ORB. It is. COM is supported by most of the Microsoft line of tools, development environments, and office automation solutions. Therefore, for organizations looking to expose an application interface to most popular applications, it is the path of least resistance. Wrapping an existing application and exposing its business processes through a COM ORB infrastructure allows those business processes to be invoked by any number of common office automation products, such as Word for Windows, PowerPoint, and Excel. COM is even making strides in becoming more heterogeneous, with support for the majority of UNIX platforms as well as the mainframe platforms.
So, given all that we've discussed in this chapter, the question begs to be asked, "What's the future of application interfaces?" Answering the question depends on the way change will be wrought in a particular enterprise—by evolution or by revolution. For most packaged or custom applications, interfaces to both methods and data encapsulated within those applications are little more than an afterthought. As a result, supporting interfaces requires retrofitting existing applications. Although this represents a step in the right direction, it is the first step in that proverbial "journey of a thousand miles." Make no mistake, it is going to be a long, slow journey. These applications typically support business-critical functions within the enterprise. Making significant changes to these applications to support interfaces for the purpose of integration may not excite the sensibilities in the boardroom. However, the EAI problem has raised the profile of application interfaces, making them a priority for those who sell and maintain both packaged and custom applications.
Taking into account the information we've presented in this chapter, we see two possibilities for the future. One, application interfaces will be standard equipment for most packaged applications. (Even more to the point, many custom applications will obtain application interfaces in future enhancements and upgrades.) Two, more applications will use standard interfaces such as CORBA and COM to enable remote applications to access both the data and services of these applications as standard object request brokers. Either outcome will add value to the EAI story.