供稿人：邓练成
内容提要：
1) 简述end to end automation domain各个部件之间的通讯机制
2) 详细描述在各种典型的场景下的通讯流程
1 简述end to end automation domain各个部件之间的通讯机制
随着end to end automation的引入，涉及到的功能部件也增加了不少，它们之间的通讯机制是怎样的呢？当first-level automation domain中的资源状态发生变化时，将通过Tivoli Event Integration Facility (简称EIF)来通知和传递给end to end automation manager。考虑到跨越服务器之间的通讯的安全性，end to end Automation manager 和 first-level automation domain 之间采用了SSH协议进行通讯。如下图1-7所示。
2 详细描述在各种典型的场景下的通讯流程
2.1 当新的end to end automation policy被激活时
如上图所示的通讯流程所示：
1) 操作员从policy pool的目录中选中将要激活的end to end automation policy。
2) 该policy的名字连同激活的请求首先转发到automation J2EE framework中。
3) 然后转发到automation engine resource adapter。
4) 该请求通过automation engine resource adapter 最终送达automation engine。
5) automation engine执行该请求，装载该policy。
6) automation engine首先会解析用XML编写的policy，然后建立起所有的资源、资源组以及它们之间的相互依赖关系。这时候，automation engine还没有任何关于policy中定义的reference资源的当前状态信息，甚至连拥有这些资源的first-level automation domain目前是否处于活动状态都不清楚。因此，当前automation engine必须要做的事情就是向automation J2EE framework登记它所关注的first-level automation domain。以便能及时获取到这些first-level automation domain的状态信息。
7) automation J2EE framework将当前正在处于活动的first-level automation domain的清单反馈回 automation engine。从这时起，当first-level automation domain 有任何状态信息发生变化时，automation engine都会收到通知。
8) 接着，automation engine对当前正在处于活动状态的first-level automation domain管辖下的资源进行登记。因为automation engine必须随时掌握它们的信息，用以计算出当前reference资源的状态和由此产生的连锁反应。
9) 该登记请求首先被转发到first-level automation manager resource adapter。
10) 然后送达first-level automation domain。从这时起，如果automation engine所登记的资源在first-level automation domain 中的状态发生变化时，automation engine将会得到及时的通知。至此，主要的初始化工作已经就绪。
2.2 当first-level automation domain 的资源状态发生变化时
如上图所示的通讯流程所示：
1) 当first-level automation domain的资源的状态发生改变时（如果该资源恰恰也在end to end automation policy中被引用，即end to end automation engine所关注的资源），将会产生一个state change 的事件发送到automation J2EE framework。
2) 而automation J2EE framework中记录着所有当first-level automation domain的资源发生变化时必须通知到的对象清单。在我们这个场景中有两个对象已经登记过。其中之一是end to end automation engine；另外一个是守候在operation console前监控该资源的操作员。
3) end to end automation engine 和 operation console的操作员都会收到从automation J2EE framework转发的事件。
4) end to end automation engine依据收到的关于该资源状态的变化，计算出和该资源相关的资源和资源组的reference资源的状态。并由此引伸出对新的reference资源状态的连锁请求，最终产生相应的和first-level automation domain 相关的新的自动化请求。
5) 每个新产生的自动化请求都会转发到automation J2EE framework，然后由framework将相应的自动化请求分发到相应的管辖该资源的first-level automation domain中。
6) 该请求首先会经过first-level automation manager resource adapter。
7) 该请求最终会送达first-level automation domain并在其内部完成请求的评估和决策，完成相应的行动。
2.3 当操作员发出对reference资源的操作请求
如上图所示的通讯流程所示：
1) 操作员在operation console对reference资源发出操作的请求。
2) 该请求被转发到automation J2EE framework。
3) 然后转发到automation engine resource adapter
4) 最终送达automation engine。
5) automation engine根据end to end automation policy中定义的所涉及到的相关资源的关系，由该操作员的请求推算出，由此引发的若干个面向first-level automation domain 的自动化请求。
6) 所有推算出的新的面向first-level automation domain 的自动化请求都会首先转发到automation J2EE framework。
7) 然后转发到first-level automation manager resource adapter。
8) 最终分发到相应的first-level automation domain。First-level automation manager将会处理相应的自动化请求，根据first-level automation policy 中定义的各个资源之间的关系来开启或关闭资源的活动状态。
