Chapter One
"They have computers, and they may have other weapons of mass destruction."
—Janet Reno, Attorney General
February 2, 1998
Defining EAI
As corporate dependence on technology has grown more complex and far reaching, the need for a method of integrating disparate applications into a unified set of business processes has emerged as a priority. After creating islands of automation through generations of technology, users and business managers are demanding that seamless bridges be built to join them. In effect, they are demanding that ways be found to bind these applications into a single, unified enterprise application. The development of Enterprise Application Integration (EAI), which allows many of the stovepipe applications that exist today to share both processes and data, allows us to finally answer this demand.
Interest in EAI is driven by a number of important factors. With the pressures of a competitive business environment moving IT management to shorter application life cycles, financial prudence demands that IT managers learn to use existing databases and application services rather than recreate the same business processes and data repositories over and over (see Figure 1.1). Ultimately, finances are a prime concern. The integration of applications to save precious development dollars creates a competitive edge for corporations who share application information either within the corporation or with trading partners.
Figure 1.1 The need for application integration
The vast majority of corporations use several generations of systems that rely on a broad range of enabling technology developed over many years. Mainframes, UNIX servers, NT servers, and even proprietary platforms whose names have been forgotten, constitute the technological base for most enterprises. These technologies, new and old, are all providing some value in the enterprise, but their value is diminished if they are unable to leverage other enterprise applications. Moreover, the need to integrate those systems with packaged systems has been intensified by the popularity of packaged applications such as SAP, PeopleSoft, and Baan.
The case for EAI is clear and easy to define. Accomplishing EAI, however, is not.
The idea of EAI is something we’ve been wrestling with over the last several years as the need for a comprehensive integration system has grown more urgent. Forester Research estimates that up to 35 percent of development time is devoted to creating interfaces and points of integration for applications and data sources. Most problems with developing software derive from attempts to integrate it with existing systems. Certainly that has been a significant problem in creating traditional client/server systems—what was inexpensive to build was expensive to integrate and became difficult to maintain.
What Is EAI?
So, if EAI is the solution, what exactly is it? EAI is not simply a buzzword dreamed up by the press and analyst community. It is, at its foundation, a response to decades of creating distributed monolithic, single-purpose applications leveraging a hodgepodge of platforms and development approaches. EAI represents the solution to a problem that has existed since applications first moved from central processors. Put briefly, EAI is the unrestricted sharing of data and business processes among any connected applications and data sources in the enterprise.
The demand of the enterprise is to share data and processes without having to make sweeping changes to the applications or data structures (see Figure 1.2). Only by creating a method of accomplishing this integration can EAI be both functional and cost effective.
Figure 1.2 The technology that drives EAI is growing quickly.
Now that you know what it is, the value of EAI should be obvious. EAI is the solution to the unanticipated outcome of generations of development undertaken without a central vision or strategy. For generations, systems have been built that have served a single purpose for a single set of users without sufficient thought to integrating these systems into larger systems and multiple applications.
Undoubtedly, a number of stovepipe systems are in your enterprise--for example, inventory control, sales automation, general ledger, and human resource systems. These systems typically were custom built with your specific needs in mind, utilizing the technology-of-the-day. Many used nonstandard data storage and application development technology.
While the technology has aged, the value of the applications to your enterprise likely remains fresh. Indeed, that "ancient" technology has probably remained critical to the workings of your enterprise. Unfortunately, many of these business-critical systems are difficult to adapt to allow them to communicate and share information with other, more advanced systems. While there always exists the option of replacing these older systems, the cost of doing so is generally prohibitive.
Packaged applications such as SAP, Baan, and PeopleSoft--which are natural stovepipes themselves—have only compounded the problem. Sharing information among these systems is particularly difficult because many of them were not designed to access anything outside their own proprietary technology.
Applying Technology
If EAI articulates the problem, then traditional middleware has sought to articulate the solution--sort of. Traditional middleware addresses the EAI problem in a limited manner.
The primary limitation is that middleware that uses message queuing or remote procedure calls (RPCs) only provides point-to-point solutions--that is, linkage between system A and system B. Unfortunately, any attempt to link additional systems quickly becomes a complex tangle of middleware links. Worse still, traditional middleware demands significant alterations to the source and target systems, embedding the middleware layer into the application or data store.
For example, when integrating a custom accounting system running on Windows 2000 with a custom inventory control system running on the mainframe, you may select a message-queuing middleware product to allow both systems to share information. In doing so, however, you generally have to alter the source system (where the information is coming from) with the target system (where the information is going to) in order to make use of the middleware. This is due to the fact that the point-to-point middleware layer only provides a program interface, and thus the programs must change to accommodate the middleware. This is costly and sometimes risky.
What’s more, as we use the same or similar technology, as with the previous example, to integrate other applications inside an enterprise, the number of point-to-point solutions may grow to accommodate information movement between various systems. The end result is software pipes running in and out of existing enterprise systems, with no central control and central management, and a limited ability to react to change. The end state looks more like an ill-planned highway system that was built by many small integration projects but with little strategic value.
An additional complication to this scenario is that IT managers must perform integration projects inside fluid environments using rapidly advancing technology. In seeking to integrate links, the manager may also encounter additional problems such as:
In addition to these structural limitations, the economics of traditional middleware have placed EAI out of the reach of most IT organizations. Even a simple dual-application linking is financially daunting, running as high as $10 million according to the Aberdeen Group.
Given these significant limitations, it follows that EAI represents a very different method of application integration than that using traditional middleware (see Figure 1.3). EAI provides a set of integration-level application semantics. Put another way, EAI creates a common way for both business processes and data to speak to one another across applications. More importantly, we approach this old problem with a new set of technologies designed specifically for EAI.
So, keeping this information in mind, we can focus on the following differences between traditional approaches and the vision of EAI:
Figure 1.3 EAI versus traditional middleware
How Did Things Get This Bad?
EAI answers the problem of integrating systems and applications. But how did the problem come about? The answer depends to a great extent on perspective. In the early days of computing, information was processed on centralized platforms. As a result, process and data existed in a homogeneous environment. Integrating applications (both processes and data) within the same machine rarely created a problem beyond some additional coding. As technology developed, platforms changed. Smaller and more open platforms, including UNIX and Windows NT (in addition to new programming paradigms such as object-oriented and component-based development), challenged traditional mainframes, once the backbone of IT.
Whether correctly or not, traditional IT leveraged the power of these newer, more open platforms. A number of factors contributed to this. Users wanted applications that were driven by newer and more attractive graphical user interfaces. Misreading or ignoring this desire, traditional legacy systems lagged in adopting "user-friendly" graphical user interfaces, abandoning the field to the newer platforms. Perhaps more importantly, the press trumpeted the claim that the cost of applying and maintaining the newer platforms was less than traditional systems. Sometimes this claim was correct. Often it was not.
In the rush to incorporate these new systems, most enterprises applied minimal architectural foresight to the selection of platforms and applications. IT managers made many of their decisions based on their perception of the current technology market. For example, when the UNIX platforms were popular in the early 1990s, UNIX was placed in many enterprises, regardless of how well it fit. Today, the same is true of Windows NT.
Clearly, the installation of these systems has been a textbook example of "management-by-magazine." Rather than making sound, business-driven decisions, or evaluating all possible solutions, decisions were made to implement the "coolest" technology.
While acknowledging that smaller and more open systems can hold a very important place in the enterprise, this decision-making process lacked the perspective and foresight that might have minimized, or possibly avoided, many integration problems. The success of these smaller, more open systems was that they met the requirement of commodity computing but with a steep price--the need for integration with the existing, older system.
The need for EAI is the direct result of this architectural foresight, or rather, the lack of it. Until recently, architecture at the enterprise level had been virtually nonexistent. Information technology decisions tended to be made at the department level, with each department selecting technology and solutions around its own needs and belief structures. For example, accounting may have built their information systems around a mainframe, while human resources leveraged the power of distributed objects, and research and development might have used distributed transaction processing technology. The end result could have been a mixing and matching of technologies and paradigms. As a result, the enterprise as a whole was left with a "system" that is nearly impossible to integrate without fundamental re-architecture--and a significant investment of precious funds.
To address the problem of architectural foresight, many organizations have created the role of the enterprise architect. This person or office is responsible for overseeing a centralized architecture and making sure that technology and solutions selected for the enterprise are functionally able to interact well with one another. As a result, departments will be able to share processes and data with a minimum of additional work.
Enterprise architects will be called upon to make some unpopular decisions. They will be charged with making decisions regarding the commitment to a single programming paradigm and technology religion. If the enterprise goes to distributed objects, it must do so as a unified whole. Tough, centralized decisions must be made. The idea of selecting technology for technology’s sake is today a proposition that is simply too expensive. Corporate America is finally shutting down the playground that was once information technology.
Chaos Today, Order Tomorrow
The establishment of enterprise architects is a significant and positive development. Often, in addition to developing a central long-term strategy for the future, the role of the architect is to coordinate the technology that is already in place.
Most enterprises leverage many different technologies. The integration of these technologies is almost always a difficult and chaotic proposition. Traditional middleware technology, such as message-queuing software, ties applications together, but these "point-to-point" solutions create single links between many applications as we mentioned previously. As a result, the integration solution itself may become more expensive to maintain than the applications it’s connecting.
When using the point-to-point approach, integrating applications comes down to altering each application to be able to send and receive messages. This can be accomplished with any number of message-oriented middleware (MOM) products (e.g., IBM’s MQSeries). While this is easily managed within the context of integrating two applications, integrating additional applications demands additional pipes. If you have successfully integrated application A with application B and would like to include applications C and D, you will have to create a pipe between each involved application. In no time, the process will grow so complex as to render it almost unmanageable. (See Figure 1.4.)
Figure 1.4 Enterprise chaos
This "solution" is absurd. However, traditional middleware leaves no other choice but to leverage this type of architecture.
Many enterprises that needed to integrate applications have implemented such integration architectures within their enterprises and continue to maintain them today.
While it is easy to criticize these enterprises, they have done the best they could, given the available technology. Unfortunately, even their best efforts have resulted in chaos.
The question is, If such chaos exists today, what can tomorrow hold?
The "order solution" to this chaos is twofold. First, the enterprise needs to understand the large-picture architecture. Understanding the processes and the data that exist within the enterprise and how each exists within the context of the other is the necessary first step in moving forward. Then, understanding the architecture, the enterprise can determine which applications and data stores need to share information, and why. With this basic requirement established, it is simply a matter of determining the correct architecture and enabling technology to solve the problem.
Sounds easy, doesn’t it? It is--on paper. The truth of the matter is that enterprises are much more complex and difficult to contend with than one may think. Obstacles, such as interdepartmental turf battles and constantly changing business requirements, have little to do with technology but a lot to do with hindering solutions. Because a sound EAI solution often requires a change in organization, the psychological considerations of the workforce and the flow chart structures of the enterprise must be handled appropriately.
Second, new technology must be leveraged to solve the EAI problem. For example, point-to-point middleware, while providing value within the enterprise, does not--and cannot--provide the ultimate solution. Message brokers provide a vital "middle ground," offering real promise while other technologies are being created. These brokers are able to move messages from any type of system to any other type of system by changing the format of the messages so that they make sense to the target system. Message brokers also assure that messages are delivered in the correct sequence and in the correct context of the application. (See Figure 1.5.)
Figure 1.5 Using EAI technology to bring order to an enterprise
In addition to integrating messages and data, developers are learning to integrate processes as well. A new generation of application servers and distributed object technologies for solving the problem of integrating processes is appearing on the market. These technologies allow developers to build and reuse business processes within an enterprise--even between enterprises.
Evolution of Stovepipes
Within enterprises exist many stovepipe applications that address and solve very narrow problems within departments. (See Figure 1.6.) For example, the new SAP system implemented in accounting is a natural stovepipe application at the module level. Inventory control applications that exist within the sales organization and the resume-tracking system in human resources are also examples of stovepipe applications.
Figure 1.6 Many stovepipe applications exist in an enterprise.
These applications came about when traditional mainframe systems failed to solve departmental problems or, more likely, did not solve them quickly enough. Because of this failure, a "departmentalized" solution ensued, and critical departments implemented their own systems--systems that they owned, maintained, and protected.
While departments might have been protective toward their stovepipe systems, that did not mean that they, or the people who maintained them, did not want to share information; it just meant that data, and the audience for the system, typically existed within a single department. Inevitably, this reality demonstrated that the system was built without much thought having been given to the requirements for information sharing. As a result, there were no open application programming interfaces (APIs), open architectures, or other mechanisms that allowed for ready access to the processes and data that existed within these stovepipe systems.
The increased number of enterprise resource-planning applications and other packaged applications that are becoming commonplace in most enterprises represent the "mothers of all stovepipe systems." These systems do not provide effective methods for accessing data and processes within their own environments, and, while interfaces to these packaged applications are improving with time, integrating them within the enterprise represents a significant challenge.
Traditional Systems
Traditional systems (also known as "legacy systems") are stovepipe applications that may exist with many other stovepipe applications in a centralized environment. While mainframes continue to make up the majority of traditional systems, minicomputers and even large UNIX systems may also correctly be called traditional systems.
The characteristics that define the traditional system include centralized processing with terminal-based access. Features of the traditional system include both database and business processing existing together within the same environment. In addition, traditional systems typically support a large user and processing load. It is not unusual for these systems to support thousands of users concurrently accessing the same application.
The significance of this is that the much heralded death of traditional systems has proven to have been somewhat premature. Rather than becoming extinct, these systems not only continue to sell, but older applications leveraging traditional systems have demonstrated significantly more staying power than originally anticipated. The rise of EAI could be attributed, in part, to the need to maintain these older applications and integrate them within the new enterprise application infrastructure.
Microcomputer Systems
Microcomputer systems--personal computers--that exist within the enterprise today represent a significant challenge to those who seek to implement EAI within the corporation. This challenge is made clear by the fact that microcomputers exist on thousands of desktops within an organization, each microcomputer containing valuable information and processes. Complicating the situation is the fact that no two microcomputers are exactly alike. As a result, integrating the data and processes that may exist on these desktops within the enterprise could prove to be a nightmare.
Traditional microcomputer application development, such as those applications built during the rise of the PC, left far too many processes existing on the desktop and thus potentially impossible to access. Accessing both the processes and the data that exists on microcomputers may require rehosting, or moving the processes and data to a centralized server.
Distributed Systems
Simply stated, distributed systems are any number of workstation servers and hosts tied together by a network that supports any number of applications. This definition covers a broad spectrum of computing trends--client/server, Internet/intranet, and distributed object computing architectures.
Distributed computing implies that distribution provides clear benefits, including scalability and fault-tolerance. While these benefits do exist to a certain degree, distributed systems, though architecturally elegant, are difficult to implement. The majority of failed application development projects over the past decade resulted from overly complex distributed computing architectures. This does not mean that distributed computing is always a bad architecture. It does, however, urge caution and a broad perspective. Distributed computing, like any other powerful computing concept, must exist within context with other types of solutions.
Despite the complexities of distributed computing, there is a real advantage to this architecture when it is considered with EAI. Because the architecture is already distributed--riding on open systems with open, better-defined interfaces--it lends itself well to integration when compared to traditional, centralized computing architecture.
Packaged Applications
Packaged applications are any type of application that is purchased rather than developed. These applications contain reusable business processes that represent best-of-breed business models and don’t require a full-scale development effort. The benefit to business is plain: Why develop a new inventory control system when the best inventory control system already exists?
While enterprise resource-planning applications are the leaders in the packaged applications market, many other types of packaged applications are finding their way into the enterprises. These include call center applications, sales automation applications, and inventory control applications.
While the question, "Why develop a new application when a packaged one exists?" is a valid one, the truth is that the popularity of packaged applications may very well be the driving force for EAI. Packaged applications are natural stovepipes. As we have seen, any stovepipe application is difficult to integrate with the rest of the enterprise.
EAI has been brought into play as a mechanism, not only to integrate existing enterprise applications, but also to integrate and free the information from the new generation of packaged applications. This was clear from the earliest days of EAI when most, if not all, integration efforts focused on bundling packaged applications among themselves as well as among the other applications in the enterprise.
Packaged applications mean so much within the context of EAI that we have dedicated several chapters of this book to discussing the details of the major enterprise resource-planning applications, including SAP and PeopleSoft.
Making the Business Case for EAI
We have already noted that the business environment no longer supports using technology for technology’s sake. To justify its expense, a technology must demonstrate its usefulness. EAI is no exception.
While the business case for EAI is clear to most people versed in the technical aspects of this discussion, it might not be as clear to those who really need to understand its value. For example: will implementing EAI within an enterprise provide a return worthy of the investment? If so, how long before the return is realized? Is EAI a short-term or long-term proposition? And, perhaps most importantly, what are the methods that best measure success?
Before we make the business case for EAI, a number of things should be understood. First, implementing EAI requires that someone thoroughly understand the business processes in the enterprise. It is only by using this information that the degree of integration necessary to optimize those business processes can be determined. While there are methodologies and procedures that can be applied, most competent managers understand the degree of value when applying EAI without over-analyzing this information.
Not all organizations are equal. For this reason, some organizations will benefit more than others from EAI. While some organizations clearly demand an EAI initiative, others might find almost no value in implementing EAI within their enterprises. If a customer leverages a single, host-based computer system with few applications existing on that platform, only a few thousand users would have only limited benefit from EAI. When applications and data exist within the same environment, they are much easier to integrate. For years programmers have been successfully integrating homogeneous applications.
However, it is when applications and data do not exist within the same environment; when the organization has gone through mergers or acquisitions; when it has experienced uncontrolled architecture and unruly application development projects; or when it has a large, distributed system with a multitude of platforms and protocols that exist to support hundreds, or thousands of users, that the enterprise will realize a tremendous benefit from EAI.
While it may be possible to develop a "common sense" set of metrics to evaluate the success of EAI, the reality is that in most cases they must be significantly adjusted on a case-by-case basis to account for the many factors that exist in any given enterprise. Because of this, there is no easy way to create a broad-based way to define EAI success. It must be measured enterprise by enterprise.
In order to evaluate the value of EAI to your enterprise, you must establish a set of measures that define success for your organization. This can be accomplished by examining and measuring the current state of the enterprise. With this baseline, consider your goals and the amount of effort that will be required for you to realize them.
For example, if increasing sales is one of your goals, sharing inventory information with the sales order-processing system may allow sales to operate more effectively and thus help realize that goal. Even so, without a significant gain in user productivity or a reduction in error rate, the integration effort between two systems has minimal value. Therefore, in order to accurately assess EAI, you need to weigh both user productivity and error reduction, giving a measure to both. Only then can you determine the impact of EAI on your enterprise.
The Virtual System
The ultimate EAI scenario is the common virtual system. This allows any and all information required for all transactions to be immediately available no matter where the information is located in the enterprise. Every application, database, transaction table, method, and other element of enterprise computing is accessible anytime, anywhere.
EAI is able to take many diverse systems and bundle them in such a way that they appear--and function--as a monolithic and unified application (see Figure 1.7). While this represents the nirvana of EAI--and as such is not achievable for most organizations in the near future--it represents what ultimately is the perfect integration of systems possible with EAI.
Figure 1.7 Extending the enterprise with EAI
e-Business
e-Business (i.e., using electronic mechanisms to conduct business between your trading partners and your customers) is an ideally efficient method of commerce. e-Business comes in two "flavors": one, business-to-business inclusive of supply chain integration and, two, business-to-consumer, inclusive of Internet commerce or conducting commerce on the Web. While both "flavors" would benefit from EAI, it is a natural fit for business-to-business or supply chain integration in that one is able to serve the needs of the other.
The mechanism techniques and technology that make up EAI are also applicable to most supply chain integration scenarios, or Inter-Enterprise Application Integration. Because EAI is very good at integrating various applications and data stores, it is able to extend its reach outside the enterprise to include both trading partners and customers within the enterprise integration architecture. This enables any application or data store to share information with any other application or data store that exists within the supply chain scenario.
Using EAI mechanisms and technology allows you to link, for example, your SAP system to your supplier’s Baan system and move information between them as needed to support the supply chain integration scenario. You may also include a "dealer" system in your supply chain by using EAI technology and techniques to first create the links and then the methods to share both data and business processes.
EAI is the "missing link" that has been absent in the quest for success in supply chain integration efforts of the past. There has always been the desire to have systems communicate seamlessly with suppliers’ systems, but until now inexpensive solutions that could make it happen have not existed. The new generation of middleware that supports EAI concepts could make this a reality.
As in supply chain integration, business-to-consumer EAI is the process of exposing information within your enterprise to people or entities, known and unknown, that exist outside your enterprise. For example, if you want to expand your sales order entry system to allow unknown customers to link to your company Web site and purchase your products, you would have to expose that information using techniques and technology created by EAI.
Business-to-consumer e-business was slow to start, but its now explosive growth is becoming more and more evident everyday--you need only consider amazon.com or barnsesandnoble.com to appreciate this.
Types of EAI
When contemplating EAI in your organization, you must first understand the sum and content of the business processes and data in your organization. IT also needs to understand how these business processes are automated (and sometimes not automated) and the importance of all business processes. Depending on your enterprise, this may demand a significant amount of time and energy. Many organizations seek new methodologies to assist them in this process and look closely at the best practices.
In brief, organizations must understand both business processes and data. They must select which processes and data elements require integration. This process can take on several dimensions, including:
While this book includes chapters devoted to each type of EAI, a brief overview of the various types is provided here (see Figure 1.8).
Figure 1.8 Types of EAI
Data-level EAI is the process--and the techniques and technology--of moving data between data stores. This can be described as extracting information from one database, perhaps processing that information as needed, and updating it in another database. While this sounds direct and straightforward, in a typical EAI-enabled enterprise, it might mean drawing from as many as one hundred databases and several thousands of tables. It may also include the transformation and application of business logic to the data that is being extracted and loaded.
The advantage of data-level EAI is the cost of using this approach. Because we are largely leaving the application alone, and not changing code, we don’t need to incur the expense of changing, testing, and deploying the application. What’s more, the technology that provides mechanisms to move data between databases, as well as reformats that information, is relatively inexpensive considering the other EAI levels and their applicable enabling technology.
In addition to simply replicating and reformatting data between two or more databases, we are also leveraging database federation software to support database-level EAI. Data federation software provides EAI architects and developers with the ability to view many different physical databases, no matter the brand or model, as a single logical database and database model. The approach and enabling technology you leverage depends on the requirements of the problem domain.
Application interface–level EAI refers to the leveraging of interfaces exposed by custom or packaged applications. Developers leverage these interfaces to access both business processes and simple information. Using these interfaces, developers are able to bundle many applications together, allowing them to share business logic and information. The only limitations that developers face are the specific features and functions of the application interfaces.
This type of EAI is most applicable to packaged applications such as SAP, PeopleSoft, and Baan, which all expose interfaces into their processes and data, but do so in very different ways. In order to integrate those systems with others in the enterprise, we must use these interfaces to access both processes and data, extract the information, place it in a format understandable by the target application, and transmit the information. While many different types of technologies can do this, message brokers seem to be the preferred solution.
Method-level EAI is the sharing of the business logic that may exist within the enterprise. For example, the method for updating a customer record may be accessed from any number of applications, and applications may access each other’s methods without having to rewrite each method within the respective application.
The mechanisms to share methods among applications are numerous, including distributed objects, application servers, TP (transaction processing) monitors, frameworks, and simply creating a new application that’s the combination of two or more applications. There are two basic approaches: You may create a shared set of application servers that exist on a shared physical server, such as an application server, or you may share methods already existing inside of applications using distributed method-sharing technology such as distributed objects.
Method-level EAI is something we’ve been practicing for years as we sought to reuse application development efforts within the enterprises. We’ve not been largely successful due to both human and technological issues. Perhaps with EAI, we may get it right.
User interface–level EAI is a more primitive, but nonetheless necessary, approach. Using this scenario, architects and developers are able to bundle applications by using their user interfaces as a common point of integration (also known as screen scraping). For example, mainframe applications that do not provide database- or business process–level access may be accessed through the user interface of the application.
Although many consider leveraging the user interface as a point of integration to be an unstable and archaic approach, the fact is that we’ve been doing this for years and have worked out many of the issues, such as performance, reliability, and scalability. Although not preferred, it may be the only solution you have in many instances. Remember, EAI at its heart is the ability to leverage any existing system by finding a reliable point-of-integration. Existing 3270 interface middleware that is typically bundled with emulators is an enabling technology to serve user interface–level EAI.
Middleware and EAI
Much of the content of this book is devoted to middleware technology. While many texts describe the features and functions of middleware, in the world of EAI, middleware is used as a simple mechanism to move information and shared business logic between applications. In short, middleware is the underlying technology of EAI.
As we have previously suggested, application integration has been going on for years, using a broad range of connection technology. In the past, this has been low-level play with developers working at the network protocol layer or just above, then moving to true middleware solutions such as RPCs, MOM, and transactional middleware. The next generation of middleware is here with new categories such as message brokers, application servers (this is actually an old category, but you wouldn’t know it from the press), distributed objects, and intelligent agents. However, expect more middleware and middleware categories to emerge as more people become interested in EAI.
So, what’s middleware? Middleware hides the complexities of the underlying operating system and network in order to facilitate the easy integration of various systems in the enterprise. Developers, generally speaking, deal with an API on each system, and the middleware handles the passing of information through the different systems on behalf of the application. These APIs are general purpose data movement or process invocation mechanisms. They typically don’t know which applications and databases they are tying together. Developers have to create the links for the middleware; however, we are moving to a more plug-and-play solution set where the middleware is able to integrate applications intelligently with little or no programming.
Middleware provides developers with an easy way to integrate external resources using a common set of application services. External resources may include a database server, a queue, a 3270 terminal, Enterprise Resource Planning (ERP) applications, custom API, or access to real-time information. In the world of distributed computing, middleware usually is a means for connecting clients to servers, clients to clients, and servers to servers without having to navigate through many operating systems, networks, or resource server layers.
The advent of advanced middleware layers allowed distributed application development to take off. Middleware provided developers and application architects with the ability to bridge many different systems, bringing them together to form virtual systems. In fact, analyst groups such as Gartner have suggested that we are moving to a paradigm of the Zero Latency Enterprise where any application (or transaction) has access to any other application or data store instantaneously, without restriction.
It’s certainly something worth aiming for.