本篇文章是基于不断的接触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的这样的形式,就显得非常臃肿了,交互太多,维护管理起来代价它的,
各个应用系统之间的调用形成了一张网，没有逻辑，随着业务的添加，维护简直就是一场恶梦。
想要处理这种关系,学习过设计模式,非常easy联系到外观模式的作用,假设有一个能够整合系统间的这种多线路的调用的就太好了,通过外观代理的方式,来处理,下图示:
各个应用的逻辑非常清晰，每一个应用都仅仅须要关心怎样暴露自己的服务，而调用的应用仅仅须要知道怎样调用服务，至于怎么做，去找谁，则全然交给ESB来完毕。
全部的ESB产品都应该能够构建和部署服务。包含对遗留系统的整理、消息的路由、消息格式的转换、运行协议的调解等。
首先我们要看ESB是否具有下面特性：
- 互通性
- 抽象化
- 资源位置的虚拟化
- 扩展能力和管理服务
- 是否具有平台无关性，即跨平台
- 松耦合
上面列出的往往非常评估，可是ESB本身具有的特性往往更easy识别和评估。
ESB所必须具备的功能：
- 路由
- 协议桥接
- 消息转换
- 服务代理托管
扩展的功能有：
- 资源适配器
- 可靠的消息传递
- 事件处理
- 交易的完整性管理
- 消息格式调解
- 负载均衡
- 消息验证
- 能力调解
等。
个人理解:ESB的原理和如今机房的大的交换机有着同工异曲之妙
实战练手
这个.MFLOW文件存储流信息供可视化编辑器编辑。当你的新项目第一次打开，Mule Studio会自己主动打开.MFLOW文件。将显示一个空白的画布。
主版面
在元素板上。每一个类别中的构建块按字母顺序排列。为避免滚动。使用选项板的右上角的过滤器工具能够更高速地找到你想要构建块。
2:双击HTTP,弹出一下,设置其属性例如以下
3:设置Logger属性
4:设置Set Payload属性
当然 world能够改动成你自己随意想输入的信息,后通过ESB拦截,打出对应的信息
总结