WebSphere Business Integration Architecture and Patterns
This chapter is from the book
This chapter is from the book
This chapter is from the book
A typical business integration project involves coordinating several different IT assets, potentially running on different platforms, and having been developed at different times using different technologies. Being able to easily manipulate and exchange information with a diverse set of components is a major technical challenge. It is best addressed by the programming model used to develop business integration solutions.
This chapter explores the fundamentals of the business integration programming model. It introduces the Service Component Architecture (SCA) and discusses patterns related to business integration. Patterns seem to permeate our lives. Sewing patterns, think-and-learn patterns for children, home construction patterns, wood-carving patterns, flight patterns, wind patterns, practice patterns in medicine, customer buying patterns, workflow patterns, design patterns in computer science, and many more exist.
A.2.1
Patterns have proven successful in helping solution designers and developers. Therefore, it is not surprising that we now have business integration patterns or enterprise integration patterns. In the referenced literature, you will find a wide array of patterns that are applicable to business integration, including patterns for request and response routing, channel patterns (such as publish/subscribe), and many more. Abstract patterns provide a template for resolving a certain category of problems, whereas concrete patterns provide more specific indications of how to implement a specific solution. This chapter focuses on patterns that deal with data and service invocation, which are at the foundation of the programming model of the IBM software strategy for WebSphere business integration.
Business Integration Scenarios
Enterprises have many different software systems that they use to run their business. In addition, they have their own ways of integrating these business components. The two most prevalent business integration scenarios are as follows:
- Integration broker: In this use case, the business integration solution acts as an intermediary located among a variety of "back-end" applications. For example, you might need to ensure that when a customer places an order using the online order management application, the transaction updates relevant information in your Customer Relationship Management (CRM) back end. In this scenario, the integration solution needs to be able to capture and possibly transform the necessary information from the order management application and invoke the appropriate services in the CRM application.
-
Process automation: In this scenario, the integration solution acts as the glue among different IT services that would otherwise be unrelated. For example, when a company hires an employee, the following sequence of actions needs to occur:
- The employee's information is added to the payroll system.
- The employee needs to be granted physical access to the facilities, and a badge needs to be provided.
- The company might need to assign a set of physical assets to the employee (office space, a computer, and so on).
- The IT department needs to create a user profile for the employee and grant access to a series of applications.
In both scenarios, the integration solution needs to do the following:
- Work with disparate sources of information and different data formats, and be able to convert information between different formats
- Be able to invoke a variety of services, potentially using different invocation mechanisms and protocols
Throughout this book, we illustrate how the foundational programming model of IBM's WebSphere Process Server (WPS) addresses these requirements.