<<  工作计划_SeraphZhang | 首 页 |

  • SOA中的Profile与基于SCA、SDO的实现部署（二）

    2006-07-14

    Tag：SOA技术导引 工作日志

    版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://nksoateam.blogbus.com/logs/2834901.html

    前面谈到了SOA中Profile的问题，我们了解到这个Profile是用来作为服务系统架构而设计的，它所关心的粒度是服务系统架构一级的，而对每个服务的具体技术组成、接口形式、绑定协议、数据类型都没有明确的定义，从实现部署的角度来说这些具体实现形式也是必要的，下面先来看看什么是SCA（Service Component Architecture）服务组件架构。

    SCA是一种新的与语言无关的服务组件编程模型，为所有服务组件提供统一的调用方式，使得客户可以把不同的组件类型采用同一标准进行封装。SCA的前身是WSIF（Web Service Invocation Framework），当然WSIF是Web Service领域的一个规范仅提供基于Java API调用各种服务的能力，没有形成架构模型，而SCA是在它的基础之上放宽了对实现细节的定义同时将关注点提升到系统架构层次。下图展示了SCA服务组件的基本结构，它是SCA的基本组成元素和基本构建单位，如图所示SCA服务组件的主要接口规范是基于WSDL的单同时部分服务组件也提供了Java接口，这样便于服务组件的客户端选择，服务组件提供的调用入口成为Interface，需要调用的出口叫做Reference。

    SCA Model

    SCA服务组件与传统组件的主要区别在于：

    1． 服务组件往往是粗粒度的，而传统组件以细粒度居多。

    2． 服务组件的接口是标准的，主要是WSDL接口，而传统组件常以具体API且大部分是二进制形式出现。

    3． 服务组件的实现与语言是无关的，而传统组件常绑定某种特定的语言。

    4． 服务组件可以通过组件容器提供QoS的服务，而传统组件完全由程序代码直接控制。

    我们可以看到这个服务组件其实就是我们在Profile中提到的Service和Specification等，当然这里隐含了Message的定义，那就会想到这样一个问题——Provider或者Partition在哪里呢？在SCA中是不是有所体现呢？是的，在SCA中我们确实可以找到Provider和Partition原型所对应的技术模型——服务模块（Module）。

    SCA Module

    服务模块是由一个或多个具有内在联系的服务组件构成的，是SCA中的运行单位。服务模块包含多个服务组件，它体现了一种逻辑/物理上的组件服务分类界定，同时可以通过独立的地址进行访问，服务组件之间的调用关系在WebSphere Integration Developer V6.0中可以通过Interface和Reference的连线来声明不需要写任何代码。

    那么多个服务模块之间如何调用呢？这就需要通过导入导出功能——导入的作用是使得模块中的服务组件可以调用模块外部的服务，导出的作用是使得模块外部的应用可以调用模块内部的服务组件，在IBM用于部署支持SOA的WebSphere Process Server V6.0中，为导入导出各自指定了包括目标服务和原服务的位置信息、调用方式等在内绑定信息，涉及JMS绑定、Web Service绑定、SCA绑定、无状态会话BEAN绑定四种绑定方式，对于同为SCA模块之间使用SCA绑定是最方便的，其他情况下可以选择其他绑定方式。

    在SCA体系中还包括可以被多个模块共享的共享库（Library），它与服务模块不同的地方在于其不包含任何服务组件，这里不详细介绍了。

    我们已经了解到了服务模块之间如何调用，但是必然还会涉及到与原有系统已经存在部分的沟通情况，例如外部Java代码、JSP/Servlet调用怎么样使用某个服务模块呢？模块中的服务组件不能直接被他们使用，只能通过Standalone Reference，它是一个只提供Reference不提功过Interface的端点，然后通过对Reference的使用就能调用它所连接的服务组件了，具体示例代码见IBM Developers网站。

    这样就比较详细的了解了SCA，但是还有几个细节问题需要考量：1、服务组件的同/异步调用；2、服务组件客户端调用方式；3、异构数据源的数据获取问题。

    对于第一个问题，显然在粗粒度的组件服务之间绝大多数情况都应该使用异步调用方式，因为从调用者角度来讲他可能面对的是一个需要长时间响应的事务，同时只有异步调用才更加良好地模拟真实环境，想想我们现实生活就明白了。SCA中提供了单向调用、延迟响应、请求回调三种异步调用方式。个人认为单向调用方式存在的情况并不多，而延迟响应显然对延迟长短的界定需要很强的领域知识和系统观念比较难以控制，真正符合我们各种情况下需要的就是请求回调这种异步方式了，这与许多编程语言中的回调机制相同，即通过将调用者接口传送给被调用者，期待事务完成之后通过事件触发由被调用者主动向调用者发送请求，这也就是所谓的回调。

    对于第二个问题，客户端存在静态/动态两种调用方式，如果采用服务组件的WSDL接口进行调用就必须采用动态方式，而采用Java接口则两种都可以使用，显然采用动态方式更加灵活，但是它的Invoke在编译期是无法被检验的，在动态调用方式下所有参数都是通过DataObject方式进行传输的，这就涉及到了下面要谈的异构数据源的问题。

    如何通过统一的方式来访问异构数据源，简化J2EE数据编程模型是一直以来困扰设计人员的问题，太多的底层数据访问细节让编程、调试和配置困难重重。SDO框架支持并集成XML，希望通过这种可自定义的语言标准来拟合各种业务数据并实现他们之间的无缝转化。SDO的前身叫做WDO，它包括三个概念上的部分：SDO客户机、Data中介服务、数据源，其中最重要的就是Data中介服务，简称DMS。以上三个仅仅是概念上的东西，不对应于任何一个具体的Java接口，而数据对象、数据图、变更摘要、属性类型等则分别对应了commonj.sdo.DataGraph、commonj.sdo.ChangeSummary、commonj.sdo.DataObject、commonj.sdo.Property，这些都在SDO1.0中提供了支持。数据对象就是结构话数据的SDO表示，它是通用的，SDO的客户机不需要了解它的细节，数据对象在属性中保存它们的数据，而多个数据对象按照层次就构成了数据图，同样数据图中也包含了变更摘要。数据图其实就是数据对象树的容器，SDO 客户机可以遍历数据图，读取和修改数据图中的数据对象，SDO 客户机与 DMS 和数据源没有连接，所以 SDO 客户机看到的只有数据图。当然数据图是在内存中的存在的，真正保留在磁盘或网络上传输的是序列化之后的XML文件，而数据图模型也就可以看作所谓的XML Schema，具体的程序例子参看IBM Developers网站。

    有了以上这些，其实从数据访问层到组件构建层都已经很清楚了，加上良好的业务、服务模型设计和系统架构设计，那么真正实现SOA部署就不是什么难事了。


    历史上的今天：


    随机文章：


    收藏到：Del.icio.us




    引用地址：
    SeraphZhang 发表于15:20:08 | 编辑 | 继续话题 | 转发 | 分享　0