SOA: 不能只有“吹捧”_软件工程

自2004年初业界推出SOA后，BEA、IBM、Oracle、微软等业界巨头纷纷发布各自的SOA战略，强烈呼吁用户在进行企业IT建设时考虑SOA。 SOA，就是面向服务的体系结构(service-oriented architecture，SOA)，这是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。由于接口是采用中立的方式来进行定义的，并且独立于实现服务的硬件平台、操作系统以及编程语言，这就使得构建在各种各样系统中的服务可以以一种统一和通用的方式来进行交互。 SOA: 不能只有“吹捧”

传统的Web（Html/HTTP）技术有效地解决了人与信息系统的交互和沟通问题，极大地促进了B2C模式的发展。Web服务（XML/SOAP/WSDL）技术则是要解决信息系统之间的交互和沟通问题，促进B2B/EAI/CB2C的发展。SOA则是采用面向服务的商业建模技术和Web服务技术，实现系统之间的松耦合，实现系统之间的整合与协同。对于SOA的发展前景，诸多市场分析和咨询公司都非常看好: ZapThink调研公司认为，2006年基于SOA架构的中间件产品将成为网络化商业系统的主要设计思路，其中70%的商业企业公司将使用SOA架构; IDC猜测2007年包括软件、服务和硬件在内的SOA市场将达到210亿美元，其中商业企业方面的市场将达到120亿美元; Gartner则认为到2008年，SOA将成为占有绝对优势的软件工程实践方法，它将结束传统的整体软件体系架构长达40年的统治地位。届时，将有60%的商业公司在进行商业IT建设时会转向SOA。采用传统的系统架构技术和传统的EAI和B2Bi技术存在系统封闭、厂商依靠性强、耦合度高、重用性差，扩展性差、无法和上下游企业的系统建立统一的接口等问题。而采用SOA技术则可以有效解决上述问题，由于SOA基于HTTP/SOAP/WSDL等开放式技术，对于特定厂商产品依靠性小; 系统开放、互操作性强，可以建立统一的Web服务用于和不同的上下游企业信息系统实现供给链协同。由于SOA的松耦合特性、比较符合集团和各下属机构的商业关系，业务流程整合和项目协调的阻力会有效降低。深究SOA的内涵，其实离不开服务模块化的概念。也就是说，任何一项可能响应某种应用而诞生的服务模块或者说服务组件，日后也可能接收其他服务的请求，而在不同的应用环境中出现，并与各个服务模块交互运作。在这种情况下，所有服务模块所能接受的接口，其实都应该是一致性的。关于这一点，SOA和已被市场接受的的Web Services真的是非常相象。简单地说，在任何一个商业环境中，SOA都是一项应用软件架构，其中所蕴含的服务模块或组件，全都相互独立地存在，用户只需运用经过事先定义的接口让它们相互联系，并依照一定的呼叫顺序，从而请求这些功能模块提供必要服务，就可构成极为完整的业务流程。而Web Services的问世，正好为SOA提供可行的标准，例如SOAP可用以建立服务请求，WSDL则用以发布服务请求，UDDI用于服务请求的目录表列治理，有了这些基础，将有助消除诸多软件供给商之间的歧异。需要说明的是，建构Web Services环境，虽然可以说是SOA的一个好的起点，但绝不等于SOA的全部。因为，SOA象征一种崭新的软件架构思维，超越了技术的范畴，自然不会被设限于如Web Services等单一技术之框架，亦有可能借助其他技术的力量。譬如，有能力将许多分布式运算资源加以集结的“网格运算”技术，就可能对SOA所需的服务组件动态定位、负载均衡或治理等事宜，产生非常大的帮助。目前业界所谈论的SOA，似乎都太过侧重中间件软件平台导向，殊不知一个完整的SOA架构，除需涵盖有关业务流程的整合环节外，也需要人员和后端信息的整合，还需要具备开发工具、ESB（服务总线），唯有这些组件做到环环相扣，才称得上是水到渠成。