解读SOA架构及其安全性的问题

日期: 2012-04-08 来源:TechTarget中国 英文

  IT组织已经成功建立并实施SOA应用软件很多年了,并有效的节约了成本和提高的生产效率,取得了很好的成果。那么,SOA如此风靡,它究竟是一种什么东西呢?简单来说,SOA就是一个组件模型,应该属于一个软件一体化中的一个概念。这个组件模型,将不同的服务以应用程序的不通功能单元的形式,通过已经预定义的接口和协议联系起来。这些预定义的接口,一般都使用比较中立的定义,这样可以确保这种接口可以做到跟编程语言无关,跟所有的软硬件无关,最大可能的满足其跨平台性。这样,当构建一个这样的平台后,这样一个平台中的系统就能以一个统一的通用的方式进行交互,而不用去关心这些系统被部署在什么样的环境中和部署在什么地方这些问题了。

  当然,即使到目前,SOA依旧没有一个统一的官方的定义,很多厂家在在拿出自己的SOA决绝方案的时候,都给除了自己的定义。这里,我们仅仅提供一个W3C提供的定义:SOA是指服务提供者完成一组工作,为服务使用者交付所需的最终成果。最终结果通常会使使用者的状态发生变化,但也可以使提供者的状态发生改变,或者双方都发生改变。

  在实施SOA架构时的关键目标是什么呢?其实就是为了节约成本,实现企业IT资产重用的最大化。这一目标促使人们在实施SOA的时候,必须考虑以下方面:可从企业外部访问,这个是因为为了满足企业的业务伙伴的需求。使业务伙伴即外部用户也能像企业内部用户一样访问相同的服务。当业务伙伴基于业务的目的交换业务信息时,这个会话过程应该不会受到阻止:随时可用,当有服务使用者请求服务时,SOA要求服务提供者能够及时响应。

  这里有个问题需要说明的是,在实际上,服务的提供者总是多于服务的使用者,当使用者多到一定程度时,对使用者来说,很容易受到服务提供者短缺的影响,所以为了缓解这个问题,一般在提供服务时,会考异步应用,因为异步应用要更为稳健,其采用队列请求设计。可以容许服务暂时短缺或迟滞的情况:考虑到减少使用者和服务层之间的多次往复,在设计接口时一般采用粗粒度服务接口,因为粗粒度服务一次能提供一项特定的服务功能。但是这里也会出现一个问题,那就是,粗粒度设计虽然能有效减少使用者和服务层的多次往复,但其重用性却很差,有的甚至没法重用,为了解决这个问题,人们在设计SOA架构的时候,采用了不通的粗粒度等级来创建服务。这种服务分级包含了粒度较细,重用性较高的服务,也包含粒度较粗,重用性较差的服务。在设计时,还有一个重要的特性。那就是需要满足松散耦合,这以特性的满足,使SOA与其它的大多数组件架构区别开来,而且,也将服务使用者和服务提供者在使用服务和提供服务上实现了完全的透明。早些时候,SOA架构一般采用ESB通信。但现在采用较多的是web services,这要优于与服务特定接口的连接。还有一个特性就是需要可重用的接口设计,这个就不用说了,为了满足重用性和易于管理性了。

  由于SOA架构满足上面描述的那些特性,其具有的优点是显而易见的。其具有的优点主要表现在:编码灵活性;能使每一个开发人员的角色明确:由于其采用了中立的通信格式,所以能支持多重客户类型;其松散耦合让其具有更易维护性,更高的可用性。对企业来说,最关心就是对现有的资产的利用和易于集成和管理了,而这个也能满足,所以,企业的成本就自然而然的降低了。

  虽然SOA现在发展的如火如荼,但还是处在不断的发展中,还是存在很多有待改进的地方。其缺点目前来说,主要表现在以下几个方面:可靠性,安全性,性能。在电子商务的应用中,有一个很重要的可靠性,就是不可否认性,信息确保发送且仅且一次以及事务的回滚,这点是必须得到满足的,但是,目前来说,SOA架构还没有为此做好准备。至于安全性我们在下面会做详细的分析。至于性能问题,不可否认,这个SOA架构最遭人诟病的地方。SOA架构的性能稍低,主要是因为SOA的分布性质和web服务协议的开销。任何分布式系统的执行速度都不如独立式系统,因为这里面有网络的制约因素。所以,在对那些实时性要求较高的地方,在构建SOA架构之前,就应该先搞清楚它的适用范围了。

  这里之所以特意把安全问题拿出来作为一个独立的段落,是因为安全问题对一个系统来说应该受到足够的重视。如果你没有在在它上面付出应有的努力,也许,它就会成为导致SOA架构在实施的时候失败的主要原因。

  由于SOA架构的松散耦合性,当其向客户提供服务时,任何形式的网络都能获取IT应用程序和系统时,人们会本能的担心非正当人群也能访问程序和系统。互联网对世界开放,从而更加剧了人们的这一担忧。通常我们企业都知道保护网络接入,认证用户以及运行访问控制列表。假设所采用的SOA基础架构具有实施安全粒度的全力,这就使得有效控制访问方式成为可能。但是,如果保证数据在网络中输送的隐秘性又是一个难题,要达到一定的保护水平,可以采用各种加密标准。然而不幸的是,市场并没有很好的处理整个SOA安全事件,简单的看很多与安全相关的web服务“标准”草案都是尚未成熟,考虑欠佳,并不真正的实用。

  那么一般来说,我们针对SOA的安全能做些什么呢?需要的SOA网络安全策略和许多的基于web的应用程序是采用相同的策略的,他们采用的方式都可以归结为创建一个虚拟局域网来保证服务器和客户端达到交互,使用数字证书来建立SSL(secure socket layer)保护或者HTTPS。或者通过在软件或者硬件上部署防火墙基础架构来检测通过SOA进来的可疑请求。但是这只是构建一个安全的通道,我们依旧不能保证数据不被窃取,所以,为了确保数据的安全性,我们需要对数据加密。针对SOA架构来,说,就是对原始的XML数据进行保护了,通常,我们采用XML加密和XML签名来把安全加入到基于XML的数据中去。XML加密可以让数据能够在请求者和晌应者之间以一种模糊的方式传输,这样,即使数据受到窃取,信息也很难读懂。而XML签名,则是用来进行XML文档的篡改检测的。它可以保证所传输的数据没有收到篡改或者状态没有发生改变。至于具体的操作方式,限于篇幅。就不在这里详细讲解了。

  尽管SOA产品和平台已经发展有一段时间了。但这仅仅意味着开始。相信SOA架构在以后的一段时间内,仍然会有巨大的发展。但毕竟SOA架构也还是存在一些问题,所以,对于用户而言,究竟该选择什么平台或者什么产品,的确是应该三思而行。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐

  • 总线技术究竟该不该用?

    曾几何时企业服务总线(ESB)被视为企业IT的核心。今天,不仅ESB受到了比被废弃还要糟糕的攻击,若干开发趋势似乎对更简单的消息总线也发起了质疑。

  • 从ESB到微服务:如何演变?

    从web开发人员的角度看,大量的微服务部署到轻量级的Karaf 容器中,这就符合了ESB的定义。

  • API管理工具能否弥补REST与Web服务之间的鸿沟?

    随着企业学习如何通过RESTful利用现有服务,API管理工具正在引起轰动。API管理工具能否弥补REST与Web服务之间的鸿沟?

  • 支付宝分布式事务测试方案

    基于SOA架构,整个支付宝系统会拆分成一系列独立开发、自包含、自主运行的业务服务,并将这些服务通过各种机制灵活地组装成最终用户所需要的产品与解决方案。