基于SCA规范的服务框架设计与实现

基于SCA规范的服务框架设计与实现<o:p></o:p>

Author: 岑文初<o:p></o:p>

Email: [e-mail]<o:p></o:p>

Version: 0.1<o:p></o:p>

Date: <st1:chsdate isrocdate="False" month="7" day="1" islunardate="False" w:st="on" year="2007" style="BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x">2007-07-01</st1:chsdate><o:p></o:p>

概述... 2<o:p></o:p>

SCA的简单介绍... 3<o:p></o:p>

SCA & OSGI 4<o:p></o:p>

Tuscany, First Demo. 5<o:p></o:p>

Mail Composite Demo. 5<o:p></o:p>

基于Tuscany实现内嵌服务框架定制... 9<o:p></o:p>

一点感想... 10<o:p></o:p>

<o:p> </o:p>

概述<o:p></o:p>

       SCA（Service Component Architecture）是针对SOA提出的一套服务体系构建框架协议，内部既融合了IOC的思想，同时又把面向对象的复用由代码复用上升到了业务模块组件复用，同时将服务接口，实现，部署，调用完全分离，通过配置的形式灵活的组装，绑定。

       从代码级的面向对象思想，到组件级的EJB概念，再到服务级的SOA理念，是一个开发复用的不断提升的过程，经历的经验教训正在给实践做出最好的指导。SOA提倡的就是更高级别的复用，服务的复用，Internet提供了开放的环境，但是没有一种统一的服务访问模式，让各个企业之间成了信息内部丰富的孤岛，需要将这些孤岛串联起来，同时要最大限度的复用有限的资源，因此提出了面向服务概念，但是多年的SOA口号下却缺少着一个真正的实施标准和解决方案，因此SOA的理论传播大于实际实施。<o:p></o:p>

       SCA和SDO的出现，给SOA来了点实际的。SCA（Service Component Architecture）其实就是将过去EJB的成果继续下去，基于Component的复用，同时吸收了IOC的思想，Component之间的组装是通过SCA框架来实现的，但是很重要的一点，他没有走EJB的老路，而是学习spring的轻量级框架，不再为开发者作的面面俱到。SCA的Component和OSGI的Bundle一样其实是对Java封装的一种贯彻，它有需要Import的服务引用，需要Export的服务，很重要一点就是它对于Component，service,reference的实现都没有作限制，这类对象只需要有个接口定义和实现描述即可，当前规范中支持的接口定义可以是java接口也可以是wsdl文件（最终也是转换成为java接口），实现的话那么更加广泛java,webservice,rmi,jms,脚本语言等等，同时提供了扩展接口。<o:p></o:p>

SCA的简单介绍<o:p></o:p>

OSOA（Open Service Oriented Architecture）针对SOA实现提出了一系列技术框架规范，其中包括了两大部分：SCA（Service Component Architecture）和SDO（Service Data Objects）。SCA旨在解决使用各种不同的实现来创建面向服务的组件，以及如何将创建的组件装配和发布，满足业务流程需求的开发和部署。SDO提供给应用开发一套完整的数据处理方案，数据源及其格式将对应用处理透明。这两者可以分开使用也可以一起配合使用。http://www.osoa.org/display/Main/Home 是SCA的官方网站，里面现在提供了两部分项目的规范定义文件。

       SCA最基本的结构单元就是Component，SCA Composite将多个Component包含定义在内，组成了完整的业务模块单元。下面就是Component基本结构单元的结构图，后面会对这个基本单元的各个部分作详细的描述：

<v:shapetype o:spt="75" coordsize="21600,21600" filled="f" stroked="f" id="_x0000_t75" path=" m@4@5 l@4@11@9@11@9@5 xe" o:preferrelative="t"><v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0 "></v:f><v:f eqn="sum @0 1 0 "></v:f><v:f eqn="sum 0 0 @1 "></v:f><v:f eqn="prod @2 1 2 "></v:f><v:f eqn="prod @3 21600 pixelWidth "></v:f><v:f eqn="prod @3 21600 pixelHeight "></v:f><v:f eqn="sum @0 0 1 "></v:f><v:f eqn="prod @6 1 2 "></v:f><v:f eqn="prod @7 21600 pixelWidth "></v:f><v:f eqn="sum @8 21600 0 "></v:f><v:f eqn="prod @7 21600 pixelHeight "></v:f><v:f eqn="sum @10 21600 0 "></v:f></v:formulas><v:path o:extrusionok="f" o:connecttype="rect" gradientshapeok="t"></v:path><o:lock v:ext="edit" aspectratio="t"></o:lock></v:shapetype><v:shape coordsize="21600,21600" id="_x0000_i1025" type="#_x0000_t75" style="WIDTH: 414.75pt; HEIGHT: 257.25pt"><v:imagedata src="10C657F8.files/image001.emz" o:title=""></v:imagedata></v:shape>

图 1  SCA Component结构图

<o:p> </o:p>

Composite通常都有一个xxx.composite文件用来描述Composite的结构以及每一个Component的实现，接口，服务，引用的定义。

<v:shape coordsize="21600,21600" id="_x0000_i1026" type="#_x0000_t75" style="WIDTH: 414.75pt; HEIGHT: 495.75pt"><v:imagedata src="10C657F8.files/image003.emz" o:title=""></v:imagedata></v:shape>

图 2  SCA Composite结构图

<o:p> </o:p>

SCA & OSGI<o:p></o:p>

基于OSGI的开发首先要求就是基于接口开发，任何业务模块的开发，都需要将业务操作抽象成为一系列的接口定义（通常就成为最基本的Interface Specification Bundle），业务间的调用都是通过接口调用来实现的，也支持IOC来注入接口。

<v:shape coordsize="21600,21600" id="_x0000_i1027" type="#_x0000_t75" style="WIDTH: 415.5pt; HEIGHT: 236.25pt"><v:imagedata src="10C657F8.files/image005.emz" o:title=""></v:imagedata></v:shape>

图 3  OSGI 模块间交互情况

       OSGI容器类似于Spring容器，负责装载以及装配各个定义好的Bundle，各个Bundle都有自己的import和export的接口包，具体的实现对彼此都是透明的，容器支持动态的装载和卸载各个实现Bundle的，这样就做到了对业务无影响的情况下就可以切换不同的业务实现。同时接口化编程能够被更好的贯彻，模块与模块之间只能通过模块间的业务接口来互相访问对方的业务信息，降低了耦合度。

但是也可以看出OSGI适合单机部署的应用开发，其实就本身OSGI的设计初衷就不是考虑跨服务器多机部署的情况，因此不适合作为平台的服务框架。但是对于需要单机部署的一些特殊业务实现（例如Job服务，当前实现了Job接口的定义以及Quartz的实现）就可以采取这种方式，不过如果不是需要切换实现，那么不是很体现的出OSGI的特性。

记得在论坛上有人讨论过SCA和OSGI的优劣，但其实作为这两个规范面向的解决问题都是不同的，SCA是SOA的一个实现，SOA是解决分布式服务的互通问题，而OSGI是针对单机服务的动态绑定义及组装，因此两者不存在着可比性，但是在我看来，两者却有着很好的互补性，在平台的现有情况下，用SCA来实现服务框架，同时通过OSGI来实现组件装配，这无疑是很好的一件事情。

<st1:place w:st="on"><st1:state w:st="on">Tuscany</st1:state></st1:place>, First Demo<o:p></o:p>

OSOA提出的SCA只是一个规范，因此包括BEA，IBM等大公司的平台都有相应的技术实现，而Tuscany是Apache孵化项目中的一个实现了SCA,SDO的规范的开源项目（http://incubator.apache.org/tuscany/home.html）。最新的版本是基于SCA 规范 v1.0版本而实现的SCA Java 0.90-incubating，当然它还提供了C++的版本。

Mail Composite Demo<o:p></o:p>

       开发SCA的组件和java开发普通的业务模块没有什么区别，只是在业务逻辑代码开发完以后需要将逻辑实现以及需要发布和引用在配置文件中定义和描述。下面分别是MailComposite的Java类图以及SCA组件的结构图。

<v:shape coordsize="21600,21600" id="_x0000_i1028" type="#_x0000_t75" style="WIDTH: 381pt; HEIGHT: 319.5pt"><v:imagedata src="10C657F8.files/image007.emz" o:title=""></v:imagedata></v:shape>

图 5  Mail Composite的基本类图

<v:shape coordsize="21600,21600" id="_x0000_i1029" type="#_x0000_t75" style="WIDTH: 417pt; HEIGHT: 459.75pt"><v:imagedata src="10C657F8.files/image009.emz" o:title=""></v:imagedata></v:shape>

图 6  Mail Composite组件结构图

Mail.composite具体的内容如下：

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"  targetNamespace="http://mail"<o:p></o:p>

              xmlns:wsdli="http://www.w3.org/2004/08/wsdl-instance"  name="Mail" ><o:p></o:p>

    <!—- 组件级别的服务定义，这个定义可以被不同的composite引用，也就是它的作用域为服务框架，promote表示这个服务由内部哪个具体的component或者component级别的service实现，也就是这里只是一个声明的部分，实现参看最后的MailCustomerComponent --><o:p></o:p>

    <service name="MailCustomerService" promote="MailCustomerComponent"/><o:p></o:p>

    <component name="MailComponent"><o:p></o:p>

         <implementation.java class="com.alisoft.sample.tuscany.MailServiceImpl"/><o:p></o:p>

<!— 此service标签是component级别的服务，内部可以组装，但是无法跨composite，作用域为composite内 --><o:p></o:p>

<service name="MailService"> <o:p></o:p>

     <!-- 服务接口描述 --><o:p></o:p>

              <interface.java interface="com.alisoft.sample.tuscany.MailService"/><o:p></o:p>

         </service><o:p></o:p>

         <!—- 组件的引用，可以是另一个component也可以是component级别的service --><o:p></o:p>

         <reference name="postOfficeService" target="PostOfficeComponent"/><o:p></o:p>

    </component><o:p></o:p>

    <component name="PostOfficeComponent"><o:p></o:p>

        <implementation.java class="com.alisoft.sample.tuscany.PostOfficeServiceImpl"/><o:p></o:p>

    </component><o:p></o:p>

    <component name="RetailStoreComponent2"><o:p></o:p>

        <implementation.java class="com.alisoft.sample.tuscany.RetailStoreServiceImpl"/><o:p></o:p>

    </component><o:p></o:p>

    <component name="RetailStoreComponent"><o:p></o:p>

    <service name="RetailStoreService"><o:p></o:p>

     <!—- 发布成为webservice的服务，设定绑定的地址，需要有wsdl文件的配合（将wsdl描述文件打入包，接口的描述可以是wsdl，也可以是java类型的接口） --><o:p></o:p>

         <interface.wsdl interface="http://mail#wsdl.interface(RetailStoreServicePortType)" /><o:p></o:p>

         <binding.ws uri="http://localhost:8085/RetailStoreService"/><o:p></o:p>

     </service><o:p></o:p>

        <implementation.java class="com.alisoft.sample.tuscany.RetailStoreServiceImpl"/><o:p></o:p>

    </component><o:p></o:p>

     <!—Composite级别的reference，指明是提供给谁的这里是提供给MailComponent的retailStoreService的，绑定的是内部那个发布成为webservice的component，注意component内部可以作为组装对象 --><o:p></o:p>

     <reference name="RetailStoreReference" promote="MailComponent/retailStoreService"><o:p></o:p>

         <interface.java interface="com.alisoft.sample.tuscany.RetailStoreService"/><o:p></o:p>

        <binding.ws wsdlElement="http://mail#wsdl.port(RetailStoreService/RetailStoreServiceSOAPPort)"/><o:p></o:p>

     </reference> <o:p></o:p>

     <component name="MailCustomerComponent"><o:p></o:p>

         <implementation.java class="com.alisoft.sample.tuscany.MailCustomerService"/><o:p></o:p>

         <reference name="customerService"/><o:p></o:p>

     </component><o:p></o:p>

     <!—- 这是Composite级别的引用，需要通过promote指定是提供给哪个具体Component的引用，promote表示的就是提供给哪一个Component的引用