北极星

搜索历史清空

  • 水处理
您的位置:电力综合正文

IT架构师该如何对应用程序实施SOA架构[1]

2008-08-04 18:39来源:希赛关键词:SOA收藏点赞

投稿

我要投稿

  围绕SOA的宣传热潮似乎是一浪高过一浪。软件提供商和分析师乐于向媒体提供信息,借此大肆吹捧自己的产品和技术特点。一些提供商声称他们的产品为实现SOA不断努力,另一些人尽管可能正在或多或少的使用着这些产品,但他们更愿意认为SOA在更大的程度上只是一种架构模式。

  不论市场上有什么样的说法,重要的是要认识到任何一个SOA基础架构产品都是实现SOA的方法之一,是人们在实现SOA这一路走到现在的一个里程碑,但同时,这并不意味SOA的完结,SOA本身还要继续发展。平台软件能够为整个企业的服务架构,提供必要的主干网络,但是选择怎样的方案只能依据企业的具体需要来定。

  目前普遍使用的企业服务总线(enterpriseservicebus,ESB)就是这样一类软件。最近的一些创新产生了一些搔动和困扰。所有的ESB提供商都说使用他们的ESB产品为面向服务的技术架构提供核心组件。然而,大多数提供商仍然是努力组成一个ESB,他们的产品仅仅具有普通ESB应该具备的功能。

  设身处地想象一下,作为IT架构师,负责对应用程序实施SOA架构。你应该作些什么?这真的非常简单,你只需回到业务需求一块,只要服务调节指挥和架构模型能够满足业务需求即可。

  服务调节

  调节(Mediation)并不是一个新概念。在传统的面向对象的文献中,众所周知,调节者(mediator)是推动“松耦合”(loosecoupling)的一种模式,Mediator可以用来控制和协调这些对象间的相互调用,避免他们之间的复杂调用造成混乱甚至死循环,同时使逻辑更加清晰,需要改变某些逻辑时也很容易实现。

  用服务替代上一句中的对象,这样你就可以很好地理解什么是服务调节。然而,在SOA中服务调节不仅可以用来控制和协调这些服务间的相互调用(尽管这种相互间的调用是一个好的开始)。在强调技术中立性的服务世界里,基于XML的信息交互作用更可以使多事情都变成可能,只要你在服务生产者和服务消费者之间放置一合格的调节者。

  传输协议转化

  通常,服务提供商基于某种传输协议(例如HTTP)提供服务,而服务消费者只能通过另一种不同的协议(比如MQ)通信。因此,也许需要在服务提供商与消费者之间建立一座异步起动同步运行的连接桥梁,超越HTTP和JavaMessagingService消息服务(JMS)等协议.从技术角度讲,JavaMessagingService消息服务(JMS)并不是一种传输协议,而是一组供应商中立(vendor-neutral)的通信APIs。正如图1所示,异步Web服务实施通常表现为“简单对象访问协议(SOAP)服务在JMS之上,”而在使用传输协议的背后是供应商特定(vendor-specific)的,如MQ或TibcoRV。

  这种现象在有很多遗留软件的环境中非常普遍,这些遗留软件的服务已被开启,而其它应用程序却因为传输协议不配不能使用这些服务。与其建立一个新的协议适配器或在执行服务提供商的基础上实施异步起动同步运行桥梁,还不如让调节者来解决这些差异不同,做必要的转换。这样服务开发人员只需要集中精力解决服务逻辑问题,可以让基础结构软件负责调节责任。

  数据格式转化

  即使在同一机构中,不同部门对于业务实体的定义也会不一样。财务部可能有特别的客户结构,它区别于从开发帐单角度定义的客户。这种情况下,一个开发帐单中与客户相关的服务就不能在没有弄清数据模型区别的情况下采用财务部的服务。
[1][2]

投稿与新闻线索:陈女士 微信/手机:13693626116 邮箱:chenchen#bjxmail.com(请将#改成@)

特别声明:北极星转载其他网站内容,出于传递更多信息而非盈利之目的,同时并不代表赞成其观点或证实其描述,内容仅供参考。版权归原作者所有,若有侵权,请联系我们删除。

凡来源注明北极星*网的内容为北极星原创,转载需获授权。