Chapter Twelve. Composite Application Integration

Executive Overview

Business agility is the new business mantra. The ability to deliver new solutions faster, respond quickly to market changes or emerging opportunities, and manage the enterprise in real-time is the goal of all organizations seeking to gain competitive advantage. Integration is changing the nature of application development from a stand-alone activity that focuses on the creation of new code to an activity that is centered on using existing applications as the basis for developing new business systems. Rather than creating a new customer database for an application, you can reuse the existing CRM system. Rather than creating code to determine the value of a customer, you can reuse the existing custom application on the mainframe. Rather than creating a new user interface from scratch, you can reuse the portal interface. Achieving this new level of business agility requires the ability to quickly add new functionality or business processes while leveraging existing system and information assets. This is the goal of composite integration.

Composite integration is a form of application assembly. It is not a new idea. The idea of components and application assembly has been discussed for over twenty years going back to the early days of object-oriented programming. Rather than writing the application from scratch, the application is assembled from existing components or business services, and combined with new services. However, what makes it different is that composite integration is accomplished through standardized interfaces for the components representing business services. In the past, it was very difficult to achieve the benefits of composite application assembly unless the enterprise standardized on just one development platform. Due to the lack of standards, integrating across different platform and technologies was difficult, time consuming, and expensive. Web services and application integration technology have now removed this obstacle. Any modern development environment and language can be used to develop these applications.

What makes composite application integration different from application and information integration is the focus on creating new applications through the reuse of existing systems as software components. This is done in a programmatic fashion. Programmers rather than integration specialists perform the integration using the application development tool sets. The end result feels like a custom-developed application and not an integration of existing systems. However, the application is primarily constructed through the integration of existing systems.

Composite application integration helps achieve business agility because it enables companies to develop new functionality and integrate it with existing systems and information sources. It enables an incremental approach to delivering systems and can rapidly deliver new business processes or functions through a modular approach.

Composite application integration presupposes a service-oriented architecture. The components of the composite application are bundles of code implementing a business function, packaged at a level of granularity to maximize reuse, and wrapped in a standard interface. With this architecture, the bundles of code themselves can be written in any programming language as long as it adheres to a standardized interface, and Web services have become an almost universally supported interface. A Web service can physically reside on any platform, and be accessed by any program or service that can call a Web service. A composite application can include services or components running on different platforms, and written in different programming languages. Integration technology is an essential enabler of composite applications.

While integration provides the underpinnings, composite application assembly is a unique style of integration that is more programmatic in nature. The center of the solution is more often the development and deployment platform rather than an integration broker.

The business case for composite applications is clear. However, realizing a 30% to 40% savings first requires a sizeable investment in creating and managing reusable modules of code. But companies can ill afford not to make that investment if they wish to achieve business agility. Case Study 12.1 shows how Miami-Dade County was able to achieve remarkable results through the application of SOA and composite application integration (Morris and Gold-Bernstein 2003).

Composite Application Integration Scenarios

Composite applications can be used to solve the following business requirements:

  • Extending the functionality of packaged applications

  • Assembling new business solutions from existing modules

  • Adding a new functional module to existing applications

In all of these scenarios, the focus is on implementing new business functionality from a combination of new and existing components. It is the building block approach to application development. Integration technology is the primary enabler of this approach.

In each case, a programmer focuses his or her design efforts on the modules that exist or working to establish new interfaces for existing systems. New modules are minimized, and if they need to be developed are done so in a fashion to allow reuse in the future. The bulk of the application is in orchestrating the flow between existing modules. The first few applications using this approach can be challenging, because the Web service interfaces may not exist for a broad enough set of services.

Choosing Composite Application Integration Technology

The key technologies for composite application integration are application platform suites, Web services that provide the standardized interface, and orchestration technology to control the flow of the business process across all technical components and services.

Composite application integration is a distinct style of integration. It involves different core technologies and the implementers are usually application developers rather than integration specialists. In this chapter we focus on the development aspect of composite applications. However, it must be noted that the technologies discussed under Application Integration (Chapter 10), can also be used to provide the infrastructure for composite applications.

Application Platform Suites

Application platform suites include portals, integration brokers, and application servers. The components of the suite may not share a single platform or common development environment. However, an integrated platform has numerous advantages, including decreasing training and maintenance costs. All the major application server vendors offer platform suites but not all offer solutions on a common platform. There are also some Web service integration suites that offer lighter weight solutions.

Web Services

Web services provide the standardized interface to the components and systems that are part of the composite application. All the integration broker vendors support Web services. Additionally, as stated above, there are also pure play Web service development and deployment suites. When choosing technology for creating Web services, consider the skill sets necessary for implementing the solution. For example, in some implementations the legacy application developers may be the primary implementers because they understand how best to wrap the legacy code, and a tool focused on legacy skill sets might be most appropriate. In other cases, a tool focused on .NET or Java developers might be more appropriate.

Orchestration

Orchestration manages the flow of control across the services in the composite application. While the functionality of the application is delivered by the different services, the overall business process is defined in the orchestration logic. Orchestration is still in the early stages of adoption. There have been a number of different standards proposed by different groups, and at this point BPEL4WS (Business Process Execution Language for Web Services) is the most widely supported. There are currently few tools on the market that are fully BPEL compliant, although vendors are giving much lip service to the standard. The choice of orchestration technology is closely tied to the development and deployment platform and will most likely come from the application platform and integration suite vendors. Business process management tools can also be used to orchestrate composite applications.

Composite Integration Implementation Specification

Introduction

This specification provides implementation guidance for the implementation of a composite application integration based solution. It is most likely that the Service Integration Architecture Specification from Chapter 7 will form the basis for the implementation.

This section describes the specific technical problems that are being addressed in the implementation, and provides a context for the specific implementation. See Appendix J for the full specification.

Scope

The scope of a Composite Integration Implementation Specification is limited to the specific services, components, and systems that are being integrated. It should cover organizations, information, systems, and the expected end result.

Key Participants

This section identifies all stakeholders in the implementation, including business managers who control all or part of the systems, the development team who will execute the implementation, and any system designers and/or architect(s) who participated. Any other participants or stakeholders should also be identified, including their roles.

Composite Integration Patterns and Services

There is really only one composite integration pattern but there are numerous variations on how it can be implemented. The composite application consists of services and/or components or systems that can be called as services. The services have a standard interface, and are integrated into an application through code logic or an orchestration engine.

A good example of a composite application is the creation of any new channel for product sales. For example, if an organization wants to create a call center to provide a new method for customers to place orders, this would be a good candidate for a composite application. Since all of the processes exist for placing an order, it makes more sense to use this infrastructure rather than build a redundant set of applications that will need to be integrated together to synchronize the information. The same holds for creating a customer portal that can be a duplication of the call center functionality provided in a new user interface with different security controls.

Figure 12-1 depicts the Composite Application Integration Reference Architecture with the services essential for composite applications. The services can be implemented through an application platform suite, message broker, ESB, or adapters.

Composite Application Integration Reference Architecture

Figure 12-1. Composite Application Integration Reference Architecture

The Composite Application Implementation Table (Figure 12-2) defines the alternative technologies that can be used to implement the solution.

Composite Application Implementation Table

Figure 12-2. Composite Application Implementation Table

Conclusions and Commentary

This section should provide any final comments on implementation.

Best Practices in Composite Application Integration

  • Invest in creating reusable services. This may require a higher initial investment, but will decrease cost and implementation time in future implementations. The strategy also increases business agility.

  • Create functionally independent services. Loose coupling between services makes the infrastructure more adaptable to change.

  • Manage and reward reuse. Changing programmer behavior involves both the carrot and the stick. The carrot includes rewards for maximizing reuse. The stick is the central architecture group that manages reuse. This can include rewards for minimizing development time that would inspire developers to look for ways to reuse existing assets.

  • Structure design reviews. Focus design reviews on the definition of interfaces to improve reuse potential.

  • Implement directory services. Use a directory to register and locate interfaces and components at runtime.

Next Steps

Composite integration is an on-going journey. The goal is to create reusable business services that can be implemented quickly and inexpensively. While there is a high ROI for reuse, few companies achieve it because it requires ongoing management and investment. Reuse often requires a change of development focus. Programmer productivity is directly disproportionate to the amount of programming done. The less a programmer codes, the more productivity he or she can achieve. Much more can be accomplished through reuse.

The next step in composite integration is to manage and grow the repository. Reward reuse—employees generally focus on where they are being measured. Reward contributions of reusable services, and reward reuse of existing services. This will help build a culture of reuse.

The composite application may include a combination of other patterns as well, including process integration and substantial application integration and/ or data integration. If this is the case, you can refer to the appropriate chapters in Part III of this book (Figure 12-3).

Integration Roadmap

Figure 12-3. Integration Roadmap

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset