Page 2 of 4   « previous page   next page »

Composite applications enable the creation of coarse-grained services with flow logic to determine the execution sequence of the services. These composite applications become the IT analogy of business process in the business domain. The SOA design leverages middleware and operating environment functions to separate the flow logic from the underlying business logic implemented in the individual services. Services can be enabled from existing components (for example, mainframe CICS application) or be completely new functions.

A key challenge in a service-oriented integration approach is in the definition and implementation of services at the appropriate level of abstraction. The ability to apply sound architectural design in developing an enterprise approach to integration is tied directly to the concept of separation of concerns as well as the emerging concepts of model-driven design and architecture.

Separation of Concerns Simplifies Integration Architecture Implementation
The development and implementation of information technology comprises multiple dimensions that have to be reconciled in an enterprise-level integration strategy. IT's role in defining and managing the boundary between business applications and the underlying operating environment becomes the key factor in implementing business solutions. The operating environment provides infrastructure services for business applications and represents common services to support the integration solutions.

When defining an enterprise's integration architecture, it's critical to consider the breadth of integration requirements. These integration requirements can include traditional workflow processing based on human task interaction, the choreography of activities between different systems, distributed data management involving structured and non-structured information, and user interaction capabilities. An enterprise requires the ability to differentiate and design service artifacts appropriate to specific styles of integration required to solve a particular integration problem. As a result, the concept of separation of concerns is the foundation of the definition of the integration services.

Separation of concerns suggests decomposing business needs into services and composing combinations of existing and new services that represent business processes. By separating concerns, integration requirements are decomposed into more granular services. This decomposition is accomplished through the identification of the specific functions that have to be defined to support business requirements, as shown in Figure 1.

A separation-of-concerns approach to defining services results in a design that isolates and characterizes functions and services that are implementation-independent. With this approach, building integration solutions becomes an iterative process and components are refined over successive integration projects. Enterprises give design governance and integration mentorship to development teams to promote best practices and the reuse of services and components.

In an SOA-based solution framework, service components are isolated and defined. Besides supporting a top-down model-driven approach, the solution approach enables a bottom-up approach to the development of new services. The resultant composite application consists of service invocations with flow logic to manage the execution order of the individual services. The composite application can be made available to other services as a service, itself the development of additional composite applications.

The prevailing approach for building component-based architectures is via model-driven architecture (MDA), and the MDA approach provides a foundation for developing an SOA. In An MDA Manifesto, Grady Booch comments that an MDA is "a style of enterprise application development and integration based on using automated tools to build system-independent models and transform them into efficient implementations." The MDA approach provides greater efficiency in the IT development process through the tool-based generation of artifacts, as well as enabling business stakeholders to participate in developing business processes. MDA is rapidly converging with both SOMA (service-oriented modeling and architecture) and SODA (service-oriented development of applications) methodologies for Service Oriented Application development.

In Guide to Enterprise IT Architecture, it says, "IT persists in reinventing technical functions because the existing functions were not built by the current faction. At some times this approach may be perfectly justifiable; however in the many circumstances it is merely a whim of the project team. Application development is all about business functions, not building technical infrastructure." This comment underscores the need for an enterprise-governed approach to developing integration in tandem with the application of a separation-of-concerns perspective to building enterprise-level integration strategies.

The WebSphere Integration Reference Architecture
Business integration benefits from an enforcement of separation of concerns to integrate data and applications as appropriate for business needs. It's not enough to have a process solution or an application server foundation - it's the aggregation of multiple integration styles using common components and services that provides long-term sustainability, preserves investment in existing IT assets, and avoids a "cobbled" integration approach. Effective business integration also requires an operating environment that supports the implementation of service-oriented solutions, can be implemented in a modular build-as-you-go fashion, and supports all functions required for enterprise-level implementations.

The WebSphere Integration Reference Architecture provides a comprehensive set of services to enable business integration. The services provide the breadth of functionality needed to solve integration requirements. More importantly, the component services can be implemented in stages to enable incremental evolution on a project-by-project basis while working towards an enterprise integration solution architecture. Although specific projects may not require all of these services, enterprise-level integration will require the ability to add these functional capabilities to the integration architecture. The resulting architecture provides for separation of concerns by enabling business logic, control logic, routing, and transformation logic to be loosely coupled and, as a result, more flexible to change. At the organizational level, this approach facilitates simpler integration solution development and enhances maintainability and operation of the solution.

The WebSphere Integration Reference Architecture (Figure 2) shows the key integration functions required for comprehensive enterprise-level solutions. These service groupings provide the ability to apply separation of concerns to enterprise integration requirements and lead to a convergence with the principles of SOA as they apply to integration.

This high-level architecture depicts the integration functions/services needed to enable a comprehensive approach to integration. Since these services are described by their interfaces and not by their implementation, a given solution can be made up of mainframe applications, local, or remote services, choreographed processes described by BPEL (the standard for business process description) or as components built with J2EE. The implementations of these integration components provide support for non-functional requirements including reliability, security, availability, and management at both the operating environment level, and the component/service level as well.

Connectivity Services
At the core of the WebSphere Integration Reference Architecture are the connectivity services. This component provides the infrastructure to support and instantiate the Enterprise Service Bus (ESB) architectural pattern. The ESB delivers inter-connectivity services across the distributed component topology. Transport services, event services, and mediation services are provided through the ESB. Transport services provide the fundamental connection layer; event services enable the system to respond to specific events arising as part of a business process; mediation services enable the loose coupling of interacting services in the system. The ESB essentially becomes the extended enterprise's arterial system providing messaging, notification, and invocation services across the enterprise's various operating environments. The ESB is a key factor in leveraging the service orientation of the WebSphere Integration Reference Architecture for implementing service-oriented solutions today as well as in the future.

Page 2 of 4   « previous page   next page »