Journey into the world of corporate service tires on IBM WebSphere ESB

This article wants to open a cycle dedicated to IBM WebSphere ESB (hereinafter - ESB) in the context of development for this product. And, first of all, you will have to get acquainted with technologies of this kind.
Enterprise service bus (enterprise service bus) - middleware, providing centralized and unified event-oriented messaging between different information systems on the principles of service-oriented architecture.
Of course, it is possible and without special software (perhaps, something common still needs to be developed) to build a corporate system based on this approach, and what will be the result, call the service bus. But the IBM product has not only a ready-made device for centralized messaging and control of this process, but also a full range of capabilities for developing flexible service-oriented applications specifically for ESB. In summary, the following features and benefits of IBM WebSphere ESB can be highlighted:

• The order and uniformity of architectural relationships
• Centralized management
• Server side application configuration
• Implementing the Service Component Architecture (SCA) technology in the spirit of the principles of service-oriented architecture
• Protocol independence of the developed code
• Extensive bus and application configuration options

In this case, the ESB provides transactional control, data conversion, security and guaranteed message delivery. Access to all services through a single point allows you to configure the communication of services centrally. You can also manage failed events centrally for mass error handling.
The classic ESB build topology is a cluster that provides horizontal scalability and fault tolerance. According to official recommendations, increasing the number of cluster members increases productivity more efficiently than increasing server capacity in a stand-alone topology. In addition, the cluster can be rebooted (or part of it can fail) without stopping the service.
Usually, ESB is used as a service layer in IBM BPM, but it may well play a leading role in building a model of interaction between corporate systems as a powerful integration machine (meaning ESB as an add-on over IBM WebSphere Application Server).
This, in essence, is required from the ESB, since it is a “service collection point” - if you need a service that will work with other services (perhaps external), then the integration between these services is most logical to do on the ESB. For external or heterogeneous services, a “wrapper” can be made an ESB service. We will slightly illustrate the convenience of using “single housing” for services:

Order
The larger the system, the more important it is order and uniformity. If we are talking about a complex of large enterprise systems, then we can definitely call it a large-size system. Of course, you can always find an administrator who has in his head the interaction scheme of hundreds of servers, or a bunch of volumes of unrelated documentation for each software module, which describes what and how it interacts.

But it is much easier to have a service (ESB), which allows you to conduct all the interaction through yourself. With this approach, part of the interaction architecture in any subsystem is already clear - there is no mess in the connections between systems, servers and applications: everything is connected with the ESB and the ESB is connected with everything.


Centralized management
It is always more convenient to configure systems centrally - whether it is configuration, adaptation to server relocation, fault tolerance, load balancing, error handling or monitoring and analytics.

For example, when moving a database server, you do not need to climb into the configuration of all existing application servers, and in setting up specific applications in particular, it is enough to have one environment variable in the ESB, which indicates the database address, and then the changes will need to be done at just one point.
Or, if one of the external systems was unavailable for a long time, and no request to it should be lost, you can use the service of handling failed events to “throw in” the failed messages when it is convenient.
If you need to adjust the number of simultaneous requests to a system, or monitor these requests, analyze the load, look for bottlenecks - you need to go to the messaging control center - to the console of the ESB server.
')
Server side configuration
“Single housing” for services, in terms of configuration, allows to achieve several useful goals. First, it is configuration reuse (similar to code and module reuse, which is so useful in SOA), since different modules and applications can use the same database connection parameters, resources, authentication parameters, environment variables, etc. .

Secondly, when configuring on the server side, it is the application environment that can influence it in many ways, which allows you to transfer applications between different circuits (test and productive), tune and even fix bugs without making changes to the application.

If you use all these advantages, applications get the capabilities of a true chameleon - they are so flexible that they become part of the environment in which they work, and at the same time they bring in their important functionality.

But the flexibility of applications for IBM WebSphere ESB is not limited to their work environment. Development opportunities make a huge contribution to this. Since systems not only need to have where to run, but still need to develop and refine, these interesting points should not be overlooked:

SCA
This architecture is based on the principle that the component provides its functionality as a service available to other components. Within one module, the components are program blocks (java code) that fully implement some functionality described by the corresponding interface. The component execution logic is implemented by linking them into a structure by interfaces and references (Partner Reference).

This module structure is very convenient to develop, test, develop, modify and maintain. The atomicity of the functional implemented in the components allows you to operate on the components as a whole, without going down to the code level. On the other hand, it is logically necessary due to the implementation of component implementations in a transactional context.
Each component has an interface (s), the implementation of which it provides. Thus, interconnecting the components, there is no need to know their internal features - it is enough that they implement the necessary interfaces.
Through this architecture, it is also possible to solve all the tasks that require parallel work, without “manual” flow control (for example, you can make asynchronous calls to several components with a delayed response).
Non-java-components, for example, types Export and Import, allow you to provide services for external use or use external services, respectively; The Mediation Flow component provides low-level access to messages exchanged between other components and allows for various transformations when working with heterogeneous interfaces.
In addition to interfaces, the IBM business object framework provides very useful features. Business objects (BO), represented by xsd-schemes, are used as objects for data transmission in interfaces, both between components, and for communication between modules. They are directly integrated, for example, into the wsdl scheme for describing web services. That is, for example, if module "A" provides its functionality as a web service, module "B" to use it is enough to connect the interface and ready-made BOs, and it will be able to fully work with such a service without creating any additional java -objects for data transfer. BO is also convenient to use when exchanging data from a database, if this data is used by other components (this, of course, goes against the “DAO” pattern, but eliminates unnecessary java-objects and data rewriting operations “back and forth”).

Protocol-Independent Software Code
As you can see, the protocol-independent code is achieved by using the Export and Import components. Since the connection with these components goes through interfaces and references, the program code is completely independent of the protocol used for interaction. The same functionality can be made accessible by any traffic using any number of supported protocols and any desired interfaces. The following figure shows the addition of SCA-bound export to a component that already provides its interface as HTTP, JMS, and Web service.

The convenience is obvious - flexibility, versatility, code reuse, speed of development and modification.
By the way, SCA binding uses a special protocol and is intended for communication between modules within a single server / cluster. Interaction through this binding is less resource intensive and faster than other protocols.

Configuration
Configuring the server and applications is done through the IBM console server.
In ESB, as in IBM WebSphere in general, there are quite a few specific features and artifacts. For example, using the same imports and exports, you can configure the end-points of the corresponding services on the fly. For service calls, you can customize policy sets with various rules (for example, you can install support for the WS-AT mechanism, which allows you to call a web service in the same transaction the client works in; but transactionality is already a topic for a full article) set authentication parameters, connect certificates and so on.
Through the configuration, you can configure some mechanisms for automatic response to exceptional situations (for example, automatic repetition of component execution in case of errors). You can set up component tracing on the fly or change logging levels. Also available is a service for managing failed events that can be consciously used for mass error handling.
Well, of course, you can configure a lot of other things according to the Java2EE specification, which, sometimes quite strictly, is implemented in the IBM Application Server.

All of the above claims ESB as a convenient, powerful and flexible integration apparatus, though not always easy to learn. In the future, you just need to learn how to use it.

The following images were used in the article: 1 2 3 4 5