CHAPTER 1

Enterprise Application Integration Fundamentals

Enterprise Application Integration (EAI) grew out of the incompatibility between the many different ERP applications prevalent during the 1990s and the many in-house applications that needed to use them. ERP applications like SAP, PeopleSoft, and JD Edwards, and customer relationship management systems (CRMs) like Clarify and Siebel quickly became enterprise data silos, and it became increasingly important to reuse the data and functionality in those systems. EAI is an architectural approach for integrating disparate services and data in software. EAI seeks to simplify and automate business processes without requiring comprehensive changes to the existing applications and data structures.

As an organization grows in size, it creates different departments with particular areas of focus, interests, and expertise. Partitioning is required to keep team sizes down to a manageable level and to foster hires of the best people for a particular set of responsibilities while providing enough autonomy to get the work done. While the instinct to partition is natural, all departments must also work together, sharing business processes and data in service of an overall goal and vision. Business processes develop over time, organically; some focus on the entire enterprise as a whole and some are unique to a particular area. Software applications are developed or purchased to support business processes. Organizations can end up with a wide range of sometimes overlapping, conflicting, or incompatible applications and systems. These applications may be based on different operating systems, may use different supporting databases, or be written in different computer languages. It can be very difficult to bridge these disparate applications and services, owing in part to technical incompatibilities and to the prohibitive costs of cross-training personnel in the various systems.

Integration of Data and Services Between Disparate Systems

The main driver for EAI is the desire to share data and business processes across existing applications within an enterprise. In a typical scenario, a company purchases a new CRM system (see Figure 1–1). This system is a major upgrade from the old homegrown mainframe system that has served the company well for many years. It is a common requirement to simultaneously employ the new system while still keeping the old system in service, usually because certain of the old system's functions aren't yet available in the new one. In such a scenario, new customer information is entered into the CRM but the legacy system must be synchronized to reflect the data to support required enterprise business processes. In addition, the CRM might also need to invoke some of the legacy system's functions.

Figure 1–1. Integration with Modern CRM and Legacy System

Organizations often want to use the best of breed software solution. Although it is possible to purchase software applications from a single vendor to support a large enterprise's needs, organizations usually like to use what is considered the best software for each business function. This happens for several reasons: specialization sometimes yields better results, and it's always practical to avoid completely investing in one vendor. Support could be an issue if the vendor goes out of business. In addition, there is the possibility that only a custom application will fulfill the business needs. Even with modern systems there may not be a standard means of communication that would work with each vendor's software. Business applications can run on different operation systems such as Linux, Mac, Windows, Solaris, HP-UX, and IBM-AIX. These applications may be based on different databases, such as Oracle, DB2, SQL server, Sybase, RDB, and Informix. Applications are written in different languages such as Java, C, C++, .NET, Cobol, and ABAP. In addition the legacy mainframe systems (e.g., IBM and DEC) should not be forgotten.

Integration Between Information Silos

An information silo is defined as a management system that is incapable of reciprocal operation with other, related management systems. The focus of even internally built applications is inward, and the communication emphasis is vertical. Even with the current push toward open standards and the desire to exploit the power of the Internet, information silos are quite prevalent in most organizations. They are usually caused by the lack of communication and common goals between departments in an organization. Surveying the majority of the current open source framework, the focus is toward vertical database-backed web applications. There are fewer options for horizontal communication between these applications. This may be another driver, or just be symptomatic of the growth of information silos. Information silos limit the ability to achieve business process interoperability and prevent an organization from leveraging all the departments to work toward a common goal. In addition, it prevents the applications from using the full power of the internet. Integration between information silos is another problem that EAI attempts to resolve.

Integration Between Companies

With the power and promise of the Internet, an opportunity arose to improve communication between different companies. After the initial focus on business-to-consumer (B2C) applications, a movement took place to create business-to-business (B2B) systems. Electronic information exchange between different organizations has the potential to reduce cost, increase efficiency, and eliminate human error. The electronic data interchange (EDI) standard was created to support electronic commerce transactions between two computer systems or trading partners. EDI uses a series of electronic messages sent from one computer system to another without human intervention. The message must abide by strictly defined contracts. EDI's original intent was to create a common message standard for B2B communication. EDI is still heavily used, especially within the financial industry.

Although promising, EDI posed a number of issues stemming from a lack of a general purpose message format. EDI lacks obvious looping declarations. The separation of structure from the data increases the difficulty in extracting the proper information. EDI has no standard parsing API, and usually requires proprietary software.

Other industries also feature standards to facilitate partner communication. In the healthcare industry in the United States, for example, HL7 describes the secure exchange of patient health information and treatment.

In contrast, XML was created as a general-purpose data format that can be easily transmitted over the foundations of the Internet, including HTTP. XML has had a broad adoption and has become the de-facto standard for message exchange. Web services are a response to the need to expose business processes using HTTP communication. The growth of web services speaks to how important integration is.

Integration with Users

Today's applications aren't mainframe applications with amber-screen clients. They are web applications. Where “web application” might've described an application accessible from a web browser five years ago, today it describes an application that stores your information in one place and exposes its feature sets in many ways. Today's users increasingly rely on their tablet computers, their mobile devices, and their everyday tools—chat, e-mail, news feeds, and social networks, like Facebook or Twitter—to interact with these applications and with each other. Today's developer can no longer afford to expect the user to be at a desk, logged into a web page. She must go to where the user is and make it as easy as possible for those users to use the application. This is integration, and it's a key part of the most radical changes in application developments in the last five years.

Challenges

EAI implementations do not have the best reputation for success. There have been many reports that indicate the majority of EAI projects fail. And the failures are not usually due to software or technical issues, but to management challenges. Before getting into the management issues with EAI, a look the technical issues is appropriate.

Technology

EAI was originally dominated by the commercial vendors offering a number of proprietary solutions. Implementing an EAI solution required a strong knowledge of the vendor's software and tools. A number of the commercial products and approaches will be discussed later in this chapter. Until recently, viable open source frameworks did not exist. Although open source integration was possible, the results lacked the required management and monitoring capabilities for a production environment. In addition, these solutions required a great deal of custom coding of business logic and adapters to many of the existing enterprise applications. Spring Integration is one open source solution that has come of age and is ready to solve your integration requirements. Alternative open source solutions are discussed in Chapter 2.

Integration usually requires interfacing with a number of different technologies and business domains. SAP may be used for accounting, Siebel for customer relations, and PeopleSoft for human resources. All these applications have different technologies, configurations, and external communication protocols. It is usually very difficult to integrate with an application or system without knowledge of the underlying endpoint system. Adapter technology offsets some of these difficulties, but often there needs to be some configuration and software modifications to the applications to integrate. Different systems expose different integration options: SAP has business application programming interface (BAPI), Siebel has business components, and PeopleSoft has business objects. These systems are formidable, but usually require a system integrator to have some basic understanding of the applications with which to be connected, and the business domain with which they are part. Depending on the number of integration points, this can be quite a challenge.

Many times the target application cannot be changed or altered to enable the integration. The application may be a commercial product in which any changes would void the warranty and support process. Or the application could be legacy with which any change is difficult. Despite the widespread need for integration standards, only a few have emerged. XML and web services have received a great deal of hype, but these technologies are still marked with a large amount of fragmentation. Even with numerous standards organizations in the world today the specifications are becoming more and more inconsistent. Look at the number of Web Services (WS-*) standards and the number of corresponding Java specification requests (JSRs). The standards committees are typically dominated by the vendors with their own agenda. On a positive note, however, the open-source community more and more drives standards adoption.

Today's applications are often a myriad of many moving parts, separated by unknown networks and protocols. It is foolish to assume that both client and server will always be available. By using messaging to introduce asynchronous communication between two systems, you can not only decouple the producer from the uptime—after all the messages are buffered until both sides have capacity to handle it—you can also speed up the performance of individual components in the system since they no longer have to wait for each other before proceeding. Similarly, independent parts of a system may be scaled out to achieve capacity.

People

As with all business problems, solving the technical issues is the easy part. Dealing with the people issues is what's hard. It's no different with EAI. Implementing it may even be more difficult than implementing a vertical application, since it runs across the entire enterprise. EAI implementations often cross corporate boundaries, engage partners, and touch customers. This is where the real fun begins when internal corporate politics start entering into the mix causing simple questions to take months to resolve. One multinational company had a different set of software standards and practices dependent on which side of the Atlantic the division was located.

Integrations typically touch many parts of an organization with a different set of technologies as well as processes, management styles, and politics. The motivation for the integration implementation may be different for the various areas. Often one area may not want to share data with the other. A successful integration requires that there can be an agreement on what data will be shared, in what format, and how to map the different representations and interpretations between the areas. This in not always easy or achievable, and many times compromises must be reached.

The timing for implementing integration may be determined by different factors across an organization. One area might want the data made available as soon as possible where the other may be working on another project and have no motivation for the integration effort. This needs to be negotiated, because integration with an application usually requires access and support by the business owners.

Security is always an issue, because data may be proprietary because of privacy and/or business value. Integration requires access to this data and obtaining the appropriate authorization is not always easy. However, this access is vital to the success of the implementation where security requirement must be met.

A successful integration often requires both communication between computers systems as well as business units and information technology departments. Because of there wide scope, integration efforts have far reaching implications on the business. Failed integration processes can cost a business millions of dollars in lost orders, misrouted payments, and disgruntled customers. In the end however, working well with everyone from the business owners to the computer support staff is essential and often more important than the technical issues involving an integration. Integration frameworks such Spring Integration mitigate the technical barriers, but you must be sure to address business motivations as well.

Approaches

There have historically been four approaches to integration: file transfer, sharing a database, leveraging services, and asynchronous messaging. One way to look at these approaches is how they affect coupling in your architecture. Broadly, there are three types of coupling:

• Spatial coupling (communication): Spatial coupling describes the requirement of a producer to know how to communicate with another and how to overcome error scenarios in the communication. A server side fault in an RPC operation, for example, is an example of spatial coupling.
• Temporal coupling (buffering): Temporal coupling describes the requirement of a producer to be aware of, and available for, a consumer to share data. A decoupled system uses buffering so that a message may be sent, even if the consumer isn't available to receive it.
• Logical coupling (routing): Logical coupling describes the requirement of a producer to know how to connect with the consumer. One way to fix this is to introduce a central, shared location where both parties exchange data. Then, if a producer decides to move (change IP, put up a firewall, and so on) or decides to add extra steps before publishing messages, the client remains unaware as the client only concerns itself with the ultimate message payload.

File Transfer

Usually the first approach that comes to mind when sharing data is using a file (see Figure 1–2). If information is to be shared across two different applications, one system can produce a file containing the data of interest. The other system can poll for this file in a well-known, agreed upon directory or mount. Naturally, this directory might be anywhere—in an FTPS share, a SAN-based file system mount, an SFTP directory, a clustered file system like Hadoop's HDFS and VMware's VMFS. When it is available, the other system can process the file for the data. There must be an agreement when file transfer is employed as to which file format to use and how often to publish and consume the files. A major issue with using this approach is managing all the files and formats, and insuring that none of the files are missed. In addition, there is always a time lag based on the frequency of the file production and the consumption of the files. This may cause synchronization issues. File transfer integrations are temporally decoupled because neither the producer nor the consumer need be available for integration to occur. Additionally, the systems in file transfer integration only need to be aware of the shared mount, not each other, and thus they are logically decoupled, as well.

Figure 1–2. File Transfer Approach

Shared Database

What better way to share data than to used the same data source or shared database (see Figure 1–3). Integration between two systems is as simple as joining two tables. However, there are several issues that stem from using a shared database for integration. First, it is difficult to come up with a unified schema that will suit the needs of the different applications. Using a shared schema can potentially create interdependencies between two systems that may have different requirements and time schedules. Using a single dataset limits the potential to scale due to locking contention and network lag when distributing across multiple locations. Shared databases couple all systems involved to a well-known schema (the database table), though the various systems are temporally decoupled—one system does not need to be available for another system to communicate a change so long as the database is available. Because systems in a shared database don't need to be aware of each other, just the shared database, they are logically decoupled.

Figure 1–3. Shared Database Approach

Remote Procedure Calls

If data or a process needs to be shared across an organization, one way to expose this functionality is through a remote service (see Figure 1–4). For example, an EJB service or a SOAP service allows functionality to be exposed to the rest of the enterprise. Using a service, the implementation is encapsulated, allowing the different applications to change the underlying implementation without affecting any integration solution as long as the service interface has not changed. The thing to remember about a service is that the integration is synchronous: both the client and the service must be available for integration to occur, and they must know about each other.

Figure 1–4. Remote Service Call Approach

Messaging

The challenge of integration is to enable applications to share functionality and data in real time without tightly coupling the systems together in a way that introduces reliability issues in terms of application execution and application development. File transfer works well for decoupling the different applications, but has inherent performance issues. Shared database insures that data access is timely, but ties all applications to a single database. In addition it does not allow for external applications to share their functional behavior. A remote service is a viable alternative; however, extending a single application model for integration brings up all sorts of issues. Working on a single application has the potential to become distributed development. Service calls seem like local calls, but must support all the functionality required when going across a network. They are slower and have the potential to fail. If one application goes down, it can bring down the entire enterprise. What is needed is something like file transfer, but without the performance issues.

Messaging is an approach to transfer packets of data frequently, immediately, reliably, and asynchronously using a customizable format. Two systems connect to a common messaging system and exchange data and invoke behavior using messages (see Figure 1–5). An example of this is the familiar hub-and-spoke Java messaging service (JMS) architecture. Sending a message does not require both systems to be up and running at the same time. In addition, using an asynchronous process forces the developers to think about the issues involved with working with a remote application. Messages can be transformed in transit without either the sender or receiver knowing about the modification. Both data and processes may be shared using messaging. Message may be broadcasted to multiple receivers or directed at one of many receivers. Messaging meets the needs for integration scalability and extensibility.

Figure 1–5. Messaging Approach

Event-Driven Architectures

Most systems are event-driven in nature. Systems react to changes and interesting events in the enterprise, not to some fixed routine. These events are conveyed as messages that contain information about the event and how to process it. Messaging decouples the producer and the consumer—they don't need to know about when the other is available, nor do the producer and the consumer need to be aware of the other's public interface or its speed. One publishes a message as quickly as possible and then leaves the consumer to process it at its own pace.

There are two approaches to communicating data across systems: the client needs to ask for the information (a pull system) or the remote system needs to send the data when something has changed (a push system).

The traditional approach for obtaining data is a pull system. Issuing a database query, a remote procedure call, or a web service call are all examples of pull-oriented communication. Integrations are often point-to-point, where any interested party needs to know how to speak to any other system directly to obtain a result. In architectures with many systems, maintaining these connections can become very tedious very quickly. Metcalfe's law (named for Robert Metcalf, co-inventor of Ethernet and founder of 3Com) describes the number of connections possible for compatible communicating devices. It can be used to calculate how much different connections are required for any number of partners in a system that need to communicate with each other using point-to-point communication. The formula–n(n − 1)/2 – where n is the number of connected nodes–can yield some very scary results! For two nodes or partners in an integration, one connection is required (2(2-1)/2 =1); for five nodes, ten connections are required (5(5-1)/2=10); and for ten nodes, 45 connection are required (10(10-1)/2 =45)!

Pull-based systems have synchronization gaps. A system may change but consumers of that event will only find out about the change on the next poll. Assuming a poll of ten seconds (for example), clients could possibly have data as far out of sync as 10 seconds. In some systems (social networking “status” updates, for example) this isn't a big deal. For other (stock market trading), this delay is intolerable.

Event Driven Architecture (EDA) is a software architecture pattern promoting the production, detection, and/or consumption of events as messages. In essence, EDA is an architecture where events are transmitted between loosely coupled software components and services. An event-driven system consists of event producers or publishers and event consumers or subscribers. Building applications and systems around an event-based architecture allows these applications and systems to be more responsive because event-driven systems are by design engineered to deal with unpredictable and asynchronous environments. A simple example of an event driven architecture is shown in Figure 1–6.

Figure 1–6. Event-Driven Architecture (EDA)

SEDA (Staged Event-Driven Architecture)

Staged event-driven architecture (SEDA) is an approach to build a system that can support massive concurrency without incurring many of the issues involved with using a traditional thread and event-based approach. The basic premise is to break the application logic into a series of stages connected by event queues. Each stage may be conditioned to handle increased load by increasing the number of threads for that stage (increasing concurrency). For more information on SEDA readers are advised to consult the paper SEDA: An Architecture for Well-Conditioned, Scalable Internet Services, by Matt Welsh, David Culler, and Eric Brewer. Interestingly, Eric Brewer also originated the CAP theorem.

EAI Architecture

EAI architectures have gone through various stages in development since their initial conception, which was with the purpose of dealing with sharing data and business processes across the enterprise. Older solutions used platform agnostic RPC like CORBA and Oracle (formerly BEA's) Tuxedo to integrate. In order to address the issues discussed previously regarding tight coupling and real-time access to data processes, EAI moved to message brokers. The connection to the disparate applications was done using an adapter to convert the application protocol to something the message broker would understand. The adapter software was usually run inside of some sort of container to provide basic application support such as configuration and lifecycle (see Figure 1–7).

Figure 1–7. Traditional EAI Adapter and Broker Architecture

At the same time the need for B2B integration drove the development of EDI and trading of documents via e-mail, FTPS/SFTP, and HTTP and others. Application server development followed to support these and other needs. Eventually, the application servers and adapter containers merged together (see Figure 1–8).

Figure 1–8. Application Server Architecture

After a slight diversion back to remote procedure calls with service-oriented architecture (SOA), it seems messaging technology has returned. Today's architectures demand common data exchange mechanisms (for which XML is ideal) and asynchronous, loosely coupled, stateless and horizontally scalable service tiers, for which messaging is ideally suited. The push toward open, standards-based integrations has given us the enterprise service bus (ESB). This is a lightweight adapter container with message routing capabilities based on open standards (see Figure 1–9).

Figure 1–9. Enterprise Service Bus (ESB) Architecture

An ESB is still a server and still encourages isolated servers, but it provides ready-to-go routing and integration technologies. For many people, something lighter still is required–something that can be embedded or used standalone. To meet this call, integration frameworks like Apache Camel and Spring Integration have proven very successful. Even old-guard ESB vendors like MuleSoft are increasingly trying to enable use of their adapters independent of the broker through frameworks. Time will tell how this approach works.

Domination by Proprietary Solutions

EAI solutions have traditionally been dominated by costly proprietary solutions that required domain experts to implement. Until recently, these have been the best approach to solving integration problems. Some of the more popular integration products are discussed in the following sections.

webMethods (Active Software)

webMethods is an integration product suite now offered by Software AG. The main components of webMethods are the Integration Server and message broker. The Integration Server is the predecessor to the modern application server. Essentially an HTTP server on steroids, the Integration Server was developed to support B2B integration. With support for EDI and custom XML messages, and its own process flow language, Integration Server provides a platform to integration between companies over the Internet. With the acquisition of Active Software, webMethods added an enterprise integration platform to its offerings. Active Software products included an enterprise grade message broker and a suite of adapters supports integration with all the major ERP and legacy systems. Additional acquisitions added monitoring and business process support, and created a complete integration platform. Commercial products such as webMethods provide a suite of visual tools that simplify and accelerate the implementation of an integration solution.

Tibco

Tibco is another major player in the commercial enterprise integration platforms. Tibco has similar software offering to webMethods with messaging support from TIB/Rendezvous and an integration server package called ActiveIntegration. Tibco has been used in financial services, telecommunications, electronic commerce, transportation, manufacturing, and energy with an array of application adapters. Tibco enters the analytics and next-generation business intelligence markets by acquiring Spotfire, the grid computing and cloud computing markets by acquiring DataSynapse and enterprise data matching software product by acquiring Netrics.

Vitria

Vitria has the following two main software product lines.

• BusinessWare: This is Vitria's integration offering, which has a business process management (BPM) platform that allows its users to carry out general business process management, enterprise application integration, and B2B integration; it supports B2B standards such as EDI, ebXML, and AS2.
• M3O: Thisallows users to monitor and react to processes across a company's internal operations. It uses a combination of BPM, business activity monitoring (BAM), and web technologies.

IBM MQSeries

MQSeries is IBM's message-oriented middleware (MOM) offering. Combined with IBM WebSphere and supporting technologies, MQSeries offers a complete integration solution. This includes a suite of application adapters and visual tools for development and configuration.

SonicMQ

SonicMQ started life as a messaging broker implementing the JMS API. Later a Sonic ESB product was added, essentially a container supporting adapters and message routing configurations. Visual tool support called Sonic Workbench and a BPEL process engine server completed the offering, making it a full integration solution suite.

Axway Integrator

Axway also provides enterprise and business-to-business (B2B) integration applications. Axway's solutions feature a flexible integration and B2B framework, analytics, services and customized applications.

Oracle SOA Suite

Oracle ESB is largely composed of the message broker and application server from WebLogic and the message router from BEA AquaLogic. Together with some additional products from Oracle, this is an integration suite that includes visual tools.

Microsoft BizTalk

BizTalk is the Microsoft offering in the enterprise integration market. However, limitation in its product offering and its ability to run only on Windows has prevented larger market penetration.

EAI Patterns

In a broad sense, integration means connecting computer systems, companies, and people. There are three basic patterns that you see repeatedly when implementing integrations for enterprise customers: data synchronization, web portals, and workflow system. These three patterns cover the majority of integration implementation requests.

Data Synchronization

Data synchronization is the most requested type of integration for an organization, and is used when business processes in different parts of an organization require access to the same data. It's almost an anti-pattern, since this is usually a stop-gap approach where a façade pattern could be used instead. For example, a customer's address may be used in a customer relations management system, an accounting system to bill the customer, or a delivery system to ship a product to them. It is very typical for each system to have its own data store for customer information for a variety of reasons, including performance and unique domain models. If a customer makes a change, for example, to his address, each system must update its view of that customer information. This may be accomplished by implementing a data synchronization integration pattern (see Figure 1–10).

Data replication only works if each application uses the same database vendor and schema structure. This is usually not the case when each application has its own technology stack. Another approach is to export the data into files and re-import them into the other system. This approach can be slow, since it is difficult to determine what data has changed. Often all the data move between the systems. In addition, the timeliness of the data will be dependent on how often this synchronization process is run.

The standard integration approach to data synchronization is using a message-based system to move the data records inside the messages. A mechanism is needed to detect when a record is created or updated such as a database trigger or a hook or façade into the application to determine when to push the data to the other systems.

Figure 1–10. Data Synchronization Pattern

Web Portals

Often business owners and executives require information from different systems to answer specific questions or to get a general overview of the entire organization. It would be ideal to get this information from a single location rather that search across several different applications. For example, a customer agent needing to check the status of an order may need to access information from several sources, including the web application taking the order and the fulfillment system supported by a third-party application. Or maybe the business executive would like to monitor the activities of several different areas using a single web page instead of running several different applications. Web portals aggregate information from several different data sources into a single display without requiring the user to log in into the different applications supporting the various business areas.

Portal applications have become prevalent in recent years, allowing users to configure a web page consisting of different frames, or portlets, which allows a composite view (see Figure 1–11). In addition, most portal frameworks allow a certain amount of interaction between the different frames. Also, integration frameworks support combining multiple data sources into single model, including combining the information based on shared properties such as customer or order IDs.

Figure 1–11. Web Portal Pattern

Workflow

A business process can span multiple business areas and systems within an organization, and may require both automatic agents and human actors to complete successfully. The canonical workflow example is that of a loan approval process, because it has multiple steps and enlists both human and system actors. The example goes like this: a customer requests a loan from a bank. The bank rep enters the request into the system where it will first pass basic validations–does the requester have good credit, does the requester have the required documents in order, and so on. If that checks out, and the loan is for an amount deemed to be low risk, the loan is approved. If the loan amount is high risk, it requires additional audits–somebody in the risk-assessment department needs to scrutinize the request manually and decide, on a case-by-case basis, whether the loan should be approved. Finally, a letter will be printed and sent to the requester to notify him of the status of the request (approved or not approved). In this example, the request moved through at least two different systems and required a worker of specific authority to examine the request for the process to terminate.

There are a number of workflow engines available using different methods of representing a process flow, such as BPEL and BPMN. The process flow can be designed at high level without concern for the actual implementation. Later the process can be implemented by integrating the workflow process with the different applications using an integration framework (see Figure 1–12).

Figure 1–12. Workflow Pattern

Spring Integration Framework

The Spring Integration Framework is a response to the need for an open-source, straightforward integration framework that leverages the widely adopted Spring Framework. Spring Integration provides an extension of Spring's plain old Java object (POJO) programming model to support the standard integration patterns while building on the Spring Framework's existing support for enterprise integration. The Spring Framework is the most widely adapted framework used in organizations today. Spring Integration works in terms of the fundamental idioms of integration, including messages, channels, and endpoints. It enables messaging within Spring-based applications and integrates with external systems via Spring Integration's adapter framework. The adapter framework provides a higher-level of abstraction over Spring's existing support for remote method invocation, messaging, scheduling, and much more. Developers already familiar with the Spring Framework will find Spring Integration easy to pick up, since it uses the same development model and idioms.

Summary

This chapter has covered the basics of Enterprise Application Integration (EAI) and integration in general. It has addressed the motivations and challenges typical of an integration solution. We have covered the basic approaches to implementing integration: file transfer, database sharing, remote procedure calls, and messaging. The drive for real-time information has led to event-driven architectures where information is published as events (in messages) as soon as data is available.

We have looked at the historical evolution of the technology and discipline of integration. Application integration has been dominated by proprietary vendors for a long time. And finally, the three most commonly requested patterns for an integration solution were covered: data synchronization, web portal, and workflow.