了解我们

 

玛丽·柯特兰
Microsoft Corporation

2001 年 1 月 3 日

欢迎使用“服务”,这是一个专门介绍 Web 服务的新列。

Web 服务通过基于标准 Internet 协议构建的妥善定义的编程接口向应用程序提供信息和服务。 它们是 Microsoft .NET 的关键部分。 当然,MSDN 认为我们应该了解如何构建它们。 不只是如何在 Visual Studio 中按下按钮,以及如何构建可缩放、高度可用、安全、可靠的 Web 服务。

我们的团队在构建 Duwamish Online 等 Web 应用程序方面获得了宝贵的经验。 生成 Web 服务有什么不同? 当其他开发人员想要在其应用程序中使用 Web 服务(托管在不同操作系统上、以不同语言编写的应用程序)以及使用不同的关键规范实现(如 SOAP)时,你会遇到哪些问题?

我们认为,找出的唯一方法是自行构建一些服务。 因此,在接下来的几个月里,Web 服务指导团队将生成、部署和操作一些示例 Web 服务。 我们的目标:说明在设计、实现、部署和操作自己的 Web 服务时需要考虑的问题。 (我们还将探讨如何使用 Web 服务!) 我们希望每三个月发布一个 Web 服务。

不过,三个月是一个漫长的时间,让你等待新信息。 因此,在 Duwamish 日记的宏伟传统中,我们将使用此栏目来跟踪从概念到设计、实现和部署的每个示例项目。 我们将至少每两周发布一次日记条目,以便你可以与我们一起关注。 完成每个项目时,我们会在 MSDN 上在此处发布规范、源和其他项目项目。 你将始终能够从我们新的 Web 服务开发人员中心访问所有这些信息。

认识团队

Web 服务指导团队目前由六人组成:

  • 我,Mary Kirtland,是团队的首席厨师和瓶颈——我的意思是,架构师和项目经理。 除了编写代码、测试或操作我们的示例服务之外,我还可以执行大部分操作。 你们中的一些人可能从我作为 OLE/COM/DCOM/MTS/COM+/任何你想要呼叫它团队的项目经理时代就认识我。 然后,我消失在 .NET 周围的沉默锥中。 大约一年前,我发现我喜欢写如何使用技术来构建应用,而不是我喜欢自己构建技术。 因此,在 4 月,我转到 MSDN,从事 Web 服务指导团队的工作。 我大部分时间都花在为 Web 服务资源页编写此栏目和内容上。 其余的花费是试图使项目规格保持最新,并跟踪我们希望覆盖的新技术。
  • 马特·鲍威尔和斯科特·西利组成了我们的开发团队。 Matt 于 10 月从开发人员支持部门加入团队。 Matt 在用于 Visual Studio 6.0 的 SOAP 工具包中编写了 ISAPI 侦听器,合著了 Running Microsoft Information Server 4.0 for Microsoft Press,并为 MSDN 杂志 及其前身 MSJMIND 撰写了多篇文章。
    Scott 于去年 12 月加入 Microsoft 和我们的团队,过去五年时间使用 Microsoft 产品构建真实应用。 在大量的业余时间,他为 Windows 开发人员杂志 和一本名为 Windows Shell 编程的书撰写了文章。 当他不在我们的示例服务上工作时,他正在写一本关于 SOAP 的书。
    在未来几个月里,你会看到 Matt 和 Scott 撰写有关开发方面的文章。
  • 我们的测试团队由扬·麦考伦和吉姆·弗朗西斯科组成。 Jan 于 10 月加入我们,担任测试主管,并努力为第一个项目制定测试计划。 Jim 于 12 月加入我们,并致力于单元测试和测试自动化。 Jim 曾就职于 Windows 98 网络测试团队和 Microsoft Host Integration Server 生成/发布测试团队。 在为 n 层 Web 应用程序开发部署和管理工具后,他来到我们的团队。 当我们走得更远一点时,我们将尝试让他们写一些有关测试 Web 服务的文章。
  • Bronwyn Calsyn 是我们的运营经理。 Bronwyn 从 11 月开始,一直忙于找出我们需要哪些设备才能在 Internet 上部署我们的示例服务,以及我们需要的操作程序来保持事情顺利运行。 我们还将尝试让她撰写一些有关部署和操作方面的文章。

收藏夹服务简介

我们的第一个项目是收藏夹服务。 作为 Web 的狂热用户,我们认识到最终用户面临的问题之一是查找他们以前访问过的页面,尤其是在动态网站(如 MSDN Online)或新闻网站上,这些网站在几天内无法从头版访问文章。 虽然可以使用浏览器收藏夹来跟踪收藏的页面,但浏览器收藏夹是特定计算机的本地收藏夹。 但是,如果使用多个计算机或设备,该怎么办? 如果收藏夹可以存储在某个服务器上的某个位置,可以从你碰巧使用的计算机轻松访问,那难道不是很好吗?

这正是收藏夹服务所执行的操作。 它使网站能够存储指向最终用户最喜爱的网页的链接。 现在,你可能会认为这听起来不像是一项非常复杂的服务。 从业务逻辑的角度来看,它不是。 这意味着,我们无需花费大量时间来解释业务逻辑,并且你也不需要花很多特定于应用程序的代码来查找可在自己的 Web 服务中使用的技术。 但是,我们在该服务中遇到了许多有趣的问题,我们与之交谈过的许多其他开发人员也正在处理这些问题。

前几列将重点介绍我们在项目设计阶段遇到的问题。 我们正在考虑的一些主题:

  • 保护用户隐私。 世界上是否有任何应用程序能够查询或编辑每个最终用户的收藏夹,而不管哪个应用程序首先保存了收藏夹?
  • 如果每个应用程序都无法访问所有最终用户的收藏夹,我们如何控制对服务的访问? 我们应该为该服务收费吗? 哪些业务模型有意义?
  • 身份验证和授权。 如果我们要限制对服务的访问,如何对客户端应用程序进行身份验证并决定它们有权执行哪些操作? 无论如何,我们如何识别最终用户?
  • 估算性能要求。 如何确定服务将承受何种负载? 是否可以使用用于估计网站上的负载的相同方法? 如何确定客户需要哪种类型的响应时间和可用性?
  • 开发、测试和操作中的许可人要求。 如果我们限制对服务的访问,可能会根据使用情况收费,客户端应用程序开发人员和测试人员如何试用依赖于我们的服务的应用? 它们如何避免影响生产数据存储? 客户的测试和操作人员需要哪些类型的工具来帮助排查问题是否在他们的应用程序或我们的服务中? 应提供哪种类型的文档?
  • 全球化。 我们需要执行哪些操作才能确保世界各地的客户端应用程序可以使用我们的 Web 服务?
  • 可管理性。 运营人员需要哪种类型的信息来管理 Web 服务? 我们如何收集这些信息并将其呈现给管理工具?

如果想要了解其他主题,请发送电子邮件 wsgmsdn@microsoft.com至 。 请注意,目前我们无法通过此页面上的用户评论进行响应。 但是,我们会定期阅读评论。 如果我们能弄清楚你的评论与我们的内容有什么关系,我们将在未来的一列中看到我们可以做些什么来解决你的问题。

下周,我们将探讨在定义收藏夹服务项目愿景时遇到的问题。 再见!