内蒙古java团队

j2se,j2ee开发组
posts - 139, comments - 212, trackbacks - 0, articles - 65
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

实现ESB

Posted on 2007-12-20 11:43 帅子 阅读(1180) 评论(0)  编辑  收藏 所属分类: j2se技术专区
激活SOA的全部潜力还需五年。即使用企业服务总线(Enterprise Service Bus,ESB)是实现ESB全部潜力4步中的第三步。模型中的步骤如下: 

使用XML,以更标准的方式使用应用程序接口。 
捕获一些业务过程,并将它们转化成为Web服务。 
引入并全面使用企业服务总线。 
产生业务过程执行语言(Business Process Execution Language,BPEL),它可由业务过程建模工具完成。BPEL可以改变应用程序的行为,而无需修改软件。 
Rippert先生在采访中表示,尽管很多组织拥有ESB,但是它并没有被完全利用。他进一步的表示,大多数公司仍处于阶段1。与这个ESB所处位置的论断相对比的是,Burton Group的分析师Anne Thomas Manes的叙述,其发表于近期面向服务架构Yahoo Group的讨论中。Anne说: 

......如果缺少我推荐启动SOA的“基本组件”,ESB将不会列在我的清单中。事实上,我并不鼓励人们由ESB开始。ESB并不会鼓励好的SOA行为。ESB本质上是集成系统,而非SOA系统。SOA是用于拆卸应用竖井(application silos),而集成系统则是修补这些竖井。
引用她的书,她接着提及的基本组件包括: 

一个或多个服务平台(如,.NET,Java EE应用服务器等) 
SOA管理解决方案 
注册表 
如果服务要被暴露在防火墙之外,那么需要XML网关 
引用组员早期的帖子,她说道: 

“......ESB特别适合桥接传统应用,因此,在服务基础设施中,它是一个有用的组件。很多ESB也支持可靠消息传递、异步消息传递和发布/订阅交换模式。这些能力都非常有用,但是,在SOA项目的初始阶段可能不会发挥多大的用途。(每个组织有很多不选用这些能力的项目。)在SOA项目的后期,你还可能需要一个编制(orchestration)引擎,并且大多数的ESB都会提供一个。即便如此,ESB也绝对不是组织启动SOA的起点。所有这些能力你一开始并不需要。因此,ESB应该在后期购买。”
这似乎符合Rippert先生的观点,即尽管很多组织拥有ESB,但是它并没有被完全利用。Manes女士的评论同样有助于定义ESB的范围,通过暗示许多ESB支持的特性,它确定了一组适当的能力。 

根据维基百科的ESB定义,ESB有如下特性: 

它是面向服务架构的实现。 
它通常是操作系统和编程语言无关的;它应能在Java和.Net应用程序之间工作。 
它使用XML(可扩展标识语言)作为标准通信语言。 
它支持Web服务标准。 
它支持消息传递(同步、异步、点对点、发布-订阅)。 
它包含基于标准的适配器(如J2C/JCA),用于集成传统系统。 
它包含对服务编制(orchestration)和编排(choreography)的支持。 
它包含智能、基于内容的路由服务(itenerary路由)。 
它包含标准安全模型,用于ESB的认证、授权和审计。 
它包含转换服务(通常是使用XSLT),在发送应用和接收应用之间转换格式,简化数据格式和值的转换。 
它包含基于模式(schema)的验证,用于发送和接收消息。 
它可以统一应用业务规则,充实其它来源的消息,分拆和组合多个消息,以及处理异常。 
它可以条件路由,或基于非集中策略的消息转换,即不需要集中规则引擎。 
它可监视不同SLA(服务级别合约)的消息响应门限,以及在SLA中定义的其它特性。 
它(常常)简化“服务类别”,向更高或更低优先级用户做出适当的响应。 
它支持队列,在应用临时不可用时用来保存消息。 
它由(地理)分布式环境中的选择性部署应用适配器组成。 
看起来,共识之一是ESB是与编制(orchestration)和业务过程管理(Business Process Management)截然不同的单独一类产品。此外,对于ESB到底是产品还是模式还有很大的争议。 

在本系列的第二部分,InfoQ调查了ESB的使用目的 - ESB的使用案例和需求是什么? 

Sonic公司的Dave Chappell开启前文中的讨论,部分1暗示了Sonic软件公司可能事实上正试图标准化基于UML的模式集,实质上,它们定义了ESB的参考架构。 

Stuart Charleton(BEA系统策略咨询服务的企业架构师,位于Canada的Toronto)提供了以下的使用例子: 

消费者使用基于HTTP/S的认证,生产者使用WS-Security。 
消费者使用HTTP/RSS,生产者使用WebSphere MQ或JMS。 
消费者使用HTTP/REST和URI,生产者使用SOAP/WSDL。 
消费者有一组证书,生产者有另一组(键链映射)。 
一端使用FTP站点作为“服务接口”,而另一端文件被拆分成JMS消息。 
在路由到目的地之前,消息需要被充实,这样就可以执行callout来收集额外信息。 
生产者要求协议独立的负载均衡和/或故障转移。 
消息需要被存储转发,在不可靠服务上改进可靠性。 
同时,作为这些主题的补充,Paul Fremantle(WSO2的共同创建者和技术副总裁)增加道: 

因此,ESB是实现仲裁(mediation)的通信基础设施。ESB应该有什么样的拓扑结构呢?我认为它应该是灵活的:你可以将ESB构建为中间层的单个且大的代理,也可是很多智能终端。当然,拓扑结构会影响可管理性,但是只要有配置ESB的中心注册表/仓库,那么它将工作很好。这其中的关键点是ESB应该由策略而非书写代码驱动。
Burton Group的Anne Thomas Manes也说道: 

“......ESB特别适合桥接传统应用,因此,在服务基础设施中,它是一个有用的组件。很多ESB也支持可靠消息传递、异步消息传递和发布/订阅交换模式。这些能力都非常有用,但是,在SOA项目的初始阶段可能不会发挥多大的用途。(每个组织有很多不选用这些能力的项目。)在SOA项目的后期,你还可能需要一个编制(orchestration)引擎,并且大多数的ESB都会提供一个。即便如此,ESB也绝对不是组织启动SOA的起点。所有这些能力你一开始并不需要。因此,ESB应该在后期购买。”
以上强调将ESB作为桥接传统应用的手段。Network Computing的近期研究中:调查一组回答者,让他们使用“从强烈同意到强烈反对”的标准,为一组关于ESB技术的表述评分。回答者强烈同意的前4个表述是: 

ESB必须给企业数据源(SAP、Peoplesoft、Oracle、SQL Server)提供适配器。 
ESB必须至少支持基础的业务过程管理。 
ESB实现需要支持开放标准(JMS、Web服务)。 
ESB必须与现有的企业应用集成(EAI)和面向消息产品平滑集成。 
这暗示着传统数据源(如ERP和EAI系统)是ESB的重要接口,并且它们应该将那些应用层作为基于标准的消息暴露。有趣的发现是,终端用户似乎同意"至少基础的"业务过程管理是ESB“必须支持的”。 

关于最后的评论,Steve Jones(来自CapGemini)暗示,ESB的问题事实上是3个毫不相关的问题:集成、构建和业务。 

……第一个挑战是利用现有资产发掘功能(集成),第二个则是构建新的应用(构建),最后则是管理新应用间的交互(业务)。待会儿我将在我的博客中讨论这些。 
 

集成产品有很多非常不同的需求,并且驱动力来自于人们想在更面向标准的空间中实现交互,而我不太确定混淆这两个领域为什么有意义。同样的,构建新应用(使用过程或面向对象语言)则需要不同的技术和方法。 

集成总线以其能力作为衡量标准,而业务服务总线则在于简单性和应用开发解决方案的灵活性。并且无论何种合理规模的业务也不会有一劳永逸的解决方案。 
ESB综述的第二部分期望能帮助定义用户要求的使用案例,尤其是当他们需要ESB时。共识是:业务过程工具与ESB是不同的,加上ESB包含来自最终用户的完全相反的兴趣,这也暗示着可能将不同种类的产品合并为成了一个。 

欲了解这个讨论,请关注适合于ESB的使用案例。 

只有注册用户登录后才能发表评论。


网站导航: