偶看新闻iknewyouweretrouble:SOA--ESB的消息交换模式（MEP）
来源：百度文库 编辑：偶看新闻 时间：2024/04/29 20:36:41
服务的工作方式是在服务供应者和消费者之间发送消息。在不同通信层上存着许多消息交换模式（MEP Message Exchange Patterns），其中一个模式带来了事件以及事件驱动的架构。（EDA）
基本MEP
这也许是对于SOA来说，最重要的模式了。这种模式下，消费者向供应者发出一个请求消息，等待供应者发出应答消息。
如果供应者不可用，或者出现错误，消费者可能无法得到答案，结果永远停留在阻塞状态。这可以引入定时器，如果在给定时间内没有应答，则开始某种异常处理。
单程
如果需要应答才能继续工作，那么可能就需要请求/应答模式；如果需要应答，但是可以在没有应答的情况下继续工作，那么可以把应答消息想象成另一个服务请求，该请求将回头来针对发起第一个请求的系统，也就是使用两个单程消息。
单程消息的最大优点是没有哪个过程被阻塞。也就是说，消费者和供应者没有必要同时可用。更进一步的，你可以在基础设施（ESB）中插入消息队列，这样一来，消息一旦被持久化，不会丢失。这也是诸如MQ和JMS这些“面向消息的中间件”（MOM）的核心所在。
更复杂的EMP
请求/回调
通常，一个进程/线程需要某些数据或对某些操作的确认，但是，不一定非得在应答到来前阻塞该进程/线程。这种模式可以叫非阻塞请求/应答/异步请求/应答。或者请求/回调。
他复杂的地方在于：
l 如果发送了多个请求/毁掉消息，那么应答的顺序可能不同，必须把应答和当初请求相匹配。通常，靠引入关联ID来做到这点。关联ID和请求一个发送，并和请求一起发送回来。
l 必须保证每个应答的上下文环境仍然有效，仍然包含了素有要用来处理应答的消息。
他的优点在于：
引入了一种形式的松耦合，请求被发送时，服务供应者不必处于可用状态，并且，在等待应答时，消费者可以继续工作。
发布/订阅
不同的MEP层
消息交换模式永远都依赖于传输层或消息所使用协议的特性。看下面的例子，即使传输层不可靠，仍然可以提供一个有可靠接口的API。
上图中，请求消息丢了，然后应答丢了，最后才成功。这是支持同步请求/应答MEP的API，然而，最底层协议是一系列请求/回调MEP。注意，协议本身也可以使用其他MEP，如单程消息来处理内部通信。
从SOA角度看，如果ESB是协议驱动的，则消费者可能需要复杂重试这些东西，如果ESB是API驱动的，那么基础设施团队就应该负责为不同的MEP提供API。后一种情况，可能还需要指定重复次数，两次重试之间的超长时间等等。
