Application integration covers a broad array of business integration scenarios. Many companies start by connecting just a few applications point-to-point, and synchronizing some data and transactions across them. However, as the number of applications and platforms increases, and the complexity of the data structures and transformations grows, the integration requirements and technical solutions change. The business integration scope is also an important factor. When integrating with applications external to the organization or to a myriad of mobile devices, additional integration requirements, technologies, and security are involved.
Despite the attempts of integration vendors to build end-to-end integration platforms, there is no one-size-fits-all integration solution. Each business scenario will have unique requirements, and the optimal solution will most often depend on implementing not one integration technology, but the right set of technologies, and getting them all to work together seamlessly.
This chapter identifies different application integration scenarios, and provides reference architecture models for each. Application integration includes all technologies that might be used to connect disparate applications both inside and outside the firewall, including communication and messaging, translation and transformation, routing, application access, data access, presentation-level integration, B2B integration, and technology integration. This chapter will help you determine the right set of integration services required to implement your solution.
Application integration enables two or more applications to communicate to gether to perform a business function. Types of problems that are well suited to application integration include
Replicating transactions across multiple applications
Extending legacy systems to the Web
Business-to-business transactions across the Web
Publishing information and request replies to mobile devices
If the solution requires integrating information from disparate sources to present in a unified interface to a human, such as self-service applications or customer management, or an aggregated view of data is required, such as a single view of the customer across systems, see Chapter 11 on enterprise information integration.
If the solution is focused primarily on new functionality, but needs to be integrated with existing applications, or the enterprise has developed a service-oriented architecture (SOA) and is in a position to create new applications from new and existing services, see Chapter 12 on composite applications.
If the solution requires a combination of automated and manual processes, and the purpose of the solution is to monitor, manage, and optimize end-to-end business processes, see Chapter 13 on process-driven integration.
It is also quite possible to have a combination of integration needs in a single project. The reference architectures in each Chapter in Part III of the book will help you identify overlapping functionality required for the combination of integration requirements. Redundancy in integration technologies is the result of implementing a variety of tactical solutions in isolation. Proliferation of redundant technologies increases maintenance costs and over time, decreases business agility. The enterprise integration architecture helps control redundancy and guides specific implementation decisions.
The next section defines the types of integration technologies specific to application integration. Section 10.4 defines application integration patterns for different types of application integration solutions, and provides reference architectures for each pattern.
The value of taking a service-oriented approach to building the integration infrastructure becomes more apparent when considering the collection of technologies for application integration. These include technology for connecting applications, doing data translation and transformation, intelligent routing, application access including legacy integration, B2B Integration, portals, and mobile integration. (For a listing of vendors offering each of these technologies, please refer to the ebizQ Buyer's Guide, http://www.ebizq.net).
Every integration solution includes underlying connectivity. Asynchronous communications are usually most appropriate for integration solutions because of the high probability that not all applications are available at the same time. Communication technologies include proprietary message queuing (such as IBM MQ Series, TIBCO Rendevous, and Software AG EntireX). There are also solutions based on the Java Messaging Service (JMS) standard. A number of the EAI vendors also provide messaging as part of their platform. Additionally, application servers also support JMS as well as other messaging solutions. For some integration solutions, such as connecting a few applications using a point-to-point approach, messaging may be the only integration technology needed. If possible, choose just one messaging solution throughout the enterprise. When this is not possible, you will need to integrate the different messaging solutions. Message bridges and message system adapters are available to accomplish this.
Applications developed for different purposes by different vendors and developers inevitably define similar business entities differently. A customer can be identified in one system as CustID, in another system as Customer, in another system as Name. Furthermore, the definition will most likely be formatted differently in each of these systems; the field can be 20 characters in one system and 30 characters in another. Synchronizing data across applications requires translation and transformation. There are a number of graphical tools for mapping and transforming data from EAI vendors, from data warehousing vendors, and from a new emerging sector of Enterprise Information Integration (EII) vendors (described in Chapter 11). Traditional solutions have been proprietary. As XML has emerged as the lingua franca for the canonical data format, XSLT is emerging as a standards-based transformation solution. The newest products are based upon these standards.
Routing messages between systems is an essential integration service. Routing can be simple, based on headers with destination addresses, or intelligent and based on the content of the message and business rules. Messages need to be parsed and then sent to the target systems in a format they can understand: either a canonical format or an application-specific format. The latter requires data transformation. There are two technologies that provide this functionality, each with different architectures: message brokers and Enterprise Server Buses (ESB).
Message brokers are the original EAI tools, created for the purpose of providing intelligent routing and data transformation. They have a hub and spoke architecture. All routing and transformation is done in the hub. The hub connects to the spoke applications through a standardized interface, which can be an application adapter that works specifically with that broker, a standard adapter based on the Java Connector Architecture (JCA), or most likely these days, a Web service, which can work with any technology or platform. A slight variation on the message broker architecture includes the use of intelligent adapters, where the transformation is done at the target. This increases scalability. Most of the broker vendors have also added a process management layer to their platforms. Case Study 10.1 looks at the use of message brokers to help Central Hudson Gas & Electric Corp. solve a variety of integration problems (Software AG n.d.)
ESB essentially provides the same services as a message broker, but has a very different architecture. The integration services such as routing and translation, plug into the bus, and execution of services is distributed instead of at a central hub. The architecture is extremely flexible and scalable because the options for deploying services are pretty limitless. This makes it easier for companies to perform incremental implementations and tactical solutions. Only the services necessary to do the job are “plugged into” the bus. However, this is also what makes it more complex. Because it provides great flexibility in how services can be implemented, it requires many more decisions, such as where services are located, which technologies are used, which vendors are used, which programmers are involved. However, the ESB vendors are building out their platforms, much as the message broker vendors have done, to provide a full range of integration services, including business process management, to enable a single source solution. Until recently there were no widely accepted standards in the industry. Web services make the service bus a more viable commercial approach to application integration.
The bottom line may be that the ESB is easier for a company to afford and implement tactically and provides increased flexibility and scalability. However, to achieve long-term ROI from ESB architecture, it is necessary to manage the implementation of services on an enterprise level, to reduce redundancy across projects. The problem is that companies most interested in tactical implementations are generally least interested in investing in developing the enterprise integration architecture. Those who skip this step may end up paying more in the end.
Once a message gets routed to an application, the application itself needs to be able to accept and process the message. This requires a special application interface to accept external messages. The options for application interfaces include application programming interfaces (APIs), adapters, and Web services. There are also database interfaces, including open database connectivity standard (ODBC) and Java database connectivity (JDBC).
APIs are application-specific, proprietary interfaces that require the sending application to use the function calls specific to the API. This means that the application would need to be hard coded for the API of each application it is integrating within a point-to-point configuration, greatly increasing time and cost for integrating systems and decreasing agility. Any changes to an API ripples out to all applications that utilize it. Adapters are generalized APIs that provide a common set of function calls across different applications. Intelligent adapters perform the data translation and transformation at the target, thereby distributing the processing and increasing the scalability of the solution. Nonintelligent adapters provide basic connectivity, and the translation and transformation is done at the hub. It should also be noted that there are technology adapters for connecting to messaging systems, transaction monitors, and application servers.
Adapters are generally specific to a particular vendor's integration broker or ESB. While JCA has been proposed as a standard adapter architecture, the clear market winner seems to be Web services, which provide a standard interface specification. The benefit of Web services is they decrease the cost of application connectivity by obviating the need to install and configure adapters. But while they replace adapters, they do not replace the rest of the integration stack. They do not provide translation and transformation, routing, or process management.
Legacy systems typically do not have APIs, and are usually the most challenging applications to integrate. Legacy integration can consume a disproportionate percentage of the time and cost of application integration. Legacy application access is a specialized area of application integration, and there are vendors that specialize in it. Legacy integration solutions are typically used with other integration software and are often part of the integration platform. Legacy integration technology should be selected for the unique set of legacy code that is to be accessed. Emphasis should be placed upon the method that is used to connect into the legacy code. Specifically the operational and performance aspects should receive significant attention. Often too much emphasis is placed on the ease of making the connection. While this is important the long-term viability of a tool is based on how it will impact the stability of the application. It may be that the tool that requires the most work to setup and use provides the best operational characteristics.
While many EAI solutions focus on automating transactions across systems, portals aggregate information from multiple sources to present a unified interface to the end user. Portals provide a set of information and services for a specific user role or business service. They provide integration “at the glass,” giving end users a single graphical interface to disparate systems, including legacy systems. The user is unaware of where the information is coming from. Portals are used for self-service applications, management dashboards, kiosks, registration systems, and many other Web applications. Portal technology is most often focused on portal interface development. The integration with systems fueling the portal can be through adapters provided by the portal vendor or through integration with brokers or ESBs. This will continue to be necessary when the portal includes business transactions as well as presenting aggregated information. However, it must be pointed out here that the emerging EII solutions provide unique capabilities for aggregating disparate information (see Chapter 11).
While mobile integration is still in the early stage of adoption, the proliferation of mobile devices throughout organizations provides an opportunity for providing enterprise information to a variety to devices. Mobile devices such as personal digital assistants (PDAs) and cell phones can browse the Internet and receive text messages. For many years, logistics companies have used mobile devices to enter information about shipments and deliveries. Mobile integration offers the possibility of also presenting information on mobile devices. Mobile integration aggregates information and functions from back-end systems and presents it to different mobile devices based on the target display characteristics. There are many challenges in mobile integration, including the number and variety of mobile interfaces, and the fact that it is inherently insecure and unreliable technology. Mobile integration is a specialized market segment with only a few vendors offering solutions. However, as demand increases, the available solutions undoubtedly will also increase.
When integrating with applications beyond the firewall, including suppliers, partners, and customers, B2B integration services are required. While backend application integration is also required for B2B solutions, additional integration services are also required including support for multiple types of connectivity and messaging including EDI, HTTP, SOAP, and Web services as well as FTP. B2B solutions typically include partner management and different levels of partner software for different size partners. Web services are also an important standard for B2B integration.
B2B integration exchanges are becoming viable alternatives for essentially outsourcing the B2B solution. Each partner only needs to connect with the exchange and doesn't need to manage the details of connecting with every other partner, which reduces the burden on the company for connecting to multiple partners that all have different technology infrastructures. Case Study 10.2 is about northAmerican Logistics's success with transitioning to a modern B2B integration architecture from a legacy EDI approach (Vijayan 2002 and Software AG n.d.).
As stated previously, the message broker and ESB vendors have added services to support a wide range of integration requirements. Similarly, the application server vendors have added integration technology. The goal is to create a complete enterprise integration platform. The platform can include all or a combination of the following integration services: messaging, adapters, support for Web services, legacy integration, translation and transformation, B2B integration, business process automation, monitoring and management, workflow management, mobile integration, and portals. With this wide range of technologies, it is not unusual for the integration platform to include a collection of technologies, some of which are licensed from different vendors. Some of these integration platforms are more integrated than others. Few have common interfaces or development tools across all integration capabilities. Some have proprietary development environments that require specialized skills and training. When it comes to integration platforms, a single vendor solution rarely means a single technology and the integration platform may require integration.
Integration platforms are expensive, heavy weight infrastructure solutions. Maximizing the value of an investment in this all-encompassing solution requires that the organization commit all of its resources to this single platform. Taken at face value, this may seem easy. However, while these solutions are wide ranging, they cannot provide everything no matter how complete. Legacy integration is one area where they will generally fall short. Furthermore, they often have one or two areas that they excel in while having mediocre capabilities in other areas. Finally, not all of the capabilities may be of use to the organization, thereby adding costs that may not make sense. For this reason, the Enterprise Application Integration Specification identifies application integration patterns to provide guidance for companies wishing to implement only the integration services they need for a particular solution. Furthermore, this approach supports a service oriented integration architecture, where integration services can be reused and flexibly deployed for different solutions.
This specification provides implementation guidance for the development of an application-integration based solution. Application integration includes a number of different services, and applies to a broad range of business solutions requiring integration. When two or more applications need to communicate together to accomplish a given task and the level of integration is passing information and messages between and among applications, then application integration is the appropriate solution. See Appendix H for the complete Enterprise Application Integration Implementation Template.
This section describes the specific technical problems that are being addressed in the implementation, and provides context for the specific implementation.
The scope of an application integration specification is limited to the specifics of the applications that are being integrated. This section of the specification includes organizational units, external organizations, users, and applications involved. It should also define the expected time frames and end result.
This section identifies all stakeholders in the implementation. Very often, once the project goes into implementation, business managers only participate in design reviews (if at all). However, when there is both a business manager and an IT manager responsible for implementation success, the rate of success is statistically much higher. Other key participants include the system designers and architect(s) and the development team who will execute the implementation. Business managers who are responsible for any applications or services included in the solution should be part of all design reviews relevant to their systems. Any other participants or stakeholders should also be identified, including their roles.
As stated many times in this book, integration is not a single technology or solution. Choosing the right set of technologies or integration services to meet a specific integration requirement is not an easy task. We have often seen short lists that were comparing very different types of integration technologies. Understanding different integration implementation patterns will help you identify the right technologies to meet the business requirements.
There are several basic application integration implementation patterns that relate to different types of business solutions.
These patterns are:
Message broker
Enterprise service bus
Legacy integration
B2B integration
Portals
Mobile integration
Message brokers are well suited to coordinating and replicating transactions across multiple applications, as well as providing back-end integration to B2B applications and other integration solutions. When more than a couple of applications are involved, or when complex data translation and transformation is required, the message broker is a good implementation choice. For example, when a transaction is entered into one system and the organization wants to update a number of other systems with the same information for other purposes, then a message broker would make sense. When a new employee is hired, his or her information is entered into the human resource system. With this information in hand, messages would be sent outside the company to enter the employee into the health benefits provider and 401(k) system. Inside the organization, messages may be sent to the payroll, security, and e-mail system to initiate business processes to establish these services for the new employee.
The message broker implements an integration hub that provides transformation and routing services (see Figure 10-1). Adapters or Web services provide interfaces to the applications. Note that adapters can be open, meaning they are accessible by different vendor solutions, or are specific to the message broker. Without standard interfaces, if different integration technologies are used multiple adapters on a single application will be required. For this reason, Web services are gaining popularity as standard application interfaces that can be used by multiple vendor technologies.
The message broker implementation is focused on defining message routing rules, configuring adapters, and mapping data sources to each other or a canonical format. While the architecture is primarily hub and spoke, when intelligent adapters are used, transformation and routing can be distributed to the adapters. This increases scalability. The disadvantage is that “intelligent adapters” are proprietary, and the market is moving towards standardized interfaces including JCA and Web services.
It should be noted that the message broker vendors have added other levels of integration to their platforms, including B2B integration, business process management, mobile integration, and portals. These products continue to evolve into broader integration platforms that will handle multiple integration patterns.
The Implementation Table (Figure 10-2, page 198) further defines the services identified in the implementation architecture. The broker can provide messaging, or the broker may integrate with and use the messaging system already in place.
The ESB is beginning to gain more popularity as a viable option to a message broker. The ESB provides connectivity services, including transport protocol, message protocol, and message routing; some provide guaranteed message delivery through a light weight message repository. ESBs also usually provide some basic data transformation, such as XML translation via XSLT style sheets. However, for more complex data transformation requirements, an additional data transformation tool might be required. The big advantage of the ESB is that other integration services can easily be plugged in when needed. The ESB provides a very flexible and scalable architecture. The ESB is better suited when using Web services as the method of connectivity to applications. It provides the infrastructure for the development and management of these services. While a message broker might use the Web service interface, it is not intended to provide the infrastructure for the interface. For example, if a company wants to create a Web service to update a change of address, then an ESB would make more sense than the message broker. This type of Web service would be useful in an environment where the change can come into the organization through multiple channels. In a banking environment where the customer might go to a branch, talk to a call center or interact with a portal it would be useful to have this type of Web service. The Web service would not only have the connectivity element but the interface elements that could be integrated into the teller, call center, or portal applications. The ESB would provide all of the infrastructure support to manage this Web service, including the directory, routing, translation, and operational management.
The ESB Reference Architecture (Figure 10-3) and Implementation Table (Figure 10-4, page 200) help manage redundancy by documenting reusable services and technology in the infrastructure.
The ESB Implementation Table further defines the services identified in the ESB Reference Architecture. As stated previously, the ESB architecture supports a best-of-breed approach in implementing integration services. Therefore, the implementation table calls out all the services separately. In contrast, the message broker implementation assumes all these services come from the message broker vendor.
Legacy integration provides a number of ways to extract and insert information or invoke processing on mainframe systems. There is no generic approach or set of standards in legacy integration implementations. The systems were never designed to be accessible to other systems—quite the contrary. They were designed not to let anyone in.
The goal is to integrate with the legacy data, application, or process noninvasively, without changing the legacy application. Creating a new interface to the legacy system can do this. There are different types of interfaces that can be used.
Database interfaces. These data level adapters allow front-end applications access mainframe data through the database calls native to the requesting application, including JDBC, ODBC, ActiveX Data Objects (ADO), and OLE-DB (a set of COM-based interfaces that provide uniform access to data in diverse data or information sources). Data interfaces are appropriate for nontransactional systems, such as information aggregation and publishing to the Web.
Messaging interfaces. If the integration includes transaction processing, a message interface can provide better integrity and manageability than a data interface. Vendors provide connectors for JCA and SOAP messaging. There is also a number of proprietary messaging systems available for the mainframe, including IBM MQ Series, TIBCO Rendezvous, and Software AG EntireX.
Screen/report interface. Sometimes, the only way to access mainframe data is through the screen or report interface, also called screen and report scraping.
They both work the same way. The 3270 screen or report provides a defined interface to legacy systems for extracting information to the screen or report. The interface technology captures those data bits, and redirects them to a Web browser. The available technology adds the ability to combine data from several screens and/or reports. This is the least adaptable and reusable of solutions, but it is widely used because in many cases it is still much better than having to crack mainframe code; in which case you don't know what you might break.
Service interface. The service level interface, also called legacy wrapping, is the most adaptable and reusable method of legacy integration, but it also requires the highest initial investment. The technology enables mainframe processes and functions to be wrapped with a Web service, .NET, Java, or CORBA interface. .NET, Java, and CORBA components can also be expressed as Web services. The industry-wide acceptance of Web services has taken the risk out of investing in creating service-level interfaces to mainframe functionality. Originally created to enable B2B integration, the initial adoption of Web services has been in mainframe integration.
Typically, legacy integration is focused on the mainframe because this is the source of most legacy applications. However, legacy systems on UNIX platforms, especially those implemented more than five years ago, may also present challenges to integration. Figure 10-5 (page 202) depicts the different interfaces to mainframe applications, but they may also be applied to legacy systems on other platforms. Each of these interfaces can be implemented in a piecemeal fashion, or a legacy integration platform can provide a single solution that provides multiple interface options.
The Legacy Integration Implementation Table (Figure 10-6, page 203) defines what types of interfaces are provided to the mainframe, and what specific technologies are used. This information will serve as a resource in future implementation to define what interfaces have already been implemented on the mainframe. Therefore, in the implementation notes, it is important to include specifically what data, functions, or services are available through the interface.
B2B integration technology is used whenever business data needs to be communicated among trading partners. EDI has been the workhorse of B2B integration for over a decade. In the past few years, the options for business interconnectivity have exploded, giving organizations a much richer set of choices. While it may seem that a custom development using an ESB or message broker might be simple, it is better to consider the use of a B2B server or service to get some of the critical support services. For example, if an organization desires to setup an online auction capability, then one of the new servers or services would be a logical choice.
B2B integration most often includes application integration services, but also has additional services required when integrating with applications external to the organization. Partners may use a variety of communication mechanisms to communicate, including EDI, HTML, Web services, or even FTP. In some cases, a browser interface is appropriate for small partners. Additional security is sometimes required for encrypting transactions, authenticating the sender, and ensuring nonrepudiation of the transaction. Security for accepting external transactions and integrating them with back-end systems is also a consideration for B2B integration. In addition, these B2B solutions usually provide services required for partner management, including defining and managing processes among and between partners, as well as service-level agreements.
Some B2B services integrate directly to back-end systems through adapters and application APIs. Others are part of an EAI solution or integrate with an EAI solution through technology adapters. A growing area for B2B is enabling collaboration between and among partners to negotiate direct supply-chain interactions, such as product specifications and design, so collaboration services may be included.
Another option is to outsource B2B connectivity through an electronic exchange. There are a few vendors offering a B2B hosting platform for outsourcing B2B connectivity. The benefit is that the exchange provider takes care of all partner connectivity. Figure 10-7 (page 204) depicts both options of an internal B2B server and connectivity to an external exchange.
The B2B Implementation Table (Figure 10-8) specifies all components of the B2B architecture, including how back-end integration will be accomplished. This can be through other integration technology, including message brokers and enterprise service buses, or it may be through application adapters.
Portals provide integration at the glass (or graphical display). By themselves, they are not an integration technology. They are used to represent the results of integration. They can be used to extend mainframe or other internal application functionality to the Web and provide customer-facing applications.
Portals require extensive integration services. There are a number of different ways to provide portal integration. All of the methods described previously are legitimate methods. The portal can have point-to-point connections to each of the applications. APIs, database interfaces, Web services, or adapters can be used. Portals can also be part of an application server solution, and the application server can provide the integration services. Message brokers and ESBs can also provide integration services to the portal. Lastly, when the portal requires real-time access to aggregated enterprise data, EII (discussed in Chapter 11) can be used. Moreover, if the portal supports business transactions as well as data aggregation, a combination of technologies can be used. Figure 10-9 depicts the alternative integration services that can be used in a portal implementation. Each of the services in the dotted box can be implemented as the sole portal integration solution. Alternatively, EII can be combined with a message broker, or ESB, or application server. Multiple types of interfaces may be used in a single implementation.
The Portal Integration Implementation Table (Figure 10-10) defines all the technologies and services that will be implemented as part of the portal solution.
If mobile devices are part of the solution, including multiple types of PDAs, cell phones, and other hand-held devices, then mobile integration servers can significantly reduce the time and cost of connecting to these devices. A mobile integration server can take the same information from multiple source systems, and flexibly format it for different target devices.
A number of EAI vendors partner with mobile integration vendors or license the solutions to provide this capability. The mobile integration server sits in between the firewalls in the DMZ, much like a B2B server. Also it can connect to applications through adapters or through other application integration platforms and brokers.
Because wireless connectivity is inherently insecure there are additional services that must be implemented, including additional security, and especially services for guaranteeing delivery. Mobile integration is becoming increasingly popular in business. The two basic uses are providing email and browser access to the mobile employee and the creation of custom mobile applications such as delivery tracking or warehouse logistics operations. The need for this technology is to deal with the unique constraints of bandwidth, screen size, and input mechanisms. In the future, these capabilities will be add-on enhancements to other methods such as an ESB, but the market has not fully matured to this level. Investments into these technologies should be treated as investments for several years since the rate of change here will be very high for the next few years. Figure 10-11 depicts a mobile integration architecture.
The Mobile Integration Specification Table (Figure 10-12, page 210), like B2B integration, may specify how integration to back-end systems will be implemented. This can be through other integration technology, or through application adapters.
In this section other services are identified. This could include security, transactional, persistence, or other types or services. Integration implementations may involve a number of different patterns defined previously in this chapter and in other chapters in Part III of this book. In this section describe any additional services that will be included in the implementation.
Invest in reuse. It may cost a bit more initially, but will decrease implementation time and cost on future projects. Create reusable interfaces that can be leveraged in the next project.
Avoid or reduce redundancy. Redundancy ultimately increases implementation and maintenance costs. One messaging system and one metadata repository for canonical data are a must for enabling enterprise integration.
Minimize the impact of change. Take a service-oriented approach for creating the enterprise integration infrastructure. Design the solution with minimal dependency on particular technologies. Replacing a particular technology or vendor solution for an integration service should cause minimal disruption. This can be accomplished by adding layers of abstraction, such as access services, to the infrastructure.
Use standards wherever practical. XML is currently an appropriate message and canonical data format standard. Web services are evolving as a standard application interface. Where standards are not yet mature, design the solution so that propriety technology can be changed later on with minimal impact to existing applications.
Large companies are likely to have a diverse set of integration needs, and therefore are likely to implement a number of different integration patterns. All of the patterns included in this chapter can be combined with any or all of the other patterns in this book. The patterns can be used as a guide when implementing tactical solutions. However, when using multiple patterns there is a risk of implementing overlapping technologies and increasing redundancy in the infrastructure. While business requirements dictate what types of integration services are necessary, the technologies used to implement the services, and the enterprise integration architecture should control how they are implemented. When implementation choices are guided by enterprise building codes, redundancy and cost can be controlled.
Each remaining chapter focuses on a different integration pattern, each of which meets a particular set of business requirements (Figure 10-13). Chapter 11 is on information integration, Chapter 12 is on composite integration, and Chapter 13 is on process integration. Some implementations may require a combination of patterns. Over time, a large enterprise can expect to have all types of integration technology. Chapter 14 shows how the patterns can all fit together in an integrated enterprise infrastructure.
