SCA(Service Component Architecture)面向服务的组件模型，源于IBM 的WSIF (Web Service Invocation Framework，具体请参考http://ws.apache.org/wsif/)，SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用(这一点与EOS的思路一致)。
服务组件模型(SCA)中提出了一些新的概念，比如服务组件，模块，共享库，导入和导出。
- 服务组件
包括对外提供的接口，所依赖的接口。服务组件的接口类型可以是
- 模块(Module)
模块是由多个服务组件以及服务之间的调用关系组成的，每个模块相当于J2EE应用中的一个项目。通过将不同的“服务组件”用连线组装起来，就成为一个模块。模块是最小的部署单元。
- 共享库(Library)
如果多个Module需要共享一些资源，则可使用共享库。但是共享库不包括服务组件(即不包括业务逻辑)，只包括数据定义、接口定义、数据映射等。
- 导入(Import)
目的是为了调用其它组件(包括SCA组件、JMS、WS等)
- 导出(Export)
与导入相反，导出是为了让其它系统可以调用SCA组件，调用方式同样可以是SCA组件、JMS、WS等。
目前，SCA模型已经得到了业界几个主要软件厂商的支持。IBM、Oracle、BEA、SAP、Siebel、Sybase、IONA等厂商联合发布了SCA规范的0.9版本。具体规范可参见IBM DW的网址：http://www.ibm.com/developerworks/library/specification/ws-sca/。
关于服务组件模型(SCA)更详细的概念参见IBM DW网站(http://www-128.ibm.com/developerworks/cn/webservices/ws-sca/)的介绍。
二、 IBM对SCA的产品支持
SCA服务组件模型的提出，解决了EJB、POJO等组件模型与实现语言相关的问题，同时也将SOA的抽象概念落到了实处。也为集成软件项目的
目前IBM对SCA的产品支持为2005年10月发布的WPS (Websphere Process Server)6.0 ，并为之提供了可视化的集成开发工具WID(Websphere Integration Developer)。使用WID开发集成项目，只要有一定基础编程经验或知识，就可以拖拉的方式，进行图形化的组装，不需要了解太多的J2EE技术细节。
三、 EOS与SCA的对比
从上文，可以看出，SCA的这些概念在EOS里几乎都有相类似的概念。对比如下(以IBM的WID产品为例)：
- SCA中的概念EOS中的
- 相应概念相同点不同点
服务组件业务构件
1、都是描述后台业务逻辑;
2、都提供了接口
1) EOS中可以用图形化的方式定义业务逻辑的实现;而且EOS还提供了展现构件、运算构件等;
2) SCA服务组件则要么通过WSDL调用已经开发好的具体组件，要么用编写特定语言的代码来实现
模块项目、构件包都是可部署的单元
1、EOS中的构件包、单个构件都是可部署单元
导入引用构件包都是为了复用已有软件
1、EOS的引用构件包可引用EOS的任何构件，包括展现、业务、数据、运算构件
2、SCA的导入只能复用业务逻辑
导出导出都是为了复用已有软件资产
1、SCA在导出时需要指定导出为SCA组件服务、JMS、WS等类型
2、EOS导出后被新的项目引用时，可以直接拖放组装
服务数据对象SDO数据实体
1、都是XML与RDB之间的映射
2、都支持Xpath访问
3、都是作为展现层、业务层与持久层之间通信的
1) SDO支持对象的嵌套
2) SDO除了可以Xpath访问，也可以对象的形式访问
3) 数据实体是EOS数据总线的基础
从上可看出，SCA的概念和EOS的一些概念大同小异，可以说是异曲同工。
四、 小结
诚然，SCA规范推出的目的是为了对遗留系统进行集成，EOS的定位则在于开发新的应用。虽然两者定位不同，但是不难看出，未来软件开发的趋势必然是朝着以图形化的构件组装的方向前进。EOS不仅提供了图形化的构件组装工具，同时在调试、部署、应用管理与维护方面都提供了一体化的工具，因此在构件化这一步，普元EOS无疑走在了潮流的前面。
用户评论