??xml version="1.0" encoding="utf-8" standalone="yes"?>
Q、国内发展现状和应用需?br /> SOA几乎已经成ؓ企业应用架构的主,?006q??2日计机世界“中间g应用q会”上可以看出Q大部分主题演讲都涉及到SOA的应用和部v问题QIBM当前不仅以服务商的角色介入SOAQ而且在此ơ大会上q带来了众多的SOA的成功实施案例;BEA公司也定位于SOAq_提供商,q且推出了一pd产品和方案;国内软g企业Q像中创、东斚w科技以及金蝶、用友、科诺等公司也在不同E度地切入SOA工具或解x案的开发。种U迹象表明,SOA已经越概念走向应用Qƈ逐渐形成一股不可阻挡的潮流?br />
二、Web Services开源热火朝?br />1.Web Services开源项?br /> 作ؓSOA一U主要实行方式的Web ServicesQ其开源项目正如火如荼?br />
Java6 发布Q支持XML&WebService, JDKq接支持Web Services了。这样Sun强势参与Web Services的竞争。这U现象很有趣Q各大厂商在各自强项之间互相渗透,Sun被Apache Harmony目所|被一些厂商要求两q后Q将JDK开源,但同时也lIBM、BEA、Oracle{厂商反戈一击,在刚发布的JDK 6中捆lWeb Services?br />
Axis2和XFire是最火的两个Web Services开源项目,但其他的目也做得不错?br />
XFire
Celtix
Mule
Apache Axis2
Apache CXF
XFire和Celtix合ƈQ在Apache下Ş成的一个新的孵化项目?br />Apache Ode
是一个WS-BPEL实现
Apache Rampart
是一个WS-Security实现
Apache Sandesha2
是一个WS-ReliableMessaging实现
Apache Tuscany
是一个SCA实现?br />Apache ServiceMix
是一个JBI实现?br />
Eclipse的STPQSOA Tooling ProjectQ子目
此Eclipse目旨在提供一个其他开发h员可以用的SOA开发工hӞ以便使他们不必自己开发这些工兗?br />
2.Web Services开源项目特点:
1)各项目侧重点有些不一Pq互相引用,交流甚多Qh员合作也较多。不像Sun JDK开源和Apache HarmonyQApahce Geronomy和JBOSS{几乎重叠,正面冲突?br />
2)q些目都支持Spring的Bean配置或扩展Spring的接口,和Spring集成。可见Spring火爆E度。不同开源社Z断融合,互相吸引人气?br /> 3)使用工具的变?br /> 版本理工具由cvs变ؓsubversion
build工具由ant变ؓmaven
4)众多开源社ZApache的h气最?br /> 有意思的是,很多开源项目在别的社区发展到2.0, 3.0版本后还不遗余力地迁UdApache, 如ServiceMix从Codehaus搬到ApacheQCodehaus的XFire和objectweb的Celtix合ƈ后,乔迁到Apache。它们甚至甘愿接受ApacheC的规定:需要一D|间的修炼才能从孵化器中毕业?br />
3.微YIndigo
说了q么多JAVA阵营的Web Services目Q还得提一下巨人微软的{略?br /> Indigo是微软用于构建面向服务应用程序的代号Q后被正式命名ؓWindows Communication Foundation。Indigo允许目前创徏面向对象应用E序的开发h员采?.NET Framework以相似的方式来创建面向服务的应用E序。同时ؓ了让q些应用E序能够与运行在 Windows 和其他^C的Y件有效地q行交互QIndigo q实CSOAP和其他Web服务技术,q样开发h员就可以创徏可靠、安全且能够与运行在Mpȝ上的软g实现互操作的事务型服务?br />
Z实现基本通信以外的功能,Indigo 采用了一些更新的WS-* 规范。这些文定义了用于d可靠消息传输、安全性、事务以及更多基?SOAP ?Web 服务的多供应商方式。所有这些规范最初均是由 Microsoft、IBM 及其他供应商共同制定的。随着它们日渐E_Q所有权通常会{Ud一些标准机构,如结构化信息标准促进l织 (OASIS)。Indigo W一版中支持?Web 服务规范包括 WS-Addressing、WS-Policy、WS-MetadataExchange、WS-ReliableMessaging、WS-Security、WS-Trust、WS-SecureConversation、WS-Coordination、WS- AtomicTransaction ?SOAP 消息传输优化机制 (MTOM)?br />
Indigo已经包含在Vista之中?br />
目前Web Services的实现分Z大阵营,一是微软,一是Java厂商。这两大阵营实现Web Services规范的品都在互相进行互操作性测试?br />
三、这一q各开源项目广泛实现的web services规范
括弧里的开源项目支持前面的规范及其新版本?br />
SOAP 1.2QAxis2 1.1Q?br />WSDL 2.0QXFire 1.2.2Q?br />JAX-WS 2.0QCeltix 1.0Q?br />WS-PolicyQAxis2 1.1Q?br />MTOMQAxis2 1.1Q?br />XOPQAxis2 1.1Q?br />WS-RMQCeltix 1.0、Apache Sandesha2、Axis2 1.1Q?br />WS-AddressingQAxis2 1.1、Celtix 1.0Q?br />WS-SecurityQApache Rampart、Axis2 1.1Q?br />SAAJ 1.1QAxis2 1.1、Celtix 1.0Q?br />JBIQServiceMix 3.0.1QCeltix 1.0仅集成,XFire 1.2.2仅集成,MuleQ?br />SCAQTuscanyQ?br />WS-BPELQApache Ode、ServiceMix 3.0.1Q?br />
四、争Z融合
1. SOAP和REST正走向融?br /> ZSOAP和WSDL的Web Services规范多而复杂,虽然它是标准的,但是用户头疼Q学习曲UK而长Q应用构建时间长。简单就是美Q易用性是金。在java企业应用开发领域, EJB的没落,Spring框架的兴起和行印证了这一规律。同P在SOA领域q一规律也已起作用,兴v了另一U简单的实现——RESTQ虽然它不是标准的?br />
其实REST和SOAP各有所ѝREST单、易用,与互联网思想一脉相承,核心思想是资源共享、面向资源的Web Services。而SOAP是广为接受的标准Q在互操作性方面,解决复杂的系l集成方面优势明显,其核心思想是面向活动的Web Services?br />
以前QREST和SOAP的争论异常激烈。如google选择SOAPQ而Amazon 85Q的web services应用采用RESTQ?5Q采用SOAP?br />
但慢慢地厂商变得来聪明,逐步摆脱理论上的争论Q看重实际的接受度。如微Y的Web Services目Indigod底宣布支持RESTQApache Axis2同时支持SOAP协议栈和RESTQ而且二者可互相通讯?br /> 同时QSOAP族的Web Services规范新版本开始支持REST的特性(http get/postQ?如WSDL 2.0和SOAP 1.2
真所谓分久必合,合久必分。SOAP和REST正走向融合?br />
2. JBI和SCA之争
SUN阵营支持JBIQ而BEA、IBM、SAP、SIEBEL支持SCA。随着7月初SUN公司的加入SCA/SDO国际构g标准l织Q标志着Sun逐步攑ּ自己的JBIQ预C着Java和JavaEE在未来五年内逐渐退出‘解军_户关键问题的L技术’的C?br /> 其实不少JBI和JCA专家l的成员更們于JBIQ但是IBM{不喜欢SUN控制JAVAQ不愿看到将来SUN控制SOA的商业应用。其实JBI是好东西Q被牺牲了。不q,SUN如果早点JDK开源,避垄断JAVA之嫌Q就不会q么孤立?br />
3. JAX-WS2.0 替换JAX-RPC 1.1
JAX-WS2.0即Java API for XML Web Services (JAX-WS) 2.0QJAX-RPC 1.1即Java API for XML-Based RPC (JAX-RPC) 1.1。它们都是sun公司的?Java 技术开?Web 服务的规范,前者是后者的升版本?br /> JAX-WS2.0的binding层用JAXBQJSR 222Q,xml解析层用StAXQJSR 173Q,完全Z标准Q性能得到大幅提升Q支持Java 5的注释(annotationQ,Ҏ开发?br />
五、ȝ
1. SOA是未来企业的IT应用模式
而在SOA创造的商业世界里,企业有Z像玩U木Q网l服务构件就是积木)游戏一样创造崭新的商业模式Q从不同厂商购买|络服务Q编排和l装自己的应用。IT的收Ҏ式不是整个品,也不是按CPU、license收费Q而是按网l服务调用次数收贏V灵zRM拥有成本大大降低,注意力集中于自w的商业逻辑?br /> 同时Q经历十几年、二十几q的ITQ企业拥有了各种各样的系l,c++、java、c、cobra写的各种各样的遗留系l,保护企业以前的投资,构徏出新的应用,q样的需求越来越多、越来越强烈。而这正是SOA发挥作用的舞収ͼSOA可提供跨q_、跨语言的、可扩展的、可靠和安全的网l服务?br /> Gartner预测Q到2008q_75%的新企业应用采USOA?br />
2. ESBQ企业服务ȝQ的淡出
ESBq一概念会淡出QSOAȝ、策略(policyQ和SOA Network、SOA Repository正在兴v?br />
3. SOA应用势
ȝ一句,SOA的应用大潮将臻ISOA中间件品的竞争来激烈。IBM 11?日宣布在北京和印度成立SOA全球解决Ҏ中心。这标志着SOA应用竞争的升U?br />
]]>
JBI Q?/span> Java ?/span> Business Integration Q是一U企业服务ȝ (Enterprise Service Bus,ESB) Q用于Ş成一U关键基设施片段Q我们能够?/span> Java 实现面向服务的架构,主要目的是提供一个基于服务的q_作ؓ对现?/span> Java/J2EE q_功能的扩展?/span>
当前?/span> J2EE 部v都运行在一个基上,那就是应用服务器。应用服务器本n׃个独立的部分l成 ——Servlet 容器?/span> EJB 容器Q它们分别用于部|?/span> JSP/Servlets ?/span> EJB 构g。在它们中的M一个,你都能?/span> Web services 。但是,在Q何环境中以分散的方式使用 services 是很困难的工作,?/span> JBI 的目的就是ؓ完成q个d提供一个专门的环境。其最底层是一个容器,它与 J2EE 中的容器一样定义了自n的部|构件?/span>
JBI 提供了一U正规消息\由器 (Normalized Message Router,NMR) Q说白了Q就是一个地炏V在q个地点Q所有基于消息的数据片段 ——SOAP 片段?/span> MOM 消息?/span> HTTP 数据或其它信?/span> —?/span> 被聚合、集中、应用到业务逻辑、传输,如果有必要则被{换成其它格式q后被分派到最l目的地?/span>
JBI 很适合企业U应用,因ؓ它通过一Uȝ型架构的Z消息的手D到达了适应大范围的消费者和提供者的目的。现在,让我们看看除?/span> NMR q有什么构成了 JBI ?/span>
?/span> JBI 环境直接交互的是两个部分Q?/span> JBI machine ?/span> JBI binding ?/span> JBI machine 定义了部|构件以及在环境中管理它们的方式。本质上Q它是提供商设计的黑盒,用于?/span> JBI 中支持他们自q模型。另一斚wQ?/span> JBI binding 则被环境通过专门的业务协议与外部世界q行通信?/span>
JBI 是提供了一些简单的 API 定义Q?/span> q些定义包括 NormalizedMessage Service , 在一?/span> Router lgQ以及一个管理模型用来管理服务的部v集成Q例?/span> routing engines, BPEL engines, rule systems, transformation engines
JBI 提供了一个逻辑?/span> XML 消息|络Q?/span> q一|络能够很容易的映射?/span> HTTP, email ?/span> JMS/MOM Qƈ很方便地适应遗留pȝQ二q制C输,?/span> RPC pȝQ?/span> EJB ?/span> CORBA) ?/span> JBI 可以看做是对 JMS 的更高层ơ的逻辑抽象Qƈ提供了不同的消息交换方式Q?/span> 单步Q?/span> h应答{)
2
?/span>
SCA
服务构g架构 SCA Q?/span> Service Component Architecture Q致力于Z用广泛的~程语言来构造服务构件提供一U编E模型,q且也ؓ把这些服务构件组装ؓ一个业务上的解x案提供了一U模型,q种l装的活动正是采用面向服务的架构 (service-oriented architecture) 来搭建应用系l的核心?/span>
SCA 为徏讑֟于面向服务的体系l构的应用和pȝ提供了一U编E模型。这Z一U观点,即业务功能以一pd服务的Ş式被对外提供出来Q然后它们被l合在一起去实现满特定业务需求的解决Ҏ。这些复合的应用Q可以包含专门ؓ此应用程序创建的新服务,也可以包含来自已有的pȝ和应用程序的业务功能Q重复利用就像其中的一部分一栗?/span> SCA 即ؓl合服务提供了模型,也ؓ服务构g的创建,包括?/span> SCA l装中重用已有应用系l的功能提供了模型?/span>
在服务定义中Q?/span> WSDL Q?/span> Web Service Description Language Q是一个很好的范例?/span> WSDL 在增强应用之间的可连接性以及互操作性方面迈Z一大步。然而, WSDL 只关注了服务接口Q它q不提供描述一个服务所依赖的其它服务,以及q个服务所需要用的配置{略和服务之间的依赖关系。单独通过 WSDL 很难实现服务之间的组合调用?/span>
SCA ?/span> WSDL 走的更远的方面是定义了一个服务组件模型以及一个服务组装模型。服务模型提供了?/span> WSDL 更多的功能,它允许服务开发者不单定义服务的接口而且q可以定?/span> q个服务和其他服务的依赖关系Q以及这些交互(事务Q安全,以及可靠 传输Q之间的{略 q有服务所可能提供的配|功能?/span>
一?/span> SCA 模型对等于一?/span> SOA 目Q模型允许开发者组装一l服务组Ӟ解决引用依赖和用策略。这是一个很大的q步Q因为当前的 SOA q_需要开发者自p取那些私有的服务部v引用Q甚x时要在他们的服务实现中写 hard code.
3
?/span>
SCA
?/span>
JBI
的区?/span>
SCA x的重点只?/span> SOA 开发所看到和接触到的?/span> SCA q没有关注用来执?/span> SCA 模块的引擎是如何构架的。只是对q个引擎的实现提供一个规范和实现依据。这个引擎可以用M方式实现?/span>
JBI 从另一个方面来说就是一l关注创Z个开发的Q可扩展的以及标准组件的企业服务ȝ?/span> q样它的内核是和 SCA 有一些重合的地方。同时两者之间也存在互补的机制?/span>
重合斚wQ是 JBI x的是如果一l引擎组装ƈq行于一?/span> JVM 中,是对~码开发的一U设计方式?/span> 相反 SCA 在另一斚wq不一个模块约束单?/span> JVM 中。当然一?/span> SCA 模块可以执行在一?/span> JVM 中,但同时它也可以很方便的将q些引擎部v在不同的q程甚至是不同的节点上?/span>
最大的区别之处?/span> SCA 不但支持 Java 而且q支?/span> C ?/span> EJB ?/span> Spring ?/span> BPEL Q在今后也许q会支持 C# Q?/span> php {?/span> ?/span> JBI 只是 SCA 的一个实现方式,而不是唯一的选择?/span>