• 当前位置:首页>>Web Service>>Web Service>>Web服务 标准化的青春期
  • Web服务 标准化的青春期
  • 新标准正在帮助Web服务成长起来。但是,Web服务已经准备好成为贵公司的企业软件策略的骨干了么?

    业务优化在很多IT公司中已经成为习惯用语。其目标简单而明确:减少应用程序开发的时间和成本,改善履行订单等流程,并且将供应链管理这样的外部交互流程化。

    当然,最经常被推荐的解决方案就是基于SOA。

    银弹?可别指望它。如此之多的IT架构师都试图部署基于SOA的Web服务,这足以证明Web服务缺乏安全的、确保的分发机制以及实现复杂业务过程所必需的基础。

    但是,当Web服务开始成长的时候,这些都改变了。尽管确保分发的标准正在被定义,至少对于如何进行发送,业界已经达成一致。然而,还有很长的路要走。

    发布和订阅的机制现在还在标准化的过程中,并且标准也还没有准备使用Web服务来定义独立于数据访问逻辑的统一业务逻辑。

    当这些标准被采用的时候,它们将改变公司的网络架构师的工作方式。SOA超越了公司和部门的界限,它将会创建一个安全化XML服务、认证用户并且强化基于策略的安全性架构的网络。

    同时,路由基础架构也可能需要使Web服务有意识地阻止某种长时间的事务(也就是那些信息服务的订阅)充斥这个数据网络。这样的增强型的路由网络将会更多地用来确保其他重要Web服务的QoS。

    Web服务成热潮

    除非你在过去的三年里深居简出,否则你一定听说过SOA。它正在为企业如何设计它们的软件基础结构带来革命性的变化。有了SOA,公司可以把工作的每个元素(如更新一个客户账号)定义为可以被其他应用程序复用的一个服务。这使得公司可以降低软件开发成本,缩短开发时间,并且创建新的业务流程。

    和SOA一起得道升天的是Web服务,这种软件构造使用Web服务描述语言(Web Service Description Language,WSDL)和简单对象访问协议(Simple Object Access Protocol,SOAP)来实现系统间的消息传递。

    尽管SOA优于Web服务并且也可以用其他的技术来构建,但Web服务也为SOA注入了新鲜的活力,这些都是不争的事实。独立于平台的Web服务意味着开发者可以在.NET中开发,在J2EE平台中输入数据,并且可以使用大量的第三方管理和部署工具。

    与IBM的WebSphere MQ和Sonic Software的SonicMQ等面向消息的中间件(Message-Oriented Middleware,MOM)相比,Web服务的许可授权和实施也许是基于标准的并且比较便宜。但是,它也因为显著的性能问题而出了名,而这个问题是基于MOM的解决方案所没有的。

    然而,别忘了,性能问题并不是Web服务的基本问题,并且自2002年以后已经发生了很多变化。根据Rutgers大学的分析,SOAP性能不佳的主要原因在于Apache Axis SOAP堆栈的优化不好,使用了多个系统调用来发送一条逻辑消息。

    这是个好消息,但是自2002年以来还是有很多没有改变的地方。Web服务仍然依靠基于文本的XML协议。基于文本的消息要比等同的二进制形式长很多,以至于Allstate Financial的企业架构师Kevin Rice都建议保证限制事务不要超过5KB到10KB。

    为了解决围绕XML的文本特性产生的问题,今年秋天,W3C的XML二进制字符工作组开始制定一个二进制XML的标准。二进制XML格式对已经解析的XML文档进行编码,从而减少发送和存储的信息量大小。编码的文档可以以60倍于一些二进制XML解析器的速度来解析和转换。

    私有的二进制格式已经存在。尽管二进制XML可能改善语言的性能和降低存储需求,但是,随着不同二进制XML版本出现,还是引发了互用性问题。工作组当前正在试图解决这个真正的问题。

    要安全,也要可靠

    大多数公司可能希望等待XML方面的标准或投资来加速硬件,从而改善Web服务的性能,但是安全是另一个重要的事项。公司从在内部网络中运行Web服务过渡到把Web服务从Internet扩展到业务伙伴,安全性成为一个极为重要的问题。

    实际上,根据调查,66%的IT架构师读者表示他们非常关心安全问题。对逆向工程或集成应用程序的成本的关注位居第二,占到49%。

    如何才能更加安全?

    如今,大多数IT架构师(40.9%)仍然使用SSL来加密和签署Web服务数据,但是SSL并不会保护一个事务的完整路径。当公司传递需要遵从规定需求的敏感数据时,路径级的保护就变得很有必要了。结构化信息标准推动组织(OASIS)已经研发出一种新的标准用来解决这个问题。有了WS-Security,应用程序开发者就可以加密和解密SOAP数据包,然后通过用户名和标记来认证用户。来自W3C的XML签名提供了一种数字化签名XML文档的方法,而XML加密定义了如何加密XML文档或部分加密之。

    这些标准提供了足够的保护,可以确保Web服务通过互联网时的安全性。安全性确实不应该是一个主要的问题。确保Web服务的安全并不困难。

    然而,还没有广泛可用的是对来自底层的Web服务的安全策略的抽象。如今,公司必须把安全性硬编码到Web服务中,这就限制了它的适应性。OASIS在忙于WS策略的制定,这是允许独立于Web服务指定那些方法的一个标准,但最终草案和最初实现可能在2006年底前不会产生。

    安全性断言标记语言(Security Assertion Markup Language,SAML)的2.0版本提供了可以对多个单独的名字进行断言的方法。

    随着IBM、微软、Novell、甲骨文、RSAS Security和Sun的身份管理系统的实现和上市,SAML 2.0的采用可能要到明年才会变得更为广泛。

    Web服务需要被可靠发送

    如果公司依靠自动服务来实现某个或所有的客户和伙伴的交互,IT架构师必须确保事务被完成。他们还需要能够在比较复杂的交互中清楚地表示出Web服务,而这种交互可能需要较长的一段时间(相对于快速查询和响应)才能完成。当事务需要很多的Web服务交互的时候,如响应一个信息请求或填写一个购买订单的时候,复杂性也随之增加。

    直到今年5月,为了使用SOAP,IT架构师一直被迫在两种可靠的消息发送规范之间做出选择。

    Novell、甲骨文、Sun和SeeBeyond都属于支持OASIS的Web服务可靠性消息技术委员会。该委员会在2004年11月发布了WS-Reliability(WS-R)作为标准。同时,IBM、微软、Tibco和BEA则支持Web服务可靠性消息和Web 服务可靠性消息策略断言(WS-RM Policy)规范。

    5月,工业界通过第三个OASIS组织弥合了鸿沟,这就是Web服务可靠性交换技术委员会(WS-RX)。WS-RX组织包括来自WS-Reliability和WS-ReliableMessaging阵营,并且很可能在2007年的某个时间推出一个单独的规范。

    尽管如此,这个标准可能还不足以解决金融事务所需的可靠性级别。

    除了可确保的发送,金融事务之前可能还需要完成较长时间的外部过程.例如,对一个购买订单做出响应、向相关社团的全体发送金融信息或者在一个生产过程中发布订购修改。

    这种类型的事务需要异步发送机制来取代当今的SOAP事务所需要的立即响应。仅仅使用异步事务普遍地限制了Web服务的范围,因为应用程序在继续自己的操作之前必须先等待事务完成。

    OASIS已经支持两套规范,WS-RX和WS-Notification,它们使得标准化异步事务成为可能。

    保证逻辑的灵活性

    长期的目标是在Web服务部署中达到这样的效果:底层的SOA变得足够敏捷,能够适应和应付过程的改变而不需要大量地修改代码。这部分,取决于服务流程是如何构建的,但也依赖于从底层服务概括安全和业务策略的能力。就像一个数据中心负责将表示层(Web服务器)和应用逻辑层(应用程序服务器)以及信息(数据库服务器)分隔开来一样,一个设计精良的SOA则负责把业务逻辑和用户所需数据区分开来的计划任务。

    从应用逻辑概括业务逻辑是OASIS的业务流程执行语言(Business Process Execution Language BPEL)的核心功能。这是一种试图对业务逻辑建模的语言,其目标是定义一种构建基于事件的应用程序的方法。

    例如,当一个购买订单或RFP发生,需要有在企业中执行这些文档直到完成的业务流程。在购买订单的情况下,这可能意味着要调用一个库存检查,如果有充足库存就向用户发送确认消息。

    甲骨文已经有最为知名的BPEL的标准前实现,他们早在18个月前就启动了Collax项目。微软的BizTalk使用自己的语言来对业务流程建模,但是不能够导入和导出BPEL。IBM提供了BPEL的一个测试实现(www.alphaworks.ibm.com),并且在4月份将BPEL支持引入到WebSphere Business Integration Server Foundation 5.1。

    尽管都在谈论BPEL,但是标准要普遍地实现还需要数年时间。工业界首先需要围绕他们将要使用的方案达成一致。

    到目前为止,BPEL可能已经为实现做好了准备。今天,BPEL已经足够复杂,但还不够强大。我们可以使用BPEL来进行简单的操作,但是它还太复杂无法用来实现复杂的工作流。

    BPEL还有其他的一些问题,包括必须使用中央化的、非分布式的架构的限制。

    打造数据新网络

    正如业界不厌其烦地重复,企业间的Web服务迫使人们对公司网络中的关键接合点进行重新思考,这已经是再清楚不过的了。而至今还不明朗的是,这些变化是通过专门的Web服务设备来实现,还是通过扩充现有的设备。在过去的半年里,如果说这个问题有任何迹象的话,大多数公司倾向于后一种方法。

    由于Web服务是基于XML的,它们并不表现为一种可以预先知道的二进制格式。每个包必须单独处理,计算量很密集。像DataPower、Sarvega(现在属于英特尔)、Reactivity和Conformative这样的公司都提供可以加速XML和Web服务数据处理和转换的XML引擎。

    公司需要决定如何在网络中最好地引导Web服务。所谓Web服务(即那些对信息的订阅)路由器整合,就是意味着可以相当于IP多播功能一样在网络中只发送Web服务信息的一份拷贝,从而减小网络流量。然而,XML有意识的路由还需要经过12到18个月才能够被广泛采用。

    今年8月份英特尔对Sarvega的收购为这种趋势推波助澜。

    6月份
  • 上一篇:无
    下一篇:对Web服务进行压力测试