SOA 大讨论

 SOA 大讨论

－、国内发展现状和应用需求
    SOA几乎已经成为企业应用架构的主流，从2006年6月22日计算机世界“中间件应用年会”上可以看出，大部分主题演讲都涉及到SOA的应用和部署问题，IBM当前不仅以服务商的角色介入SOA，而且在此次大会上还带来了众多的SOA的成功实施案例；BEA公司也定位于SOA平台提供商，并且推出了一系列产品和方案；国内软件企业，像中创、东方通科技以及金蝶、用友、科诺等公司也在不同程度地切入SOA工具或解决方案的开发。种种迹象表明，SOA已经超越概念走向应用，并逐渐形成一股不可阻挡的潮流。


二、Web Services开源热火朝天
1.Web Services开源项目
    作为SOA一种主要实行方式的Web Services，其开源项目正如火如荼。

    Java6 发布，支持XML&WebService, JDK就直接支持Web Services了。这样Sun强势参与Web Services的竞争。这种现象很有趣，各大厂商在各自强项之间互相渗透，Sun被Apache Harmony项目所逼，被一些厂商要求两年后，将JDK开源，但同时也给IBM、BEA、Oracle等厂商反戈一击，在刚发布的JDK 6中捆绑Web Services。

    Axis2和XFire是最火的两个Web Services开源项目，但其他的项目也做得不错。

XFire
Celtix
Mule
Apache Axis2
Apache CXF
    XFire和Celtix合并，在Apache下形成的一个新的孵化项目。
Apache Ode
    是一个WS-BPEL实现
Apache Rampart
    是一个WS-Security实现
Apache Sandesha2
    是一个WS-ReliableMessaging实现
Apache Tuscany
    是一个SCA实现。
Apache ServiceMix
    是一个JBI实现。

Eclipse的STP（SOA Tooling Project）子项目
此Eclipse项目旨在提供一个其他开发人员可以使用的SOA开发工具框架，以便使他们不必自己开发这些工具。

2.Web Services开源项目特点：
    1)各项目侧重点有些不一样，还互相引用，交流甚多，人员合作也较多。不像Sun JDK开源和Apache Harmony，Apahce Geronomy和JBOSS等几乎重叠，正面冲突。

    2)这些项目都支持Spring的Bean配置或扩展Spring的接口，和Spring集成。可见Spring火爆程度。不同开源社区不断融合，互相吸引人气。
    3)使用工具的变化
    版本管理工具由cvs变为subversion
    build工具由ant变为maven
    4)众多开源社区中Apache的人气最旺
    有意思的是，很多开源项目在别的小社区发展到2.0, 3.0版本后还不遗余力地迁移到Apache, 如ServiceMix从Codehaus搬到Apache，Codehaus的XFire和objectweb的Celtix合并后，乔迁到Apache。它们甚至甘愿接受Apache社区的规定：需要一段时间的修炼才能从孵化器中毕业。

3.微软Indigo
    说了这么多JAVA阵营的Web Services项目，还得提一下巨人微软的策略。
    Indigo是微软用于构建面向服务应用程序的代号，后被正式命名为Windows Communication Foundation。Indigo允许目前创建面向对象应用程序的开发人员采用 .NET Framework以相似的方式来创建面向服务的应用程序。同时为了让这些应用程序能够与运行在 Windows 和其他平台上的软件有效地进行交互，Indigo 还实现了SOAP和其他Web服务技术，这样开发人员就可以创建可靠、安全且能够与运行在任何系统上的软件实现互操作的事务型服务。

为了实现基本通信以外的功能，Indigo 采用了一些更新的WS-* 规范。这些文档定义了用于添加可靠消息传输、安全性、事务以及更多基于 SOAP 的 Web 服务的多供应商方式。所有这些规范最初均是由 Microsoft、IBM 及其他供应商共同制定的。随着它们日渐稳定，所有权通常会转移到一些标准机构，如结构化信息标准促进组织 (OASIS)。Indigo 第一版中支持的 Web 服务规范包括 WS-Addressing、WS-Policy、WS-MetadataExchange、WS-ReliableMessaging、WS-Security、WS-Trust、WS-SecureConversation、WS-Coordination、WS- AtomicTransaction 和 SOAP 消息传输优化机制 (MTOM)。

    Indigo已经包含在Vista之中。

    目前Web Services的实现分为两大阵营，一是微软，一是Java厂商。这两大阵营实现Web Services规范的产品都在互相进行互操作性测试。


三、这一年各开源项目广泛实现的web services规范
    括弧里的开源项目支持前面的规范及其新版本。

SOAP 1.2（Axis2 1.1）
WSDL 2.0（XFire 1.2.2）
JAX-WS 2.0（Celtix 1.0）
WS-Policy（Axis2 1.1）
MTOM（Axis2 1.1）
XOP（Axis2 1.1）
WS-RM（Celtix 1.0、Apache Sandesha2、Axis2 1.1）
WS-Addressing（Axis2 1.1、Celtix 1.0）
WS-Security（Apache Rampart、Axis2 1.1）
SAAJ 1.1（Axis2 1.1、Celtix 1.0）
JBI（ServiceMix 3.0.1，Celtix 1.0仅集成，XFire 1.2.2仅集成，Mule）
SCA（Tuscany）
WS-BPEL（Apache Ode、ServiceMix 3.0.1）


四、争论与融合
1. SOAP和REST正走向融合
    基于SOAP和WSDL的Web Services规范多而复杂，虽然它是标准的，但是用户头疼，学习曲线陡而长，应用构建时间长。简单就是美，易用性是金。在java企业应用开发领域， EJB的没落，Spring框架的兴起和流行印证了这一规律。同样，在SOA领域这一规律也已起作用，兴起了另一种简单的实现——REST，虽然它不是标准的。

    其实REST和SOAP各有所长。REST简单、易用，与互联网思想一脉相承，核心思想是资源共享、面向资源的Web Services。而SOAP是广为接受的标准，在互操作性方面，解决复杂的系统集成方面优势明显，其核心思想是面向活动的Web Services。

    以前，REST和SOAP的争论异常激烈。如google选择SOAP；而Amazon 85％的web services应用采用REST，15％采用SOAP。

    但慢慢地厂商变得越来越聪明，逐步摆脱理论上的争论，看重实际的接受度。如微软的Web Services项目Indigo去年底宣布支持REST；Apache Axis2同时支持SOAP协议栈和REST，而且二者可互相通讯。
    同时，SOAP族的Web Services规范新版本开始支持REST的特性（http get/post）,如WSDL 2.0和SOAP 1.2

    真所谓分久必合，合久必分。SOAP和REST正走向融合。
       
2. JBI和SCA之争
    SUN阵营支持JBI，而BEA、IBM、SAP、SIEBEL支持SCA。随着7月初SUN公司的加入SCA/SDO国际构件标准组织，标志着Sun将逐步放弃自己的JBI，预示着Java和JavaEE将在未来五年内逐渐退出‘解决客户关键问题的主流技术’的地位。
    其实不少JBI和JCA专家组的成员更倾向于JBI，但是IBM等不喜欢SUN控制JAVA，不愿看到将来SUN控制SOA的商业应用。其实JBI是好东西，被牺牲了。不过，SUN如果早点将JDK开源，避垄断JAVA之嫌，就不会这么孤立。


3. JAX-WS2.0 替换JAX-RPC 1.1
    JAX-WS2.0即Java API for XML Web Services (JAX-WS) 2.0，JAX-RPC 1.1即Java API for XML-Based RPC (JAX-RPC) 1.1。它们都是sun公司的使用 Java 技术开发 Web 服务的规范，前者是后者的升级版本。
    JAX-WS2.0的binding层用JAXB（JSR 222），xml解析层用StAX（JSR 173），完全基于标准，性能得到大幅提升；支持Java 5的注释（annotation），容易开发。
   


五、总结
1. SOA是未来企业的IT应用模式
    而在SOA创造的商业世界里，企业将有机会像玩积木（网络服务构件就是积木）游戏一样创造崭新的商业模式，从不同厂商购买网络服务，编排和组装自己的应用。IT的收费方式不是整个产品，也不是按CPU、license收费，而是按网络服务调用次数收费。灵活、总体拥有成本将大大降低，将注意力集中于自身的商业逻辑。
    同时，经历十几年、二十几年的IT建设，企业拥有了各种各样的系统，c++、java、c、cobra写的各种各样的遗留系统，保护企业以前的投资，构建出新的应用，这样的需求越来越多、越来越强烈。而这正是SOA发挥作用的舞台，SOA可提供跨平台、跨语言的、可扩展的、可靠和安全的网络服务。
    Gartner预测，到2008年，75%的新企业应用将采纳SOA。

2. ESB（企业服务总线）的淡出
     ESB这一概念将会淡出，SOA治理、策略（policy）和SOA Network、SOA Repository正在兴起。

3. SOA应用趋势
总结一句，SOA的应用大潮将至，SOA中间件产品的竞争越来越激烈。IBM 11月1日宣布在北京和印度成立SOA全球解决方案中心。这标志着SOA应用竞争的升级。
 ---------------------------------------------------------------------------------------------------------------------------------------------

不客气地说一句，我读过的所有国内的有关SOA的论述，都是完全不得要领。这反映了国内软件业根深蒂固的RPC情结。与之相对应的有趣现象就是对消息机制（Messging）和XML技术的漠视。

楼主的第二条结论：“2. ESB（企业服务总线）的淡出“，不知根据何在？没有数据总线,服务如何串联成系统？又是RPC?

---------------------------------------------------------------------------------------------------------------------------------------------------

由于整个SOA话题很大，ESB（企业服务总线）的淡出这一点没有展开阐述。其实这是2006年的大趋势之一。这里补充一下。

ESB仅仅是web services的client和server(称端对端更准确)互相talk的stack，包括SOAP消息的封装和解包，传输和协议的处理等。ESB是web services的基础，长久都需要。所以2005年(包括2005年)以前众厂商和开源风风火火地做了很多ESB产品。

但是，随着SOA实际应用的不断深入，厂商们发现仅仅有ESB是远远不够的。

随着SOA应用规模的增长，一个大企业的service几十甚至成百上千，不同service可能部署到不同厂商的container(ESB)，安装在不同的地点(如北京和纽约，或北京上海)，不同service有不同的访问权限，不同的service有不同的policy(日志级别，安全，权限，传输和协议)，怎样管理service及其属性，怎样方便的查找和发现service等等，这些问题就浮出水面，迫在眉睫。这催化了SOA治理、策略（policy）和SOA Network、SOA Repository的兴起。

以前有UDDI产品和网站，但UDDI只是简单的查找和发现service，不能满足上一段话描述的管理service的众多需求。

------------------------------------------------------------------------------------------------------------------------------------------------

不是想得远啊，是很多国际知名厂商在实实在在地做这方面的产品，是多年在客户那里实施SOA后产生的实际需求。

感觉国内还在炒SOA的概念，而且还是国外以前流行的概念，如ESB等。而对Web Services的深入的东西不甚关注，如SOAP消息机制和相关XML技术(XPath、XLST、Schema), 如SOAP消息优化传递机制(MTOM)，可靠消息传递(WS-ReliableMessaging)，消息路由(CBR、WS-Addressing等)，事务(WS-Transaction)，安全(WS-Security)，管理(WS-Policy、SOA Network)。这些都是SOA的企业应用要解决的问题，而且都是有标准也有国际大厂商的很多实现和大量高质量的开源实现(其实这些开源也大多有知名厂商的背后支持)。

网友：pingpangsong 出自 JavaEye