ESB-Oriented Architecture: a wrong way to adopt SOA

Introduction

More and more customers are often asked to complete projects that do not use SOA at all, but to implement the Enterprise Service Bus (BUS,ESB) architecture only. This type of ESB-oriented architecture is not difficult, but its success is hard to conclude. Customers who require such projects are not aware of this: an ESB-oriented architecture does not bring business value. Projects that are based on an ESB-oriented architecture need to be SOA-based projects to help ensure that business value is delivered successfully.

using only the ESB architecture

SOA is based on business requirements. SOA helps ensure it generates business value by maintaining it-business consistency and enabling IT systems to work in a business-system way. For more details, see the IBM whitepaper "IBM SOA Foundation:an Architectural Introduction and Overview" (The Resources section provides a link).

The main goal of SOA is to be consistent between the business and IT realms, thereby increasing the efficiency of both.

IT departments that use IBM products and services to build IT systems may not know enough about their business needs. For engineers accustomed to precise planning how the system will work, the way the business works may be felt to be unplanned and random. The description appears inconsistent, not feasible, and the needs of business users seem unrealistic and always changing. Business requirements have become "urban myths" that seem to exist in organizations, but are not found in careful analysis.

From this perspective, it is unrealistic to align it with the business. The business unit doesn't seem to know what it needs. Its processes pose a challenge to automation. The work of automating the process is ineffective and untenable.

What engineers know is technology. Technology doesn't need a list of required requirements, just code. The code doesn't complain about bad use, and the compiler doesn't change its needs every day. The code is either running or not running. If the code is running today, it will also run tomorrow.

Technology is easier for engineers to master, and makes them feel more satisfied. This also happens to be the main content of sales for most enterprise software companies. An ESB is a technology that is used to connect to other technologies.

SOA is very complex, and unlike this, the ESB is easier to understand. The ESB does not require any such business requirements, but requires only technical requirements. The ESB is very precise and is based on standards: data format, connection protocol, XML, IP, HTTP, SOAP, JMS, Jax-RPC, JAX-WS, and so on. SOA may always be in a state of stagnation, and building an ESB can actually accomplish some of the work that is visible.

This is often called a project that connects everything. Customers have many parts-applications, computer systems, data centers, departments, subsidiaries, foreign agencies, partners, and customers-that do not communicate with each other. The sections do not know the work done by the other parts. One section has the data needed for another part, so these two parts need to work together. Only all the parts are connected together to work properly. Connecting everything is a problem that can be solved, as compared to trying to understand the effects of business requirements, because the solution is technology. If you compare IT to a hammer, the ESB is a nail in SOA.

They often think, "We don't know what else we need, so for now we'll just build an ESB." "But this is not the actual difference between" You start writing code, and we'll see what they need "method.

ESB "Land of Dreams" Introduction

Readers often summarize the idea of connecting everything through a single part: An Enterprise service Bus (ESB). So what exactly do they want when they say they need an ESB? What does their ESB refer to? It is really necessary to call it an ESB.

Customers often like to replace the first word in an ESB. They do not use the enterprise and use other organizational units, such as companies, departments or governments. It is sometimes used for descriptions, such as purchasing or payroll. or describe what it will deliver, such as a product or an order. Even if the customer needs the company's product Procurement Service bus, do not be fooled by the words before service bus. What these customers need is an ESB. They sometimes even describe the need for "an ESB, but ...".

The customer's focus is actually on the last part: the bus. In a technical topology that includes a bus, all objects are connected to the bus, and therefore the bus is also used to connect to all other objects. The bus is the main road of communication between the various parts. Communication between applications, even between computers on the network, is usually done using messages (that is, a series of different information packets). Enterprise Integration Patterns (see the links provided in the Resources section) provides a good overview of this, which is called the message bus.

Clients often do not think too much about the service parts of the ESB. XSB (x can be a business or something else) is used to invoke the service, otherwise it is just a message bus. A service invocation is an application that tells another application what to do, while the latter completes the work, and usually sends back a response to report the results.

So, if the customer wants to build a xSB, what the service is. The IT staff may say, "The service can be anything that is needed in any form." It is most clearly stated that the project is in fact still a technical solution. Implying that the service is irrelevant, is that the application using the bus is irrelevant, how the application uses the bus is irrelevant, and that the application integration requirements (which are not considered business requirements) are irrelevant. XSB will be used for any purpose. An ESB that is architecture-oriented for SOA may initially overlook many of these service requirements, as services become apparent in the process of enriching SOA. But an ESB without SOA has no service, so it's just a bus.

Building a bus-only project can be considered an IT-in-the-Dream project. Just like Kevin Costner's role in the baseball film of "The Land of Dreams" (Field of Dreams), the IT department holds the attitude that "if you build it, they will come." "If you build a bus, people will build SOA applications around the bus." The problem with the "Land of Dreams" is that unlike Hollywood, there is no guarantee that services will be available in the world of business. If people build SOA applications, it might not be like the application you build, so you may have to do a lot of rebuilding work before you can use it. Even if it is finally put into use and the effect is very good, the delay in getting the reward is very large, which may make it difficult for the IT department to wait for the final happy ending of the movie.

understand the limitations of an ESB-oriented architecture

What's wrong with the ESB? Remember the part where Annie wanted to get divorced with Ray in the middle of the movie? (That's the whole second act, when everyone thinks Ray is a fool.) Your project will also go through a period of time when the project sponsor may not want his employees to leave.

The problem is that the ESB itself does not generate any business value. An ESB is a means of achieving an end, not an end in itself. An ESB is like an SOA wire or pipe. Water pipes do not produce value, and pools with water-emitting taps can bring value. Wires do not generate value, but electric lamps (especially those connected to switches) are valuable. Unless a path allows you to reach another location from one location, the road is worthless. An ESB without SOA is like a way to start and end without meaning. People may eventually want to go to these places, but the road has been full of costs and no good.

An ESB-oriented architecture has an inherent drawback, which is that it builds connections that no one wants to use. Unless the system is connected to each other and works together, the business does not bring any additional value. Until then, the ESB was simply a cost-free thing. The IT department may feel good about building something real, but the business doesn't feel any better, and the business is still unable to do what it doesn't do without an ESB. The ESB became an unnecessary thing for the IT department and a nuisance in the deployed application topology.

Do not follow the IT "Land of Dreams" approach to "if you build it, they will come", a sentence in extreme programming (Extreme PROGRAMMING,XP) may be more appropriate: "You will not need it." "This statement represents a very practical principle:

implement what you want when you really need it, not when you expect it to.

This principle, which is built until it is needed, is contrary to the principle pursued by the IT "Land of Dreams" approach. Do not build because you want someone to use it, but build it when you know someone really needs it. This ensures that you can build what they really want, not what you think they might eventually need. This will only be built if you really want to get the benefits of this build, until this time you need to pay the appropriate cost. This principle is a good business philosophy and also applies to IT departments and other parts of the business.

using SOA

Now to review the previous section, here are some principles that apply to any software development process: build only when needed. Build something that delivers business value. Keep IT aligned with the business.

Instead of adopting an ESB-oriented architecture, use SOA to build an ESB as part of an SOA. That is, in accordance with IBM SOA Foundation:an Architectural Introduction and overview (see the links provided in the Resources section) for SOA development, creating and integrating SOA Foundatio N-Architecture applications.

With this approach, the ESB can be developed as part of an SOA. You will discover services based on your business needs. Each service requires not only the provider and the consumer, but also the channels in the ESB to connect the two. The channel implements the service interface as a provider (but actually acts as a proxy), including the message format of service requests and responses for remote calls that support services, such as in-process communications. The differences between the service interface, message format, scope, and quality of service of the user and provider can be resolved and eliminated by intermediaries. All of this is at the heart of the ESB design, and no work can be done without knowing the services invoked by the ESB. Understanding these services also requires understanding the services that will be used by the ESB in the SOA.

From this point, connecting the application is a relatively easy part to complete. Connecting their business functions will be a bigger challenge. This cannot be achieved by building only the ESB.

Concluding remarks

Customers often build only the ESB because it involves technical challenges without messy business requirements. Building an ESB just doesn't make sense, because in this case IT builds an ESB and then wants an SOA to appear and use that ESB. This ESB-oriented architecture lacks the benefits of SOA. It does not bring business value. In fact, it generates costs without direct benefits. And that doesn't keep it and business consistent. A better alternative to an ESB-oriented architecture is SOA. Don't just build an ESB, but build it as part of an SOA (preferably the SOA foudation architecture that IBM recommends).

References

Learning You can refer to the original English text on the DeveloperWorks global site in this article. Understanding Enterprise Service Bus scenarios and solutions in a service-oriented architecture, part 1th: This paper studies the implementation of Enterprise Service Bus (BUS,ESB) to support service-oriented architectures (service-oriented ARCHITECTURE,SOA) the minimum required functionality. Understanding Enterprise Service Bus scenarios and solutions in a service-oriented architecture, part 2nd: This article describes and analyzes some common scenarios for implementing an ESB and other service-oriented architecture (SOA) solutions. Understanding Enterprise Service Bus scenarios and solutions in a service-oriented architecture, part 3rd: This article describes scenarios and solutions for implementing Enterprise Service Bus (BUS,ESB). For more information on these topics, please read "Exploring the Enterprise Service Bus, part 2:why The ESB is a fundamental part of SOA". Also read the 1th part of this series, where Greg Flurry refines what an ESB means in an IBM SOA message. "IBM SOA Foundation:an Architectural Introduction and Overview" is a white paper on the IBM SOA Foundation architecture. See "A Quick Intro to websphere®business Process Management", which provides an overview of the IBM SOA product strategy, involving people from the enterprise Architect to all levels of the developer. By reading "Should IT departments really build systems the means Kevin Costner builds baseball fields?" Learn more about the IT "Land of Dreams" concept. Learn more about the ESB. See "Simplifying the integration architecture with Enterprise service Bus" and "Why developers need enterprise service bus." ", James Snell and Bobby Woolf illustrate the practical benefits of using an ESB. For the best way to learn about integrated applications, refer to the Enterprise integration Patterns book. Through Extreme programming RoAdmap wiki "you aren t gonna need It" to learn more details. The IBM developerWorks SOA and Web Services zone provides a number of articles, as well as introductory, intermediate, and advanced tutorials on how to develop WEB service applications. The IBM SOA Web site provides an overview of SOA and describes how IBM can help you implement SOA.