步步为营---- MuleEsb学习(一) 扫盲篇
本篇文章是基于不断的接触GXPT之后,对其技术开始不断的积累学习^^^,有很多问题带给我了思考,对于如何的处理各个部分的流程?这个如何处理?太多的问题促使着我一步一步的学习,在师哥们的指导下,逐步的清晰,现在武装补充知识能量.
什么是SOA?
SOA:面向服务的体系结构是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。
什么是ESB?
企业服务总线（Enterprise Service Bus，ESB）的概念是从面向服务体系架构(Service Oriented Architecture， SOA)发展而来的。SOA描述了一种IT基础设施的应用集成模型；其中的软构件集是以一种定义清晰的层次化结构相互耦合。一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。
在企业计算领域，企业服务总线是指由中间件基础设施产品技术实现的、 通过事件驱动和基于XML消息引擎，为更复杂的面向服务的架构提供的软件架构的构造物。企业服务总线通常在企业消息系统上提供一个抽象层，使得集成架构师能够不用编码而是利用消息的价值完成集成工作。
企业服务总线提供可靠消息传输，服务接入，协议转换，数据格式转换，基于内容的路由等功能，屏蔽了服务的物理位置，协议和数据格式.
ESB在SOA中扮演着重要的角色
在技术层解决了SOA的整合问题，耦合了应用与应用之间的集成逻辑，使得SOA更灵活，更易于扩展，更敏捷。有了ESB，新建的服务消费者应用程序不需要关心服务的提供者在哪里，使用何种通讯协议，与其交互的数据是怎样的……，它只需向ESB发出请求，使用开放的、标准的通讯协议。
结合到GXPT上来,可以简单的理解为,现有这么系统间的服务的交互\通信\数据的传递等等,都是需要来整合的,一开始来说在一定程度上解耦合,是不同系统之间通过WebService来各自发布自己的服务,其他需要的再调用即可,但是如果服务过多(颗粒多的话),这种A直接依赖B的这种形式,就显得很臃肿了,交互太多,维护管理起来代价它的,
各个应用系统之间的调用形成了一张网，没有逻辑，随着业务的增加，维护简直就是一场恶梦。
想要处理这样的关系,学习过设计模式,很容易联系到外观模式的作用,如果有一个可以整合系统间的这样的多线路的调用的就太好了,通过外观代理的方式,来处理,下图示:
各个应用的逻辑很清晰，每个应用都只需要关心如何暴露自己的服务，而调用的应用只需要知道如何调用服务，至于怎么做，去找谁，则完全交给ESB来完成。
所有的ESB产品都应该可以构建和部署服务。包括对遗留系统的整理、消息的路由、消息格式的转换、执行协议的调解等。
首先我们要看ESB是否具有以下特性：
- 互通性
- 抽象化
- 资源位置的虚拟化
- 扩展能力和管理服务
- 是否具有平台无关性，即跨平台
- 松耦合
上面列出的往往很评估，但是ESB本身具有的特性往往更容易识别和评估。
ESB所必须具备的功能：
- 路由
- 协议桥接
- 消息转换
- 服务代理托管
扩展的功能有：
- 资源适配器
- 可靠的消息传递
- 事件处理
- 交易的完整性管理
- 消息格式调解
- 负载均衡
- 消息验证
- 能力调解
等。
个人理解:ESB的原理和现在机房的大的交换机有着同工异曲之妙
实战练手
这个.MFLOW文件存储流信息供可视化编辑器编辑。当你的新项目第一次打开，Mule Studio会自动打开.MFLOW文件，将显示一个空白的画布。
主版面
在元素板上，每个类别中的构建块按字母顺序排列。为避免滚动，使用选项板的右上角的过滤器工具可以更快速地找到你想要构建块。
2:双击HTTP,弹出一下,设置其属性如下
3:设置Logger属性
4:设置Set Payload属性
当然 world可以修改成你自己任意想输入的信息,后通过ESB拦截,打出相应的信息
总结
推荐播客连接地址<贾琳师哥>
原文英文官网地址: