Patent application title: Rules engine for a persistent message store

Abstract:

A method and apparatus for using a persistent message store in a
distributed computing system. A message is stored in a persistent message
store, wherein the message is a copy of an original message transmitted
from a message producer to a message consumer in a distributed computing
system. A command is received from a requestor to search the persistent
message store for a stored message, the command indicating a search rule.
The search rule is processed by a rules engine of the persistent message
store to search for the stored message.

Claims:

1. A computer implemented method, comprising:storing a message in a
persistent message store, wherein the message is a copy of an original
message transmitted from a message producer to a message consumer in a
distributed computing system;receiving a command from a requestor to
search the persistent message store for the stored message, the command
indicating a search rule; andprocessing the search rule by a rules engine
of the persistent message store to search for the stored message.

2. The method of claim 1, further comprising:receiving a new search rule
from the requestor;storing the new search rule;assigning a rule
identifier to the new search rule; andcommunicating the rule identifier
to the requestor.

3. The method of claim 2, further comprising:receiving a search command
that includes the rule identifier; andprocessing the new search rule by
the rules engine.

4. The method of claim 1, further comprising:transmitting the message to
the requestor if the message is found.

6. The method of claim 1, wherein the command includes the search rule.

7. A machine-accessible storage medium including data that, when accessed
by a machine, cause the machine to perform a method for a service
oriented architecture, comprising:storing a message in a persistent
message store, wherein the message is a copy of an original message
transmitted from a message producer to a message consumer in a
distributed computing system;receiving a command from a requester to
search the persistent message store for a stored message, the command
indicating a search rule; andprocessing the search rule by a rules engine
of the persistent message store to search for the stored message.

8. The machine-accessible storage medium of claim 7, the method further
comprising:receiving a new search rule from the requestor;storing the new
search rule;assigning a rule identifier to the new search rule;
andcommunicating the rule identifier to the requester.

9. The machine-accessible storage medium of claim 8, the method further
comprising:receiving a search command that includes the rule identifier;
andprocessing the new search rule by the rules engine.

10. The machine-accessible storage medium of claim 7, the method further
comprising:transmitting the message to the requestor if the message is
found.

12. The machine-accessible storage medium of claim 7, wherein the command
includes the search rule.

13. An apparatus for a distributed computing architecture, comprising:a
router networked to a message producer and a message consumer, to
intercept a message generated by the message producer, and to generate a
copy of the message;a persistent message store coupled with the router to
store the copy of the message, and to receive a command from a requestor
to search for the copy of the message, the command indicating a search
rule, anda rules engine coupled with the persistent message store to
search for the copy of the message using the search rule.

14. The apparatus of claim 13, further comprising:a message store manager
coupled with the persistent message store to receive the command, the
message store manager including the rules engine to search for the copy
of the message in the persistent message store.

15. The apparatus of claim 14, further comprising:the message store
manager to receive a new search rule from the requester, to store the new
search rule, to assign a rule identifier to the new search rule, and to
communicate the rule identifier to the requestor.

16. The apparatus of claim 15, further comprising:the message store
manager to receive a search command that includes the rule identifier,
and to process the new search rule by the rules engine.

17. The apparatus of claim 13, wherein the message store to transmit the
copy of the message to the requestor if the copy of the message is found.

18. The apparatus of claim 13, further comprising:a comparator to compare
search rules, and, if duplicate search rules are discovered, to delete
the duplicate search rules.

19. The apparatus of claim 13, wherein the command includes the search
rule.

Description:

REFERENCE TO RELATED APPLICATION

[0001]This application is a continuation in part of application Ser. No.
11/809,829, which was filed on May 31, 2007, and which is hereby
incorporated by reference.

TECHNICAL FIELD

[0002]Embodiments of the present invention relate to distributed systems,
and more specifically to use of a persistent message store in a service
oriented architecture.

BACKGROUND

[0003]Periodically, applications and services in a distributed system
terminate abnormally. Often, an abnormal termination is caused by a state
change that should not have occurred. In a distributed computing
environment, it can be difficult and time consuming to determine a cause
of the abnormal termination. This may be especially true for distributed
computing environments that include non-deterministic components (e.g.,
applications or services).

[0004]Debugging in a non-deterministic system is more difficult than
debugging in a deterministic system. In a deterministic system, given
some set of input messages, the same state will always be achieved, and
the same output will always be produced. Therefore, a fault may be
recreated by applying the same set of inputs (e.g., messages) that
originally caused the fault. In a non-deterministic system, on the other
hand, a single set of input messages may cause different states, and
induce different output messages to be generated. Therefore, it may
require upwards of 100 or more executions to recreate a fault.

BRIEF DESCRIPTION OF THE DRAWINGS

[0005]The present invention is illustrated by way of example, and not by
way of limitation, in the figures of the accompanying drawings and in
which:

[0006]FIG. 1 illustrates an exemplary distributed system, in which
embodiments of the present invention may operate;

[0007]FIG. 2 illustrates a flow diagram of one embodiment for a method of
maintaining a persistent message store in a distributed system;

[0008]FIG. 3 illustrates a flow diagram of another embodiment for a method
of maintaining a persistent message store in a distributed system;

[0009]FIG. 4 illustrates a flow diagram of one embodiment for a method of
using a persistent message store in a distributed system;

[0010]FIG. 5 illustrates a flow diagram of one embodiment for a method of
debugging a distributed system using a persistent message store;

[0011]FIG. 6 illustrates a flow diagram of one embodiment for a method of
searching for messages in a persistent message store;

[0012]FIG. 7 illustrates a flow diagram of one embodiment for a method of
adding search rules to a message store manager and/or to a persistent
message store;

[0013]FIG. 8 illustrates a flow diagram of one embodiment for a method of
consolidating search rules; and

[0014]FIG. 9 illustrates a block diagram of an exemplary computer system,
in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION

[0015]Described herein is a method and apparatus for using a persistent
message store in a distributed computing system. In one embodiment, a
message is stored in a persistent message store. The message may be a
copy of an original message transmitted from a message producer to a
message consumer in a distributed computing system. Upon receiving a
command from a requestor, the persistent message store may be searched
for the stored message. The command may indicate a search rule, which may
provide search criteria. The search rule may be specified in the command,
or may be located at the persistent message store or at a message store
manager that manages the persistent message store. The search rule may be
processed by a rules engine of the persistent message store to search for
the stored message. The rules engine may be hosted by the message store
manager.

[0016]In the following description, numerous details are set forth. It
will be apparent, however, to one skilled in the art, that the present
invention may be practiced without these specific details. In some
instances, well-known structures and devices are shown in block diagram
form, rather than in detail, in order to avoid obscuring the present
invention.

[0017]Some portions of the detailed description which follows are
presented in terms of algorithms and symbolic representations of
operations on data bits within a computer memory. These algorithmic
descriptions and representations are the means used by those skilled in
the data processing arts to most effectively convey the substance of
their work to others skilled in the art. An algorithm is here, and
generally, conceived to be a self-consistent sequence of steps leading to
a desired result. The steps are those requiring physical manipulations of
physical quantities. Usually, though not necessarily, these quantities
take the form of electrical or magnetic signals capable of being stored,
transferred, combined, compared, and otherwise manipulated. It has proven
convenient at times, principally for reasons of common usage, to refer to
these signals as bits, values, elements, symbols, characters, terms,
numbers, or the like.

[0018]It should be borne in mind, however, that all of these and similar
terms are to be associated with the appropriate physical quantities and
are merely convenient labels applied to these quantities. Unless
specifically stated otherwise as apparent from the following discussion,
it is appreciated that throughout the description, discussions utilizing
terms such as "processing", "computing", "deleting", "storing",
"determining", "storing" or the like, refer to the actions and processes
of a computer system, or similar electronic computing device, that
manipulates and transforms data represented as physical (e.g.,
electronic) quantities within the computer system's registers and
memories into other data similarly represented as physical quantities
within the computer system memories or registers or other such
information storage, transmission or display devices.

[0019]The present invention also relates to an apparatus for performing
the operations herein. This apparatus may be specially constructed for
the required purposes, or it may comprise a general purpose computer
selectively activated or reconfigured by a computer program stored in the
computer. Such a computer program may be stored in a computer readable
storage medium, such as, but not limited to, any type of disk including
floppy disks, optical disks, CD-ROMs, and magnetic-optical disks,
read-only memories (ROMs), random access memories (RAMs), EPROMs,
EEPROMs, magnetic or optical cards, or any type of media suitable for
storing electronic instructions.

[0020]The algorithms and displays presented herein are not inherently
related to any particular computer or other apparatus. Various general
purpose systems may be used with programs in accordance with the
teachings herein, or it may prove convenient to construct a more
specialized apparatus to perform the required method steps. The required
structure for a variety of these systems will appear from the description
below. In addition, the present invention is not described with reference
to any particular programming language. It will be appreciated that a
variety of programming languages may be used to implement the teachings
of the invention as described herein.

[0022]FIG. 1 illustrates an exemplary distributed system 110, in which
embodiments of the present invention may operate. In one embodiment, the
distributed system 100 includes a service oriented architecture (SOA). A
service oriented architecture (SOA) is an information system architecture
that organizes and uses distributed capabilities (services) for one or
more applications. SOA provides a uniform means to offer, discover,
interact with and use capabilities (services) distributed over a network.
Through the SOA, applications may be designed that combine loosely
coupled and interoperable services.

[0023]The distributed system 100 may include clients (e.g., first client
105 and additional clients 125) and services (e.g., first service 110,
additional services 130 and core ESB services 115), connected via a
network 135. Each of the clients 105 and 125 and services 110, 115, 130
may be both message producers and message consumers, as described below.
The distributed system 100 may also include a persistent message store
120 connected with one or more of the core ESB services 115. In one
embodiment, the distributed system 100 further includes a message store
manager 175 connected with the persistent message store 120 and with one
or more of the core ESB services 115.

[0024]The network 135 may be a public network (e.g., Internet), a private
network (e.g., Ethernet or a local area Network (LAN)), or a combination
thereof. In one embodiment, the network 135 includes an enterprise
service bus (ESB). An ESB is an event-driven and standards-based
massaging engine that provides services for more complex architectures.
The ESB provides an infrastructure that links together services 110, 115,
130 and clients 105 and 125 to enable distributed applications and
processes. The ESB may be implemented to facilitate an SOA. In one
embodiment, the ESB is a single bus that logically interconnects all
available services and clients. Alternatively, the ESB may include
multiple busses, each of which may logically interconnect different
services and/or clients.

[0025]Clients 105 and 125 may be, for example, personal computers (PC),
palm-sized computing devices, personal digital assistants (PDA), etc.
Clients 105 and 125 may also be applications run on a PC, server,
database, etc. In the SOA, clients 105 and 125 include applications that
access services 110 and 130. Clients 105 and 125 maybe fat clients
(clients that perform local processing and data storage), thin clients
(clients that perform minimal or no local processing and minimal to no
data storage), and/or hybrid clients (clients that perform local
processing but little to no data storage).

[0026]In the illustrated embodiment, the first client 105 is a message
producer. Alternatively, additional clients 125, first service 110,
additional services 130 or core ESB services 115 may be message
producers. A message producer is a client or service that generates a
message. Messages include data that may convey information to, or
initiate an event on, a message consumer (e.g., a service or client). A
message may be generated for any of a myriad of purposes. For example,
the message may be generated to report a purchase of a good, to request
contact information, to begin a remote process (e.g., initiate a
service), etc.

[0027]In one embodiment, a message includes a message header, a message
context and a message body. The message header may include a unique
message identifier and routing information (e.g., recipient, sender,
message priority, etc.). The message header may be used to identify the
message, and to route the message to end points (recipients) intended by
the message producer and/or as determined by the ESB (e.g., by a router
within the ESB). The message may be directed to a specific endpoint
(e.g., a specific client or service). Alternatively, the message may be
posted to an intermediate location, which one or more endpoints may
communicate with to receive the message.

[0028]The message context may include properties that support
compatibility between services and clients (e.g., between the message
producer and message consumers). The message context may provide, for
example, custom fields or filters, transactional information (e.g., to
identify a distributed transaction or session associated with the
message), security information (e.g., authorization information,
authentication information, etc.), and so on.

[0029]The message body may include data to which a client or service may
respond (e.g., by initiating an event). The content and configuration
(layout) of the message body may determine a message type. Examples of
message types include text messages, map messages, bytes messages, stream
messages and object messages. Other message types are also possible. In
one embodiment, the message body is formatted using an extensible markup
language (XML). Use of XML allows flexible information formats to be
implemented. Other flexible information formats, such as standard
generalized markup language (SGML) may also be used for the message body.

[0030]Services 110 and 130 may be discretely defined sets of contiguous
and autonomous functionality (e.g., business functionality, technical
functionality, etc.). Services 110 and 130 may be resident on personal
computers (PC), servers, routers, etc. Each service 110 and 130 may
represent a process, activity or other resource that can be accessed and
used by other services or clients on network 135. Each service 110 and
130 may be independent of other services 100 and 130, and may be accessed
without knowledge of its underlying platform implementation.

[0031]In an example for a business function of "managing orders," services
may include, for example, create order, fulfill order, ship order,
invoice order, cancel/update order, etc. Each such service may be
autonomous from the other services that are used to manage orders, and
may be remote from one another and have different platform
implementations. However, the services may be combined and used by one or
more applications to manage orders.

[0032]In the illustrated embodiment, the first service 110 is a message
consumer. Alternatively, first client 105, additional clients 125, core
ESB services 115 or additional services 130 may be message consumers. A
message consumer receives a message generated by a message producer.
Based on the content of the message, the message consumer may store
information contained in the message, generate a response message to send
to a service or client, undergo a state change, and/or initiate some
other event. A state change initiated by a message may be dependent on
contents of the message (e.g., the message body, message context, etc.),
rules governing responses to the message, etc.

[0033]In one embodiment, the distributed system 100 includes an ESB that
has a collection of core ESB services 115. The core ESB services 115 act
on messages that flow through the ESB. Messages can also be directed
towards any of the core ESB services 115 in the same manner as described
above with reference to the first service 110 and additional services
130. Any of the core ESB services 115 may include one or more general
purpose computing devices (e.g., personal computer or server) and/or a
special purpose computing devices configured to act on messages that flow
between message producers (e.g., clients or services) and message
consumers (e.g., clients or services) within the ESB.

[0034]In one embodiment, the core ESB services 115 include a content based
router 160. The content based router 160 is a service of the ESB that
monitors the network 135 for messages, and routes the messages between
clients and services. The content based router 160 may be transparent to
both message producers and message consumers.

[0035]The content based router 160 may route all messages that flow
through the ESB, or a subset of all messages. In one embodiment, the
content based router 160 routes messages according to routing information
included in message headers. Alternatively, content based router 160 may
route messages based on information contained within the message (e.g.,
based on the message header, message context, and/or message body). In a
further embodiment, the content based router 160 includes a configurable
rules engine that determines a destination channel (route to a client or
service) based on a set of configurable rules.

[0036]In one embodiment, the core ESB services 115 include a message
copying module 145. The message copying module 145 may be connected with
the ESB and with persistent message store 120. The message copying module
145 monitors the network 135 for all messages that flow through the ESB,
and generates copies of some or all of such messages. The messages may be
copied in a manner that is transparent to both message consumers and
message producers. The message copies may be stored in the persistent
message store 120. In one embodiment, the message copying module 145 is
included in the content based router 160.

[0037]In one embodiment, the message copying module 145 generates a copy
of each message that flows through the ESB. Alternatively, message
copying module 145 may copy a subset of all messages. For example, an
administrator may not be interested in copying all messages that flow
through the ESB. In such a case, messages may be stored, for example,
only for high priority clients and/or services.

[0038]In one embodiment, the message copying module 145 includes a rules
engine 170 and one or more rules 165. A rule 165 is an abstract structure
that describes a formal language precisely (e.g., a set of rules that
mathematically delineates a (usually infinite) set of finite-length
strings over a (usually finite) alphabet). Rules 165 may perform actions,
provide information, help process messages, etc. A rule 165 may include
conditional elements (e.g., and, or, not, exists, etc.), constraints
(e.g., equal to, not equal to, greater than, contains, etc.) and
consequences or actions (e.g., decrypt message, process next rule, etc.).
In one embodiment, a rule 165 dictates a transition to be made on a
message or message consumer based on a set of criteria. Alternatively, a
rule 165 may perform other functions.

[0039]Rules engine 170 may be a logic component that processes rules 165
to produce outcomes. The rules engine 170 may match facts, data and rules
165, and infer conclusions which may result in actions or events. In one
embodiment, the rules engine 170 matches the facts, data and rules 165
using a Rete Algorithm. Alternatively, the rules engine 170 may use a
Linear Algorithm, Treat Algorithm, Leaps Algorithm, etc. Hybrid
algorithms that use combinations of, for example, the Leaps Algorithm and
the Rete Algorithm, may also be used.

[0040]The rules engine 170 may use rules 165 to determine whether messages
should be copied, where messages should be stored, what formats and/or
structures should be used for storing messages, etc. Such decisions may
be made based on message contents (e.g., message header, message context,
message body, etc.). For example, a first rule may specify that messages
produced by client A should be stored in a first file, and a second rule
may specify that messages produced by client B should be stored in a
second file. In another example, storage of messages may be restricted
where a prior agreement allowing copies of the messages to be generated
has not been obtained. In such an instance, rules 165 may enable the
message copying module 145 to only copy messages generated by parties
that have agreed to have their messages copied. Alternatively, rules 165
may proscribe certain portions of a message from being copied, but permit
copying of other portions of the message. Where portions of a message are
not copied, information may be added to the copied message (e.g., to a
header) indicating that portions of the message were not copied, and why
such portions were left out.

[0041]In one embodiment, the core ESB services 115 include a debugging
module 140. The debugging module 140 may be connected with the ESB and
with the persistent message store 120. Debugging module 140 may use
stored messages 155 in the persistent store 120 to debug distributed
system 100. The debugging module 140 may debug the distributed system 100
as described below with reference to FIG. 5.

[0042]Returning to FIG. 1, the core ESB services 115 may include one or
more additional modules 150, each of which may be a service of the ESB.
Examples of additional modules 150 include modules that provide services
for redirecting a message from an original intended endpoint, splitting a
message into multiple messages, combining multiple messages into a single
message, transforming messages from a first format to a second format,
applying rules to a message, etc. Each additional module 150 may provide
a service to clients 105 and 125 and/or services 110 and 130 of the
distributed computing system 100.

[0043]Persistent message store 120 receives and stores message copies from
message copying module 145. Persistent message store 120 may reside on a
single storage device, or on multiple networked storage devices at the
same or different locations, each of which may include RAM, a hard disk
drive, optical drives, etc. Persistent message store 120 may be a
database, a file system, a repository, etc. Stored messages 155 within
the persistent message store 120 may be audited (online or offline) to
verify that they were successfully sent and/or received. Stored messages
155 may be accessed by clients or services, for example, to identify
failed and successful transactions, to verify that messages have been
sent, to error check distributed system 100, etc.

[0045]In one embodiment, message store manager 175 stores message copies
in the persistent message store 120 with keys such that stored messages
155 are searchable based on one or more search criteria. The keys may
include information such as transport medium, message type, message body
content, etc. Alternatively, stored messages 155 may be searchable
without use of such keys.

[0046]In one embodiment, the message store manager 175 includes a rules
engine 190 and one or more rules 185. The message store manager 175 may
further include a comparator 180.

[0047]Rules engine 190 may be used to process the one or more rules 185
stored at the message store manager 175. Rules engine 190 may be the same
as rules engine 170 of the message copying module 145. Alternatively,
rules engine 190 may be different from rules engine 170.

[0048]The one or more rules 185 may have a format similar to or different
from the format of the rules 165 stored in the message copying module
145. Each of the rules 185 includes a set of search criteria to be used
in searching for messages stored in the persistent message store 120.
Rules 185 may be used to search messages based on one or more of a sender
identity, a receiver identity, a timestamp, or other message header
information or message context information. Rules 185 may also be used to
search messages by message type, message body content, or other message
parameters, such as whether a message contains information about errors
(known as fault messages) or a transport medium used (e.g., FTP, HTTP,
etc.). For example, a search may be made that retrieves all messages that
were sent from a first client to a first service during a specified time
period. In a further example, a search may be made that retrieves all
messages that were sent from the first client to the second client during
the specified time period using a file transfer protocol (FTP).

[0049]Rules 185 may be arbitrarily complex, so long as they can be
processed by the rules engine 190. Rules 185 may require an input, or may
require no input. For example, a first rule may run a time frame based
search on messages, and may require that the time frame be input.
Therefore, a message that requests that the first rule be processed would
include a unique identifier of the first rule and the timeframe to be
used for a search. A second rule may search for all messages sent from a
specified client to a specified service. A message requesting that the
second rule be processed may include only a unique identifier of the
second rule.

[0050]New rules 185 may be received by the message store manager 175 to
perform new searches. New rules may be received from clients 105, 125,
services 110, 130 and/or core ESB services 115. Each rule 185 is assigned
a unique rule identifier. Thereby, the rule maybe called via a search
command (e.g., from a message identifying a rule to process).

[0051]The rules 185 and rules engine 190 described herein above may
increase the efficiency with which stored messages 155 are searched on
the persistent message store 120. Rules engine 190 and rules 185 allow
for focused searches of desired messages that may improve search times
and reduce network traffic. Without rules engine 190 and rules 185, only
basic searches may be supported that return many messages to a requester,
most of which may not be relevant. Such messages would then be further
searched at the requestor side. The rules engine 190 and rules 185 allow
for flexible searches that may ameliorate or eliminate such an
occurrence.

[0052]Comparator 180 may compare stored rules 185 to determine whether
there are any duplicates. Comparator 180 may compare rules periodically
(e.g., at a predefined interval) or upon receiving a compare command
(e.g., in the form of a message). Once a duplicate is found, comparator
may then delete it, thus minimizing required storage space.

[0053]In one embodiment, before a rule is deleted, each client 105, 125,
service 110, 130 and/or core ESB service 115 that previously requested
that the rule be processed is sent a notification of the deletion. The
notification may include the unique identifier of a rule that matches to
the rule being deleted. Alternatively, the unique identifier of the rule
being deleted may be applied to the matching rule. Thereby, the matching
rule may be invoked using either its original unique identifier, or the
unique identifier of the deleted duplicate rule.

[0054]FIG. 2 illustrates a flow diagram of one embodiment for a method 200
of maintaining a persistent message store in a distributed system. In one
embodiment, the distributed computing system is a service oriented
architecture (SOA) that includes an enterprise service bus (ESB). The
method may be performed by processing logic that may comprise hardware
(e.g., circuitry, dedicated logic, programmable logic, microcode, etc.)
software (such as instructions run on a processing device), or a
combination thereof. In one embodiment, method 200 is performed by one or
more services of distributed computing system 100 of FIG. 1.

[0055]Referring to FIG. 2, method 200 begins with processing logic
detecting a message transmitted from a message producer to a message
consumer over an enterprise service bus (block 205). The message may
detected by a message copying module, which may be a service of the ESB.

[0056]At block 207, processing logic determines whether the message should
be copied based on predetermined criteria. Such a determination may be
made based on contents of a message header, message context, message
body, etc. In one embodiment, the determination of whether to store the
message is made by a rules engine that uses one or more rules. If it is
determined that the message should be copied, the method proceeds to
block 208. If it is determined that the message should not be copied, the
method ends.

[0057]At block 208, processing logic determines whether the entire message
should be copied. If it is determined that the entire message should be
copied, the method proceeds to block 210, and a copy of the entire
message is generated. If it is determined that only part of the message
should be copied, the method proceeds to block 209, and a portion of the
message is copied.

[0058]At block 215, the copy of the message is stored in a persistent
message store. In one embodiment, a determination of how the message
should be stored in the persistent message store is made by a rules
engine that applies one or more rules. The method then ends.

[0059]FIG. 3 illustrates a flow diagram of another embodiment for a method
300 of maintaining a persistent message store in a distributed system.
The method may be performed by processing logic that may comprise
hardware (e.g., circuitry, dedicated logic, programmable logic,
microcode, etc.), software (such as instructions run on a processing
device), or a combination thereof. In one embodiment, method 300 is
performed by one or more services of distributed computing system 100 of
FIG. 1.

[0060]Referring to FIG. 3, method 300 begins with processing logic
detecting a message transmitted from a message producer to a message
consumer (block 305). The message may be intercepted and routed by a
content based router, which may be a service of an ESB. At block 310, the
message is transformed from a first format to a second format. The first
format may be a format readable by the message producer, and the second
format may be a format readable by the message consumer. In one
embodiment, the message is transformed by a message transformation
service of the ESB.

[0061]At block 315, a copy of the message is generated by a message
copying module, which may be a service of the ESB. The copy of the
message may be generated in the first format or in the second format. At
block 320, the copy of the message is stored in a persistent message
store. The method then ends.

[0062]FIG. 4 illustrates a flow diagram of one embodiment for a method 400
of using a persistent message store in a distributed system. The method
may be performed by processing logic that may comprise hardware (e.g.,
circuitry, dedicated logic, programmable logic, microcode, etc.),
software (such as instructions run on a processing device), or a
combination thereof. In one embodiment, method 400 is performed by one or
more services of distributed computing system 100 of FIG. 1.

[0063]Referring to FIG. 4, method 400 begins with receiving a request to
view a copy of a message (block 405). The copy of the message may be
stored in a persistent message store. The request may be received from a
service or a client, and may include search parameters to identify the
copy of the message. Examples of search parameters include a unique
identifier of the message, a timestamp, message body contents, message
context, etc. At block 410, the copy of the message is presented to the
requestor. Presenting the copy of the message may include sending the
copy of the message to the requester over a network. The method then
ends.

[0064]In a non-deterministic system, given the same set of inputs, a
service or client may generate different messages. The content of the
generated messages may be based on, for example, a day of the week, a
time of day, or some other variable which may or may not be temporal in
nature. Therefore, when a system terminates prematurely (e.g., crashes),
reproducing the system state that caused the premature termination is
nontrivial. To facilitate recreation of a previous system state, a
persistent message store may be used.

[0065]FIG. 5 illustrates a flow diagram of one embodiment for a method 500
of debugging a distributed system using a persistent message store. The
method may be performed by processing logic that may comprise hardware
(e.g., circuitry, dedicated logic, programmable logic, microcode, etc.),
software (such as instructions run on a processing device), or a
combination thereof. In one embodiment, method 500 is performed by one or
more services of distributed system 100 of FIG. 1. In a further
embodiment, the services are core services of an enterprise service bus
(ESB).

[0066]Referring to FIG. 5, method 500 begins with initiating a debugging
mode or a debugging environment (block 505). The debugging
mode/environment may facilitate recreation of a previous system state
that caused the system to terminate prematurely. This may be accomplished
by reproducing and resending each message that was transmitted between
services and clients prior to the premature termination.

[0067]At block 510, a message generated by a message producer is received.
The message may be received by a debugging module. The received message
may be a reproduction of an original message that was generated previous
to a premature system termination, and may have a destination that is the
same as a destination of the original message. However, in a
non-deterministic system, the reproduction of the original message may
not match the original message.

[0068]At block 515, the received message is compared to a message stored
in a persistent message store. The stored message may be a copy of the
original message that was stored in the persistent message store when the
original message was previously transmitted.

[0069]At block 520, processing logic determines whether the received
message matches the stored message. In one embodiment, a match occurs
between an original message and a reproduction of the original message
when the messages are identical. Alternatively, a match may occur when
the messages are substantially the same. For example, a match may occur
even though a time stamp differs.

[0070]If the received message matches the stored message, the method
proceeds to block 525, and the received message is transmitted to a
message consumer. If the received message does not match the stored
message, the method proceeds to block 530, and the stored message is
transmitted to the message consumer. This enables messages (and therefore
transactions) to be recreated even in a non-deterministic system.
Therefore, when a service or client receives a message in debugging mode,
the received message will match (e.g., be the same as or substantially
the same as) a message that it received previously (e.g., prior to a
premature system termination).

[0071]Once debugging mode is initiated (block 505), blocks 510 through 530
may be executed for each message that is received. Therefore, an entire
transaction or multiple transactions that preceded a premature system
termination may be reproduced. For example, blocks 510 through 530 may be
performed with a first message sent from a client to a user, then with a
reply message sent from the service back to the client, and so on. This
may ensure that each message matches its original counterpart that led up
to a premature system termination.

[0072]FIG. 6 illustrates a flow diagram of one embodiment for a method 600
of searching for messages in a persistent message store. The method may
be performed by processing logic that may comprise hardware (e.g.,
circuitry, dedicated logic, programmable logic, microcode, etc.),
software (such as instructions run on a processing device), or a
combination thereof. In one embodiment, method 600 is performed by one or
more services of distributed system 100 of FIG. 1. In a further
embodiment, the method 600 is performed by message store manager 175 of
FIG. 1.

[0073]Referring to FIG. 6, method 600 begins with storing a copy of a
message or messages in a persistent message store (block 605). At block
610, a command to search the persistent message store is received. The
command may identify one or more search rules to use to search for the
message or messages. The one or more search rules may be included in the
command. Alternatively, the search rule(s) may be present at a message
store manager or persistent message store that receives the command. In
one embodiment, the command itself is a message.

[0074]At block 615, the search rule or search rules are processed by a
rules engine to search for the stored message or messages. The search
rule(s) may specify search criteria that are satisfied by the message or
messages being searched for. At block 620, processing logic determines
whether the message(s) have been found. If the message(s) are found, the
method proceeds to block 625. If the messages are not found, the method
proceeds to block 630.

[0075]At block 625, the message or messages matching the search criteria
of the search rule(s) are transmitted to the requestor. The method then
ends.

[0076]At block 630, the requestor is notified that no messages matching
the search criteria could be found. The method then ends.

[0077]FIG. 7 illustrates a flow diagram of one embodiment for a method 700
of adding search rules to a message store manager and/or to a persistent
message store. The method may be performed by processing logic that may
comprise hardware (e.g., circuitry, dedicated logic, programmable logic,
microcode, etc.), software (such as instructions run on a processing
device), or a combination thereof. In one embodiment, method 600 is
performed by one or more services of distributed system 100 of FIG. 1.

[0078]Referring to FIG. 7, method 700 begins with receiving a new search
rule (block 705). At block 710, processing logic determines whether the
new search rule is a duplicate of an existing search rule. If the new
search rule is not a duplicate, the method proceeds to block 715. If the
new search rule is a duplicate, the method proceeds to block 730.

[0079]At block 715, the new search rule is stored. The new search rule may
be stored at a message store manager and/or at a persistent message
store. At block 720, a rule identifier that uniquely identifies the new
search rule is assigned. Thereby, requesters may cause the new search
rule to be processed by a rules engine by providing the rule identifier.
At block 725, the rule identifier of the new search rule is communicated
to an originator of the new search rule. The method then ends.

[0080]At block 730, a rule identifier of the existing search rule is
communicated to an originator of the new search rule. Thereby, the
originator may request that searches may be performed using the existing
search rule. The method then ends.

[0081]FIG. 8 illustrates a flow diagram of one embodiment for a method 800
of consolidating search rules. The method may be performed by processing
logic that may comprise hardware (e.g., circuitry, dedicated logic,
programmable logic, microcode, etc.), software (such as instructions run
on a processing device), or a combination thereof. In one embodiment,
method 600 is performed by one or more services of distributed system 100
of FIG. 1.

[0082]Referring to FIG. 8, method 800 begins with comparing search rules
(block 805). Search rules may be compared to determine whether they
provide the same searches. At block 810, processing logic determines
whether there are any duplicate search rules. In one embodiment, search
rules do not need to match exactly for one to be considered a duplicate.
A first search rule is considered to be a duplicate to a second search
rule if the first search rule would, in all cases, provide the same
search results as the second search rule. If a duplicate search rule is
found, the method proceeds to block 815. If no duplicate search rules are
found, the method ends.

[0083]At block 815, the duplicate search rule is deleted. In one
embodiment, a notification of the deletion is generated and sent to one
or more destinations. The notification may provide a rule identifier of
the search rule that matches the deleted search rule. The destinations
may correspond to clients and/or services that previously used the
deleted search rule. In another embodiment, a rule identifier of the
deleted search rule is associated with the matching search rule. The
method then ends.

[0084]FIG. 9 illustrates a diagrammatic representation of a machine in the
exemplary form of a computer system 900 within which a set of
instructions, for causing the machine to perform any one or more of the
methodologies discussed herein, may be executed. In alternative
embodiments, the machine may be connected (e.g., networked) to other
machines in a LAN, an intranet, an extranet, or the Internet. The machine
may operate in the capacity of a server or a client machine in
client-server network environment, or as a peer machine in a peer-to-peer
(or distributed) network environment. The machine may be a personal
computer (PC), a tablet PC, a set-top box (STB), a Personal Digital
Assistant (PDA), a cellular telephone, a web appliance, a server, a
network router, switch or bridge, or any machine capable of executing a
set of instructions (sequential or otherwise) that specify actions to be
taken by that machine. Further, while only a single machine is
illustrated, the term "machine" shall also be taken to include any
collection of machines that individually or jointly execute a set (or
multiple sets) of instructions to perform any one or more of the
methodologies discussed herein.

[0086]Processor 902 represents one or more general-purpose processing
devices such as a microprocessor, central processing unit, or the like.
More particularly, the processor 902 may be a complex instruction set
computing (CISC) microprocessor, reduced instruction set computing (RISC)
microprocessor, very long instruction word (VLIW) microprocessor, or a
processor implementing other instruction sets or processors implementing
a combination of instruction sets. The processor 902 may also be one or
more special-purpose processing devices such as an application specific
integrated circuit (ASIC), a field programmable gate array (FPGA), a
digital signal processor (DSP), network processor, or the like. The
processor 902 is configured to execute the processing logic 926 for
performing the operations and steps discussed herein.

[0087]The computer system 900 may further include a network interface
device 908. The computer system 900 also may include a video display unit
910 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)),
an alphanumeric input device 912 (e.g., a keyboard), a cursor control
device 914 (e.g., a mouse), and a signal generation device 916 (e.g., a
speaker).

[0088]The data storage device 918 may include a machine-accessible storage
medium 931 on which is stored one or more sets of instructions (e.g.,
software 922) embodying any one or more of the methodologies or functions
described herein. The software 922 may also reside, completely or at
least partially, within the main memory 904 and/or within the processor
902 during execution thereof by the computer system 900, the main memory
904 and the processor 902 also constituting machine-accessible storage
media. The software 922 may further be transmitted or received over a
network 920 via the network interface device 908.

[0089]The machine-accessible storage medium 931 may also be used to store
data structure sets that define user identifying states and user
preferences that define user profiles. Data structure sets and user
profiles may also be stored in other sections of computer system 900,
such as static memory 906.

[0090]While the machine-accessible storage medium 931 is shown in an
exemplary embodiment to be a single medium, the term "machine-accessible
storage medium" should be taken to include a single medium or multiple
media (e.g., a centralized or distributed database, and/or associated
caches and servers) that store the one or more sets of instructions. The
term "machine-accessible storage medium" shall also be taken to include
any medium that is capable of storing, encoding or carrying a set of
instructions for execution by the machine and that cause the machine to
perform any one or more of the methodologies of the present invention.
The term "machine-accessible storage medium" shall accordingly be taken
to include, but not be limited to, solid-state memories, optical and
magnetic media, and carrier wave signals.

[0091]It is to be understood that the above description is intended to be
illustrative, and not restrictive. Many other embodiments will be
apparent to those of skill in the art upon reading and understanding the
above description. The scope of the invention should, therefore, be
determined with reference to the appended claims, along with the full
scope of equivalents to which such claims are entitled.