Mule has the ability to notify you when certain key internal events occur.

Mule has the ability to notify you when certain key internal events occur. It can, for example, raise a notification when a transaction is successfully committed or when it has successfully completed loading. This facility is not very well known and I thought I would create a series of blog posts to talk about it and show how it can be used.
Let me first point out that these notifications are NOT Mule messages. The notification is NOT sent to an endpoint. It is NOT sent via a router. It has nothing to do with the messages that would be sent through a normal Mule application.
The only way you can receive these notifications is if you create a POJO that is registered to listen for them. There are (currently) 12 different types of notifications that Mule can raise:

Manager notifications are raised while the state of your Mule application changes, such as when it is initialising, starting or even stopping.
Model notifications, on the other hand, are raised when the state within a single Mule model (identified by the XML elements) changes. You will also receive notifications when individual components are being registered or unregistered.
Component notifications are specific to state changes for individual components. Whenever a component is started or stopped (or paused and resumed), a component notification is raised.
Connection notifications are related to transports and can tell you whether it was un/successful in connecting to the underlying resource or whether the resource was released.
Message notifications are fired when a MuleMessage is sent or received by the Mule application. While ideal for tracing, the performance impact when using these is tremendous and it is disabled by default for this reason alone. It is the only notification to be disabled by default.
Exception notifications indicate that an exception was thrown.
Transaction notifications show a change in the life cycle of a transaction and therefore shows whether a transaction was started, committed or rolled back.
Security notifications indicate that a request is denied security access.
Space Monitor notifications are related to space implementations such as JavaSpaces, when messages are sent into, or received from, a space.
Admin notifications are fired when requests are received by the Mule Admin agent, usually from the MuleClient through the RemoteDispatcher, which proxies calls to a remote server.
Custom notifications - can be used to raise notifications of your own.
Management notifications show that monitored resources are low ( but this has yet to be implemented)
By being able to monitor certain key events within a Mule application, you can react to changes by performing different tasks. For example, you could stop a service from processing any more messages from its inbound endpoint given certain criteria.
Over the next few blog posts, I am going to do the following:
Show how to create Java classes that can listen for these notifications and act upon them.
Show how to register these Java classes with Mule both through configuration and programmatically.
Demonstrate a typical use-case where system notifications can be used.