我们正在仔细研究SDO。这是一个有些出乎意料的有趣规范。我的理解是，它提供了一种操作机制，特别是将对象或看起来足够接近对象、可以有意义地表示为图
的实体外部化的机制。例如，XML。
这对我们来说自然非常重要，因为我们试图通过Hibernate实现的一个重大事情就是摆脱位置透明性
的概念，并重新发明分布式对象
，作为可以在不同进程之间移动的对象图。特别是，我们对这样的想法很感兴趣：一个图可以从一个进程的持久存储中检索出来，在另一个进程中修改，然后将这些修改传播回第一个进程的数据库中，这一切都使用乐观语义。
因此，我们面临的最大问题是，在Java中精确跟踪类型安全对象的修改非常困难，除非使用重大的字节码技巧（我们至今不愿采用）。SDO通过以非类型安全的方式表示对象（与我们透明性的概念相反）来绕过这个问题。尽管我认识到SDO规范的作者正在寻找一种从POJOs、EJBs、DOMs等抽象出来的方法，但我还没有确信这是否值得牺牲类型安全的优势。
有人建议，在考虑这些内容时，Jakarta DynaBeans是一个有用的类比，但我认为这并没有什么帮助。我们正在尝试弄清楚与CarrierWave的关系，CarrierWave也是关于处理对象图（Christian以前对CarrierWave很感兴趣）。我们迄今为止最大的障碍似乎是SDO似乎没有解决CarrierWave解决的主要问题之一：即指定对象图/结束的地方。我的理解是，这留给了读者去练习，以及使用什么原生查询语言，例如HQL、XPath等。无论如何，尽管DynaBeans是为了解决Struts设计中特定的限制而采取的一种权宜之计，但这是一种解决使用领域模型构建分布式系统的一些更难问题的方法。
