An analysis of enterprise service Bus Solutions, part 1th: Basic concepts of enterprise service Bus

Introduction

"Everything is flowing, nothing lasts." Everything melts, nothing is fixed "-Heraclitus (Heracleitus)

In about 2003 years, the concept of SOA gradually entered the field of vision, and at one time people happily published their own views of SOA. SOA has become a hot topic for practitioners in the IT industry, especially in the fields of software development and system integration. Many authorities are also predicting the wonderful prospects of SOA, for example, Gartner predicts that by 2008, at least 60% of enterprises will use SOA as their IT infrastructure. Aside from the hustle and bustle and the echoes, for software developers, after more than a year of concept indoctrination, with growing confusion, more people want to take a quiet look at what the system architecture is designed to be SOA, and what technologies can be used to implement SOA? In particular, the Enterprise service Bus, an ESB, seems to be a psycho concept in SOA, and this series of articles will explain in detail how an ESB is implemented in an SOA system through practical case studies.

This series of articles will be directed to a broad range of software developers, starting with an intuitive introduction to what an ESB is, and then introducing a real-world case-based approach that details how to implement an ESB step-by-step. Now that we are talking about SOA and the ESB is no longer castles in the castle, IBM, as an advocate of SOA, has provided a good product to realize our vision. We'll describe two implementations of WebSphere 6 and IBM EAI products in the second and third parts of this series, and then in part fourth, describe how the bus is interconnected and how it expands in complex enterprise scenarios. Hope that through this series of articles, can let the vast number of readers friends quickly grasp the actual development of the ESB skills.

Back to top of page

About SOA

With regard to the concept of SOA, you can find many articles that describe it in different ways, and different software providers have different definitions. Bea has fluid calculations, Microsoft has Indigo and soa-building, and SAP has an ESA. Everyone can understand SOA from a different perspective, from the programmer's perspective, SOA is a new development technology, new component models, such as Web Service, from the architect's perspective, SOA is a new design pattern, methodology, from the perspective of business analysts, SOA is a standard-based business application service. From a conceptual perspective, IBM's definition of SOA is the most comprehensive, and SOA is a way to construct a distributed system that delivers business application functionality to end-user applications or other services in the form of services. SOA includes the following elements:

• An architecture that uses open standards to translate software assets (Asset) into services
• Provides a standard way to represent software assets and their interactions
• Separate software assets are used as construction units and reused to develop other applications
• Shift concerns from detail implementation to application (application) assembly
• Ways to integrate enterprise external applications
• The unification of development (now) and consolidation (future)

This article is aimed at the reader is software developers, standing in the perspective of developers, often hope that software development can meet the development efficiency, reliability, ease of maintenance, easy management and other aspects of the higher requirements. Let's look at the inevitability of SOA's emergence by reviewing the evolutionary process of software development:

• development mode for machine language (Monolithic): code needs to be developed according to the machine language of different platforms.
• Process-oriented (Procedure) Development patterns: machine-independent programming languages (C, Pascal, and so on) make the development process simple, using procedures to represent an abstract collection of code, wrapping the reuse of ready-made code.
• Object-oriented development pattern: to express a relatively complete object with a closer to the real thing. The object-oriented language (Smalltalk,java, etc.) provides a more abstract encapsulation and reuse pattern. Object-oriented development emphasizes the direct mapping from the real-world problem domain to the software program, which is closer to the human natural thinking mode.
• component-oriented (Component) mode: With the scale of software development, in the context of distributed, heterogeneous and other complex features, code-level reusability, poor maintainability, inefficient weaknesses are insurmountable, so people in the framework of the operating environment (such as. Net, Java EE, etc.) to provide a complete support platform, so as to liberate the developers, more focus on business core development. These business functions, which are published in the form of components (DCOM, EJB, and so on), run in the schema runtime environment. The reuse pattern of software development also rises to the level of business components.
• Service-oriented (SOA) patterns: When software is extended to a wider scope, it often faces more complex IT environments and more flexible requirements. The concept of services (service) emerged, and people used the application (application) in the form of business services to be published for others to use, without having to think about which architecture the business services were running on. Because all the services speak the same language. SOA takes into account the long-term nature of business development and embodies the idea of "Change is Eternity". The core of SOA is "reuse" and "interoperability" of enterprise applications or business functions, instead of opposing it to the business, which can be seen as an important step in the direction of it-driven business.

We note that SOA also emphasizes reuse (reuse), but SOA reuse is more granular than traditional code reuse, object reuse, and component reuse. The reuse of SOA lies in the application of business-level, that is, service reuse, which is consistent with the development law of software. In the process of software development, the object of software reuse is more and more close to our real life. Software development is more efficient through the reuse of components, and it begins to attempt to express business patterns with components. However, it is still difficult for IT staff to explain to business people how it architecture maps to the business model. However, bridging the IT architecture with the business model is an unavoidable direction. The biggest challenge facing the business environment of modern enterprises is change, rules changing, demand changing, and the quickest response to change, adapting to change as soon as possible, becoming the key to the successful operation of enterprises. Many businesses have a business environment that relies on their IT infrastructure, so IT departments are often directly bearing the pressure of business change. Every specific business change is directly responsive to the requirements of an existing IT platform: either the enterprise IT architecture itself adapts to change, or it architecture can adapt to new business rules within a short time. This is the root cause of the SOA architecture, where we need a more business-oriented it architecture that can directly portray the business, and for business domain experts who do not know it, the business services are most familiar to them, that is to say, SOA has moved software reuse objects from it to business people. Therefore, we can say that the greatest improvement in SOA compared to other models is its relevance to the business, and the "service" corresponds to the actual business. It has a close relationship with the business through "services", where both business and IT staff can focus on the implementation of the business logic, and the common language is "service".

However, SOA is not available on any occasion. Generally speaking, SOA is suitable for more complex it architectures, often requiring interaction with external complex IT environments, and the need to respond quickly to frequent business changes. Just as you can't use EJB development on a chip that controls a washing machine, if your IT environment is small enough to respond flexibly to changes without frequent interaction with other heterogeneous IT environments, the benefits of SOA will not be enough to offset the system complexity it brings to you. But, even if, you are not completely excluded from the megatrends of SOA. SOA is so compelling that we can anticipate its rapid growth, so even if your internal IT architecture is not SOA-based, you also have the opportunity to participate in future SOA architectures. For example, publishing one of your business as a service to an external SOA platform for others to use, as a service provider for a third-party SOA platform (Provider) exists.

When choosing an implementation of SOA, keep in mind that the specific implementation techniques of software such as Web services and SOA are two different things, SOA is a concept, methodology, or a more fashionable word: a model. And what about Web services? It is a specific implementation technique, just like ejbs. Soa≠web Services. However, it is fair to say that Web services are indeed one of the most suitable technologies for implementing SOA today, and it is a good choice to encapsulate business services with Web services. Because Web services are standard, the WS-I protocol guarantees that Web services from different vendors can interact smoothly even if they are running on different platforms, and that is not the case with any previous technology such as CORBA,EJB, or DCOM. Moreover, the definition and implementation of Web services are described separately, loosely coupled, so that the inherent implementation of the service can be easily replaced without any impact on existing systems, which greatly facilitates the flexibility of the IT architecture.

For a closer look at SOA, you can refer to other SOA-related articles on IBM developerworks (see Resources), and our series of articles will focus on the ESB, so it's no longer too much to discuss SOA. To make our discussion smoother, remember the basic requirements of a typical SOA architecture:

1. SOA encapsulates and reuses application services or business modules on a relatively coarse granularity;
2. The service is loosely coupled, and based on open standards, the interface description of the service is irrelevant to the implementation;
3. Flexible architecture-the implementation details of the service, the location of the service, and the underlying protocol of the service request should be transparent;

Back to top of page

Esb

Let us temporarily return to the era of Internet technology is not popular, how do you transfer files between two machines? I remember to install Borland C + + environment for every machine in the lab and guess what I was using: a "serial line". However, I still feel lucky, fortunately, every machine runs the same operating system-DOS (very few people remember that DOS has interlnk such a command bar), used to pass the serial line between the two machines transfer stream files. Otherwise I will have to use a floppy disk to copy all the installation files. My dream at that time was that one day there was something called "the Internet" that could connect all the machines in the lab without me running between the machines.

Let's get back to the topic and you now have a basic understanding of what SOA is. Assuming you've distilled the business services out of the SOA mindset, you've discovered that many others have done the same thing. Everyone is very excited to start the enthusiastic try, I call you a service, you tune me a service. Ah ha! Everyone has SOA. Wait, what benefits does this SOA bring to you? Ok, now I can invoke. NET components in the Java EE environment, but it can be done without SOA. As long as two nodes mutually recognize each other's way, even if there is no public/unified service interface can also achieve point-to-points interconnection. So we have to admit that this is not a typical SOA architecture if we only have the service, and the requester of the service and the provider of the service still need this explicit point-to call. Take a look at figure two, where both parties to the service must establish a 1-to-1 link. Such a structure is similar to the way I connected more than 10 years ago! But remember the three basic elements of SOA that we mentioned above? Obviously the 3rd did not do.

Therefore, in SOA, we also need such a middle tier, which can help to realize intelligent management between different services in the SOA architecture. The easiest thing to think about is a hub-spoke structure that sets up a hub-like middleware between services in the SOA architecture, which serves as the central manager for the entire SOA architecture. Look at figure three, now there is an intelligent broker between the requester and the provider of the service, and the requester of the service no longer needs to know the details of the service provider. Not bad! Seems to be a good SOA structure. In fact, traditional EAI is a way to try to solve the problem of application integration within the enterprise.

The goal of EAI is to support the re-use of existing IT systems and to extend the lifecycle of these applications by concatenating different software and systems with EAI technology. Traditional EAI often uses message middleware such as CORBA and COM to distribute, cross-platform program interaction, modify enterprise resource planning to achieve new targets, and use middleware, XML and other methods to distribute data. Therefore, the traditional EAI is a part-level reuse. Unfortunately, there is no uniform standard for component-based architectures, so each vendor has its own different EAI solution, and you'll see a variety of middleware platforms. If EAI encounters a heterogeneous IT environment, it must consider how to juggle between different middleware to achieve a reasonable interconnection, you have to consider a variety of complex possibilities. As a result, most of the traditional EAI solutions you've seen are cumbersome.

Look again at the SOA scenario we've described above: a complex enterprise-class architecture. If we choose the hub model to build an SOA infrastructure, what are the possible problems from a purely logical point of view? First, the performance of the entire SOA architecture, if the request of each service through the central hub of the relay, then the burden of the hub will be very heavy, the speed will increase with the number of participants and slower, second, such a system will be fragile, once the hub error, the entire SOA architecture will be paralyzed; Such an architecture would undermine the openness of SOA, and it would be cumbersome for participants to run in a relatively closed environment. Therefore, this is not an ideal SOA architecture either.

Well, now that the ESB is on the scene, see our positive solution:

How does it differ from the previous hub structure? First, it is more open than the form of a single hub, the bus structure can be infinitely expanded, and secondly, the concept of SOA is truly embodied, everything is service, service in the bus is equal status. Even if we need some hubs, they are also deployed on the bus in the form of a service, much more flexible than the structure above. This is the ESB, and we need to give it a clear definition: An ESB is an integrated approach to standards between loosely coupled services and applications. It can be used for:

• Service-oriented architecture-distributed applications consist of reusable services
• Message-Oriented architecture-applications send and receive messages through the ESB
• Event-driven schemas-asynchronously generates and receives messages between applications

Unfortunately, the definition above looks very awkward, and we'll describe it in a more mundane way: an ESB is an intermediary that implements intelligent integration and management between services in an SOA architecture. and its relationship to SOA is relatively well understood: the ESB is a service integration infrastructure that is logically consistent with the underlying principles that SOA follows, providing a way to service management and the ability to interact with services in a distributed, heterogeneous environment. It can be said that an ESB is a way to implement EAI in a specific environment (SOA architecture): First, in an ESB system, the integrated object is clearly defined as a service rather than a variety of middleware platforms in traditional EAI, which greatly simplifies the consideration of integration heterogeneity, Because no matter how the underlying implementation of the application, as long as the service in the SOA architecture, it must be standards-based.

Second, the ESB explicitly emphasizes the role of message processing in the integration process, where the message refers to the communication between the integrated objects in the application environment. In the past, the most important problem encountered in the traditional EAI implementation is that the integrators have their own dialects, that is, their message formats. An EAI system that is an infrastructure must be able to parse any kind of message within the scope of the system. In traditional EAI systems, the processing of messages is mostly passive, and the processing of messages requires the proprietary support of their middleware, such as the way of API. So while the message processing itself is important, the direct processing of the message is not the core of the traditional EAI system. Because the integration object is unified into the service, the format is standard when the message is passed between application services, and the direct message-oriented processing is possible. If the ESB can support the various existing communication protocols at the bottom, then the processing of the message does not take into account the underlying transmission details, but is directly defined by the standard format of the message. Thus, in an ESB, the processing of messages becomes the core of the ESB, because it is the simplest and most feasible way to integrate services through message processing. This is also the embodiment of the bus function in the ESB. In fact, the concept of the bus is not new, the traditional EAI system, has also put forward the concept of information bus, through some middleware platform, such as CORBA to connect Enterprise Information Island, but the concept of ESB is not only to provide the channel of message interaction, more importantly, the provision of services intelligent integration infrastructure.

Finally, event-driven becomes an important feature of the ESB. There are usually two forms of messages passed between services, one is call, that is, request/response, which is a common mode of synchronization. There is also a single-channel message (one-way), which is often intended to trigger an asynchronous event, and the sender does not need to get a reply immediately. Given that some application services are long-running, the message interaction between such asynchronous services is also something that the ESB must support. In addition, many of the functions of an ESB can be implemented using this mechanism, such as infrastructure functions such as performance monitoring of services in SOA, which require data through an ESB, which is very easy for an ESB to pass information to an SOA infrastructure service through an ESB when the service's request is brokered through it.

Back to top of page

The applicable scenarios and elements of the ESB

First, let's take a look at the basic functions of an ESB. Since an ESB will appear as an intermediary, it must have two considerations, first it must understand the two endpoints it mediates: 1) The requester of the service and the requester's requirements for the service, 2) the provider of the service and the description of the service it provides, and secondly, it must have some mechanism to accomplish the task of the intermediary. We summarize these two types of considerations into the two basic functions of an ESB: service-oriented primary data (METADATA) management functions and mediation (mediation) functionality. As an important component of SOA, the responsibility of the ESB also includes how to connect the existing business services in the enterprise architecture to the bus, which we call the adapter (Adapter) feature. Although the service itself has been described with a public interface, the implementation is still running in a different environment, so the ESB should also provide support for the underlying protocol of the service, such as application protocol J2ee,.net, communication protocols such as HTTP,JMS, and so on. In addition, the services involved in specific applications need to be managed, such as performance, reliability, security, and so on.

The ESB provides the most basic functionality to guarantee the operation of the SOA system, which should include the following:

• Registration naming and addressing management functions for services within the bus category-Meta-data management of services
• Service-oriented mediation capabilities
  • Provides location-transparent service Routing and positioning services
  • Multiple messaging patterns (Request/response, single-pass, publish/subscribe, etc.)
  • Support for widely used transport protocols (HTTP,JMS,MQ, etc.)
• Supports multiple service integration approaches, such as JCA, Web services, Messaging, Adaptor
• Support for service management, such as the recording of service calls, measurement, and the provision of monitoring data

In many cases, it is difficult to define which features should be provided by the SOA infrastructure (infrastructure) and which should be addressed in the context of the ESB. The author argues that it is not appropriate to magnify or highlight an ESB's position in the SOA architecture. The logical explanation is that the ESB should be built on a perfect SOA architecture and do what it should-service integration. As for how to integrate, you should consider what SOA infrastructure is available to you based on your context, and then implement your ESB design based on your SOA infrastructure.

At a higher level, the ESB also provides functions such as service proxies, protocol transformations, and so on, which we call the ESB application pattern (ESB usage pattern). As a service integration feature provider for the SOA architecture, we can summarize some of the more common application patterns, such as:

1) Protocol conversion model for message conversion scenarios when the requester of a service and the service provider are based on different protocols

2) message broadcast mode for event-driven multiple actions or message broadcast scenarios

3) service matching mode for situations where a service provider needs to be dynamically selected, for example, depending on the content of the message, or the load situation, or the service level agreement (SLA), to select the appropriate service for the service requester.

Here we have just listed 3 typical patterns, and there are too many examples of this, and you can think of more, and that's the allure of the ESB. However, in the design of the ESB, attention cannot be distracting, and the function of the ESB is to help integrate the services rather than participate in the business logic. Business logic should be encapsulated in a business service or organized through a Business Orchestration Service (Process service).

Back to top of page

Actual combat

There is currently no agreed standard on the ESB. We can realize the integration and interoperability of services by selecting mature EAI middleware. The benefit of this is that your development process will be smooth because it is stable enough and has a wealth of tools to support. Often such EAI products are not based on open standards at this stage, such as IBM's WebSphere MQ5.3, which is not an open standard for the IBM EAI implementation of the ESB's messaging platform. If it is important to choose an open standard ESB implementation, WEB services plus the WS-* protocol is almost our only option, but SOA, ESB is still in its infancy, on the one hand we don't have a mature product to support all the WS-* protocols, on the other hand these WS-* The protocol itself is in a phase of frequent change. So when you choose an ESB implementation, it's best to consider balancing the effort of ESB implementation and development.

Here you may wonder why we tolerate the use of proprietary ESB products such as IBM WBI/MQ to build an integrated environment for SOA architectures, since the SOA architecture pursues openness. This is a good question. SOA is always the big goal we pursue, and openness is the inevitable trend, which is beyond doubt. Note, however, that the definition of an ESB, at least until now, does not explicitly require its implementation to be open, and every software vendor may have different strategies for understanding and implementing it. We do not have to doubt the future of the ESB's path of openness, but at least at this stage we cannot sit and wait for it to come. In fact, the ESB acts as a mediator in the SOA, so even if the ESB changes in the future, there will be no significant impact on the requester of the service and the provider of the service, because it is inherently transparent to the user. For example, the standard of the Java EE has been changing, but it is common for everyone to accept the change, the society is always going to progress, and it is the same. You can't just stop using the current 1.4 because of the 1.6 that Java EE will have in two years.

The products that IBM can now use for ESB implementations can also be divided into two major camps:

1. The EAI solution represented by current stable products such as WS Mq,wbi Message Broker,tivoli.
2. A dedicated ESB platform represented by WAS6 Sibus.

The existing EAI solution may involve the following IBM software products:

• WebSphere BI message Broker is used to provide the Message mediation functionality of the ESB (mediation)
• WebSphere MQ/JMS for message transfer services
• WebSphere process choreographer to implement service flow
• WebSphere adaptor for connecting legacy systems
• Web Service gateway for implementing Web services Proxy, masking implementation details for enterprise internal/external Web services

WAS6 provides a new message service platform WPM (WebSphere platform messaging) and provides a concrete implementation of the ESB based on this platform-SIBus (Service integration Bus) It can support synchronous and asynchronous message communication. The bus manages the message source through the connected Messaging engine. It also supports message interactions based on Web services and JMS,MQ formats. You can see the changes in IBM's strategy from WAS6, Sibus just a step in IBM's support for SOA, and you'll soon see more changes, such as standalone ESB products, ESB development tools, and so on. But you don't have to worry that these changes will remain compatible, and that SOA is now being invested in, either way, in IBM's SOA as a whole.

The two scenarios above are not antagonistic, you can choose to implement an ESB based on a mature product, or you can try out the latest IBM technology. These two schemes can even be interconnected, as shown in Figure eight. We will explain this more complex scenario in the fourth part of the series.

In the next three sections of this series, we will continue to describe in detail the specific implementation steps of the ESB.

Back to top of page

Conclusion

This article introduces you to the basics of SOA and the ESB, identifies some of the most common basic functions of ESB implementations, discusses the necessity of ESB generation, and the position of an ESB in an SOA.

Analysis of Enterprise Service Bus Solutions, part 1th: Basic concepts of enterprise service bus