Browse Prior Art Database

Dynamically interchangeable runtime versioned components for fault tolerant runtime operation Disclosure Number: IPCOM000240233D
Publication Date: 2015-Jan-14
Document File: 2 page(s) / 27K

Publishing Venue

The Prior Art Database


Within this publication, a method to enable dynamic roll-back of version updated components within an Enterprise Service Bus (ESB) system is presented. Such instances may be required when multiple updates to a product result in unexpected failures for a subset of messages being processed, when the previous version level of the system was able to successfully process the messages. This is achieved by enabling the runtime system to instantiate any previous component level and use the components interchangeably during runtime operation.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 2

Dynamically interchangeable runtime versioned components for fault tolerant runtime operation

In production messaging systems the backbone ESB is regularly updated when fixes are available. Most of the time these fixes work and do not introduce regressions. But it is not impossible that a regression may be introduced as a result of unexpected behaviour from the applied fix, which had not been identified in regression testing. This is exacerbated by the fact that groups of fixes are pulled together into a update containing a group of fixes is applied to a system today the fixed code and libraries replace the existing level of code and libraries. The previous level of code is no longer available, but you may rollback the update to a previous version. Whilst this is possible, it is time consuming since this requires rollback of all fixes supplied in the update. It may be a very small number (of potentially millions) of messages which cause this failure and normally it is desired to be running the most up to date version of the code for performance and feature reasons; it is not practical to change complete install levels just for a single poison message.

    Making all previous update levels available to the runtime would alleviate this issue. In such a situation, if an exception occurs in the ESB code base then an alternate path can be tried using the previous version of the ESB component where the exception occurred. For example, we consider a Functional Node that is installed at a version 5, which converts an input message to an output message. During operation the ESB runtime code throws an exception during the processing of a particular message within the Functional Node. Upon exception detection the same message is now routed to the version 4 Functional Node, and if successfully processed, is passed down the flow to the next ESB Node that will be running the most up-to-date version 5 code base. A warning message will also be output to a system or event log to identify that this has happened. This means that a customer will be aware of the issue but processing will still have successfully completed, so their business will not be impacted.

    Subsequent messages may then revert back to using the latest version of the Functional Node class (V5).

    This behaviour could be user customised so that only certain versions can be considered dynamically interchangeable at runtime and this behaviour could even be turned off for certain components.

    Realisation of this idea relies on the fact that the interfaces between the nodes are well defined so that the node runtime code is isolated and operates on a common message tree and common message environment.

    A solution to this problem requires the ability to instantiate different versions of the same class. This is available today in .NET and Java code. For .NET it is possible to specify a version of a...