业务优化在很多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月份，子系统也使得思科公司公司能够在自己的面向应用程序网络(Application-Oriented Networking，AON)策略上进行发送。AON将使得特殊的XML流程能够整合到Catalyst 6500交换机平台上。

　　今天，Web服务流程在普通的平台上崩溃，只剩下网络基础结构来追随数据中心的一般趋势。

　　组合了应用程序层交换、SSL终止和Web加速的应用程序前端(Application Front Ends，AFE)开始抬头。通过把XML流程和其他平台组合起来，IT就可以继续获益而不必遭受崩溃以及管理其他头疼的问题。

　　Web服务 改变业务模式

　　那些已经部署了Web服务的人们不仅宣扬其给IT带来的显著变化，而且也包括业务运行的方式的变化。最常提及的好处就是减少了IT成本。快速的应用程序开发是JetBlue Airways使用Web服务的一大原因。JetBlue的应用程序架构师Tyrone Paige说:“我们可以构建一个服务来解脱我们的人力，而不必再重新发明车轮”。

　　成本的缩减也可以以其他的形式体现。例如，一个集成商使用Web服务帮助客户进行文档发送，这个客户要通过通宵传输来发送一个很大的图像文档。E-mail无法使用，因为这可能导致E-mail系统的阻塞，FTP对客户来说太麻烦了。通过部署Web服务，集成商可以使客户看不到系统的复杂性，把传输费用减少了50%达到每年约200美元，当然也减少了共享文档的时间。

　　带宽的节省也有很大的潜力。尽管对于SOAP的性能问题已经讨论了很多，XML的声明特性能够使公司减少他们需要在网络中传送的流量。

　　一个软件在线订购系统的开发者遇到的情况是这样的。在使用XML和Web服务之前，通过消息软件来发布请求，该软件要求对所有需要的字段都插入请求的数据。很多事务并不需要每一个字段，这就迫使开发者插入空字段并且毫无必要地扩大了消息容量。有了XML，公司可以描述数据，允许他们只提供和一个请求相关的信息。这种标记XML消息的一部分的能力，将处理“截断”事务的周期从两三秒缩短到十分之一秒。

　　从战略上讲，公司已经能够通过Web服务和SOA来将他们的业务流程流线化。Forrester Research指出:作为澳大利亚的一个地区政府机构，Queensland 交通局就是这种现象的典型例子。Queensland实现了一个基于XML的接口，使得交通工具可以登记它们的购买地点。

　　交通局发现它还可以解决和交通监察员相关的业务问题。Queensland面积很大，要对政府雇用的交通监察员进行团队管理很难。现在，Queensland可以对独立的交通监察员进行认证，并通过XML接口把他们纳入到交通工具管理系统中