WSO2 ESB是一个快速、轻量级、100%开源的ESB,基于Apache Synapse和Apache Axis2项目构建。支持协议转换、消息路由、服务编排、服务注册、容错、负载均衡、集群配置等功能。
WSO2 ESB是基于WSO2的Carbon平台的(OSGi框架),包含许多功能和组件,可通过简单的添加删除来定制化ESB。
从消息处理角度介绍ESB架构,pipe组件的顺序不是固定的。
(1)一个应用发送消息到ESB。
(2)消息被transport接收。
(3)Transport通过消息管道发送消息,消息管道进行一些服务质量的处理,如安全、可靠消息传输等。两种实现方式:(1)Mediating Messages(一个单独的 pipe)。(2)Proxy Services(把pipes分到不同的代理服务)。
(4)消息转换和路由都可以被认为是一个独立的单元。WSO2 ESB称这个为中介框架。有些转换发生在路由之前,有些发生在路由之后。这部分由Synapse实现。
(5)然后消息根据目的地注入到相应的管道,再次进行服务质量的确定。
(6)Transport层负责ESB所需的传输协议的转换。
这个图显示了一个请求如何通过ESB传输到实际的端点,响应处理是相反的过程。有其他的一些模块像 tasks和events没有显示在图中,所有这些组件通过WSO2 ESB 控制台进行管理和监控。
从构件组成角度介绍ESB架构。
WSO2 ESB 支持所有广泛使用的传输协议,如HTTP, HTTPS, POP, IMAP, SMTP, JMS, AMQP, FIX, TCP, UDP, FTP, FTPS, SFTP, CIFS, MLLP, SMS. Transport负责传输指定格式的消息。一个新的传输协议使用Axis2传输框架可以轻松地被添加和插入到ESB中。
Transport包含两个组件:
(1)Message builders:根据内容类型识别消息并转化为XML格式。每一种内容类型都有相应的Message builders。WSO2 ESB包含基于文本的Message builders和基于二进制的Message builders(A->XML、B->XML……)。
(2)Message formatters:与Message builders相反。把XML格式的消息转化为传到Transport前消息的格式(XML->A、XML->B……)。
可以使用axis2框架实现新的Message builders、Message formatters。
参阅协议转换(Working with Transports)
Endpoints代表一个后台服务,我们需要为ESB调用的每一个后台服务定义一个endpoint。Endpoint可以被指定为address endpoint,WSDL endpoint,load balancing endpoint。Endpoint是独立于传输协议的。同一个endpoint可以使用多种协议。当你配置sequence或者proxy service处理incoming消息时,需要指定所用的transport和消息送达的endpoint。
参阅端点(Working with Endpoints)
format="soap11"/>
|
注:format - endpoint的message format ,可用的值有:
[format="soap11|soap12|pox|get"]
· Leave As-Is - 消息不转换.
· SOAP 1.1 - 转换消息为SOAP 1.1.
· SOAP 1.2 - 转换消息为SOAP 1.2.
· Plain Old XML (POX) - 转换消息为plain old XML format
· Representational State Transfer (REST) - Transforming to HTTP Get Request
· GET
代理服务是ESB上的虚拟服务,可以实现多个实际服务的无缝集成。收到消息在被送达给定endpoint前可有选择的进行处理,不改变现有的服务而对服务进行必要的转换或增加其他额外的功能。代理服务接收和发送消息可以使用任何传输协议。
顾名思义,代理服务充当了WSO2 ESB服务的代理,通常是一个已经存在的服务端点,代理服务可以使用不同的传输方式。 默认情况下,代理服务使用HTTP和HTTPS传输。在ESB的启动过程中,它会启动所有代理服务,并需要获取代理服务关联的WSDL。如果ESB可以在statup这些找不到的WSDL,它会忽略这样的服务,并继续启动。
代理服务是一个虚拟的服务,实际功能由外部的已存在的服务提供。 跟真实的服务一样,代理服务也需要用一个wsdl文件来描述自己的服务内容;这个wsdl文件可以是针对当前代理服务专门编写的,也可以将外部的一个真实服务的wsdl文件作为自己wsdl。
1)Proxy Service中的消息流
· 一个代理服务有两个主要的消息流:InSequence 和OutSequence。
· InSequence:代表的是消息进入ESB发送到endpoint前对流程进行编排的阶段。当客户端发送消息到Proxy Service,消息首先进入InSequence,所以在InSequence可以处理接收的消息并通过“send”mediator发送到后台服务(endpoint)。
· OutSequence:endpoint响应了消息,发回到ESB,ESB返回给客户端,这段流程编排默认通过outSequence实现。
· 如果出现错误,false sequence将被调用。
2)Receiving Sequence
· 上述部分我们理解了代理服务的基本消息流程,WSO2 ESB 4.x 版本以后引入了“receiving Sequence”的概念,用户可以指定一个外部请求从ESB进行处理得到响应的序列,也就是说用户可以指定接收请求的队列,而不是去默认的队列outsequence处理。通过“send”mediator指定receiving sequence
WSO2 ESB中进行消息处理的基本组件,ESB中所有的消息流都是由一系列mediatos组成的。一个mediator包含一个输入消息、一个输出消息还有其他一些配置。根据配置进行输入消息的转换、替换等操作形成输出消息。
WSO2 ESB包含一系列的mediators提供不同的能力处理消息,提供一套完整的mediator库实现不同功能。自己也可以使用Java,scripting和Spring等各种技术实现额外的功能。
参阅mediator
Sequence由一系列mediators组成。分配到sequence的消息按顺序流经每一个mediator并进行相应的改变。参阅Sequences。
Qos组件提供可靠消息传递及安全性。
WSO2 ESB提供了一个内置的Registry存储各种配置和组件,像sequence和endpoint、services、wsdls、配置文件等都可以存储在registry中,通过一个key引用(类似UNIX文件的路径)。
两种方式可以访问registry,多数情况下直接从Carbon组件调用registry API,特殊情况下允许Apache Synapse配置访问。因此,ESB配置包含如下registry定义:
|
当消息通过ESB,如果消息有对registry 资源的引用,ESB从registry获取信息并缓存为后续调用。缓存改善了消息处理的性能,但registry资源发生变化,缓存数据使用时不会得到反映。cachableDuration参数控制缓存数据的生命周期,过期后ESB将重新将数据放入registry。cachableDuration增大可以改善消息处理的速度,减少可以确保registry的资源及时更新。
基于Carbon的WSO2产品都有如下选项配置注册表空间:
(1)使用产品默认的空间;
(2)使用远程注册表示例,多个wso2产品共享注册表。配置参考Sharing Registry Space Among Multiple Products.
Carbon为每个产品提供的注册表空间包含三个主要部分:
(1)Local repository:存储本地配置和运行时数据,不允许多个服务器共享。可以在/_system/local 目录下浏览。
(2)Configuration repository:存储指定产品配置和数据。允许相同产品的多个实例共享,如一个ESB集群共享ESB配置。可以在 /_system/config 目录下浏览。
(3)Governance repository:存储整个平台可共享的配置和数据。.包括service、service description、endpoint、datasources等,可以再 /_system/governance目录下浏览。
注意:集成WSO2 ESB和一个新的注册表,必须实现org.apache.synapse.registry.Registry接口。
注册表具体使用参见Managing the Registry. 和Storing Various WSO2 Enterprise Service Bus Configurations.