服务数据模型

    package org::crm 中定义的 Customer Relationship Management (CRM) 数据模型，定义了在这个例子中的 Purchase Order Process 模型中所有服务操作所使用的所有数据（请参见图9）。CRM 包反映了 Customer Relationship Management 服务数据模型的设计，该模型能够在许多服务中被复用，甚至是由不同公司所提供的服务。服务数据是如何被发现和格式化的，以及它是如何同持久实体或者物理数据源相关联的，已经超出了本文的范围。我们这里所介绍的是该服务数据是什么，以及该模型如何被捕获。

    图9. CRM 服务域模型
    

    图9中所显示的服务数据中的每一个 <message>。服务数据就是在服务消费者和提供者之间进行交换的数据。用于服务操作的参数的数据类型既可以是消息也可以是简单类型。

    请注意：

    服务数据消息同 Web Services Description Language (WSDL) 消息并不一致。服务操作能够拥有任何数量的消息或者简单类型的输入和输出。服务操作能够被设计用作输入、输出、和错误消息，但是这并不是必须的，而且还将导致不合需要的邮戳数据耦合。

    消息作为 数据传递对象(DTOs) 能够被轻易的在分布式环境中的地址空间之间进行交换。服务消费者和提供者并不关心数据存放的实际位置，因此他们假定自己拥有一些实际持久域数据的视图的一个拷贝。消息没有同一性。由于它们的等同性是基于它们内容的值的，而不是基于它们的身份的，所以它们是值对象。

    消息反映了在可能的分布式环境中，服务消费者和提供者之间的数据交换。服务提供者通常也需要访问持久的数据，用于它们的执行设计。服务数据和服务执行设计中所使用的持久域数据之间的关系就是服务提供者及其服务功能性的执行的职责。通常，服务数据是域数据的一个选集和投影（或者视图）。虽然如此，服务数据如何从域数据中得到或者更新，取决于服务执行。服务数据对象(SDOs) 对于服务数据消息来说是一个非常有用的执行。它们还具备管理变化集和自动将变化提交到持久存储区的能力。服务参与者执行可能会用到这些功能，但是它们不需要在模型中被处理。

    数据模型使用一个 <id> 规则来识别唯一可以识别类的实例的属性。这将成为贯穿服务模型的主题。这是因为 Web 服务和面向 Web 服务的 Business Process Execution Language (BPEL) 特别依赖实例相关性的业务数据或者基于值的对象同一性。