A simple introduction to the service-based enterprise integration model, part 1th: Evolution of basic concepts

Introduction

Enabling all applications in an enterprise to operate in an integrated manner to provide uniform and consistent data and functionality is a very difficult task. This involves a variety of applications, such as homegrown applications (c + +, Java™ or Java 2 Platform, Enterprise Edition [EE]), packaged applications (such as SAP CRM applications), and legacy applications (mainframe IBM®CIC s® or IBM information Management System [ims™]). Also, these applications may be distributed in different geographic locations and may run on a variety of platforms. This may require integration of applications outside the enterprise.

As the enterprise evolves, the complexity involved in enterprise integration increases over time and involves many integration patterns. Therefore, there are a large number of integrated models. These integration patterns are various, some are based on the file between the application for simple data transfer, and some are fully based on SOA integration model.

Parts 1th and 2nd of this series describe the evolution of these patterns to help you understand all of the basic concepts and functionality involved in an soa-based integration pattern. Some of the concepts and functions involved include:

Consumers and providers of services

Loosely coupled

Code Reuse and Tiering

Language independence

Platform Independence

Definition, publishing, and discovery of service interfaces (i.e., registry concepts)

The Enterprise Service Bus (ESB) integrates development from point-to-point, involving the concepts of connectivity, marshaling, and mediations

Coarse granularity

These descriptions of the development of integrated patterns also highlight many of the previous technology and technology concepts that have greatly facilitated the development of soa-based integration patterns.

Another reason to discuss old patterns is that even in today's world, there is still the coexistence of old patterns and new patterns. For example, many ESB implementations support an integrated file transfer mechanism. Similarly, many application servers, such as IBM websphere®, have both object request proxies (ORB) and asynchronous messaging capabilities.

It is to be concerned that the standardized service integration Maturity Model (Simms) recently proposed by IBM has been approved by the Open Group Board of Directors. The description of early integration patterns in parts 1th and 2nd of this series will greatly help you identify and define the maturity level of the application domain in Simms.

Loosely coupled

Among all the concepts, the main drivers of the tendency to use SOA type integration patterns are loosely coupled ideas. The reason for the use of loose coupling is the increasing number and type of integrated applications. This requires that the integration pattern make changes to one application minimize the impact on other applications. Another business reason for loose coupling is that businesses need to be flexible in meeting today's changing business needs. The integration model must therefore be able to meet this change and have sufficient flexibility. As you will learn in this article, while the path to loose coupling and flexibility is not straightforward, the coupling between application and software components is often weaker when we move from old to SOA.

Maximize code Reuse

A second important factor in promoting the development of a service based architecture is the emphasis on maximizing code reuse. Code reuse can get more reliable and efficient code because the same code is tested repeatedly. To implement code reuse, you typically need to use hierarchies (also called components). Layering or assembly is the extraction of different pieces of code as separate software components so that multiple applications can use the same code to make network connections to remote applications at run time. Tiering also facilitates loose coupling because you can change the internal work of each layer without affecting other layers or applications.

Now we start with the simplest integration to discuss integration patterns, which only involve data sharing between applications. This can help you understand the concept of connectivity between different applications.