- Business Integration Scenarios
- Business Integration: Roles, Products, and Technical Challenges
- The Business Object Framework
- Service Component Architecture
- Business Integration Patterns
- Business Processes
- Qualifiers
- Closing the Link
- Links to developerWorks
This chapter is from the book
This chapter is from the book
This chapter is from the book
Business Integration: Roles, Products, and Technical Challenges
Successful business integration projects require a few basic ingredients:
- A clear separation of roles in the development organization to promote specialization, which typically improves the quality of the individual components that are developed
- A common business object (BO) model that enables business information to be represented in a canonical format
- A programming model that strongly separates interfaces from implementations and that supports a generic service invocation mechanism that is totally independent of the implementation and that only involves dealing with interfaces
- An integrated set of tools and products that supports development roles and preserves their separation
The following sections elaborate on each of these ingredients.
Clear Separation of Roles
A business integration project requires people in four collaborative, but distinctly separate, roles:
- Business analyst: Business analysts are domain experts responsible for capturing the business aspects of a process and for creating a process model that adequately represents the process itself. Their focus is to optimize the financial performance of a process. Business analysts are not concerned with the technical aspects of implementing processes.
- Component developer: Component developers are responsible for implementing individual services and components. Their focus is the specific technology used for the implementation. This role requires a strong programming background.
- Integration specialist: This relatively new role describes the person who is responsible for assembling a set of existing components into a larger business integration solution. Integration developers do not need to know the technical details of each of the components and services they reuse and wire together. Ideally, integration developers are concerned only with understanding the interfaces of the services that they are assembling. Integration developers should rely on integration tools for the assembly process.
- Solution deployer: Solution deployers and administrators are concerned with making business integration solutions available to end users. Ideally, a solution deployer is primarily concerned with binding a solution to the physical resources ready for it to function (databases, queue managers, and so on) and not with having a deep understanding of the internals of a solution. The solution deployer's focus is quality of service (QoS).
A Common Business Object Model
As we discussed, the key aspects of a business integration project include the ability to coordinate the invocation of several components and the ability to handle the data exchange among those. In particular, different components can use different techniques to represent business items such as the data in an order, a customer's information, and so on. For example, you might have to integrate a Java application that uses entity Enterprise Java Beans (EJBs) to represent business items and a legacy application that organizes information in COBOL copybooks. Therefore, a platform that aims to simplify the creation of integration solutions should also provide a generic way to represent business items, irrespective of the techniques used by the back-end systems for data handling. This goal is achieved in WPS and WebSphere Enterprise Service Bus (WESB) thanks to the business object framework.
The business object framework enables developers to use XML Schemas to define the structure of business data and access and manipulate instances of these data structures (business objects) via XPath or Java code. The business object framework is based on the Service Data Object (SDO) standard.
The Service Component Architecture (SCA) Programming Model
The SCA programming model represents the foundation for any solution to be developed on WPS and WESB.
SCA provides a way for developers to encapsulate service implementations in reusable components. It enables you to define interfaces, implementations, and references in a technology-agnostic way, giving you the opportunity to bind the elements to whichever technology you choose.
There is also an SCA client programming model that enables the invocation of those components. In particular, it enables runtime infrastructures based on Java—such as IBM's WebSphere Process Server, BEA's WebLogic Server (with its Aqualogic product family), and Oracle's Application Server (part of Oracle's Fusion Middleware family)—to interact with non-Java runtimes. SCA uses business objects as the data items for service invocation.
Tools and Products
IBM's WebSphere Integration Developer is the integrated development environment that has all the necessary tools to create and compose business integration solutions based on the technologies just mentioned. These solutions typically are deployed to the WPS or, in some cases, to the WESB—the products that are at the center of this book.
Now that you understand the key ingredients of business integration solutions, let's take a look at the business object framework, at SCA, and at some of the key patterns, processes, and qualifiers in more detail.