![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
在决定要使用哪一种类型的安全监视 Web 服务时，首先为您的组织中有关提供 Web 服务来监视安全性的支持、操作和管理实践制定计划。只需确保在评估的风险与应对措施的成本之间取得平衡。即使您的企业通过定期的风险评估、应对措施的投资回报 (ROI) 和安全策略实现了平衡的安全性，您仍然需要确保 Web 服务在正常运行时间以服务级别协议（service level agreement，SLA）所保证的级别执行。
下面是应该包括在您的计划中的一些事项：
- 管理委托：包括地理位置的指定、管理权限的委托级别，以及监视安全性的管理角色——专用和分布式。在本地、地区和全球级别制定此管理委托计划。
- 安全基础结构：确定是否使用一个中央组专门管理整个企业的安全性，或者是否每个部门经理独立管理各自的基础结构，并在数据共享或传输安全性方面进行协作。考虑企业中所有可能的管理员的角色，然后确定为一个企业分配多少个角色。
- Web 服务交互：考虑您的企业中的 Web 服务是否需要通过网格或点对点连接与其他企业的 Web 服务交互。如果使用网格的话，考虑是在本地、地区还是在全球级别使用——或者在所有三个级别使用，以及如何在每个网格级别在多个工作站利用未使用的资源。
- 风险、培训和文化：执行风险评估和容纳计算机及网络基础结构的设施的物理安全性评估。提供培训课程以提升开发人员在构建安全监视 Web 服务方面的技能。考虑您的企业以及其他企业（如果了解的话）中的文化和组织方面。
如果您决定采用作为主机的专用安全监视 Web 服务，务必记住这与集中的安全监视 Web 服务不是同一回事。与集中的方法不同，您可以将多个专用监视 Web 服务组合在一起作为企业中的虚拟主机，每个专用监视 Web 服务包括面向服务的体系架构（Service-Oriented Architecture，SOA）中的安全工具、策略和标准。一家企业不能有多个集中的安全监视 Web 服务。
一家企业的专用安全监视 Web 服务可以在三个不同级别与另一家企业的另一个专用安全监视 Web 服务通信：本地、地区和全球级别。专用安全监视 Web 服务必须表明自身能够比分布式监视 Web 服务提供更好的成本收益比。
专用模型的优点之一在于，所监视的 Web 服务可以在企业中的 Intranet 上或封闭的网络中传输敏感数据，从而跳过网格。从一个 Intranet 到另一个 Intranet、从一个 Intranet 到封闭网络或者从一个封闭网络到另一个封闭网络传输或访问数据将需要安全的通信。
分布式安全监视 Web 服务的模型描述这些服务如何在网格中跨整个企业分布。从顶部开始的是全球监视主机，此主机分组为第二个级别的地区主机，后者又分组为第三个级别的本地主机。
让我们看看转换到分布式监视 Web 服务或将其构建为主机的一些理由：
不同企业中的安全监视 Web 服务需要一个分布式安全模型。安全职责在企业之间划分。每个企业独立管理安全基础结构中各自负责的一端。
网格中的 Web 服务交互必须能够跨企业穿越公司防火墙。例外情况是防火墙后面的公司和政府 Intranet，以及没有连接到 Intranet 或 Internet 的封闭网络。
如果专用监视主机检测到某个企业在一段时间内的风险增加了，则为该 Web 服务分配中央安全控制（以将风险减轻到更加可容忍的级别）将会使其变得不堪重负。
有些企业可能采用让一个网格中的 Web 服务与其他网格交互的策略。企业可以与提供不同服务的多个网格交互。这些服务可以是从供应商服务到工资单服务的各种服务。企业使用这些服务网格与其他合作伙伴、服务提供商客户以及供应商的系统交互。这些服务网格使参与公司可以形成松散的联盟，每个公司具有自己的内部计算机、网络以及安全基础结构和策略。
来自不同企业的 Web 服务可能是使用异构的技术堆栈来构建的。每家企业独立地决定所采用的计算基础结构。Web 服务（包括不同企业或网格中的安全监视 Web 服务）很可能使用不同的语义。每家企业对企业之间交流的数据的解释是不同的。还不存在作为企业级标准的通用数据模型。
问题是无论资源是否缺乏，Web 服务通常均以松散耦合方式运行。需要有某些方法来确保分布式安全监视 Web 服务的资源不会在网格中浪费掉。
在非网格环境中，资源量可能有从低到高的变化，反之亦然。Web 服务等待发送或接收消息时，资源可能缺乏也可能不缺乏。如果在数千个工作站都不能充分控制规模变化，则会对网格中的单系统映像造成影响，从而导致资源过载，并且可能导致拒绝服务。
一个解决方案是开发网格监视器来监视其他工作站如何利用和共享每个工作站的未使用资源。如果系统发现没有正确地利用任何工作站上的未使用资源，则分布式服务监视 Web 服务应该向网格和系统管理员发送警报，这样他们可以在日志中查找详细信息以便解决问题。
我的文章“SOA 中的紧密耦合 Web Services”讨论了另一种解决方案：带工作站级别的耦合切换机制的 Web 服务。当 Web 服务收到的相应资源已达到指定级别的警报时，此切换机制将从松散耦合转换为紧密耦合。在 Web 服务进行切换时，必须切换某些标准（例如，用于松散耦合的 WS-Context 切换为用于紧密耦合的 WS-Addressing）。
分布式安全监视 Web 服务应该包括耦合切换机制以及 WS-Resource Framework 和 WS-Resource Transfer。有了 WS-Notification 和 WS-Security 规范，当网格级别的资源达到特定级别时，此 Web 服务可以在网格级别将警报发送给指定的工作站，以便将某些 Web 服务从松散耦合切换为紧密耦合。
如果是相反情况，则在同一计算机中已切换为紧密耦合的其他 Web 服务的资源到达指定的级别时，指定的工作站上应该有某个 Web 服务能够向网格中的分布式安全监视 Web 服务发送警报。
如果一家企业中的分布式监视 Web 服务主机要访问不同企业中的类似主机，则需要企业之间的协作。为什么呢？
- 为了确保分布式安全监视 Web 服务主机提供的策略、标准和工具可互操作和兼容。
- 为了通过确定将要标准化的内容以及需要兼容和可互操作的内容，从而操作和保护企业的网格。
- 为了就适用于参加协作工作的企业的安全策略、标准和工具达成一致意见。
您需要一个开发人员、测试人员和系统及网格管理员的团队，才能在作为主机的专用或分布式安全监视服务之间做出选择。您必须预先为在企业中或跨企业开发、迁移、测试和部署任一种主机类型做好计划。解决这些问题后，监视 Web 服务安全性的工作将变得容易得多。您可以使用 IBM® Rational® ClearQuest®、IBM Rational Tester for SOA Quality 和 IBM Rational Functional Tester，通过减少测试和缺陷跟踪时间来提高工作效率。
学习
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文 。
- 探索 OASIS 联盟。
- 查看 Judith M. Myerson 的系列在企业级 SOA 中使用 Web 服务中的所有文章。
- 阅读“SOA 中的紧密耦合 Web Services”。
- 了解有关 WS-Resource Transfer 规范 的更多信息。
- 获得有关以下产品的详细信息：
- 请参阅 Judith M. Myerson 的图书 The Complete Book of Middleware，其中主要讨论关于系统设计的基本原则和优先考虑事项，重点是因电子商务和分布式集成系统的兴起所带来的新需求。
- 阅读 Enterprise Systems Integration, Second Edition，了解业务概况和技术相关知识，以确保成功完成系统集成。
- 阅读 RFID in the Supply Chain，其中解释了业务流程、操作和实现问题、风险、漏洞，以及安全性和隐私。
- IBM developerWorks SOA and Web services 专区提供了大量的文章，以及关于如何开发 Web 服务应用程序的初级、中级和高级教程。
- 使用 IBM SOA 沙箱进行试验！通过 IBM SOA 进行实际的亲手实践来提高您的 SOA 技能。
- IBM SOA 网站提供 SOA 的概述，并介绍 IBM 是如何帮助您实现 SOA 的。
- 了解关于 developerWorks 技术事件和网络广播的最新信息。
- 访问 Safari 书店，浏览有关这些技术主题以及其他方面的书籍。
- 查看快速的 Web 服务按需演示。
获得产品和技术
- 下载 Rational ClearQuest 的试用版。
- 下载 Rational Functional Tester 的试用版。
- 下载 Rational Tester for SOA Quality 的试用版。
- 下载 IBM 产品评估版，获得来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。
讨论
- 参与论坛讨论。
- 参与 developerWorks Blog，从而加入到 developerWorks 社区中来。
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。