使用 SDO 和 JDBC Data Access Service 启用面向服务的体系结构

核心提示： 如果有数百合作伙伴访问该服务，该银行不会轻易更改服务，使用 SDO 和 JDBC Data Access Service 启用面向服务的体系结构(4)，因为其合作伙伴将不再能与他们开展业务，该银行的最佳选择可能就是构建另一个 99% 冗余的服务，需要维护的代码较少，通常可以尽可能减少潜在的缺陷，

如果有数百合作伙伴访问该服务，该银行不会轻易更改服务，因为其合作伙伴将不再能与他们开展业务。该银行的最佳选择可能就是构建另一个 99% 冗余的服务，并尽力说服其合作伙伴转而使用新服务。这将使用大量资源，而所得到的业务价值也有限。

将 SDO 和 DAS 配合使用，可以减缓这类问题，因为 SDO 是动态性非常强的消息。如果该银行使用的是 SDO，则可以直接通知其合作伙伴对添加的信息进行加密，而不会更改已公开的服务——只需要更改传递给该服务的消息。如果某个合作伙伴仍然发送旧 SDO XML 格式的消息，通过检查 SDO 的内容（并可能与不兼容的业务合作伙伴联系），银行的应用程序将能够对此类情况作出判断，然后按照以前的方式处理此类信息。

使用 SDO 数据访问服务的业务案例

在现有持久化技术的基础上将 SDO 和 DAS 结合使用，除了 SOA 的好处之外，其业务价值何在呢？请考虑以下管理方面的特征：

SDO 是一项开放标准。由于 SDO 是一项公开的标准，因此不会出现不得不选用某个供应商的情况。截至本文发布时，BEA、IBM、Versant、Versata 和 XCalia 均推出了 SDO 实现。同样，也已计划对 SDO 的数据访问进行标准化。

SDO 和 DAS 可以减少业务所必须维护的代码量。数据访问服务提供了一种标准的方法，用于保存封装在 SDO 中的信息，而不受后端系统的影响（不管此后端系统是使用 JDBC 访问的关系数据库、使用视图 Bean 访问的 LDAP 服务器或是具有 DAS 实现的其他后端系统）。实际上，为了使用异构后端系统而编写的自定义代码与数据访问服务采用标准的方式进行了整合。需要维护的代码较少，通常可以尽可能减少潜在的缺陷，从而缩短投入市场的时间和减少风险。