服务数据对象是一种流动数据
服务数据对象（Service Data Object，SDO）介于强类型POJO和非验证XML流中间。SDO使用户应用程序能够使用可动态创建的数据结构。当数据必须在没有（或不能）共享相同的严格类型定义的环境（例如编译后的POJO类集合）中传播时，SDO这种灵活的动态数据结构就显得尤为重要。可以将它们比作静态（POJO）和动态（SDO）――由于这种比喻――很明显，SDO是SOA的重要组成部分。这就是为什么所有企业的IT部门内都存在不同形式的‘动态数据结构’主题。怀疑论者会说：这不就是名称值对吗？但是SDO远远超越了所谓的名称值对。例如，该规范认为数据（例如人员）是通过各种关系而富有意义，并解释了DataGraph的概念。还详细说明了如何通过ChangeSummary跟踪DataGraph的变化。更多详细内容请参阅 参考资料 部分。
使用JPA持久性存储SDO
SDO是关于动态数据的高级规范。但是不具备持久性的数据是什么样的呢？我们如何将SDO DataGraph存储到数据库中，以及如何从数据库中检索它呢？最初的SDO规范（2004年11月发布）提到了Data Mediator Service但是没有给出其定义。最近再次查阅规范时，规范已经发展到了2.1版本，并且持久存储服务现在被称为数据访问服务，即DAS，但是仍然没有详细说明其细节。
在同一时期内，Java Persistence Architecture (JPA)已发展成熟，而且一些领先的应用程序服务供应商采用它作为其持久性提供者。BEA使用了Kodo，JBoss使用Hibernate，而OracleAS和GlassFish使用了Toplink。OpenJPA――Kodo的开源版本――很可能用于Geronimo和Websphere环境。自然，JPA是为SDO提供持久性存储服务的重要备选方案。
在Google中快速搜索一下“JPA”、“SDO”和“JPA+SDO”，分别返回397万、342万和16万的命中率。事实上，这些反应SDO和JPA讨论次数的数字可转换成左侧的图表。
我研究的第一个项目是Tuscany DAS。我大致查看了其中 可用 的内容，但是似乎没有使用JPA，至少目前是这样。有关论坛一直在 讨论 JPA的使用，但是其结果尚未报道出来。
下一个项目是 ALDSP。这是来自BEA的较成熟的产品，它使用的是SDO。然而，ALDSP也没有使用基于JPA的持久性服务。
Eclipse EMF是首先具体实现SDO的项目之一。然而，EMF也没有实现持久性服务（SDO规范并没有向其授权）。
为什么JPA是持久性存储SDO的自然选择？
JPA解决了O-R映射中最棘手的问题，不过需要注意一些 警告 标志。它还为持久性存储提供了一个简单的、设计良好的API，这个API通过实现EJB 3.0很好地证明了自己。除了已经证实的完善性，JPA逐渐成为为SDO提供持久性服务的自然选择，这是因为JPA还具有大量能与SDO良好结合的特性。
文章来源于领测软件测试网 https://www.ltesting.net/