对普元EOS支持SCA/SDO规范的讨论

   首先声明，本人是一名严谨的IT领域的科研人员，是依据我看到的客观事实，就事论事来地写这篇评论的，尽力避免夹杂个人过于偏颇的观点。即使是基于同样的事实，很多人的观点都会不太一样，我想这可以大家共同讨论，我相信真理是越辩越明的。

        本人长期从事软件工程方面的研究工作，对SOA架构及其编程模型规范SCA（Service Component Architecture）和SDO（Service Data Objects）非常感兴趣，并一直在跟踪这方面的技术发展。经过IBM、微软、BEA等大厂商大力推广和宣传SOA理念，以及相关的开发平台和工具的推出，使SOA架构已经成为面向业务编程的主流架构和业界的事实标准。

业界的主要厂商（IBM, BEA, SUN, IONA, Oracle, SAP等厂商）为了建立一种与具体实现语言无关的面向SOA的编程模型，并且在工作中能够一起共享研究成果并进行合作，建立了非官方的Open SOA组织，简称OSOA（www.osoa.org），OSOA不是标准化组织，只有在规范成熟之后，再提请标准化组织（应该是OASIS组织）正式发布为业界标准。

SCA和SDO规范是面向SOA编程的两个重要规范，Open SOA组织于2007年3月份推出了SCA 1.0规范（下载地址为），2006年11月推出了SDO 2.1规范，下载地址为：

http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications

http://www.osoa.org/display/Main/Service+Data+Objects+Specifications

在OSOA和OASIS-OpenCSA（www.oasis-opencsa.org）网站上惊喜地发现了国内厂商普元也是这两个组织的成员之一，说明国内厂商在参与标准化方面的意识还是很强的。

         于是充满好奇地下载了一份普元EOS 5.2的试用版来看看，安装过程还比较顺利，根据安装提示很快就装完了，没有出现什么卡壳的事情，在Windows开始菜单的程序组中有EOS Server，EOS Studio，三个URL：工作流客户端，管理控制台和用户权限管理。

缺省的EOS Server采用了一个内置的JBoss 3.2.5，EOS的服务功能由jboss-3.2.5/server/default/deploy中的eos4jboss提供。

先把EOS Server运行起来，然后运行EOS Studio，EOS Studio基于Eclipse做了一些插件。运行Studio没有问题，启动时的Splash图片也做的比较漂亮，看起来很清爽，只是启动时间较长，可能启动时要调入的插件太多了。

启动完之后，第一件事就是新建一个项目project1，里面有四个目录：pkg、LIB模块、WEB模块、引用构件包。首先当然是看看EOS宣称的强项，对SCA和SDO的支持，这也是我感兴趣的地方。

用右键点击pkg目录下的各个子包，看看能新建一些什么，巡视一圈后就初步明白了，pkg目录下的各个子包就是对不同类型组件的分类。在不同的子包下分别新建了一些组件做了一个简单的体验，在开发方法上总体感觉还是有些新颖的，与传统的开发方法有很大的区别，可以通过可视化的拖拉方式来实现业务逻辑，就像IBM的开发工具的BPEL可视化组装服务组件一样。

研究新事物的好奇心驱使着我开始深入研究通过EOS Studio开发出来的成果，在项目的目录中用文本编辑工具逐个打开每个新建的组件来查看。结果是越看越疑惑，怎么我在EOS Studio中创建的各种组件没有一个可以和我所知的SCA/SDO规范对上号呢？下面对几个EOS Studio中创建的组件及组件库做一个剖析。

•    运算逻辑组件

运算逻辑组件放在bizlet包中，是最底层的实现代码，新建的时候提供一个对话框来添加运算逻辑，但是在产生代码之后，就不能再打开可视化的设计对话框了，只能编辑源码，在这点上感觉使用不方便。

与运算逻辑组件对应的是一个同名的XML文件，描述了组件中的运算逻辑。下面是EOS中产生的对运算逻辑组件com.test.MyCompLet中的comp1运算逻辑的描述范例：

 

 

从该XML中可以看出，该组件的描述方式与SCA规范毫无相同之处，完全是普元公司自己定义的一套。

•    业务逻辑组件

业务逻辑组件是粗粒度的组件，由运算逻辑组件以及其它业务逻辑组件组成，在EOS中是通过Studio工具以绘图的方式完成，有些像可视化的BPEL组装服务一样。

通过EOS提供的模板创建了一个业务逻辑组件bizFileCallBizLogic：

 

  其对应的描述放在bizFileCallBizLogic.bzg文件中，这也是一个XML文件：

 

 

 

从复合组件及其组装描述来看，该组件的描述方式与SCA规范也毫无相同之处，又完全是普元公司自己定义的一套。

•   组件库

在项目中有一个“引用构件包”，是EOS缺省提供的。根据项目文件系统的中的引用描述文件（project1/reference/.reference）可以知道引用了基础构件库和工作流构件库：

 

费了一番周折，定位出EOS缺省提供的构件库所在的位置：primeton/ide/eostools/eclipse/plugins/com.primeton.studio.eosserver_5.2.0/lib中。每个构件库由两个文件组成：EPP文件和JAR文件，EPP文件是压缩格式的构件库描述文件，JAR文件是构件库的实现类。

用WinRAR将EPP文件打开，发现里面所有的构件描述方式都是普元公司自己定义的特有描述格式，与SCA规范毫无相同之处。以构件库中的业务组件BNBASEDT_T_ParamValue为例：

该组件的描述文件放在business.epp文件中：

其对应的BZA文件就是一个XML描述：

从该例子中可以看出，EOS构件库中的组件也不是符合SCA规范的。

SCA规范没遵守，现在剩下SDO规范了，基于没有遵守SCA规范的事实，怀着忐忑的心情来看看SDO规范的实施情况。
在自己建的项目中找了一圈，发觉似乎只有在pkg/data中才能建立数据模型。从右键菜单中可以看出可以建立“数据树”，
我想可能就是SDO规范中的DataGraph吧，于是试着建了一棵树：

结果令人失望，其对应的XML文件为：

这也是EOS所特有的描述方式，与SDO规范毫无关系。

另外，在编辑数据树时遇到一个问题，不知是否为EOS的BUG，里面出现了两个node1。
通过对EOS 5.2的简单试用，感受是复杂，从最初的令人心动到后来的令人失望，作为建立SCA/SDO规范
的主要厂商之一，竟然不按照规范做事。看到普元公司网站上轰轰烈烈的SOA、SCA宣传，虽然这些宣传工
作对在国内推广SOA、SCA是有益的，但是当看到其产品的内在东西之后，会令人更加觉得失望。

通过在网络上发表此文章，希望能够帮助广大的开发者能够从各种不同的角度来看问题，以理性的态度
来看待EOS产品。同时，我也希望普元公司能够尽早实实在在地把产品做好，希望国内唯一的SCA规范参与
制定者能够把事情做到实处，不要只搞一些务虚的东西，借用规范之名，套用概念，而行自己专有的一套。

我个人认为，按照EOS产品目前的现状，在EOS平台上进行构件积累对用户来说是危险的，因为这些所
谓的构件是不符合SCA和SDO规范的，只能绑定在EOS平台中使用，积累的构件无法在其它真正支持SCA/SDO
规范的开发平台中使用，对用户的长期价值何在？

另外，对于EOS平台中的XML总线，本人也有一些看法，XML数据总线的思想应该还是不错的，但是在多服务
器集群的环境中可能会存在一些问题，由于XML数据总线本质上是一块XML对象树的内存区，在集群环境中实现不
同服务器之间的XML数据总线状态同步是比较低效的，并且XML数据总线中是动态的数据，不是静态的，需要在全
局事务控制之下来维持不同服务器之间的XML数据总线状态同步，实现技术更为复杂，会进一步降低效率。作为底
层核心的XML数据总线在大规模、高并发的集群应用环境中是不合适的，就像在集群环境中不推荐使用Stateful 
Session Bean一样。

期望本土领先的构件平台厂商能够走上正确的、符合行业规范的轨道。

附录1：SCA规范中的基本概念及范例

Services：组件对外部提供的功能。

References：该组件对其它组件的依赖性。
Properties：通过设置属性值来对组件进行配置。
Implementation：通过具体技术实现的软件实体，例如Java, Spring, BPEL, C++, PHP, XSLT。通过组装实现的复合组件也是一种组件的实现方式。
Wire：连接References和Services。
Binding：Services和References使用的交互机制，例如WSDL binding, JMS binding, EJB Session bean binding。

 

SCA复合组件概念图

 

Interface：描述了业务功能（business function），例如java interface, WSDL portType。

ComponentType：描述了组件的实现，包含所有的references, services, properties。

ConstrainingType：根据references, services, properties描述组件外观的模板，不包含组件的具体实现，制定了组件之间交互的契约，SCA运行环境会基于ConstrainingType来校验组件的实现是否符合契约。

Autowiring：基于interfaces, bindings, policy intents/sets方面的兼容性，具有依赖关系的服务组件可以自动连接服务（component references to be wired to component services automatically, without explicit wires）。

Java Common Annotations：用于自动生成组件的componentType XML描述文档，包含Implementation annotations和Interface annotations。

Java Common APIs：涉及的方面有Component context，Request context，Callable reference，Service reference，Conversation，Exceptions。

 SCA Policy Framework：使组件能够通过配置的方式获得不同的QoS，包括Security、Transaction、Reliable messaging。

关于BPEL：与SCA是互补关系，BPEL可以用于组装SCA组件并实现新的SCA组件：

 

SCA组件打包的格式是ZIP，其它可用的打包格式是filesystem directory, OSGi bundle, JAR file。

下面是一个SCA组件的图形表示和XML描述：

 

附录2：SDO基本概念

SDO（Service Data Object）提供了一种描述数据的统一格式，SDO对SCA不是必要的，是可选规范。SDO作为一种数据交换标准格式可以用于很多场合。下面的UML图是SDO中的主要组成部分：

                           SDO的UML图

 

 

SDO可以将异构的数据源及其数据格式统一起来：