Browse Prior Art Database

Processing based on system resource monitoring as part of the integration logic

IP.com Disclosure Number: IPCOM000238166D
Publication Date: 2014-Aug-06
Document File: 2 page(s) / 36K

Publishing Venue

The IP.com Prior Art Database

Abstract

A solution described herein is based on system resource monitoring as part of the integration logic, enabling message flows and message flow logic to be driven and make decisions based on interrogation of system resource metrics - providing a smarter ESB solution that is able to more effectively deliver the required business processes.

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

Page 01 of 2

Processing based on system resource monitoring as part of the integration logic

An Enterprise Service Bus (ESB) message flow can be triggered a number of ways - across a multitude of transport protocols, changes in a DB, when a file becomes available in a given directory, etc. However, no current implementations are driven directly from system process data - for instance being triggered based on CPU / memory usage.

    There are technologies that trigger work based on CPU thresholds, for instance as described in the following URL: (http://pic.dhe.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=%2Fcom.ibm.websphere express.doc%2Finfo%2Fexp%2Fae%2Fuprf_prfadvconfig.html):

    The system herein relates to processing based on system resource monitoring as part of the integration logic.

    The system herein uses system resource data - such as CPU utilisation / memory usage / running process data - to drive ESB mediation flows.

Operating Systems expose many interfaces to access system data.

    The system herein utilises such APIs to monitor the appropriate system information as instructed in the appropriate node to determine when to trigger a message flow.

An example usage of such functionality would be:

    Here the "System Input" node output terminal will be fired when CPU utilisation on the box drops below 30%. Then a large file will be read from disk and complex processing carried out. This complex processing is CPU intensive but when the message is processed is not a priority.

    This functionality enables this particular flow to only be driven when the system is quiet. This means that the complex CPU intensive processing of the low priority job will not adversely affect more important processing on the system.

    Functionality does not need to be limited to input nodes, they could also be utilised within interim nodes as well for determination of what logical path to take. For instance:

Here a file is read...