Explore Enterprise Service Bus: Learn how an ESB can help you meet the needs of your SOA solution

Introduction

In addition to the simplest solution, Enterprise service Bus is a core component of all service-oriented architecture solutions. So what exactly is an ESB? You can find many definitions throughout the IT industry. This series of articles defines an enterprise service bus from an IBM perspective (or, more accurately, in the context of the IBM SOA Foundation). To get the most value from this series, you should first read about the IBM SOA Foundation.

This series discusses the ESB in abstract terms and avoids discussing product details, meaning that this series does not discuss any other instances of the IBM wedsphere ESB product or ESB pattern. This product-agnostic approach provides a broad foundation for understanding what the ESB brings to service-oriented solutions and evaluating the specific ESB products and related technologies that are part of such solutions. This article lays the groundwork for the entire series, discusses the positioning of the ESB in the Ibm®soa Foundation, and describes how the other parts of the foundation relate to the ESB. In particular, this article will identify the core principles of the ESB. Finally, this article provides you with the initial internal details of the ESB and explains how the ESB implements these core principles.

IBM SOA Foundation and ESB

The IBM SOA Foundation is a comprehensive architecture and a set of products, technologies, and practices that address the important aspects that SOA encompasses. The SOA Foundation describes the overall relationship between business and IT organizations tools and methodologies for modeling business design tools, programming models, and techniques for using IT systems to implement business design to host an implemented middleware infrastructure to ensure its availability to the business and to ensure Efficiently use a variety of resource governance systems to control changes in business design and their implementation in IT systems in the implementation process

To understand the full value of SOA, you need to study SOA from a different perspective. Similarly, the role of the ESB must be studied from different perspectives to understand its full value.

Figure 1 shows a logical model view of the SOA Foundation Reference Architecture. This logical model view decomposes the functional underpinnings of the SOA solution. This functional or IT-centric view depicts the ESB as an integrated part that provides the interconnection between other IT parts of the solution.

Figure 1. IBM SOA Foundation Reference Architecture Logical Model view

Figure 2 shows the SOA Foundation Reference Architecture solution view. This is a business-centric view of a service-oriented solution. Note that the ESB is depicted as an integration layer to support interconnection between the business components of the solution.

Figure 2. IBM SOA Foundation Reference Architecture solution View

Both Figure 1 and Figure 2 show that the ESB is a key architectural pattern in the Foundation Reference Architecture and supports loosely coupled interconnections between service requesters and service providers in a service-oriented solution. Loose coupling allows for a thorough separation of concerns between solution components (time, technology, and organizational separation) to support both the flexibility and agility of business processes and IT systems. The remainder of this article will detail the characteristics of the architecture pattern and how these features can be implemented.

ESB Core Principles

Figure 3 shows the logical relationship between the service requester, the service provider, and the ESB. The service requester and provider interact by exchanging messages. An ESB that acts as a logical middle tier in an interaction provides a loosely coupled interconnect between the requestor of the function and the provider of the feature. The role of the ESB as the logical middle tier allows messages to be intercepted and processed when the message flows between the service requester and the service provider. This process is called mediation.

Figure 3: Service Virtualization

It is important to understand that the ESB architecture pattern can be physically implemented in different ways. In Figure 1, the ESB appears as a centralized hub, and the physical implementation of that architectural pattern in many solutions is in fact a physical hub. Figure 3 attempts to demonstrate that the architecture pattern can have different physical implementations, for example, the ESB can be dispersed so that it can be physically passed through mediations in the service requester environment, the service provider environment, the centralized hub environment, or any combination of those implementations. (in subsequent installments of this series, you will learn more about the various ESB topologies.) ）

Support for various types of mediations enables the ESB to meet the two core principles that support separation of concerns: service virtualization and aspect-oriented connectivity. The first principle (service virtualization) refers to the ability of an ESB to virtualize the following during a service interaction: protocols and patterns. interaction participants do not need to use the same communication protocol or interaction mode. For example, a requester might need to interact with some inherent synchronization protocol, and the service provider might need to interact with some inherent one-way protocol and use two interrelated interactions. The ESB provides the required transformations to mask protocol and mode switching. interface. service requesters and providers do not need to agree on an interface for interaction. For example, a requester can use one form of message to retrieve customer information, and the provider can use another form of message. The ESB provides the required transformations to reconcile the differences. identity. participants in the interaction do not need to know the identities of other participants in the interaction (for example, addresses). For example, a request may be met by any of several potential providers in a different physical location, and the service requester does not need to be aware of this. The actual provider is known only to the ESB and can in fact be changed without affecting the requester. The ESB provides the required routes to hide identities.

The second core principle is aspect-oriented connectivity. Service-oriented solutions include multiple crosscutting aspects (cross-cutting aspect), such as security, administration, logging, and auditing. An ESB can implement or enforce crosscutting aspects on behalf of service requesters and providers, eliminating such aspects from the concerns of requesters and providers. The similarity between aspect-oriented connections and more familiar aspect-oriented programming concepts is very clear, and provides the same value in different contexts.

Applying these core principles through mediations enables the ESB to affect the quality of service in the interaction. Abstraction allows participants to avoid having to understand some aspects of the interaction. For example, you might consider auditing: If a solution requires auditing, the ESB can add auditing to the interaction without affecting the contributor. Similarly, an ESB can add or enhance service-level agreements by using its own virtualization capabilities to retry failed interactions, or, in more complex cases, the ESB can match the requester's requirements with the capabilities of the provider. There are limitations, however, because some aspects of the interaction cannot be abstracted. For example, if an ESB cannot reliably interact with one of the participants, the ESB cannot provide reliable end-to-end interaction.

An ESB-centric view of the logical model

Earlier in this article, the ESB has been positioned throughout the SOA Foundation scope (see Figure 1 and Figure 2), and the ESB is studied primarily from an out-to-inside perspective. The following will look at the ESB from an internal to external perspective. Figure 4 depicts many important relationships between the ESB and other parts of the Reference Architecture's logical model.

Figure 4: ESB-centric view of the logical model

Comparison of application logic and integration logic

Note that there are several SOA Foundation parts that are interconnected through the ESB, namely interactions, processes, information, partners, business applications, and access services. These sections are grouped into a single label for the application service category, which is positioned outside the ESB. The Foundation sections that are grouped as application services are used to implement different forms of service requesters and service providers. This is the application or business logic in the solution that is designed to achieve domain-specific business goals. The ESB implements the connection or integration logic in the solution. This logic performs service virtualization and aspect-oriented connectivity, designed to achieve on-demand interconnection between application services.

In an ideal service-oriented solution, the separation between application and business logic and connectivity and integration logic is "thorough", meaning that service requesters and service providers (application services) do not contain connectivity or integration logic, and the ESB does not contain application or business logic. Only through this complete separation of architectures can enterprises achieve the flexibility, agility, and reuse that they seek from SOA.

Sometimes it is difficult to differentiate between application and business logic and connectivity and integration logic. There is no strict guiding principle, in fact, the specific choice may depend on the nature of the enterprise or even the specific situation in the enterprise. A generally effective guideline is to take advantage of the differences between semantics and syntax. Applications and business logic Create, read, update, or delete the semantics associated with implementing business goals. Instead, the connection and integration logic modifies only the syntax associated with implementing the necessary interconnects. A related guiding principle is the use of interactive features. The application and business logic are proactive because this logic creates or uses the messages (requests and responses) used in the service interaction, and the connection and integration logic is passive, so this logic only responds to messages generated by the business logic and simply moves the message from one participant to another.

Management Services

Note that some of the important features of a service-oriented solution, especially management services as part of any service-oriented solution, are also positioned outside the ESB. This is because features such as security and IT management have a solution-level scope and require coordination and collaboration between the components of the solution beyond the scope of the ESB.

Note that the ESB does not provide connectivity between application services and management services, and can protect and manage the solution without the involvement of the ESB. It is possible and often desirable for an ESB to play an explicit proactive role in the protection and management of the solution. In this case, the security and Management policy is set by a policy management point outside the ESB and is appropriate for the policy enforcement point that the ESB is considered to be such a policy. Therefore, although the policy is set using management and security services that are not directly related to the ESB, the ESB helps enforce the policy. As a result, management services are characterized by loosely coupled to the ESB.

Service Registration Center

Service registries (sometimes referred to as service repositories or service registries/repositories) contain and manage metadata that describes services in a service-oriented solution. Examples of metadata include interface descriptions, endpoint addresses, and policies that cover service-level agreements, security relationships, and so on. The Registry contains service metadata (and therefore also the Registry itself) that is very broad in service-oriented solutions and spans governance, development and management, and runtime. Figure 2 illustrates the important nature of the registry in service-oriented solutions. The registry is depicted as an operating system that spans the vertical layer stack from integration to governance.

Figure 1 and Figure 4 show that the ESB requires service metadata to perform service virtualization and aspect-oriented connectivity. An ESB can provide value only by using static metadata that is provided during development. However, to achieve fully automated service virtualization and aspect-oriented connectivity, the ESB needs to access the service registry at run time to obtain the necessary service metadata to control the dynamic behavior of the solution. Therefore, we assert that the service registry is the preferred way to configure and control the behavior of the ESB, and that the service registry is the policy management point for policies that control the behavior of the ESB, and that the ESB is the policy enforcement point for the connection-related policies in the service registry. Therefore, we can assume that the service registry is characterized by tight coupling with the ESB.

Development Services

The development services in Figure 4 provide tools that you can use to develop and manage the ESB. Developers want to use tools to develop connectivity and integration logic, or mediations, that run in the ESB. Similarly, administrators can use tools to manage the ESB after deployment. Ideally, this type of tool uses the service registry. For example, a development tool might allow a mediation developer to use the registry to find a service provider that is needed for an interaction. In addition, administrative tools may allow you to add, remove, or modify service metadata that is designed to affect the dynamic behavior of the solution.

A glimpse of the internal ESB structure

Figure 5 shows preliminary details about the internal structure of the ESB. You can see how the ESB provides service virtualization and aspect-oriented connectivity.

Figure 5. ESB Internal Structure

Communication Protocols

To support interaction between service requesters and providers (that is, receiving and sending messages), the ESB must use a communication protocol to connect to the requester and provider. The ESB can take advantage of different communication protocols to support the different quality of service between the requester and the provider, for example, to support "make the best effort" or "guaranteed" delivery. The broader the range of protocols that an ESB exploits, the broader the scope of the requesters and providers that the ESB can interconnect with.

The ESB itself does not actually provide a communication protocol, but instead leverages one or more of the underlying communication structures provided by its operating environment (infrastructure services in the SOA Foundation Reference Logic model). It can be said that the ESB itself provides an access point (On-ramp) and an out point (off-ramp) or binding to support interaction with various protocols.

Because of the characteristics of the basic communication structure, the communication protocol originally supports one or more interactive modes. Some common interaction patterns include synchronous request/reply, unidirectional (sometimes called events), and publish/subscribe (sometimes referred to as event propagation).

Message Model

In order to interact with service requesters and providers, the ESB must support the associated message model, which defines the message content used in the interaction. To do this, the ESB must be independent of the message model and provide configuration flexibility to support the message model defined by the service requester and provider.

The message model itself is based on the meta-model, which is a method of representing the content of the message. An example of a message meta-model defines the language for an XML schema; in fact, it is the most commonly used message meta-model in an ESB product. The message model is a specific application of the meta-model, and an example of a content model is a particular XML schema. The ESB must explicitly support at least one message meta-model and be able to support multiple message meta models.

Although the architecture pattern is not related to the message model, specific ESB products can provide support for a set of cross-industry or sector-specific standard messaging models, such as the HL7 of the healthcare industry. Support in this case means the built-in model recognition feature in the associated tool, even the optimized run-time conversion feature.

Mediation Flow

To support the service virtualization and aspect-oriented connections necessary for the interaction between the service requester and the provider, the ESB provides a mediation flow. A mediation flow, typically referred to as a mediation, involves receiving an inbound request message from a requester through an access point, processing a request message, and then sending an outbound message to the provider using an AP. If applicable, the mediation can also include receiving related inbound response messages, processing related response messages, and sending outbound response messages to the requestor.

The mediation flow in a solution can vary depending on complexity, from very simple to very complex. Mediation flows can also have different reusability, from specific to individual interactions, to all interactions that apply to a solution or even across solutions. Certain types of message processing performed in a mediation flow are often highly reusable. These frequently occurring, highly reusable, well-defined message processing types are called mediation patterns. An ESB product can provide one or more pre-built mediation patterns. ESB products that provide multiple pre-built mediation patterns provide a mediation framework that supports the creation of mediation flows by combining mediation patterns.

How mediation flows implement service virtualization. The virtualization of protocols and patterns implies a transition between different communication protocols and interaction patterns. If an ESB has both an access point and an out point or binding for both protocols, the ESB can only be converted between one of the two Protocols and the other. Conversions between interactive modes may already have support for inbound or outbound protocols, or may require additional processing. For example, the conversion from inbound one-way requests that use Soap/http to outbound one-way requests using queue-based protocols, where the message model is the same, is inherent because the queue-based protocol is inherently unidirectional. Conversely, using the Soap/http Inbound synchronous request/reply to the conversion between outbound asynchronous request/reply using queue-based one-way requests and one-way replies will require the mediation flow to support the correlation between queue-based requests and responses. The mediation patterns associated with transformations include access points and point-of-contact patterns, but because dependencies are at the heart of the mediation flow, in many cases, the mediation framework implicitly includes the correlation pattern.

The virtualization of interfaces requires the ESB to support syntactic transformations between service requesters and provider-defined message models. An inbound message sent by a service requester that uses a message model may have to be converted to the specific message model required by the service provider, and any response message must also be converted. The mediation patterns associated with transformations include patterns that support a single metamodel (such as XSLT), the "Any to any" transformation pattern that supports more common meta-models, and other forms of message processing, such as message enrichment and message filtering (changing syntax rather than semantics).

The virtualization of identities requires the ESB to support various forms of routing. Routing enables an ESB to send a message from a service requester to a static (for example, at deployment time) or a dynamically selected service provider, based on conditions at the time of the request. The routing mediation flow spans from very simple to very complex situations. For example, a simple routing mediation flow might not do anything other than provide a different provider address, which might come from a property that was set at deployment time. A more complex routing mediation flow might perform the following tasks: Access a registry to understand the requester's needs and the supply of potential providers. Use complex matching algorithms to determine the "right" provider. Perform the various transformations and transformations discussed above.

Routing-related mediation patterns allow for simple address operations, various forms of registry access, and various forms of decision-making. Larger-grained routing patterns can help achieve different quality of service, for example, providing request retry and failover, and even dynamically matching requesters and providers based on policies extracted from the service registry. An ESB can support more complex and more sophisticated routing patterns, such as the aggregation of dependencies on the distribution and response of requests, or even complex event handling.

How a mediation flow implements an aspect-oriented connection. A mediation flow can simply record that a request has been passed from the requestor to the provider, block requests from unknown or unauthorized requestors, or block requests based on provider availability. The relevant mediation pattern includes auditing and logging appropriate for the solution. Other mediation patterns provide direct or indirect access to the security and management policy definition points so that the mediation flow can perform the appropriate control.

With this discussion, it is clear that many mediation flows can consist of mediation patterns that support various forms of service virtualization and service-oriented connectivity. Each mediation pattern is appropriately placed in the mediation flow to achieve the intended interaction objectives, as well as execution management and security policies.

SOA life cycle and ESB

A key element of an aspect-oriented solution is the life cycle of its components. Let's look at how the SOA lifecycle works for the ESB. In Figure 6, you can see the SOA Foundation life cycle.

Figure 6. SOA Foundation life cycle

The model phase includes the following activities: collecting interconnection and metadata requirements by analyzing the interaction of the service requester and provider, and the relevant requirements and supplies can be described in the registry. Model and design the mediation flows necessary to support the required interconnects.

The assembly phase includes the following activities: A mediation flow is combined from a smaller, granular mediation pattern. Mediation patterns can be pre-built as part of an ESB product. These mediation patterns can exist in enterprise-specific asset repositories. Alternatively, these mediation patterns can be newly developed for the solution. Stores metadata about mediations in the service registry for use by service requesters. This metadata describes the related aspects of the connection, such as security.

The deployment phase includes the following activities: Configuring mediations for Deployment to a specific runtime topology, and some of the required configuration information is stored as service metadata in the registry. Deploy the mediation to one or more run-time environments. Modify the service metadata to affect the dynamic behavior of the solution.

The management phase includes the following activities: monitoring the behavior of service interactions using mediation mode. Service interactions are managed and protected as security and management services and as a policy enforcement point for the registry.

An ESB plays an indirect role in the governance process of a service-oriented solution, because governance drives policies for security, management, and service interactivity. As already stated, the ESB can be used as a policy enforcement point for these aspects. The ESB must also be taken into account in governance decisions. For example, the governance process determines which services can be accessed through the ESB to ensure loose coupling, thus determining which mediations to deploy in the ESB.

Summary

In this introductory article, you learned how Enterprise service bus is a key architectural pattern in SOA and in IBM's SOA Foundation. This article uses product-agnostic terminology to describe how the ESB supports the aspect-oriented connection between service virtualization and interaction participants. This architecture pattern can be implemented using a variety of logical topologies and a variety of middleware technologies and products. Subsequent articles in this series explore the various ESB topologies and how they provide value. You'll also look at mediation flows in more detail, relationships with service registries, and how IBM ESB products such as WebSphere ESB, WebSphere Message Broker, and WebSphere DataPower relate to that architecture pattern.