ARC34消息传递-面向消息的中间件设计基础-Microsoft.ppt

ARC314消息传递 -面向消息的中间件设计基础 日程 应用集成技术的发展与回顾 消息传递基础 面向消息的集成中间件设计实践 展望Indigo与未来的集成 应用集成中间件设计的目标 应用程序之间需要互相“交谈” 不违反“Once and Only Once”规则 在计算的过程中需要集中处理以确保正确性 在计算的过程中需要分布处理以确保可缩放性 总之机器与机器需要进行“交谈” 传统建议我们使用RPC来解决这一问题 “让远程通信和本地调用一样容易 定义一个接口 编写服务器端实现 工具生成两者之间需要的通信管道 RPC 编程模型 RPC存在的问题 RPC方法忽略了: 延迟 (网络、应用程序) 部分失败和并发 … RPC存在的问题 RPC让通信更容易，但代价是: 请求/响应通信 针对每一个请求，我们期望一个响应 阻塞调用者线程直到接收到响应（或者响应超时） 代理和Stub强绑定 强绑定和类型一致使得编程容易 但强绑定和类型一致使得变化非常困难 RPC暴露行为 解决方案: 消息传递 系统间通过管道通信 管道有逻辑地址 发送应用程序将消息放到管道中，然后处理其它工作(“fire-and-forget”) 管道将数据排队直到被接收应用程序使用（FIFO） 解决方案: 消息传递 RPC的本质 RPC == 请求消息 + 响应消息 把消息分开，独立处理 允许不同的消息交换模式 消息传递暴露数据 替代基于接口来创建约束 (RPC)… 基于消息类型来创建约定 (messaging) 上下文完整的通信 面向消息的中间件Message-Oriented Middleware (MOM) 消息 = 消息头 (路由信息) + 消息正文 支持异步发送 不指定格式(松散约束) 目的地 = 命名的消息存储仓库 解耦合消息的产生者与消费者 便于重定向或者改变调用流程 运行环境 = 多样化的发送方式 服务质量: Reliable, transacted, prioritized, deadline-based 通信方式: publish-and-subscribe等. 消息交换模式 Request-response, fire-and-forget, request-async response 消息传递架构模式 消息传递是一种架构模式，而不是一种技术 我们可以使用一个数据库来实现消息传递，但使用数据库不地表我们使用的是消息传递 与SOA/Web Services的争论对比: 我们可以不使用Web Services来构建SOA 使用Web Services并不能保证是SOA 架构模式由一组词汇、结构和设计约束组成 消息传递系统举例 文件传输 消息: 文件 目的地: 文件系统目录 运行环境: 操作系统的文件系统 数据库 消息: 数据集 目的地: 数据库表 运行环境: 数据库 JMS/MSMQ 消息: byte, text, object, stream … 目的地: 队列 (point-to-point), 主题 (publish-subscribe) 运行环境: MOM环境支持 SOAP 消息: SOAP XML format 目的地: (取决于传送方式) 运行环境: WebLogic, WS-Reliable Messaging 为什么要使用消息传递 灵活性 可缩放性 高负载的平缓释放 集成性 为什么要使用消息传递?灵活性 更多的数据流选择 Fire-and-forget, multicast, disconnected, load-balancing, flow control, priority routing等. 多粒度的处理逻辑 Routing Slip Content-Based Router 更容易维护和变化 消息格式的变化不需要重新编译不相关的客户端 消息流的传递不需要修改中间结点 避免并发死锁 (和RPC响应阻塞相比) 为什么要使用消息传递?可缩放性 竞争消费 – 多个处理端可以读取同一队列 发送端不需要进行任何改变 粗粒度消息可以使处理端成为“无状态” 为什么要使用消息传递?高负载的平缓释放 队列中存储的消息将会等待被处理 消息处理端或消费者会经可能快的取走消息 如果处理端阶段无法继续: 我们可以增加更多的处理端 或者等待峰值负载被释放 为什么要使用消息传递?集成性 消息传递不需要一致的类型系统 消息就是类型 消息传递可以连接多个系统(.NET,J2EE,etc.) XML消息非常适合此类场景 其它数据表现形式也可用 (CSV,文本) 消息传递的灵活性使得集成更容易 消息传递面临的挑战 使用队列来通信，而不是对象 双向通信需要至少2个队列：一个用于请求消息，另一个用于响应 不存在会话状态 时序 – 消息的到达可能是无序的