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.

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, transports, 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.

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.

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 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.

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.