Mule的通知管理及上下文初始化流程
备个忘：
关于mule大量采用的非阻塞算法：Java 理论与实践: 非阻塞算法简介：http://www.ibm.com/developerworks/cn/java/j-jtp04186/
?
关于galaxy：Open Source Competition - Mule Galaxy vs WSO2 Registry ：http://wso2.org/library/3777
关于SOA治理：SOA治理【一】命名规范：http://kingoblog.appspot.com/2009/05/4/soa-governance-naming.html
?
? 从源码看出基本上所有mule的connector都实现了javax.resource.spi.work.WorkListener接口，也就是说作业（请求处理）的执行过程当中，4个阶段（workAccepted、workRejected、workStarted、workCompleted）都将会通知到相关连接器，连接器是共享的，所以估计连接器会根据correlationID或messageID来将执行结果关联到初始请求消息，再来做后续的请求响应工作。WorkerContext对work做了一层包装，手法是包含，它们共同继承了Work接口，WorkerContext包含work，WorkerContext的执行就是work的执行，此外还做了通知动作，WorkerContext保证了work作业的阶段通知。
? MuleWorkManager的三套作业执行方法通过源码看到由数种MessageReceiver的onMessage（实现自MessageListener接口）方法调用到，应该是Receiver接收器（属于connector连接器）在某端点上监听，一旦消息到达则通过connector得到WorkManager、然后向WorkManager提交work作业。MessageReceiver可以是jms的、tcp的、udp的、xmpp的...结合mule手册看的话connector连接器应该也具备自己的WorkManager线程池，这个线程池由使用了该协议connector的Receivers共享使用，使用了线程池是SEDA的本质特征，每种connector都有自己的线程池（与component等其他线程池无关）也是SEDA的本质特征，connector的线程池将给自己的receiver接收器用来处理收到的消息。
? 作业管理完毕。
? 通知管理? DefaultMuleContext代码：?
??
? DefaultMuleContext持有成员：
configuration.getPolicy().dispatch(notification);?Configuration是通知相关配置类，上述的addInterfaceToType方法实际上是把通知监听器FQN与通知类型的映射存储到Configuration的Map成员interfaceToTypes中，这些实际上都不重要，因为真正做通知操作的是Configuration持有的Policy（描述什么事件应该发往何处、只读的、延迟加载的），Configuration可以说只是Policy的包装类，负责在运行时维护Policy。真正做通知的还是Policy。在此之前的代码都是mule基础架构，基础架构之中发送通知的代码都是写死的，也就是mule底层天然具备通知机制，Configuration + Policy则相当于事件通知最后的把关者，它们结合配置、配合动态改变来最终决定通知能否发送、可以发送给谁。
?
? 参考：System Notifications in Mule：http://ricston.com/blog/?p=87：mule提供一种当特定内部事件发生时的通知机制，比如说在一个事务成功提交、成功完成时发出通知。首先这些通知并非mule消息，通知不是发给端点的，也不经过路由，通知与消息无关（消息是面向外部的ESB消息、通知是mule内部的一种基础多线程通讯机制）
? 接收通知的方式是把你的pojo注册为监听某种类型的通知，目前（08年）有12种通知类型：
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 <model> 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)
? 通过监视某些mule应用关键事件，你就可以对不同task任务的执行作出反应。例如：你可以在某些规则情况下，停止一个service对入站消息的处理——停掉某个服务，SOA治理基本功能之一。要让你的pojo变成监听器的话得继承相应接口：
The ConnectionNotificationListener interface lets a class handle connection notifications. The ExceptionNotificationListener interface lets a class handle exception notifications.The MessageNotificationListener interface lets a class handle message notifications. etc...都是org.mule.api.context.notification.ServerNotificationListener的子接口。
? 通知监听接口命名很有描述性都是类似的不再全部列出了，通过实现一个或多个、你的pojo就能得到特定类型的通知。通知是ServerNotification类型（EventObject子类、但是ServerNotificationListener并未继承EventListener）的，该类具备的方法：
getAction() which returns the action code for the current notification.? Action codes are unique codes that refer to each type of notification.getActionName() is a little more helpful as it returns a string name for the current action code.getPayloadToString() will return a string representation of the item that caused the notification in the first place.? If you’re listening for message notifications, this would return the entire MuleMessage payload as a string; if you’re listening for service notifications, this would be the service id. There is a full list of the payloads for each notification type on the MuleSource Wiki.getServerId() returns the id for the current Mule Manager.getTimeStamp() returns the time-stamp for this notification in milliseconds.getType() will indicate whether this was an informational notification, a warning, an error or a fatal error. (This is similar to the category used for Log4j)? 备个忘：http://www.ricston.com/portal/web/guest/what-we-do，帮你选择实施开源产品和技术的咨询组织Ricston，客户遍及最终用户、系统集成商、产品厂商、培训机构、政府、教育。Ricston并不关注特定市场领域的开源应用，Ricston提供高级领域知识，这些知识涉及特定解决方案（主要在五大开源领域：android移动开发、intalio BPM、垃圾liferay、mule ESB、不知道是神马的OpenIAM）的技术。Ricston可以提供顾问咨询、培训和项目服务，人员可以到现场或远程支持。总之Ricston除了关注移动热点主要关注企业集成领域。
