Browse Prior Art Database

Set service Unavailable on Message Broker Systems

IP.com Disclosure Number: IPCOM000203592D
Publication Date: 2011-Jan-28
Document File: 2 page(s) / 103K

Publishing Venue

The IP.com Prior Art Database

Abstract

Algorithms for ESB (Enterprise Service Bus) and Messaging, including routing and Mediation, the ability to set (detect) a service as "unavailable" in a Message Broker environment is the novelty of this disclosure. What happens in a typical broker environment today is that when a service is unavailable, the request does not return with an "unavailable" setting and will make an application appear to be idle/hung. The invention would enable rapid detection of an "unavailable" service and return the request efficiently.

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

Page 01 of 2

Set service Unavailable on Message Broker Systems

Disclosed is a process for providing a capability of an enterprise service bus with messaging, routing and mediation. Users typically wait for synchronous messages from thirty seconds to two minutes or longer on systems using a message broker concept before getting an exception in the application of the user. The exception occurs resulting from an unplanned outage, for example, a network issue between a message broker and a database, depending messaging

p

 rotocol or message broker configuration. The message broker typically has transactions queuing which impact processor and memory utilization. Eventually after sufficient time an exception is passed to the customer as time-out exceptions. Figure 1 depicts a typical messaging scenario.

(This page contains 00 pictures or other non-text object)

Figure 1

Currently typical message broker systems do not have a feature of the disclosed process for avoiding queuing of messages on the message broker and resulting high response time to users. In one embodiment of the disclosed process synchronous services and asynchronous services are monitored. When a monitored service attains a configurable predetermined threshold, for example, a specific number of time-outs within a set time interval, an embodiment of the disclosed process programmatically sets the service (the service may also be a flow or application program interface) as unavailable. Using a predetermined list of notification subscribers, the embodiment of the disclosed process also send notifications (for example, a

  ager notification) to all subscribers involved with the impacted service. The notification may be in the form of a request requesting a check of the tier of the subscriber and for the subscribers to contact each other to determine a root cause, work around and proposed action to avoid a future occurrence.

Using the disclosed p...