ARC314消息传递-面向消息的中间件设计基础.pptx

ARC314消息传递 -面向消息的中间件设计基础微软的中间件回归自然–MSMQMicrosoftMessageQueue日程应用集成技术的发展与回顾消息传递基础面向消息的集成中间件设计实践展望Indigo与未来的集成应用集成技术的发展与回顾RPC与应用集成应用集成中间件设计的目标应用程序之间需要互相“交谈”不违反“OnceandOnlyOnce”规则在计算的过程中需要集中处理以确保正确性在计算的过程中需要分布处理以确保可缩放性总之机器与机器需要进行“交谈”传统建议我们使用RPC来解决这一问题“让远程通信和本地调用一样容易"定义一个接口编写服务器端实现工具生成两者之间需要的通信管道RPC编程模型接口publiclongadd(longl1,longl2);实现编译器客户端publiclongadd(longl1,longl2){returnl1+l2;}longI=add(5,10);请求消息Method:addParams:5(long),10(long)methodmethodstubskeletonReturn:15(long)响应消息RPC存在的问题RPC方法忽略了:延迟(网络、应用程序)部分失败和并发…“Objectsthatinteractinadistributedsystemneedtobedealtwithinwaysthatareintrinsicallydifferentfromobjectsthatinteractinasingleaddressspace.”Waldoetal,1994“95%transparentisnotgoodenough.Infact,itisworsebecauseitdeceivesdevelopers.”WernerVogelsRPC存在的问题RPC让通信更容易，但代价是:请求/响应通信针对每一个请求，我们期望一个响应阻塞调用者线程直到接收到响应（或者响应超时）代理和Stub强绑定强绑定和类型一致使得编程容易但强绑定和类型一致使得变化非常困难RPC暴露行为解决方案:消息传递系统ASystemBChannel(Queue)Message系统间通过管道通信管道有逻辑地址发送应用程序将消息放到管道中，然后处理其它工作(“fire-and-forget”)管道将数据排队直到被接收应用程序使用（FIFO）解决方案:消息传递RPC的本质RPC==请求消息+响应消息把消息分开，独立处理允许不同的消息交换模式消息传递暴露数据替代基于接口来创建约束(RPC)…基于消息类型来创建约定(messaging)上下文完整的通信ABSendRcvRcvSend是RPC还是2条消息?面向消息的中间件Message-OrientedMiddleware(MOM)消息=消息头(路由信息)+消息正文支持异步发送不指定格式(松散约束)目的地=命名的消息存储仓库解耦合消息的产生者与消费者便于重定向或者改变调用流程运行环境=多样化的发送方式服务质量:Reliable,transacted,prioritized,deadline-based通信方式:publish-and-subscribe等.消息交换模式Request-response,fire-and-forget,request-asyncresponse消息传递架构模式消息传递是一种架构模式，而不是一种技术我们可以使用一个数据库来实现消息传递，但使用数据库不地表我们使用的是消息传递与SOA/WebServices的争论对比:我们可以不使用WebServices来构建SOA使用WebServices并不能保证是SOA架构模式由一组词汇、结构和设计约束组成消息传递系统举例文件传输消息:文件目的地:文件系统目录运行环境:操作系统的文件系统数据库消息:数据集目的地:数据库表运行环境:数据库JMS/MSMQ消息:byte,text,object,stream…目的地:队列(point-to-point),主题(publish-subscribe)运行环境:MOM环境支持SOAP消息:SOAPXMLformat目的地:(取决于传送方式)运行环境:WebLogic,WS-ReliableMessaging为什么要使用消息传递灵活性可缩放性高负载的平缓释放集成性为什么要使用消息传递?灵活性更多的数据流选择Fire-and-forget,multicast,disconnected,load-balancing,fl