SCA与SDO的开源与商业产品浅析

        OSOA于07年3月份发布了SCA1.0 和SDO2.1 规范，并已经提交到OASIS标准组织，为SOA的正式落地揭开了序幕。关于SCA（Service Component Architecture）和SDO规范本身以及规范产生的背景和意义，已经有很多资料进行了大量的介绍，本文主要对基于SCA和SDO而实现的开源以及商业产品进行分析。

　　SCA和SDO的开源产品目前并不太多，主要有Apache Tuscany、EclipseSTP（SOATools Platform）、PECL SOAfor PHP、CodeCauldron Newton等。这些开源产品中，尤其以Apache旗下的Tuscany和Eclipse旗下的STP最为引人注目。

　　基于SCA和SDO的商业产品目前已经有不少，包括IBM WPS/WAS、AquaLogic Data Services Platform、TIBCO ActiveMatrix、 Rogue Wave HydraSCA、Covansys SCAFramework for SOA、Infiniflow DSF等。这些商业产品基本都是基于SCA或者SDO的早期版本实现，而最新发布的SCA1.0 版本变化非常大，因此严格的说，目前市场上还没有真正符合SCA1.0和SDO2.1规范的产品出现。另一方面，这些SCA、SDO商业产品本身还处于一种试验状态，产品功能也不是很完善，而且使用这些产品来实施SOA（基于SCA/SDO）的用户还比较少。

　　一、Apache Tuscany

　　Tuscany是Apache Incubation的一个开源项目，主要开发人员来自IBM和BEA。Tuscany出身于皇家血统（OSOA联盟），可以算是SCA和SDO的最正宗的开源项目了。与EclipseSTP相比，Tuscany提供的只是一个SOA基础设施，包括SCA运行时环境、SDO和DAS实现，Tuscany项目本身并不提供SOA开发和管理IDE插件。

　　关于Tuscany的分析请参见杨洪波的文章“SOA与开源双剑合一（http://www.primeton.com/about/read.php?id=576&his=1）”。

　　二、EclipseSTP

　　STP（SOATools Platform）是由IONA、IBM、BEA、Sybase、ObjectWeb等公司贡献的，并于2005年成为Eclipse的第九个顶级开源项目。STP目前尚未有正式的版本release，最新的稳定版是07年2月1号发布的（S200702011041）。根据项目计划，STP将于07年6月29号发布Europa版（中文意思为“木卫二”，木星最亮的四颗行星之一，与木星的距离排在其卫星的第七位，最早为伽俐略观测到）。Europa版即是原来的Callisto版。

　　1、STP的目的与任务

　　SOA越来越受到软件供应商、行业客户和开发人员的推崇，SOA的前景也可以说是一片大好。但是SOA目前的现状是，一方面SOA本身没有统一的标准，另一方面实施SOA也没有统一的工具。随着SCA和SDO规范的推出，STP项目也应运而生（SCA/SDO0.9规范05年11月发布，STP项目05年12月）。

　　STP的目的一方面是为了统一SOA应用的开发、部署和管理工具，并使这些工具标准化；另一方面就是提供一个可扩展的SOA应用工具集，包括为开发人员提供构建服务、部署服务和维护服务的工具集；为架构设计师提供装配（Assemble）SOA基础设施的工具集；为系统管理人员提供维护、监控、和策略管理的工具集。

　　从以上目的来看，STP几乎涵盖了SOA应用的全生命周期，包括设计、开发、测试、部署、维护和治理。在SOA项目生命周期中的每个角色都能在STP中找到对应的工具。

　　2、STP的项目范围

　　对于实施一个SOA项目，从图1可以看出，从工具层面，会涉及到设计、开发、测试、部署工具，从管理方面，会涉及到QoS、服务水平协议（SLA Services Level Agreement）、生命周期管理、版本管理；从消息和传输协议层面，会涉及到SOAP、JMS、JDBC、HTTP、SMTP、IIOP、RMI等；从基础服务方面，会涉及到安全、可靠性、事务、异步和服务编排；从应用层面，会涉及到移动应用、门户、商业流程、遗留系统和本地应用。

　　图 1 STP项目的范围

　　对于STP项目，其范围为图-1中的Tools和Management两部分（图中紫色和黄色区域），主要包括：

　　1)STP提供可扩展的SOA应用工具平台；

　　2)STP的关键能力包括：服务的设计、配置、装配、开发、监控和管理；

　　3)STP的关键规范是SCA和WSDL；

　　4)STP的原则是尽可能的复用其它Eclipse项目的技术，如WTP、DTP、SDO；

　　5)STP着重于框架

　　i.保持供应商中立

　　ii.提供可扩展的架构，并且可以鼓励三方和商业扩展。支持SOA系统（SOAS）中部署的服务的编辑、创建和配置工具的扩展；

　　6)STP还要提供扩展能力，以支持一些开源的运行时容器，比如Tuscany, Celtix, ServiceMix, OSS JEE 或任何其它支持SCA的容器；

　　7)STP会实现并支持SCA装配模型。在创建服务方面，STP目前只支持SCAJava客户端规范（SCAClient and Implementation Model Specification for Java）

　　从STP的范围来看，STP强调扩展能力，强调Framework，强调SCA，提供SCA的工具插件。而Tuscany是提供基础设施的SCA/SDO运行时环境，因此STP与Tuscany有着很好的互补性。

　　3、STP的子项目

　　由于STP涵盖的范围非常大，因此STP被分成了5个子项目，包括：

　　SOASystem(SOAS)：提供SOA系统的打包、构建、配置、部署和管理工具与框架

　　Services Creation(SC)：服务创建

　　Core Framework(CF)：STP的核心模型和框架。

　　图 2 STP子项目

　　BPMN（Business Process Modeling Notaion）：BPMN的 编辑器与框架。

　　BPEL2 Java(B2J )：BPEL到Java的转换器。

　　1)SOASystem （SOAS）：

　　SOAS提供服务的装配、构建、部署、打包和管理的工具和框架。

　　策略编辑器以及赋值工具。

　　系统校验工具。

　　可扩展的包profile编辑器（包括profile模型）。

　　可扩展的包生成器。

　　可扩展的部署profile文件编辑器（包括profile模型）

　　依赖管理工具：对服务或者包之间的依赖进行管理。

　　测试与调试：测试和调试主要使用Eclipse的TPTP。

　　2)Services Creation（SC）

　　负责服务的创建，包括创建服务的编辑器、绑定编辑器以及服务发现工具。其中创建服务编辑器支持SCA构件和模块的创建，接口编辑器（借助于WTP的WSDL编辑器实现），Composite编辑器、资源生成向导（如项目、SCA构件等），SCA构件的Component Type文件编辑器。绑定编辑器主要是对传输协议和消息格式的编辑器。

　　在07年4月9号编译的一个All in one版本中，提供了对JAX-WS和SCA两种服务的生成工具。Europa版发布以后将会支持PHP和C++语言的服务创建。

　　3)Core Framework（CF）

　　CF是STP项目的核心框架与模型，提供核心的API主要包括：SCA服务装配的EMF模型，访问和创建装配模型，支持Java语言的SCA构件，SCA模型的扩展（如服务的绑定和实现类型Implentation Type扩展），校验，以及服务的引用和依赖管理等。

　　4)BPMN

　　BPMN项目提供BPMN（Business Process Modeling Notation）的编辑器以及框架。Europa版将支持BPMN建模功能。BPMN使用EMF作为对象模型，图形编辑器基于GMF实现，对象模型以XMI格式持久化。

　　STP BPMN模型可以生成与BPEL2.0兼容的模型，因此可以利用BPMN来实现对多个SCA构件的编排，从而生成一个新的SCAComposite构件。

　　图 3 BPMN

　　5)BPEL2 Java（B2J）

　　B2J子项目是集成框架的一个参考实现，提供了一个标准的BPEL运行时框架，以及BPEL到Java的转换器（即根据BPEL模型生成可以运行的Java代码），并允许Java BPEL编译后运行在任何STP所支持的运行环境中。Europa版将集成BPEL编辑器。

　　BPEL与WebService之间的关系比较紧密，对于国内的电信、银行等行业用户而言，对BPEL的性能还抱着怀疑的态度，因此不敢冒然大规模使用。另外，BPEL（包括BPMN）解决的主要是集成问题，而国内的集成市场还很小。这些都是造成BPEL或BPMN在国内得不到大规模应用的原因。

　　4、STP项目的现状

　　从STP的规划上看，是一个非常全面的SOA应用实施工具和框架。从STP项目今年4月9号编译的一个All in one Eclipse插件所提供的功能来看，开发人员想要使用STP进行SOA项目的开发，还要等待一些日子。

　　在这个版本中，还只提供了一些简单的SOA应用开发、部署功能，包括JAX-WS和SCA项目的创建向导，BPMN和WDSL的图形化编辑器，SCDL（SCADefition Language）编辑器、部署文件编辑器等。对于SCDL编辑器甚至基本上就是一个XML编辑器。对于服务装配、服务注册以及服务库，将会在Europa以后的版本中提供支持。

　　可以预见，STP要完全实现规划中的功能，并发布成熟稳定的版本，还需要等到08年。

　　三、CodeCauldron Newton

　　Newton是Paremus公司Infiniflow Distributed Service Framework (DSF) 产品的一个开源版本，它是基于GPL协议的，这意味着如果你对Newton源代码做了修改，修改后的代码也需要免费开放给第三方使用，并需要将修改后的源代码反馈给Newton项目。

　　Newton是一个分布式的构件框架，它用SCA标准来描述分布式系统，并且提供了高度动态的SCA实现（基于OSGi技术）。它能够加载和管理部署在分布不同JVM中的SCA构件。

　　Newton借鉴了Spring的分离关注思想，将域模型和基础设施分离，提供了一个轻量级的分布式构件开发模型。对于分布式模型，面临的最大问题来自于网络状态不稳定、不可预见的系统失效，以及分布式系统的管理（如部署问题、资源释放等）问题。Newton使用OSGi和Jini来解决这些问题。OSGi是Newton整个构件模型的中心，而Jini则是其远程基础设施的基石。

　　四、IBM WPS和WAS

　　IBM是SCA和SDO倡导者和大力支持者，在当前市场上公开发布的所有商业产品中，IBM是对SCA和SDO规范支持最全面的厂商。IBM对SCA的产品支持包括WPS6.0和WAS 6.1。

　　IBM WPS对SCA的支持

　　IBM在2005年10月发布了WPS （Websphere Process Server）V6.0 ，并为SCA构件的开发和部署提供了可视化的集成开发工具WID（Websphere Integration Developer）。使用WID开发集成项目，只要有一定基础编程经验或知识，就可以拖拉的方式，通过图形化的方式进行SCA构件的装配，以及Web Service服务的开发。

　　IBM WAS6.1 对SCA/SDO的支持

　　IBM于06年上半年推出了WAS 6.1的SOA补丁版，以支持SCA和SDO。 这个版本是通过Tuscany来提供SCA和SDO规范的实现的。这些新的特性只是α版，正式的特性将会包含在WAS 7.0 中。

　　在SCA0.9方面实现的特性：

　　1）POJO来实现服务以及Web Services绑定

　　2）支持标记（Annotaions）

　　3）支持HttpSession范围的构件

　　4）提供了HelloWorld以及BigBank样例程序

　　在SDO2.0的实现的特性：

　　1)动态DataObject的支持

　　2)基本的静态代码生成

　　3)支持静态DataObject

　　4)实现了一些帮助类，如XMLHelper、XSDHelper、TypeHelper等

　　5)最小化的ChangeSummary支持

　　DAS（对关系数据库的）支持：

　　1）通过SDO对数据库的CRUD操作

　　2）存储过程支持

　　3）优化的并发控制

　　4）数据库自动生成主键

　　5）通过SDO变更历史来驱动对数据的更新

　　五、普元（Primeton）EOS

　　普元软件作为国内唯一一家参与SCA/SDO规范制定的公司，将在其产品的下一个新版本EOS6.0中全面支持SCA1.0 和SDO2.1 规范，EOS6.0预计将于07年底发布β版，08年春季发布正式版，并同时提供免费社区版。

　　普元EOS 6.0采用全新的产品架构和实现，基于SCA、SDO等标准化技术，以面向构件（COA）、面向服务（SOA）为导向的一体化企业级基础应用平台。EOS6.0为实施SOA应用提供了从构件设计、开发（调试）、部署、应用监管、维护与升级的全生命周期管理功能。同时，EOS还通过“基础应用框架”提供了一套Web框架、菜单与组织机构权限管理功能，使得应用开发不再从零开始。另外，EOS提供的符合SCA规范的基础构件库大大提高了软件的复用度，保证了SOA应用实施的质量。

　　1、EOS的构件模型

　　EOS构件模型（如下图）的核心是“业务构件”（也就是SCA规范中的Composite）。业务构件是EOS部署的基本单元。一个业务构件可以由不同的“服务构件（对应SCA规范中的Component）”装配而成。在EOS中，服务构件可以由Java实现的，JMS实现，EJB实现，WebService实现，BPEL实现，甚至可以是通过一个图形来实现的（称为“EOS服务构件”，这是EOS对SCA规范的扩充）。

　　图 4 EOS 构件模型

　　在一个业务构件中，还定义了该构件与其它构件之间的依赖和引用关系。

　　业务构件通过接口来体现构件对外提供的“Service”，接口的参数类型既可以是普通的Java类型（POJO），也可以是SDO的DataObject类型。

　　2、图形化的SCA构件设计

　　提供双向设计支持：提供可视化的构件设计（包括Composite的接口设计、Composite依赖和引用关系设计、Composite的装配设计），既支持从业务视角出发的TopDown设计方式，也支持BottomUp的传统设计方式。

　　架构一致性保证：设计模型与实现模型完全相同，因此模型和实现之间的一致性能自动得到保证。

　　图 5 双向构件设计

　　设计可验证：在设计的同时即可检验模型的正确性，大幅度节省设计时间，也保证了设计阶段的质量。

　　3、图形化的SDO设计：通过图形化的方式进行域模型设计，并支持每个DataObject之间的关联关系（包括单向和双向的1：1，1：n，n：1，n：n关联）。

　　4、图形化的SCA构件组装与调试：对于EOS服务构件，其实现是基于一系列基础构件，通过图形化的组装来实现的。由于采用了图形化的组装方式，因此对构件的调试也是通过图形化的方式进行的。对于绝大多数应用，都可以采用图形化的组装方式来实现一个构件，而无需手工编写代码。

　　六、总结

　　爱因斯坦曾经说过，“事情应该尽可能简单，而不是更简单”。SCA和SDO由于简化了编程，统一了对构件的访问方式，随着SCA、SDO等规范的日渐完善，以及SCA和SDO标准化进程的推进，加上行业用户对SOA的了解逐渐深入和客观，SOA将逐渐从概念阶段转到真正的标准化时代。随着这个时代的来临，SCA、SDO的开源和商业产品也会越来越多，越来越好。对于使用SOA进行应用实施的设计人员、开发人员、系统管理人员、行业用户等，都将享受异常SOA盛宴，并最终获得SOA所带来的利益。