我眼中的数据服务

我每次与客户谈起SOA参考架构时，就不免会谈到“数据服务层”。然而每到这个时刻，客户的思路就会不知不觉地被“数据”这个词引到其它方面，接着便是一系列关于传统数据问题的发问，“如何实现数据的同步。。。”、“如何实现数据变迁。。。”、“你们是如何解决大数据量问题。。。”等等，这个时候客户往往两眼放光，仿佛久病于床的病人找到了解药。这个现象这至少说明了两个问题：一是数据对于IT系统的重要性、二是大家对于SOA中所指的数据服务与传统的数据问题存在着很大的误解。其实，对于这个误解确实不能怪大家，数据服务这个说法在我看来本身就不是很严谨，按我个人的理解，在SOA架构中，数据服务层应该被称作“信息服务层”。为什么这么说呢？我们先分别看看“数据”和“信息”。

       什么是数据？数据是基本的、最小的、或者拥有一些结构、关系和状态的“信息”片段的底层集合。那什么又是信息呢？信息是数据的集合，是提供附加的形式、基本关系、语法和语义上下文的基本逻辑。也就是说，数据是信息的最小组成部分，虽然数据本身具有一些结构或关系，但是缺少信息中的语法、语义上下文等特质。例如：家庭住址、邮编、姓名，这些都可以看作是数据，虽然家庭住址包含：国家、市、区、街道等信息，但是就其本身来说没有任何意义。如果将这些数据聚合到一起构成用户这个信息实体，那这组数据就更具业务意义，例如：用户信息实体可以与其它信息实体构成一对一、一对多或多对多的关系；邮编与家庭地址之间存在校验关系；再比如姓名一般不会超过5个字符等。换句话说，信息表示封装了状态（数据）和行为（逻辑）的实体（主体，对象）。可以认为信息类似于面向对象编程中的模型类的实例，这个实例包含用于保持状态的数据成员（实例变量）和提供（模型）行为的方法。

       那么为什么信息比数据更适合SOA？我想这源于两种思维的冲突。我们知道，无论什么样的IT系统，最终都是为业务人员服务。而业务人员的视角更多关注于他们每天都会打交道的业务实体，例如：客服人员希望在门户中看到所有关于客户的信息：如客户注册信息、客户投诉信息、客户订单信息等。而业务人员对于业务实体的定义或需求是不断变化的，例如：企业领导今天想看到今天生产情况汇总，而明天除了想看到生产情况也想看到人员变动情况。业务人员在改变他们的想法时往往只是从业务的需求出发，不会关心数据的出处。而企业的IT部门则是另一番景象，当他们拿到业务人员的需求时，就需要将业务实体翻译成具体可以操作物理数据描述。往往一个业务实体来自于多种系统（如：人事系统、生产系统、财务系统），数据访问接口各异（如：数据库、WebService、Java API等），最后，数据的格式也是各异。也就是说业务人员以业务为中心考虑问题、而技术人员以物理数据为中心考虑问题。每当业务发生小小变动，就意味着技术人员大量的工作量。从另一个角度来说，信息更象是业务人员所面对的业务实体，而数据则是技术人员面对的物理数据。因此，信息更容易与SOA中精粒度的业务方法发生关系。

       那这里的“服务”是指什么呢？我个人的理解是将“信息”—服务化、标准化。信息也好、业务实体也罢，最终还是要通过技术手段将其服务于业务系统。因此，要想让这个层次被企业中所有系统都能够访问，必须将其以标准的方式提供服务，当然我们首先想到的还是Web服务，也就是说通过Web服务的方式将信息内容对外提供服务。当然业界也提供了高效的数据服务访问API—SDO实现对业务实体的访问。