从看构件图形化软件组装的趋势覆盖

一、SCA的概念 　　SCA(Service Component Architecture)面向服务的组件模型，源于IBM 的WSIF (Web Service Invocation Framework，具体请参考，SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用(这一点与EOS的思路一致)。

服务组件模型(SCA)中提出了一些新的概念，比如服务组件，模块，共享库，导入和导出。

服务组件　　包括对外提供的接口，所依赖的接口。服务组件的接口类型可以是Java类型，也可以是WSDL定义。例如一个“客户服务”组件，可能包括“获得客户基本信息”、“获得客户帐单”、“新建客户”等接口。这些接口的实现可能是WSDL描述的，也可能是用Java类实现的。服务组件的实现对外是透明的，调用者无需知道该服务是如何实现，以及采用什么技术实现的。

模块(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的址：。

关于服务组件模型(SCA)更详细的概念参见IBM DW站(的介绍。

二、 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无疑走在了潮流的前面。

查看本文来源