- 浏览: 296393 次
- 性别:
- 来自: 深圳
文章分类
- 全部博客 (133)
- boss好文 (10)
- 数据模型 (2)
- together (1)
- oracle (10)
- 健康生活 (4)
- js好东东 (8)
- 工作流 (1)
- 常见java问题 (7)
- BOSS开发随想 (0)
- rose相关 (1)
- 股市看图 (4)
- java基础 (12)
- jbpm (1)
- 集群(负载均衡) (4)
- spring教程 (2)
- maven入门 (5)
- 项目管理 (14)
- 常用软件 (3)
- mysql (4)
- j2ee性能调优 (2)
- jfreechart相关 (1)
- 需求工具 (2)
- maven基础讲解 (3)
- AXURE下载 (2)
- db2 (2)
- svn (1)
- 日常操作技巧 (3)
- SOA (16)
- jetty (2)
- jetspeed (0)
- camel (0)
- 安卓开发 (4)
- ESB (4)
- 物流 (2)
- 软件需求的3个层次 (1)
- WMS (1)
- eclipse (1)
- 安卓源代码 (2)
- jar (0)
最新评论
-
seeYourEye:
prt1979 写道怎么在点“open project”后,选 ...
PL/SQL Developer插件之SVN -
prt1979:
怎么在点“open project”后,选择文件夹后一直弹出“ ...
PL/SQL Developer插件之SVN -
houlianxue:
LateCHI 写道东西不错。可以正常打开目录。但是进行svn ...
PL/SQL Developer插件之SVN -
LateCHI:
东西不错。可以正常打开目录。但是进行svn操作的时候提示 un ...
PL/SQL Developer插件之SVN -
w.tany:
很多地方少个# 号
<s:property>的用法
摘自:http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0905_loulj_esb2/index.html
前言
我们知道企业 ESB 实施的模式大致分为 Global ESB、ESB Gateway、Federated ESB、Brokered ESB 等若干种,IBM 的 ESB 产品主要包括 WebSphere Message Broker、WebSpehere ESB、WebSphere DataPower 三种,并且在特定的用户需求下,我们需要将这三种产品组合使用,在本系列文章的第 2 部分,我们再为大家介绍一个制造业企业使用 WebSphere DataPower 和 WebSphere Message Broker 作为企业级联邦 ESB 平台的案例和技术实现。
--------------------------------------------------------------------------------
回页首
客户背景介绍
图 1. 系统交互图
图 1 给出了某制造行业客户现有各个系统间的系统交互图 (System Context Diagram),通过系统交互图,我们可以清晰地了解到 ESB 平台和周边涉及到的系统之间交互的通信协议类型以及数据接口格式。从上图 1 中我们可以看出,其合作伙伴以多种方式调用该企业内部的后台服务,包括标准的 SOAP/HTTP 方式、XML/MQ 的方式、EDI/MQ 的方式甚至 FTP 的方式等;该企业内部的一个主要核心业务系统运行在 IBM 大型主机上,对外的接口方式采用 WebSphere MQ,数据格式采用传统的 COBOL CopyBook 的方式,除了该主机系统之外,该企业的其他一些内部应用会以 SOAP/HTTP 和 XML/MQ 的方式与外界交互。
--------------------------------------------------------------------------------
回页首
DataPower/Message Broker 联邦 ESB 解决方案
针对该客户需求,我们给出的 DataPower 和 Message Broker 联邦 ESB 解决方案架构如下图 2 所示:
图 2. 联邦 ESB 解决方案
在这个解决方案中,我们使用的 IBM 产品主要包括 Data Power XI50 和 WebSphere Message Broker V6.0.2,DB2 V9 以及 WebSphere Application Server V6.1。其中,WebSphere DataPower XI50 是一个实现 ESB 的硬件解决方案,它的主要功能包括:
XML 高速转换引擎;
基于消息内容的路由;
协议桥接 : HTTP, MQ, JMS, FTP 等;
XML/SOAP 防火墙:过滤任何内容、元数据和网络数据;
数据验证:对进出的 XML 和 SOAP 进行数据验证;
保护数据域级别安全:对不同的数据域可以进行 WS-Security, 加密和签名;
访问控制:验证、授权和审计 (AAA),支持 SAML, LDAP, RADIUS 等;
Web Services 管理:中心服务级别管理、服务虚拟化和策略管理等。
该客户的联邦 ESB 解决方案由下列组件构成:
Gateway DataPower:
在 DataPower 和 Message Broker 组合 ESB( 以下简称 DP/MB 组合 ESB) 方案中,常见的产品分工定位方法是:由 DataPower 作为企业对外的 ESB 入口,即担任 B2B 网关的角色,侧重提供其它企业的接入服务以及安全控制方面的工作;而采用 Message Broker 作为企业内部的 ESB 总线,实现企业内部各种应用系统,包括传统应用系统之间的集成平台。
在我们给出的这个实际案例中,采用了两台 DataPower,其中 Gateway DataPower 主要负责外围的接入,接入的通信协议包括 MQ,HTTP(S),JMS,FTP 四种。Gateway DataPower 位于网络架构中的 DMZ 区,它负责 XML threat protection,信息属性传递 ( 例如 IP 地址的传递 ) 和 SSL 传输层安全控制。
ESB DataPower:
这台设备位于网络架构中的受信区,对输入的消息进行更进一步的处理,其中包括:
1. 校验 Inbound/Outbound XML 类型消息的 Schema;
2. 实现非 MQ 通信协议和 MQ 通信协议之间的转换,在我们的设计中,我们在 ESB DataPower 和 ESB WMB 之间采用 MQ 的通讯协议,因此在 ESB DataPower 上我们要将所有的协议转换为 MQ;
3. 信息头的处理:在此我们将创建我们为应用设定的消息头并且插入到接收到的数据包头或 SOAP 头中。
4. 认证 / 授权:通过 LDAP 进行发送者的认证和授权;
5. 日志:为了审计目的,通过日志服务 (Logging Service) 组件对输入信息进行日志处理。
ESB Message Broker:
由于我们的后台核心系统是位于 IBM 大型主机上的应用系统,需要的数据格式是 COBOL Copybook 的格式,因此在 Message Broker 上我们将实现 XML 到 Copybook 的转换。在 Message Broker 上,我们设计了 3 种典型的 Message Flow,
1. OnBoard Flow: 通过查询数据库设置消息的环境树 (Environment Tree),把输入消息转换为标准的 XML 格式;
2. Main Application Flow:用于应用逻辑处理;
3. OffBoard Flow: 依据消息的 Environment Tree,将消息路由到特定的 Service Endpoint(服务端点),并且将数据转换为后台系统需要的格式。
Application Server 组件:
该组件接收和响应 Web Services 请求,并且 Logging 组件也运行在该组件上。
后台主机系统:
负责后台的业务逻辑处理。
LDAP 组件:
存储认证/授权相关的信息。
Routing Database(路由表):
路由表中存储了服务路由信息、服务版本信息等,其中包含了特定于应用程序的配置信息,通过 Java API 对其进行访问来决定服务的路由和绑定。
Event Database/ Event Logger(事件数据库/事件日志处理器):
Event Database(事件数据库)中存储了各种日志和错误信息,Event Logger(事件日志处理器)是一个 Java 应用,用于将各种日志和错误信息存储到事件数据库中。
--------------------------------------------------------------------------------
回页首
DataPower/Message Broker 联邦 ESB 的关键服务组件设计
下面我们来介绍在这个 DP/MB 联邦 ESB 方案中的关键服务组件设计。如下图 3 是 ESB 服务组件图:
图 3. 联邦 ESB 服务组件图
从服务的角度,联邦 ESB 主要由以下服务组件构成:
1. Gateway Services(网关服务)
2. Schema Validation Services(模式校验服务)
3. Security Services(安全服务)
4. Routing Services(路由服务)
5. Transformation Services(转换服务)
6. Logging, Error Handling and Notification Services(日志服务)
下面我们分别介绍这些服务的设计和实现方式。
Gateway Services(网关服务)
这个组件的所有功能都是通过对 DataPower 的配置实现的。它是 Internet 和 Intranet 之间的一个网关,从 ESB 的角度,它就像第一道防火墙,起到对企业外部服务调用的安全控制和协议转换的作用。同时,它根据来源数据的格式,例如 SOAP,XML,文本或 CopyBook 等,进行粗粒度的路由。
Schema Validation Services(模式校验服务)
这个组件的所有功能也都是通过对 DataPower 的配置实现的,开发者可以在部署时,在 DataPower 设备上配置有关的 Schema,对 XML Schema 的高速校验是 DataPower 的一个非常重要的功能。需要注意的是,在我们的案例中,我们的联邦 ESB 除了 XML 格式之外,还必须支持 Copybook 的主机格式,这是 DataPower 不擅长的,对这种格式的解析,我们将交给后面的 Message Broker 来实现,这正是体现了在这个联邦 ESB 解决方案中 DataPower 与 Message Broker 的各自定位以及无缝配合。图 4 描述了模式校验服务的序列图:
图 4. 模式校验服务序列图
模式验证服务主要由 ESB DataPower 实现,它负责对 SOAP/XML 消息模式的校验,如果失败,则调用日志服务进行错误处理。
1. 服务请求者通过 HTTPS 经由 Gateway DataPower 向 ESB DataPower 发送 SOAP/XML 消息;
2. ESB DataPower 对该消息进行校验;
3. 如果校验失败,Logging Service(日志服务)组件将向数据库写入日志信息,向服务请求者返回“Schema Validation Error”;
4. 如果校验成功,将继续安全校验等其它操作。
Security Services(安全服务)
安全服务将负责认证、授权和审计 (3A)。所有这些功能也都是通过对 DataPower 的配置实现的,在该方案中,我们采用 SSL 作为传输级安全控制,对于 MQ 的消息我们使用 MQRFH2 消息头来实现消息级安全控制,对于 SOAP 消息我们采用 WS-Security 标准来进行安全控制,如图 5 所示。
图 5. SOAP/XML 消息认证授权序列图
本序列图描述了对输入消息的认证授权处理,其步骤如下:
1. 服务请求者经由 Gateway DataPower 向 ESB DataPower 发送 SOAP 或 XML 消息,消息中包含了 WS-Security 头信息,其中包括 Username Token and Password;
2. ESB DataPower 接收到消息,它调用 LDAP API 对从 SOAP 消息头或者 MQ 消息头中取得的发送者凭证进行认证;
3. 如果认证失败,日志服务组件将记录失败的日志信息;
4. 如果认证成功,ESB DataPower 将通过访问 LDAP 进行粗粒度的授权,决定发送者是否有权限进行服务调用;如果失败,也记录日志信息;
5. 如果认证 / 授权都成功,则消息将被发送到 Message Broker 上进行后续处理,并且记录审计信息。
Routing Services(路由服务)
整个系统的路由服务将分为两层,第一层是介于 ESB DataPower 和 ESB Message Broker 之间,第二层是在 Message Broker 内部。
第一层的路由是一层粒度较粗的路由,我们使用请求者的 URI 来决定其调用的服务名称,然后我们将服务名称和 MQ 队列的名称一一对应,这样我们就把请求数据路由到后面的 Message Broker 上对应的队列中了,当然这是一种简单的处理方式,从理想的角度而言,我们可以使用 WebSphere Service Registry&Repository 这样的服务目录和注册库产品来实现。
第二层路由将由 Message Broker 来实现,它通过访问路由表 (Routing DataBase) 来获取路由信息,如图 6 所示。
图 6. 路由服务序列图
该序列图描述了由 Data Power 和 Message Broker 共同实现的路由服务功能:
1. 服务请求者通过 Gateway DataPower 向 ESB DataPower 发送消息;
2. ESB DataPower 从 URI 中获得服务名称,然后消息被转发到 Message Broker 上;
3. WMB OnBoard Flow 根据服务名称查询路由数据库获得路由信息;路由信息被存储到 Message Broker 消息的全局 EnvironmentTree 中;然后 Application Flow 对消息进行处理;最后由 Message Broker OffBoard Flow 将消息路由到目的服务提供者。
Transformation Services(转换服务)
转换服务由 DataPower 和 Message Broker 分别完成,其中 DataPower 实现 XML 到 XML 的转换,Message Broker 实现 XML 和非 XML,如 XML 与 COBOL Copybook 之间的转换。
Logging Services(日志服务)
日志服务由 3 个组件构成,分别是 Event Logger(日志处理器), Event DB(日志数据库)以及 Log Viewer(日志查看器)。日志处理器是一个 J2EE 应用,它通过 Message Driven Bean 读取 Log Queue(日志队列),然后将日志信息写入日志数据库。日志查看器是一个 GUI 应用,用来查看日志信息。从方案设计的角度,整个系统应该采用一致的日志和错误处理策略,在此我们仅列举 Data Power 的日志设计作为参考,其他的日志设计雷同。
图 7. 日志服务序列图
图 7 描述了 DataPower 的日志处理逻辑:
1. 当 DataPower 发生异常时,发送错误日志信息到消息队列,消息类型为永久性消息;
2. Event Logger 从队列中接收到错误消息,并将其记录数据库 Event DB;
3. 若入库失败,则将消息回滚。
--------------------------------------------------------------------------------
回页首
总结
本文介绍了一个制造业企业使用 WebSphere DataPower 和 WebSphere Message Broker 作为企业级联邦 ESB 平台的案例,以此介绍了在此类联邦 ESB 项目中 DataPower 和 Message Broker 如何协同工作,并介绍了这种复杂的 ESB 部署的方案设计和技术实现。
前言
我们知道企业 ESB 实施的模式大致分为 Global ESB、ESB Gateway、Federated ESB、Brokered ESB 等若干种,IBM 的 ESB 产品主要包括 WebSphere Message Broker、WebSpehere ESB、WebSphere DataPower 三种,并且在特定的用户需求下,我们需要将这三种产品组合使用,在本系列文章的第 2 部分,我们再为大家介绍一个制造业企业使用 WebSphere DataPower 和 WebSphere Message Broker 作为企业级联邦 ESB 平台的案例和技术实现。
--------------------------------------------------------------------------------
回页首
客户背景介绍
图 1. 系统交互图
图 1 给出了某制造行业客户现有各个系统间的系统交互图 (System Context Diagram),通过系统交互图,我们可以清晰地了解到 ESB 平台和周边涉及到的系统之间交互的通信协议类型以及数据接口格式。从上图 1 中我们可以看出,其合作伙伴以多种方式调用该企业内部的后台服务,包括标准的 SOAP/HTTP 方式、XML/MQ 的方式、EDI/MQ 的方式甚至 FTP 的方式等;该企业内部的一个主要核心业务系统运行在 IBM 大型主机上,对外的接口方式采用 WebSphere MQ,数据格式采用传统的 COBOL CopyBook 的方式,除了该主机系统之外,该企业的其他一些内部应用会以 SOAP/HTTP 和 XML/MQ 的方式与外界交互。
--------------------------------------------------------------------------------
回页首
DataPower/Message Broker 联邦 ESB 解决方案
针对该客户需求,我们给出的 DataPower 和 Message Broker 联邦 ESB 解决方案架构如下图 2 所示:
图 2. 联邦 ESB 解决方案
在这个解决方案中,我们使用的 IBM 产品主要包括 Data Power XI50 和 WebSphere Message Broker V6.0.2,DB2 V9 以及 WebSphere Application Server V6.1。其中,WebSphere DataPower XI50 是一个实现 ESB 的硬件解决方案,它的主要功能包括:
XML 高速转换引擎;
基于消息内容的路由;
协议桥接 : HTTP, MQ, JMS, FTP 等;
XML/SOAP 防火墙:过滤任何内容、元数据和网络数据;
数据验证:对进出的 XML 和 SOAP 进行数据验证;
保护数据域级别安全:对不同的数据域可以进行 WS-Security, 加密和签名;
访问控制:验证、授权和审计 (AAA),支持 SAML, LDAP, RADIUS 等;
Web Services 管理:中心服务级别管理、服务虚拟化和策略管理等。
该客户的联邦 ESB 解决方案由下列组件构成:
Gateway DataPower:
在 DataPower 和 Message Broker 组合 ESB( 以下简称 DP/MB 组合 ESB) 方案中,常见的产品分工定位方法是:由 DataPower 作为企业对外的 ESB 入口,即担任 B2B 网关的角色,侧重提供其它企业的接入服务以及安全控制方面的工作;而采用 Message Broker 作为企业内部的 ESB 总线,实现企业内部各种应用系统,包括传统应用系统之间的集成平台。
在我们给出的这个实际案例中,采用了两台 DataPower,其中 Gateway DataPower 主要负责外围的接入,接入的通信协议包括 MQ,HTTP(S),JMS,FTP 四种。Gateway DataPower 位于网络架构中的 DMZ 区,它负责 XML threat protection,信息属性传递 ( 例如 IP 地址的传递 ) 和 SSL 传输层安全控制。
ESB DataPower:
这台设备位于网络架构中的受信区,对输入的消息进行更进一步的处理,其中包括:
1. 校验 Inbound/Outbound XML 类型消息的 Schema;
2. 实现非 MQ 通信协议和 MQ 通信协议之间的转换,在我们的设计中,我们在 ESB DataPower 和 ESB WMB 之间采用 MQ 的通讯协议,因此在 ESB DataPower 上我们要将所有的协议转换为 MQ;
3. 信息头的处理:在此我们将创建我们为应用设定的消息头并且插入到接收到的数据包头或 SOAP 头中。
4. 认证 / 授权:通过 LDAP 进行发送者的认证和授权;
5. 日志:为了审计目的,通过日志服务 (Logging Service) 组件对输入信息进行日志处理。
ESB Message Broker:
由于我们的后台核心系统是位于 IBM 大型主机上的应用系统,需要的数据格式是 COBOL Copybook 的格式,因此在 Message Broker 上我们将实现 XML 到 Copybook 的转换。在 Message Broker 上,我们设计了 3 种典型的 Message Flow,
1. OnBoard Flow: 通过查询数据库设置消息的环境树 (Environment Tree),把输入消息转换为标准的 XML 格式;
2. Main Application Flow:用于应用逻辑处理;
3. OffBoard Flow: 依据消息的 Environment Tree,将消息路由到特定的 Service Endpoint(服务端点),并且将数据转换为后台系统需要的格式。
Application Server 组件:
该组件接收和响应 Web Services 请求,并且 Logging 组件也运行在该组件上。
后台主机系统:
负责后台的业务逻辑处理。
LDAP 组件:
存储认证/授权相关的信息。
Routing Database(路由表):
路由表中存储了服务路由信息、服务版本信息等,其中包含了特定于应用程序的配置信息,通过 Java API 对其进行访问来决定服务的路由和绑定。
Event Database/ Event Logger(事件数据库/事件日志处理器):
Event Database(事件数据库)中存储了各种日志和错误信息,Event Logger(事件日志处理器)是一个 Java 应用,用于将各种日志和错误信息存储到事件数据库中。
--------------------------------------------------------------------------------
回页首
DataPower/Message Broker 联邦 ESB 的关键服务组件设计
下面我们来介绍在这个 DP/MB 联邦 ESB 方案中的关键服务组件设计。如下图 3 是 ESB 服务组件图:
图 3. 联邦 ESB 服务组件图
从服务的角度,联邦 ESB 主要由以下服务组件构成:
1. Gateway Services(网关服务)
2. Schema Validation Services(模式校验服务)
3. Security Services(安全服务)
4. Routing Services(路由服务)
5. Transformation Services(转换服务)
6. Logging, Error Handling and Notification Services(日志服务)
下面我们分别介绍这些服务的设计和实现方式。
Gateway Services(网关服务)
这个组件的所有功能都是通过对 DataPower 的配置实现的。它是 Internet 和 Intranet 之间的一个网关,从 ESB 的角度,它就像第一道防火墙,起到对企业外部服务调用的安全控制和协议转换的作用。同时,它根据来源数据的格式,例如 SOAP,XML,文本或 CopyBook 等,进行粗粒度的路由。
Schema Validation Services(模式校验服务)
这个组件的所有功能也都是通过对 DataPower 的配置实现的,开发者可以在部署时,在 DataPower 设备上配置有关的 Schema,对 XML Schema 的高速校验是 DataPower 的一个非常重要的功能。需要注意的是,在我们的案例中,我们的联邦 ESB 除了 XML 格式之外,还必须支持 Copybook 的主机格式,这是 DataPower 不擅长的,对这种格式的解析,我们将交给后面的 Message Broker 来实现,这正是体现了在这个联邦 ESB 解决方案中 DataPower 与 Message Broker 的各自定位以及无缝配合。图 4 描述了模式校验服务的序列图:
图 4. 模式校验服务序列图
模式验证服务主要由 ESB DataPower 实现,它负责对 SOAP/XML 消息模式的校验,如果失败,则调用日志服务进行错误处理。
1. 服务请求者通过 HTTPS 经由 Gateway DataPower 向 ESB DataPower 发送 SOAP/XML 消息;
2. ESB DataPower 对该消息进行校验;
3. 如果校验失败,Logging Service(日志服务)组件将向数据库写入日志信息,向服务请求者返回“Schema Validation Error”;
4. 如果校验成功,将继续安全校验等其它操作。
Security Services(安全服务)
安全服务将负责认证、授权和审计 (3A)。所有这些功能也都是通过对 DataPower 的配置实现的,在该方案中,我们采用 SSL 作为传输级安全控制,对于 MQ 的消息我们使用 MQRFH2 消息头来实现消息级安全控制,对于 SOAP 消息我们采用 WS-Security 标准来进行安全控制,如图 5 所示。
图 5. SOAP/XML 消息认证授权序列图
本序列图描述了对输入消息的认证授权处理,其步骤如下:
1. 服务请求者经由 Gateway DataPower 向 ESB DataPower 发送 SOAP 或 XML 消息,消息中包含了 WS-Security 头信息,其中包括 Username Token and Password;
2. ESB DataPower 接收到消息,它调用 LDAP API 对从 SOAP 消息头或者 MQ 消息头中取得的发送者凭证进行认证;
3. 如果认证失败,日志服务组件将记录失败的日志信息;
4. 如果认证成功,ESB DataPower 将通过访问 LDAP 进行粗粒度的授权,决定发送者是否有权限进行服务调用;如果失败,也记录日志信息;
5. 如果认证 / 授权都成功,则消息将被发送到 Message Broker 上进行后续处理,并且记录审计信息。
Routing Services(路由服务)
整个系统的路由服务将分为两层,第一层是介于 ESB DataPower 和 ESB Message Broker 之间,第二层是在 Message Broker 内部。
第一层的路由是一层粒度较粗的路由,我们使用请求者的 URI 来决定其调用的服务名称,然后我们将服务名称和 MQ 队列的名称一一对应,这样我们就把请求数据路由到后面的 Message Broker 上对应的队列中了,当然这是一种简单的处理方式,从理想的角度而言,我们可以使用 WebSphere Service Registry&Repository 这样的服务目录和注册库产品来实现。
第二层路由将由 Message Broker 来实现,它通过访问路由表 (Routing DataBase) 来获取路由信息,如图 6 所示。
图 6. 路由服务序列图
该序列图描述了由 Data Power 和 Message Broker 共同实现的路由服务功能:
1. 服务请求者通过 Gateway DataPower 向 ESB DataPower 发送消息;
2. ESB DataPower 从 URI 中获得服务名称,然后消息被转发到 Message Broker 上;
3. WMB OnBoard Flow 根据服务名称查询路由数据库获得路由信息;路由信息被存储到 Message Broker 消息的全局 EnvironmentTree 中;然后 Application Flow 对消息进行处理;最后由 Message Broker OffBoard Flow 将消息路由到目的服务提供者。
Transformation Services(转换服务)
转换服务由 DataPower 和 Message Broker 分别完成,其中 DataPower 实现 XML 到 XML 的转换,Message Broker 实现 XML 和非 XML,如 XML 与 COBOL Copybook 之间的转换。
Logging Services(日志服务)
日志服务由 3 个组件构成,分别是 Event Logger(日志处理器), Event DB(日志数据库)以及 Log Viewer(日志查看器)。日志处理器是一个 J2EE 应用,它通过 Message Driven Bean 读取 Log Queue(日志队列),然后将日志信息写入日志数据库。日志查看器是一个 GUI 应用,用来查看日志信息。从方案设计的角度,整个系统应该采用一致的日志和错误处理策略,在此我们仅列举 Data Power 的日志设计作为参考,其他的日志设计雷同。
图 7. 日志服务序列图
图 7 描述了 DataPower 的日志处理逻辑:
1. 当 DataPower 发生异常时,发送错误日志信息到消息队列,消息类型为永久性消息;
2. Event Logger 从队列中接收到错误消息,并将其记录数据库 Event DB;
3. 若入库失败,则将消息回滚。
--------------------------------------------------------------------------------
回页首
总结
本文介绍了一个制造业企业使用 WebSphere DataPower 和 WebSphere Message Broker 作为企业级联邦 ESB 平台的案例,以此介绍了在此类联邦 ESB 项目中 DataPower 和 Message Broker 如何协同工作,并介绍了这种复杂的 ESB 部署的方案设计和技术实现。
发表评论
-
BPEL或ESB:应该使用哪一个?
2012-03-13 17:09 1216在设计 SOA 解决方案时 ... -
ESB 案例解析和项目实施经验分享,第 3 部分: ESB 项目需求分析和方案设计浅谈
2012-02-15 14:50 1782选自:http://www.ibm.com/developer ... -
ESB案例分析:第 1 部分: 借助 ESB 整合航空公司商务体系,提升客户服务水平
2012-02-15 14:14 1946摘自:http://www.ibm.com/developer ... -
ESB架构之企业实施案例
2012-02-14 17:33 1426本文是摘抄自: http://www.webspherechi ... -
关于mule的网站
2011-11-07 10:17 1328关于mule的网站 1,http://note.sdo.com ... -
muleStudio发布到指定目录下
2011-11-04 15:14 1146在mule studio中右键项目名称,选择EXPORT,在弹 ... -
mule配置基础
2011-11-03 10:26 8869Mule是开源的企业集成消息框架,,它的配置需要使用大量的XM ... -
mule配置常用节点
2011-11-03 09:09 12621 Mule-config.xml 示例模型: <mul ... -
mule & seda 学习四
2011-11-03 09:10 996从前,从前 程序跑的太慢,对mule有点误解 jaxb解析 ... -
mule & seda的学习三
2011-11-03 09:10 1248以竣工服务为例 package com.tydic.mule ... -
mule & seda 学习二
2011-11-03 09:11 1199mule的jdbc,配置seda以及vm的初步认识 java ... -
mule & seda的学习之一
2011-11-02 17:18 1316mule:轻量级的ESB消息框架,可以和spring集成,支持 ... -
一个不错的MULE主文件
2011-11-02 17:06 1983mule & seda 的使用每分钟处理5000单,发 ... -
mule示例分析
2011-11-02 14:55 7017一、Hello World (主要演示了两个service c ... -
Mule 官方例子研究
2011-10-28 14:26 1927Mule 官方例子研究 一、 ...
相关推荐
前言客户背景介绍DataPower/MessageBroker联邦ESB解决方案DataPower/MessageBroker联邦ESB的关键服务组件设计总结参考资料本系列文章由3部分组成,在前2部分当中,介绍了两个企业ESB解决方案的设计案例,这两个案例...
专题资料
ESB 案例解析和项目实施经验分享 本文从业务角度列举了航空公司商务体系建设中对企业服务总线(ESB)的典型需求举例,并介绍了航空公司ESB 的总体方案、组件模型、接口设计、物理部署以及涉及到的IBM 软件产品。 ...
【ESB企业服务总线】是企业信息系统集成的关键技术,它提供了一种标准化的方法来连接、管理和通信不同的应用程序,以促进信息的高效流动。在【航空公司 ESB 案例】中,ESB的主要目标是解决系统间的信息共享性、系统...
《ESB案例解析和项目实施经验分享,第2部分 刚柔相济,构建企业联邦ESB》可能涉及如何通过ESB构建灵活且强壮的企业架构。企业联邦ESB允许不同的业务单元保持独立的同时,通过ESB进行有效协作,确保数据和服务的一致...
本文主要探讨了企业服务总线(Enterprise Service Bus,简称ESB)在不同行业中的应用和实施策略,特别是通过两个具体案例——交通运输行业和制造行业的ESB解决方案,以及对ESB项目实施的方法论和经验分享。ESB作为...
**ESB(Enterprise Service Bus)** 是企业服务总线,是一种中间件,旨在促进不同...建议先从解决方案文件开始,逐个分析每个项目,理解它们在整体架构中的角色,然后逐步构建和运行示例,以加深对ESB工作原理的理解。
WSO2 ESB(Enterprise Service Bus)是一款开源的企业服务总线,由WSO2公司开发。它是企业级集成解决方案的核心组件,旨在简化不同系统之间的通信,实现服务化架构。本指南将深入探讨WSO2 ESB的安装、配置、使用以及...
2. **服务代理**:ESB可以作为服务的代理,隐藏后端服务的复杂性,提供统一的接口给前端应用。 3. **消息转换**:不同系统之间的数据格式可能不一致,ESB可以进行数据格式的转换,确保消息能被正确理解。 4. **...
### ESB和SOA介绍与比较 #### 一、SOA与ESB概念解析 **SOA(面向服务的架构)**是一种...通过合理的规划和实施,SOA与ESB可以显著提升企业的IT系统集成能力和业务响应速度,从而更好地支持企业的战略目标和发展需求。
WSO2 ESB(Enterprise Service Bus)是WSO2公司推出的一款开源的企业级服务总线,它基于Java语言开发,遵循ESB(企业服务总线)模式,旨在帮助企业实现服务的集成、管理和优化。作为一个中间件平台,WSO2 ESB的核心...
综上所述,ESB斯欧案例通过构建一个全面的企业服务总线集成管理平台,实现了企业内部不同信息系统间的高效、安全的数据和服务交换。通过对总体架构、应用集成模式以及系统接口规范的详细介绍,可以看出该案例不仅...
### ESB原理及Mule ESB实践 ...综上所述,ESB和Mule ESB是现代IT架构中不可或缺的部分,它们为企业提供了一种灵活、高效的服务集成方案。无论是理论层面还是实际应用,掌握ESB原理及Mule ESB实践都是非常有价值的。
2. 面向服务的架构:ESB可以实现服务之间的集成。 3. 事件驱动的架构:ESB可以实现事件驱动的集成。 ESB的适用场景及要素: 1. 协议转换模型:用于当服务的请求者与服务提供者基于不同协议时的消息转换情形。 2. ...
6. **企业特性**:MULE ESB企业版包含了额外的安全性、监控、管理和扩展性功能,例如高级审计日志、集群支持、实时性能监控等,这些都是为了满足大型企业的严格要求。 7. **MuleSoft Anypoint Platform**:除了MULE...
【标题】"ESB3实例代码及文档"指的是企业服务总线(Enterprise Service Bus,ESB)的第三阶段实现的相关实例代码和配套文档。ESB是企业级集成的关键技术,它提供了一种在不同系统之间交换信息和服务的方式,使得应用...