Skip to end of metadata
Go to start of metadata

Overall architecture of the UltraESB is discussed under 2 main categories in brief in this section of the documentation

Deployment Architecture

The UltraESB maybe deployed as a stand-alone server, a cluster, or deployed onto a JEE servlet container (e.g. Tomcat) or an application server (e.g. JBoss). For production deployments, the standalone server is recommended as it is better to allow the UltraESB its own JVM instance. The standalone instance could be started on the command line, or executed as a service. For production deployments a Linux OS is recommended, while for development activities, a Linux or Windows workstation is supported.

The UltraESB is typically fronted by a hardware load-balancer for HTTP/S based messages. For messages received over the internet a firewall is recommended. The UltraESB clustering is based on Apache ZooKeeper, and hence the whole cluster can be managed by connecting to any node via JMX. The nodes in the cluster would generally run an identical configuration made available over a shared drive, or version control system.

An instance maybe managed via the:

  • Web based management and monitoring console - UConsole
  • Command Line Interface (CLI) and scriptable client - UTerm

It is interesting to note that both the UConsole, and UTerm maybe run outside of the core cluster, on separate dedicated machines - or even from a remote developer desktop. The core ESB is thus completely separate from its management interfaces, which connects to it only via JMX. All ESB nodes publish JMX based statistics, and expose management methods. The UConsole is able to automatically register metrics of nodes against a Zabbix server instance. Zabbix is a free and open source enterprise management and monitoring system, which can collect historical metrics, generate graphs and fire triggers based on thresholds to issue notifications on SLA violations or possible warnings or issues via email/SMS etc.

Apache ZooKeeper is an enterprise clustering framework developed at the Apache Software Foundation, and used in Apache Hadoop and other large scale software systems across many large internet based companies.

Product Architecture

The UltraESB internally is a Spring framework based application, configured by a typical Spring configuration already familiar to many developers. While using the Spring framework syntax to configure all static aspects of the ESB (e.g. Transports, JMX, Work Managers, File caches etc), the dynamic aspects are configured with an extended customized syntax injected to the Spring configuration. These are the elements listed below

Dynamic Configuration Elements - Services, Endpoints and Sequences

Proxy Services are the basic units of deployment on the UltraESB. They define a service exposed over one or more transports, and uses one or more sequences and endpoints to define the behavior of the service. A service can accept messages over any of the existing transports supported by the UltraESB - or on custom transports implemented by users (e.g. TCP based proprietary transports etc).

A Sequence defines the actions to be performed on a message received over a transport, and maybe specified as a Java code fragment, Java class, Spring bean or a JSR 223 (e.g. Groovy, Javascript, Ruby, etc) script fragment or file. The ability to specify this mediation logic in Java or a JVM based JSR 223 scripting language allows trivial integration with any third party libraries or custom code. In addition, all features of the Java programming language is available to the user - such as Exception handling via try-catch-finally blocks, ability to code a sequence as a class/methods and use extension, IDE based development, auto-completion and debugging and unit testing etc.

An Endpoint defines how a message should be sent out of the ESB to another service over any supported transport (e.g. as HTTP/S, JMS, File, S/FTP, Email, MLLP, etc), including specification of load balancing and fail-over logic. Additionally, an endpoint is used again when a HTTP/S style message needs to be sent back over the original connection as a response to a client making the request.

While standard Java exception handling can be fully utilized during the execution of a sequence, a sequence can also assign another sequence as an error handler for any un-handled exceptions. Similarly a Proxy service can assign an error handler which will be invoked when an un-handled exception is encountered by a sequence or endpoint. An error handler will typically report the error along with the error code and description made available with the message encountering the problem to a log file and/or database or external system (e.g. JMX), and try to perform recovery measures.

The above image shows a sample Proxy Service configuration, with in-lined sequence definitions and endpoint definitions.This XML configuration snippet is a valid Spring configuration with the extended schema, and is processed by the UltraESB to create the different configuration elements. The proxy service always has an ID (1) which usually may influence the URL of the service. (e.g. default http/s based proxy services are made available at URL /service/<proxy-id>) The URL of a service can of-course be user defined - including with a pattern (e.g. "/banking/load-*" etc). A service also specifies the transport ID (2) where it is made available to receive messages. One or more transports can be specified along with service specific transport configuration properties. The inSequence processes messages arriving at the proxy service and is optional. The optional inDestination specifies a target for the message after processing - usually another external service, a JMS destination, File system, Email etc. A sequence may also control the target destination endpoint during mediation - for example, looking at message headers, or content based routing. If an endpoint returns a response back, it will be processed by an outSequence, and then forwarded to an outDestination - usually as a response back to the original client.

Deployment Units

Based on the deployment and management aspect the above dynamic configuration elements are groped into a single component called a "Deployment Unit". A deployment unit is a collection of proxy services, sequences/mediation, endpoints, any custom resources and libraries used by the mediation flows. Deployment units are either directory or a zip/uda archives placed at conf/deployments directory. There must be a ultra-unit.xml spring configuration file on the top level of the deployment unit. These can be loaded, unloaded or updated - without bringing down the ESB with a graceful maintenance shutdown. Changes or updates can be easily triggered cluster wide as well, and the UltraESB guarantees that any message exchange will use only the previous version or the updated version only.

It doesn't have any significance to the configuration, except for the fact that the configuration elements defined in a deployment unit is not shared among the other deployment units by default. So any re-usable sequence or endpoint is only available within that deployment unit artifacts. This is by design to make sure that a particular deployment unit can be administrated (undeployed/updated) without worrying about the other deployment units running on the system.

While it is possible to define artifacts that are shared among other deployment units by specifying a "shared" attribute with value true in any sequence or endpoint, it is recommended that the configuration developer should try there best to avoid using that, as that affects the ability to reload the deployment unit at runtime.

Globally shared static artifacts


It is possible to define globally shared static configuration elements such as sequences and endpoints which are available to artifacts defined in all deployment units by defining them in the ultra-custom.xml spring configuration file. However the down side is that it is not possible to update those defined in the ultra-custom.xml configuration at runtime.

Deployment units can contain libraries and any other resources that are local to a particular deployment unit, meaning that it is possible to use 2 different versions of the same library for 2 deployment units running on the same ESB server.

Core Static Configuration Elements

These are the static configuration elements that define the configured transports, Work Managers, File Caches, JMX connection semantics and other static aspects of an ESB configuration. The user is responsible for selecting the required transports for a solution, from the set of supported transports, and for configuring them as per production deployment requirements. For example, the HTTPS transport will require a user to setup the certificates, while the JMS transport will require the user to configure JMS provider access via standard Spring notations. Similarly other transports will require different configurations. These are usually defined in the conf/ultra-root.xml - and one must note that the default configuration provided is just a sample, and must thus add other transports (e.g. JMS, Email, S/FTP etc) as required into this file.

  • Transport Listeners
  • Transport Senders
  • Work Managers
  • File Caches

Transport listeners and senders allows the ESB to accept messages from or send message to external sources via the specified transports. Work managers are execution thread pools optionally assignable to proxy services for mediation. This allows some services to be allocated to a larger/high priority thread pool, while some others to another one or more thread pools. By default, work managers are hidden from users, as a system-wide default work manager is assigned to each proxy service, unless the user customizes this aspect. A file cache manages a cache of pre-created files which are based on a RAM disk or memory-mapped so that they could be used to write message payloads by the ESB. By creating the files up-front, and my memory mapping or via a RAM disk, this exercise creates a very efficient way to store message payloads, without causing a garbage collection (GC) overhead to the JVM, and facilitating zero-copy transfer of messages from the network interface to the files.

Custom Configuration Elements

By default, the conf/ultra-root.xml statically imports elements defined in the file conf/ultra-custom.xml - which is left for the user to define aspects and Spring beans etc, which are around the usage domain of the deployment. Thus this file could include definitions for custom Spring beans used by the ESB configuration, as well as any re-usable sequences, endpoints or proxy services. However, note that elements defined statically - such as the ultra-root.xml or ultra-custom.xml and any other configuration fragments cannot be changed while the ESB is in operation.


Environments are a set of named deployment configurations. There are few, pre-built environments and you can define your own environments as well. Environment is an easy way of switching a configuration from development to test to staging to production. A particular environment is associated with a set of environment properties which defines the deployment configuration. For example it defines the number of parser instances to be cached in the system, where as the value of that could be just 1 for development 10 for test, and 1000 for staging and production etc. Apart from that an environment is used to determine whether a particular feature is turned on or off on the setup, for example "Binary Class Reloading" is enabled on production and may not on test.

These named configurations helps users to optimize there setup for the purposes, where the development environment consumes lessor memory compared to production environment etc. While it is possible to define new environments it is also possible to overwrite a certain set of properties of a named environment. The following tables demonstrates the pre-built environments and there respection default configurations.


Integrated Development


Unit testing & Build

Sample configuration


TestingStagingProduction deployment
Tuned for PerformanceNONONONOYESYESYES
  • No labels