Enterprise Service Bus and Registry Overview
This chapter introduces using InterSystems IRIS® as an Enterprise Service Bus, describes the InterSystems IRIS ESB architecture, and provides an overview of deploying an ESB. It contains the following sections:
Enterprise Service Bus Concepts
An Enterprise Service Bus (ESB) provides a single point to both access and govern applications that have SOAP, REST, or other network APIs. The ESB provides the following capabilities:
Provides a centralized location to discover and access the services.
Isolates applications from detailed knowledge of the services, allowing you to change the description of a service in a single location without having to update all applications that are dependent on it. For example, you can change the address of the server or even the API of the service and handle the changes in the ESB. This provides protocol independence to your applications. If an application is developed using a SOAP API but a new service provides additional functionality with a REST API, the ESB can make the new REST service available as both REST and SOAP APIs allowing you to add the functionality of the new service while maintaining compatibility for existing applications.
Provides a mechanism to organize and track the applications used by the enterprise and the dependencies between these applications. For example, the ESB can provide the contact information for technical support when a user has problems with an application.
Why would you need an ESB? Consider the following scenario:
Your enterprise has developed many critical applications. Each application has its own environment and user interface and is independent of the other applications.
You face new problems and competitive requirements to increase efficiency. To solve these problems you must get these independent applications to communicate and interact with each other.
You modify the applications to provide access via a SOAP or REST API.
You start to develop new applications calling these SOAP and REST APIs. These new applications can combine the functionality of the existing applications, making it possible to combine workflows and streamline procedures.
But each of these new applications requires detailed knowledge of the applications it is using: the address of the server running the application and the specific API needed to access the application.
As the number of these new applications grow, it becomes more difficult to maintain the overall collection of applications. Simply moving a service to a new server or making any change to the functionality of a service requires you to update every application dependent on it. It can be difficult even finding out which applications are dependent on a service.
Users are uncertain who to contact when they run into problems.
Using InterSystems IRIS as an ESB allows you to create a unified mechanism for accessing services. This makes it easier to maintain the set of applications and provides a mechanism to track usage and identify potential blockages˙
Enterprise Service Bus Architecture
The InterSystems IRIS ESB architecture has the following components:
Routing mechanism that connects the incoming requests with the server. This is implemented by a production with specialized business services and business operations, and, optionally, business processes.
Public Service Registry—This service registry is accessible to ESB clients through the ESB public REST API. Developers use it to get information about the services available through the ESB.
External Service Registry—This service registry is accessible only within the ESB production. It provides endpoint information to the ESB business hosts.
SAML token validation service.
Both the ESB production and the service registries should be defined in a namespace that is used exclusively for the ESB.
InterSystems recommends that only one ESB production should be running on an InterSystems IRIS instance.
In its simplest form, an ESB consists of pass-through services, pass-through operations, and the service registries. The following illustrates the architecture of a simple ESB.
Typically, the application developer uses a web page or application to query the ESB service registry to find out about the available services and get the URLs for the pass-through business services that provide access to the underlying services. This query and service discovery process takes place while the developer is creating the client application. Once the developer has the URLs, documentation, and other information needed to access the services, the client application does not need to access the service registry in order to call the services. In some environments, the client application may make runtime calls to the public API to ensure that the registry entry has not been modified since last accessed.
The client application calls a pass-through service. The pass-through service sends the message to the pass-through operation that is specified in its Target setting. The pass-through operation is configured to look up the endpoint URL in the External Service Registry. It then calls the external service using that endpoint URL. The external service returns the response to the pass-through operation, which directs the response to the pass-through service. The pass-through service, in turn, returns the response to the client application.
In addition to pass-through services and operations, you can define more complex services, operations, and business processes to add capabilities such as:
Routing calls from a single incoming service to multiple external services depending on the content of the call. This allows the ESB to provide a service that is not available from a single external service. The client applications are insulated from the external services that are required to implement the expanded service.
Modifying the parameters or protocol used for a service. If a set of applications are developed using one service, but later a superior service with a different API becomes available, rather than modifying each application, the translation can be done in the ESB. The client applications are insulated from the changes required to switch from one external service to another.
Implementing the service directly on the ESB. If there is no external service that meets the need, one can be implemented on the ESB using ObjectScript.
But adding these more complex services to an ESB has an efficiency cost. The additional processing costs of these complex services slows the time it takes for the ESB to handle a request and reduces the throughput.
For ESB systems that require very high throughput, you can reduce the overhead of processing a request by eliminating the persistent messages. The persistent messages are the object that is sent from the pass-through service to the pass-through operation and the object returned by the operation to the service. These objects are stored in the InterSystems IRIS database. These persistent messages are very useful in tracking and reporting on the calls processed by the ESB and in troubleshooting any problems. But creating these objects requires resources and for systems with very high throughput, the storage required for these objects can be very large. To maintain the system, you must frequently purge these messages. You can suppress the use of persisted messages to gain efficiency at a cost of reduced flexibility. See “Suppressing Persistent Messages in Pass-through Services and Operations” for more information.
If you are running a HealthShare product, the HealthShare service registry is distinct from the InterSystems IRIS service registry. The HealthShare service registry provides a similar capability to the InterSystems IRIS External Service Registry. In most cases you should continue to use the HealthShare service registry and not use the InterSystems IRIS External Service Registry.
Configuring an Enterprise Service Bus
Installing and configuring InterSystems IRIS is described in Preparing to Create Productions. This document describes the few configuration procedures that are specific to InterSystems IRIS installations that are being used as an ESB. These procedures are:
Create an interoperability-enabled namespace to contain the ESB production and the Service Registry.
Configure the Web Gateway.
Create External Service Registry entries that define the endpoints for external services used by the ESB.
Create the ESB production, add the business services and business operations that provide the services, and start the production.
Create the roles and users needed to access the Public Service Registry through the management portal and through the public REST API.
Create the web applications needed to make the business services available to clients.
Create Public Service Registry entries that describe the services accessible through the ESB.
See “Overview of Configuring InterSystems IRIS as an ESB” for details.