曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
当然，必须根据当前的技术和网络中可能出现的异构平台判断以上原则是否现实。另外，
合作伙伴和开发人员之间还要达成一定程度的共识和协作。我们希望侧重于利用现有的技术遵
循以上原则实现应用程序。因此，我们将依次分析这些原则，并讨论如何实现这些目标。
16.2.1 从粗粒度服务构建应用程序
C O M组件和控件等软件组件虽然是非常有用的工具，但是它们只能在支持相应组件技术的
平台上运行，且只能在定位于这些平台的应用程序中重用。C O M组件不能用于U n i x平台，同样
J a v a B e a n不能在非J a v a服务器上使用（当然，某些U n i x平台有C O M端口，但是一般而言， C O M
是一种Wi n d o w s技术）。在我们的例子中，开发小组只创建应用程序中的一小部分，为现有的服
务器创建新的客户端，我们不能用组件跨越应用程序的各个层次。实际上，我们应该依靠服务。
服务是任意应用程序代码的集合，它限制于一层，完成一项明确定义的任务。服务比组件更
大；事实上，为了提高效率，我们经常用组件构建服务。服务比应用程序小。服务将问题域的
一部分模型化。如果服务过小，数据格式转化产生的开销将威胁到程序的性能。如果服务过大，
它将面临由单一模块构成的大型应用程序存在的问题。
将我们的定义与Windows DNA或Windows NT下服务的定义相比较。在Wi n d o w s中，服务
是指与操作系统挂钩的应用程序—Windows 32 API服务—或者用于获取数据的组件框
架，如：A c t i v e X数据对象（ActiveX Data Object，A D O）。它们都比单一的组件大。A D O
之所以不符合我们的定义，是因为它能够依靠专有的组件技术跨越应用程序的边界。然
而，除此之外，它还是与我们的定义吻合的—它利用几个组件之间的交互回答特殊的
问题：“根据SQL查询返回结果集合”。
通常，服务会将底层业务模型中的一些主要对象模型化——例如：销售应用程序中的客户，
或者制造应用程序中的生产线。
我们的开发原则设想的服务类型通常实现为服务器端页面或者一小组相互协作的页面。它
们使用已知的数据格式表示服务中商业对象的持续性状态。并且利用一组相关的对象提供各种
功能。例如，除了纯数据格式之外，服务还将提供H T M L，以便这些数据能够被手持设备等极瘦
的客户使用。瘦客户虽然不能享受通过程序操作数据带来的益处，但是它也不必受由纯数据格
686使用XML 高级编程
下载
式产生的额外开销而带来的困扰。虽然它能够准确地解析和操作H T M L，但是H T M L本身是一种
标记数据表示的语言，它并不说明数据的语义。实际上，支持不同的交换格式比使用H T M L标记
数据更加简单。简而言之，增加H T M L支持是一种表面上的改变，它使得简单的平台能够加入这
种有限的流行趋势，只要它们支持标准的We b浏览器。我们总是可以通过开放的协议访问服务。
通过将主要的对象抽象化，我们不仅能够保持面向对象模型的优势，而且能够减少对专有组件
技术的依赖性。
由于一项服务是由一个组织开发并维护的，而且位于由该组织机构控制的站点上，因此可以
在服务中使用更加专有的技术以提高效率。我们希望在服务中使用组件软件（通常，我们会给某
些遗留的软件或数据库增加外包装，避免重写大量代码）。我们将充分利用宿主操作系统和We b服
务器的各种功能，从站点中获得最大的价值。然而，当需要与另一个服务或客户交互时，我们应
该认识到这有可能跨越组织机构的边界，因此必须使用开放的标准和格式（参见图1 6 - 1）。
图16-1
我们的应用程序将建立在可重用的服务基础之上。在服务的内部，我们将依赖于组件。应
用程序通过精确定义的接口使用服务，服务通过接口使用内部的组件。因此，我们将受益于封
装以及将任务委托给大的服务和小的组件。
16.2.2 通过查询目录发现服务
服务的网络位置和服务提供的数据格式定义了对服务的访问。我们必须将这些因素与任何
本地约定相分离。虽然目录尚未成熟，也未被广泛应用，但是我们仍然要将它作为服务定位策
略的基础。它们对于实现位置抽象和动态资源发现来说非常关键。仅当资源能够被网络中的所
第16章实例研究2—XML和分布式应用程序使用687 下载
分布式应用程序
客户端通过协调服务建立应用程序
服务
客户端页面服务
脚本
脚本
脚本
有用户可见时，资源才有价值。因此，我们确信目录服务将受到信息系统组织最高层管理人员
的关注。它的结构和服务器的位置将成为组织内讨论的主题，我们确信该领域能够达成一致的
意见和理解。
目录不仅仅要保存服务的位置，而且要定义服务在它们所要解决的业务问题中的功能（参
见图1 6 - 2）。
图16-2
我们必须定义有价值的目录结构，并且利用工具对目录进行分析。每个应用程序都必须浏
览目录，以便搜索与所需服务相关的信息，因此我们要尽可能将该任务标准化。
目录服务使得我们能够对应用程序隐藏服务实现的物理网络位置。应用程序可以在运行时
动态发现所需的数据源—服务。在应用程序运行过程中，它可以从网络添加或删除网络服务。
如果你小心翼翼地坚持这条原则，你的应用程序将变得非常灵活，能够适应资源位置和可用性
的变化。
《Designing Distributed Applications》为实现这条原则提供了一种推荐的方案，它在服务表
示中包含XML词汇表名称。由于目录服务目前尚未广泛采纳（大多数读者也不能使用它），
因此在我们的应用程序样例中仅提供stub实现。
16.2.3 将服务提供为自描述数据
为什么我们对数据交换格式如此关注？毕竟，我们坚持了在组件软件中使用的面向对象方
法，这些方法试图对数据的使用者尽量屏蔽数据的格式。但是我们需要例外，根据服务的定义，
我们要分离服务中的组件。当跨越服务页面和客户之间的平台边界时，必须以一种所有客户都
能够访问的形式表示服务实现中的对象。尽管近年来基于对象的分布式计算有了一定发展，但
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
XML高级编程下(56)
