通过java编程处理xml 为soa减少内存占用

　　很多大型软件供应商还在开发各自的 soa 产品。因此，soa 领域目前综合了各种技术，包括 java business integration (jbi)、intelligent event processing 和 business process execution language (bpel) 服务器。因此，在将各种技术融入到一个解决方案之前，想要从 soa 中受益的用户组织很可能需要进行大量投资。通过对 soa 布置如此高的复杂性，行业提前为实现供应商定位铺好了道路，即使 soa 其中的一项承诺是实现基于标准、面向组件、独立于供应商的计算。在开始代价高昂的迁移过程前，用户组织能够获得一些实用的 soa 使用体验吗?

　　java 技术为 xml 数据处理提供了一些真正强大的工具(请参见侧栏 java 技术和 xml)。如果将 清单 1 中的内容看作是给定数据集的基于 xml 的呈现，那么您还可以使用其他方式进行呈现。构成 清单 1 基本内容的原始数据一般保存在数据库中。因此，您如何将这些数据打包成 xml?

　　用户组织不需要进行大型投资就可实现一个试验性质的 soa。通过这种方式，陈述特定于组织的 soa 需求时可以脱离任何供应商实现。实际上，某些较小的用户组织可以继续使用他们的试验性 soa 模式，只在后期迁移到软件供应商提供的大型商用解决方案。

　　对于大多数服务提供商来说，自助服务正在发展为一种趋势 ― 特别是那些资金紧张的 isp。因此，如果您需要更多带宽(进行下载或玩在线游戏)，您可以登录到提供商的 web 站点并通过 web 页面自动升级与提供商的连接。让我们看一个具体的例子：清单 1 展示了一个简单的基于 xml 的用户服务配置文件。

　　无疑，服务定义可以比此处的例子复杂很多。其他内容可能包括客户地址、账单明细、往返延迟、加密和服务信用信息等。重点是，越来越多的提供商提供如 清单 1 所示的 web 访问细节。某种程度上讲，这种尝试可以减少支持电话的花销和发生频度。有趣的是，这种基于 web 的服务可以使用户觉得为他们提供服务的是较为先进的提供商。这实现了双赢的局面，因为客户可以更好地访问他们的服务数据，而提供商可以销售无需他们插手的服务包。授权的用户可以修改如 清单 1 所示的一些服务参数 ― 例如，配置的带宽。随之修改的是用户每月的订购费用。

　　然而，您将要了解的是另一种更加松散耦合的自助服务 ― 使用这种服务，用户可以通过在网络中传输 清单 1 中的 xml 内容修改数据。在这种场景中，所传输的 xml 内容可通过一个 java 客户机进行修改，后者可运行在台式机、笔记本电脑、甚至某种资源受限的设备上(例如手机)，然后将数据发回给网络服务提供商。这种机制超越了基本的 html 页面模型并采纳了 soa 思想。