5）数据建模 从第一个选定的资源开始（我建议您首先端到端地制作一个资源，也许不是最高优先级的那个，这允许您使用控制度更高并且便于管理的方式实现数据管理和数据服务层的SDLC过程），对现有的物理方面进行检查。对于数据库或者一组表，考虑来自用户的各种查询、数据库的逻辑存储过程及其触发器、各种具有副作用的操作。这构成了物理数据资源定义和描述。对于信息访问，要使用什么呢？MOM、第三方适配器、专有的集成或者点对点的定制集成？这构成了物理信息资源定义和描述。
由于数据服务层是完整的SOA参考架构的一部分，所以应该规定SOA构建块的定义和要求。您的资源的当前状态与SOA RA构建块的目标状态之间很可能存在差距。业务的第一步是引导当前的物理状态尽可能地接近您的SOA构建块目标状态标准。您可能会想起前面讨论的关于SOA参考架构中“服务”的定义和描述。为简单起见，假设您的服务定义要求包含WSDL、SOAP和用XSD定义的文档样式。其它推荐的规范包括 WS-Addressing和XQuery/XPath。有了这个定义，我们需要考虑怎样把关系数据库、XML数据和／或信息访问系统中的表转换或者映射到一组满足构建块服务定义准则的服务上。
有许多不同的工具和技术可以映射现有的数据和信息访问资源到图２所示的物理数据层，定义与您的特殊要求和服务定义一致的逻辑服务模型。BEA的 AquaLogic Data Services Platform（ALDSP）是我们的从数据／信息访问资源向SOA构建块（数据服务）转换的实现技术，它为您的SOA参考架构提供了基于标准的、面向服务的数据服务层。
一旦您导入了您的物理资源（不考虑它们的接口和实现），您就有了物理的数据服务层（参见图2）。物理的数据服务层中的服务有着一致的外观和表示——即底层的实现细节和通信协议被抽象化和封装，并且从视图中移除（必要时，您仍然可以访问底层），只提供了资源定义（服务定义）和操作的信息。 既然您有了自己的“数据”，下面该定义您的逻辑模型。