Using Ensemble as an ESB
Enterprise Service Bus and Registry Overview
[Home] [Back] [Next]
InterSystems: The power behind what matters   

This chapter introduces using Ensemble as an Enterprise Service Bus, describes the Ensemble 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:
Why would you need an ESB? Consider the following scenario:
  1. Your enterprise has developed many critical applications. Each application has its own environment and user interface and is independent of the other applications.
  2. 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.
  3. You modify the applications to provide access via a SOAP or REST API.
  4. 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.
  5. 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.
  6. 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.
  7. Users are uncertain who to contact when they run into problems.
Using Ensemble 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 Ensemble ESB architecture has the following components:
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 Ensemble 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.
Simple Enterprise Service Bus Architecture
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:
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 Caché 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 Ensemble service registry. The HealthShare service registry provides a similar capability to the Ensemble External Service Registry. In most cases you should continue to use the HealthShare service registry and not use the Ensemble External Service Registry.
Configuring an Enterprise Service Bus
Installing and configuring Ensemble is described in Preparing to Use Ensemble. This document describes the few configuration procedures that are specific to Ensemble installations that are being used as an ESB. These procedures are:
See Overview of Configuring Ensemble as an ESB for details.

Send us comments on this page
Copyright © 1997-2019 InterSystems Corporation, Cambridge, MA