SOA 2006年终回顾以及2007展望（一）

－、国内发展现状和应用需求
    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应用竞争的升级。

评论

16 楼 abcgoup 2007-09-11  

<div class='quote_div'>写的太棒了，看过很多SOA方面的介绍，都是概念云杂，不知所云，这篇文章真是言简意赅。</div>
<div class='quote_div'/>
<div class='quote_div'>可是我目前正在做ESB，说具体点用的是ServiceMix，您说ESB淡出，JBI不如，SCA。</div>
<div class='quote_div'/>
<div class='quote_div'>现在心里好不踏实啊！</div>
<div class='quote_div'>难道我做的是要被淘汰的，真不愿意接受啊！～～<br/>
<br/>
<br/>
<br/>
</div>

15 楼 lsy 2007-09-10  

2007大半年过去了，Oracle确实还是很重视ESB，不过在IBM那里似乎已经淡出了

期待LZ的2007总结

14 楼 cglxa 2007-06-14  

楼主是个高手，在下佩服！
什么时候写出2007展望？翘首以待啊！

13 楼 coolfish 2007-01-18  

参看URL:http://servicemix.org/site/how-does-servicemix-compare-to-tuscany-or-sca.html

12 楼 coolfish 2007-01-18  

我也比较同意crosier的意见. jbi和sca有重叠的地方.但是两者并不是对立的竞争关系吧.

11 楼 pingpangsong 2007-01-03  

enhydra 写道

SOA　阵营里应该不能少了 SAP 这个ERP龙头吧
它的Netweaver 从2003 年就推出了

确实少不了SAP。这也引出一个问题（我引伸一下），ERP和SOA有什么关系，SAP凑什么热闹。毛新生先生有一篇blog对此有精彩的见解(http://mxs.blog.ccidnet.com/blog/ccid/do_showone/tid_32544.html)。我摘录部分段落如下：
－ERP作为企业应用的重要部分，提供企业经营管理活动方面的支持。也受到 SOA 这个新的发展方向的影响，你可以看到 SAP，Oracle　在SOA方面的一些动作　－－　他们都想用 SOA 的方式/风格来重构他们的打包软件，希望借此提供：跟企业其他软件系统更好、更便宜的集成，更好的概念抽象（ERP 相关的高层 service／business process／行业模型，而不是今天主要以数据驱动的方式－谁愿意在那１０，０００多张非常底层实现的表上折腾呢？）并在此基础上提供更好的可定制性、可变化能力、业务性能管理、风险控制、规范遵循等方面提供更好的支持。但这并不意味着 ERP 需要抛弃过去的东西完全重新实现，相反过去的东西在实现级别上是有效、可行的，需要增加的是一层粗粒度、商务层面上的抽象（也就是 SOA 所专注的层次，服务模型）
－企业其他的系统也可以采用 SOA 的方式来建设和相互集成，这些系统同 ERP 的集成和交互以 SOA 的方式／风格来进行

10 楼 crosier 2006-12-27  

SCA和JBI应该可以并存把，感觉他们不应该是竞争关系，JBI想是更底层技术面的，他提供了各种协议，系统之间的公共交换支持，然而如何开发业务模块确不是很明确。而SCA偏向于业务层面。我觉着可以把他们接合起来，程序员按照SCA标准开发具体业务模块。而架构师或框架开发人员来开发JBI组件实现SCA模块同其他模块的组装。
servicemix 有一个SCA组件，还没搞懂怎么用

9 楼 shaucle 2006-12-22  

KayMO 写道

pojo 写道

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

赫赫,正想问这个.
今后长时间ESB这个东西将会作为SOA比较核心的部分而存在,
并将更加完善,标准化,产品化.

俺看好ESB,WS的确是通用
但同样想想为什么流行的是XML，而不是SGML
还说不定等ESB不够用时，WS被新技术给取代．

8 楼 pingpangsong 2006-12-22  

pojo 写道

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

严重同意。

IBM在北京成立全球SOA方案中心了，明显瞄准即将开始的大规模SOA应用。国内应该做好准备，不能还是瞎子摸象，不能只空谈啊。

7 楼 pingpangsong 2006-12-22  

引用

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

想得真远,佩服:)


不是想得远啊，是很多国际知名厂商在实实在在地做这方面的产品，是多年在客户那里实施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的企业应用要解决的问题，而且都是有标准也有国际大厂商的很多实现和大量高质量的开源实现(其实这些开源也大多有知名厂商的背后支持)。

6 楼 KayMO 2006-12-20  

引用

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

想得真远,佩服:)

引用

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

从目前来看,UDDI还是个比较失败的产品

5 楼 pingpangsong 2006-12-18  

KayMO 写道

pojo 写道

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

赫赫,正想问这个.
今后长时间ESB这个东西将会作为SOA比较核心的部分而存在,
并将更加完善,标准化,产品化.

由于整个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的众多需求。

4 楼 KayMO 2006-12-18  

pojo 写道

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

赫赫,正想问这个.
今后长时间ESB这个东西将会作为SOA比较核心的部分而存在,
并将更加完善,标准化,产品化.

3 楼 pojo 2006-12-18  

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

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

2 楼 enhydra 2006-12-17  

SOA　阵营里应该不能少了 SAP 这个ERP龙头吧
它的Netweaver 从2003 年就推出了

1 楼 pingpangsong 2006-12-17  

这第一篇仅仅是SOA 2006年终回顾，侧重Web Services开源和规范，准备继续补充2006年终回顾，着手写2007展望。预计包括SOA 2.0以及推荐好书，各大厂商的策略，并展望2007年的Web Services开源及国内外应用。

不过写这种长篇的东东很浪费时间，预计下一篇出炉的时间晚一些。