时间：2022-08-11 02:46:05
自SCA/SDO规范于2005年面世以来，已经产生了大量基于这两个规范开发的产品，其中有着OSOA联盟支持厂商研发的自主产品，也有大量来自于社区的优秀项目，他们在各自的领域分别实现了开放SOA的标准。
OSOA于2007年3月份了SCA 1.0 和SDO 2.1 规范，并已经提交到OASIS标准组织，为SOA的正式落地揭开了序幕。关于SCA和SDO规范本身以及规范产生的背景和意义，已经有很多资料进行了大量的介绍，本文主要对基于SCA和SDO而实现的开源以及商业产品进行分析。
SCA和SDO的开源产品目前并不太多，主要有Apache Tuscany、Eclipse STP（SOA Tools Platform）、PECL SOA for PHP、CodeCauldron Newton等几个项目。这些开源产品中，尤其以Apache旗下的Tuscany和Eclipse旗下的STP最为引人注目。
基于SCA和SDO的商业产品目前已经有不少，包括IBM WPS/WAS、AquaLogic Data Services Platform、TIBCO ActiveMatrix、 Rogue Wave HydraSCA、Covansys SCA Framework for SOA和Infiniflow DSF等。
这些商业产品基本都是基于SCA或者SDO的早期版本实现，而最新的SCA 1.0 版本变化非常大，因此严格而言，目前市场上还没有真正符合SCA 1.0和SDO 2.1规范的产品出现。
另一方面，这些SCA、SDO商业产品本身还处于一种试验状态，产品功能也不是很完善，因此使用这些产品实施SOA（基于SCA/SDO）的用户还比较少。
Apache Tuscany项目
Tuscany是Apache Incubation的一个开源项目，主要开发人员来自IBM和BEA。Tuscany出身于皇家血统（OSOA联盟），可以算是SCA和SDO的最正宗的开源项目了。与Eclipse STP相比，Tuscany提供的只是一个SOA基础设施，包括SCA运行时环境、SDO和DAS实现，Tuscany项目本身并不提供SOA开发和管理IDE插件。
Eclipse STP项目
STP（SOA Tools Platform）是由IONA、IBM、BEA、Sybase和ObjectWeb等公司贡献的开源项目，并于2005年成为Eclipse的第九个顶级开源项目。STP目前尚未有正式的版本。
根据项目计划，STP将于2007年6月29号Europa版（中文意思为“木卫二”，木星最亮的四颗行星之一）。Europa版即是原来的Callisto版。
1.STP的目的与任务
SOA越来越受到软件供应商、行业客户和开发人员的推崇，SOA的前景也可以说是一片大好。但是SOA目前的现状是，一方面SOA本身没有统一的标准，另一方面实施SOA也没有统一的工具。随着SCA和SDO规范的推出，STP项目也应运而生，SCA/SDO0.9规范于2005年11月，STP项目于2005年12月诞生。
STP的目的一方面是为了统一SOA应用的开发、部署和管理工具，并使这些工具标准化;另一方面就是提供一个可扩展的SOA应用工具集，包括为开发人员提供构建服务、部署服务和维护服务的工具集，为架构设计师提供装配（Assemble）SOA基础设施的工具集，为系统管理人员提供维护、监控、和策略管理的工具集。
从上述目的可以看出，STP几乎涵盖了SOA应用的全生命周期，包括设计、开发、测试、部署、维护和治理。在SOA项目生命周期中的每个角色都能在STP中找到对应的工具。
2.STP的项目范围
对于实施一个SOA项目，从工具层面，会涉及到设计、开发、测试、部署工具;从管理方面，会涉及到QoS、服务水平协议（SLA Services Level Agreement）、生命周期管理、版本管理;从消息和传输协议层面，会涉及到SOAP、JMS、JDBC、HTTP、SMTP和RMI等;从基础服务方面，会涉及到安全、可靠性、事务、异步和服务编排;从应用层面，会涉及到移动应用、门户、商业流程、遗留系统和本地应用，如图1所示。
从STP的范围而言，STP强调扩展能力，强调Framework，强调SCA和提供SCA的工具插件。而Tuscany是提供基础设施的SCA/SDO运行时环境，因此STP与Tuscany有着很好的互补性。
3.STP的子项目
由于STP涵盖的范围非常宽泛，因此STP被划分为5个子项目，分别包括以下几个项目，如图2所示。
SOA System(SOAS)，提供SOA系统的打包、构建、配置、部署和管理工具与框架;
Services Creation(SC)，服务创建;
Core Framework(CF)，STP的核心模型和框架;
BPMN（Business Process Modeling Notaion），BPMN的 编辑器与框架;
BPEL 2 Java(B2J )，BPEL到Java的转换器。
4.STP项目的现状
从STP的规划而言，是一个非常全面的SOA应用实施工具和框架。从STP项目今年4月9号编译的一个All in one Eclipse插件所提供的功能而言，开发人员想要使用STP进行SOA项目的开发，还要等待一些日子。
在这个版本中，只提供了一些简单的SOA应用开发、部署功能，包括JAX-WS和SCA项目的创建向导，BPMN和WDSL的图形化编辑器，SCDL（SCA Defition Language）编辑器、部署文件编辑器等。对于SCDL编辑器甚至基本上就是一个XML编辑器。对于服务装配、服务注册以及服务库，将会在Europa以后的版本中提供支持。
可以预见，不久以后，STP将完全实现规划中的功能，并成熟稳定的版本。
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。
1.WPS对SCA的支持
IBM在2005年10月了WPS （Websphere Process Server）6.0版本 ，并为SCA构件的开发和部署提供了可视化的集成开发工具WID（Websphere Integration Developer）。使用WID开发集成项目，只要有一定基础编程经验或知识，就可以拖拉的方式，通过图形化的方式进行SCA构件的装配，以及Web Service服务的开发。
2.WAS对SCA/SDO的支持
IBM于2006年上半年推出WAS 6.1的SOA补丁版，以支持SCA和SDO。 这个版本通过Tuscany提供SCA和SDO规范的实现的。这些新的特性只是测试版，正式的特性将会包含在WAS 7.0 中。
普元（Primeton）EOS
普元软件作为国内惟一一家参与SCA/SDO规范制定的公司，将在其产品的下一个新版本EOS6.0中全面支持SCA 1.0和SDO2.1规范，EOS6.0预计将于2007年底β版，2008年春季正式版，并同时提供免费社区版。
普元EOS 6.0采用全新的产品架构和实现，基于SCA、SDO等标准化技术，以面向构件（COA）、面向服务（SOA）为导向的一体化企业级基础应用平台。EOS6.0为实施SOA应用提供了从构件设计、开发、调试、部署、应用监管、维护与升级的全生命周期管理功能。
同时，EOS还通过“基础应用框架”提供了一套Web框架、菜单与组织机构权限管理功能，使得应用开发不再从零开始。此外，EOS提供的符合SCA规范的基础构件库大大提高了软件的复用度，保证了SOA应用实施的质量。
1.EOS的构件模型
EOS构件模型的核心是“业务构件”（也就是SCA规范中的Composite），业务构件是EOS部署的基本单元，如图3所示。一个业务构件可以由不同的“服务构件（对应SCA规范中的Component）”装配而成。在EOS中，服务构件可以由Java、JMS、EJB、WebService和BPEL实现，甚至可以是通过一个图形实现（称为“EOS服务构件”，这是EOS对SCA规范的扩充）。
在一个业务构件中，还定义了该构件与其它构件之间的依赖和引用关系。业务构件通过接口来体现构件对外提供的“Service”，接口的参数类型既可以是普通的Java类型（POJO），也可以是SDO的DataObject类型。
2.图形化的SCA构件设计
EOS提供双向设计支持，提供可视化的构件设计（包括Composite的接口设计、Composite依赖和引用关系设计、Composite的装配设计），既支持从业务视角出发的TopDown设计方式，也支持BottomUp的传统设计方式。
架构一致性保证设计模型与实现模型完全相同，因此模型和实现之间的一致性能自动得到保证。设计可验证在设计的同时即可检验模型的正确性，大幅度节省设计时间，也保证了设计阶段的质量。
3.图形化的SDO设计
EOS通过图形化的方式进行域模型设计，并支持每个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所带来的利益。