定义愿景

 

Mary Kirtland
Microsoft Corporation

2001 年 1 月 10 日

在 上周的专栏中，我介绍了 Web 服务指导团队和我们的任务：生成、部署和操作示例 Web 服务，以说明执行相同操作时需要考虑的问题类型。 我还介绍了我们的第一个示例项目收藏夹服务。

感谢大家的评论和反馈。 我们正在跟踪你提出的问题，所以请继续“来吧！

有人问为什么我们发布该示例需要三个月的时间，以及为什么在宣布该想法之前，我们还没有开始发布该示例。 事实上，在过去的两个月里，我们几乎全职致力于收藏夹。 很多功能都是 正常运行的... 但是，在将一切打包成可安装在自己的计算机上或通过 Internet 进行尝试的示例之前，仍有一些工作要做。 编写、技术评审、编辑和处理要随示例源一起提供的所有文章也需要一些时间。 因此，我们的目标是三个月的项目周期。 我们保持我们的手指交叉，我们将能够得到第一个版本的收藏夹在2月的某个时候。 (编写本文时，团队正在经历一个计划练习，以更好地估计发布日期。)

一些注释还假定我们使用 .NET Framework 开发此示例。 情况不一定如此。 我们将使用我们认为最适合工作的任何技术。 最好并不总是意味着技术上优越、更易于使用或大多数新闻。 无论我们选择什么，我们都会告诉你原因，我们会告诉你在尝试使用它时遇到了什么问题。

本周，我们将开始了解我们的团队在构建收藏夹服务时遇到的问题。 存在相当多的积压工作，但我们会从头开始：找出项目的目标和目标。

入门

在 Microsoft 解决方案框架 流程模型中，任何项目的第一个阶段都是 设想阶段。 在设想阶段，项目团队和客户创建项目目标和约束的高级视图。 此阶段的主要可交付结果是一个愿景文档，其中包含对业务问题的分析、产品目标的说明、解决方案概念的概述、产品用户配置文件、设计目标以及项目范围的定义。 设想阶段最终达到 愿景/范围批准的 里程碑。

我们的团队从一个不寻常的起点开始：我们知道我们想要编写 Web 服务，但我们没有考虑到任何特定的问题领域，也没有我们必须使用的现有应用程序。 因此，我们需要做的第一件事是想出一个相当现实的业务方案，可以证明构建可缩放、可靠等等的合理性。Web 服务。

首先，我们把一群人锁在一个房间里，集思广益，讨论潜在的企业或行业、服务和技术问题，这些问题将成为很好的指导主题。 在此过程中，我们提出了一些你可能想要生成 Web 服务的原因：

• 你是最终用户或其他企业要使用的时间敏感型或参数化数据的来源。 如果数据不经常更改，而客户端几乎总是需要所有数据，则不妨在网站上发布 XML 文档。 但是，如果客户端想要对数据执行查询，那么 Web 服务就很有意义。 如果要将数据推送到客户端，订阅和通知操作也是潜在的 Web 服务。
• 你实现了其他企业无法或不希望自己实现的算法。 在这种情况下，每个算法都是一个潜在的 Web 服务：客户端传入数据，你用答案进行响应。
• 聚合其他几个服务以提供更高级别的服务。 在这种情况下，客户端使用你的服务，因为它提供了所需的信息组合，从而节省了组合现有服务本身的工作。
• 你想要将业务流程与合作伙伴集成。 跨企业边界的业务流程的每个步骤都是一个潜在的 Web 服务或 Web 服务操作。
• 你有异类和/或地理分布式企业体系结构，其中使用专用网络或紧密耦合协议进行应用程序集成是不切实际的。 要集成的每个应用程序的 API 都是一个潜在的 Web 服务。
• 你为其他 Web 应用程序和 Web 服务开发人员（例如标识服务或计费服务）提供 (“管道”) 基础结构服务。 可以将 API 公开为 Web 服务，而不是为每个客户端平台生成自定义 API 库。

当然，出于上述任何原因，你还需要考虑是否有足够数量的潜在客户可供你的服务来证明实现和操作服务的成本。

我们还很快意识到，在构建用于教育普通开发人员受众的示例服务时，还存在一些其他注意事项。 首先，业务方案不应要求对给定行业有广泛的了解。 其次，我们希望你能够在自己的计算机上安装和运行示例。 第三，许多有趣的方案需要一个或多个数据存储或源。 在交付示例源代码时，存在许多问题，这些源代码显示如何访问我们并不拥有的数据源。 我们 没有任何数据源... 至少不是说我们可以自由地放弃样品。

这让我们从网上银行、控制家庭数字视频录制器、检查航班状态或每日漫画服务器等场景，而更多地按照基础设施服务。 我们开始考虑 MSDN 可以提供 (真实服务的 Web 服务类型，而不是示例) 。 人们真正喜欢的一种想法是跟踪他们想要再次查找的 MSDN 文章的一种方法，无论他们使用哪种计算机访问 MSDN。 这让我们产生了服务器端收藏夹的想法。

愿景，修订版 1

大致了解要生成的服务后，我们围绕它构建了一个业务方案：

• 我们正在寻找方法来扩大我们的 Web 开发实践的客户群，并产生固定的收入流。 我们相信，可以通过提供网站要使用的高质量 Web 服务来实现这两个目标。 由于 Web 服务是一个新概念，我们认为潜在客户需要确信他们可以将部分业务押注于我们的服务。 因此，我们需要一个可：
  • 为潜在客户的网站提供明显的价值。
  • 不提供任务关键型服务。
  • 显示开发和运营实践的质量。
  • 可以以合理的成本实现和部署。

下面是我们对项目愿景的第一个切口：

• The server-side Favorites Service will enable Web surfers to store their favorite links in a safe, secure, central location, so their favorites are accessible anywhere, any time. We will offer the service free of charge to all users; however because we want to protect each user's privacy, users will need to be authenticated to access their favorites. By using the service through a client Web site, users agree that we may use their favorite lists after all personally identifying information is stripped from the data. 在此项目的第二阶段，我们将向网站许可其他服务。 例如：
  • 对其网站中的哪些页面添加书签的统计信息。
  • 基于所有用户收藏夹的相关性分析推荐的链接。

从技术角度来看，此方案看起来可以解决我们从客户听到的许多问题。 业务逻辑看起来不太难实现，或者太难向读者解释。 但是，一旦愿景声明被写下来供大家查看，一些大红旗就升起了：

• 我们需要一个全局用户标识方案，这个方案非常通用，网站能够将用户标识符传递给我们的服务。
• 当请求来自网站而不是直接来自最终用户时，我们如何对最终用户进行身份验证？ 听起来我们需要委派，或者我们需要信任网站，仅在最终用户实际使用其网站时代表用户发出请求。
• 是否允许任何网站检索从另一个网站添加的最终用户收藏夹？ 如果是这样，我们是要让任何网站使用我们的服务，还是应该限制对服务的访问权限，允许许可的网站？ 让任何网站可以访问存储在收藏夹服务中的任何和所有数据，而无需最终用户的任何输入，这听起来像是一个巨大的隐私问题。
• 同样，如果我们的 Web 服务提供了更新方法来维护用户收藏夹信息，该怎么办。 是否允许一个网站修改从另一个网站添加的最终用户收藏夹？
• 如果最终用户发现我们正在对其从多个网站收集的数据进行相关性分析等操作，他们不会大喊大叫吗？ 他们怎么知道这些网站正在使用我们的服务？ 我们是否需要执行类似要求最终用户注册我们的服务并设置其隐私首选项等操作，然后任何网站才能访问其数据？ 最终用户如何知道向我们注册？

也许还有一些额外的研究是有序的。

愿景，修订版 2

在查看了我能找到的有关用户隐私的所有内容后，我花了几个小时与 Microsoft 企业隐私小组的成员讨论我们的服务可能启用的方案以及隐私影响。 我翻了一页又一页的笔记，还有一些悬而未决的问题。 但是，从隐私的角度来看，一个网站可以访问或修改从另一个网站添加的数据的情况听起来很糟糕。 这不是说不应允许它们，只是更难编写准确但可理解的隐私策略来涵盖这些场景，最终用户可能对这些方案感到不自在。

我们还对身份验证问题进行了一些初步研究。 当中间有应用时，目前确实没有一种通过 Internet 对用户进行全局识别和身份验证的好方法。 当用户通过浏览器与网站交互时，Microsoft Passport 非常有效。 但是，网站无法安全地将用户的凭据传递到另一个网站。 Passport 的单一登录功能呢？用户移动到另一个已启用 Passport 的站点时无需重新输入用户名和密码？ 它使用客户端重定向。 我们的 Web 服务从不直接与最终用户的计算机通信。

根据此初步研究，我们决定分阶段实施收藏夹。 这将给我们更多时间来整理隐私影响，也许在去年的 PDC 中多次提及的标识 Web 服务将在我们需要全局标识方案时可用。

修改后的愿景如下所示：

• 我们将在 CY2001 期间实现和部署收藏夹 Web 服务，使最终用户能够将网站中的所选页面加入书签供以后访问。 这些收藏夹将由收藏夹服务存储，因此可从最终用户使用的任何计算机或设备访问它们。
• 收藏夹服务将用于向潜在客户做广告，因此必须是高度可用、可缩放且安全的服务，以展示公司对质量和个人隐私的承诺。

纯粹主义者可能会争辩说，这太长了，不能成为一个愿景声明。 然而，重要的是每个人都理解它，无论你想叫它。

我们定义了如下阶段：

• 在第一阶段，我们将实现并部署一个收藏夹 Web 服务，该服务可以授权给网站开发人员，以便在后台管理客户收藏夹。 (实际上每个被许可人都有用户收藏夹的专用数据存储。) 我们还将提供一个示例，演示如何将收藏夹服务集成到网站中。 服务和示例将于 2001 年 3 月 1 日提供许可。 我们的目标是在 2001 年 3 月 1 日之前将该服务授权给 5 到 10 个每月代表大约 10，000 个新最终用户的网站。 (我们认为，鉴于我们目前的员工，这是一个可控的增长率。)
• 在第二阶段，我们将为 Internet Explorer 和 Netscape Navigator 实现浏览器扩展，使最终用户能够安全、安全地管理任何网站的收藏夹，就像他们目前管理客户端收藏夹一样。 我们还将实现和部署网站最终用户可用于管理其收藏夹、阅读我们的隐私声明、设置有关使用其个人信息的用户配置文件选项以及下载浏览器扩展。 浏览器扩展和网站将于 2001 年 5 月 1 日交付。 我们的目标是每月接触 1，000 名新最终用户。
• 在第三阶段，我们将扩展收藏夹 Web 服务，以便最终用户可以查看他们通过浏览器加载项或收藏夹网站直接保存 (收藏夹) 收藏夹，以及通过收藏夹服务的被许可人存储的收藏夹。 被许可方可以选择显示特殊徽标，让最终用户知道“咨询收藏夹服务”正在使用 (因此也可以通过浏览器加载项或收藏夹网站) 访问这些收藏夹。 被许可人还可以在后台继续使用收藏夹服务，在这种情况下，通过该网站存储的收藏夹将无法通过浏览器加载项或收藏夹网站使用。 第三阶段将于2001年6月1日交付。
  第三阶段为未来的 Web 服务奠定了基础。 例如，如果用户访问网页，该网站可能会显示其他喜欢该网页的人也喜欢的网页列表。 网站将从 Web 服务检索页面列表。 我们尚未决定是否实现这种类型的分析服务。

有了这个，我们可以充实视觉文件的其余部分。

下一步是定义一些用户配置文件。 在定义 Web 服务项目的愿景时，请务必仔细考虑 所有用户 是谁。 我们在设想阶段确定的用户类别包括：

• 最终用户 - 使用 Web 浏览器访问网站的任何人。
• 被许可者 - 具有使用收藏夹服务的网站的任何企业。
• 被许可人开发人员 - 构建被许可人网站的开发人员。
• 被许可人操作员 - 被许可人网站的操作员。
• 操作员 - 负责操作收藏夹服务的人员。

可以在此列随附的收藏夹视觉文档中阅读完整的用户配置文件。 事实证明，我们错过了几个类别：被许可人的经理和经理。 当我们开始考虑报告要求时，这些内容被裁剪了。 我们可能也应该将测试人员拆分为单独的类别。 此列表应为大多数 Web 服务项目提供良好的起点。

我们还花费了一些时间思考业务目标和设计目标。 main问题之一是：为什么要生成 Web 服务？ 你是想赚钱吗？ 正在尝试简化业务流程？ 还是别的东西？ 无论你决定什么，它都可能会对你的要求产生影响。 例如，收藏夹服务的主要目标是：

• 展示我们对优质产品的承诺。
• 避免因服务不可靠、安全问题或个人隐私问题而导致的不良新闻。

这种目标组合为我们的服务增加了大量要求，尤其是在许可和能力要求 (可伸缩性、可用性等方面。) 。 但赚钱是这个项目的一个完全非目标。 如果这是一个目标，我们的许多许可要求会有点不同。

从设计的角度来看，应考虑用户隐私、安全性和其他非功能性要求的总体理念。 你还应考虑世界各地的客户端是否将使用 Web 服务，以及这意味着全球化和本地化。 例如，我们的一些设计目标是：

• 提供全球解决方案。 该服务和所有支持的应用程序都必须全球化。
• 提供可靠、安全的服务。 该服务必须高度可用，不得丢失数据，并且必须仅允许授权用户访问。

可以在收藏夹视觉文档中找到我们的其余业务目标和设计目标。

结论

如果项目团队和客户预先同意总体目标、目标和范围，那么在项目完成时，总是更容易知道。 即使认为只是将 Web 服务前端添加到现有网站，也值得花时间编写视觉文档。 为什么要添加前端？ 你希望谁使用它？ 你的运营人员不希望对网站施加多少额外负载？

为收藏夹编写愿景文档对我们来说是一项有价值的练习。 如果没有它，我们将错过至少一半的要求，最终在我们的功能规范。例如，我们可能直到游戏后期才认识到隐私和安全问题。 视觉文档也为我们执行其他操作。 它为我们提供了评估功能请求和确定需求优先级的衡量标准。 本文档提醒我们在未来阶段要执行的操作 - 我们可以在示例设计中说明这一点，因此我们无需在后续阶段完全重写内容。

下周，我们将更详细地了解此处提到的隐私问题。 我会让你知道我从公司隐私小组学到了什么，讨论我们推迟的难题，并讨论仍处于第一阶段的隐私问题，以及这些问题对我们的设计和实现有何影响。

再见！

Mary Kirtland 是 MSDN Web Services 指导团队的架构师，除了编码、测试或操作，她还可以做所有工作，包括尝试使规范保持最新状态、写下团队在 MSDN 的文章中学到的所有内容、在评审期间提出烦人的问题以及订购午餐。