Search 开发负责人 Larry Jordan、开发人员 Michael Ruggiero 和 Michael Stanton 以及 .NET 框架项目经理 Hari Sekhar 在暗中构建了基于 .NET 技术的 Microsoft Web 站点搜索引擎新版本。迄今为止，只有参加过今年 7 月在奥兰多举行的“专业开发人员讨论会”中的一次特别会议的少数外部开发人员略知一些细节。现在终于可以将实情公诸于众了。

如果您经常访问“内幕新闻”站点，您就会知道，Microsoft Web 组在 2000 年 7 月份召开的“专业开发人员讨论会”之前推出了其 Search 引擎的新型改进版本。您已知道该版本引入了先进的同义词匹配、可返回最为相关的加按语搜索结果的扩展 Best Bets 逻辑，以及对最常用搜索的智能缓存。

然而，有关该版本的内幕消息远比表面上的东西多。

我们当然会兴奋不已，因为该搜索版本的丰富的功能以及经改进的搜索结果明显地能为客户带来更佳的搜索体验（参阅 Search 2.5 技术内幕）。但是，大多数人当时并未意识到，我们同时在幕后将传统的基于 ASP（Active Server Page 活动服务器页面）的 Search 2.5 版移植到新型的 Microsoft .NET 框架。

对搜索组而言，这是最具前沿性的开发。因为我们已经深入到 Internet 服务的未来。而且我们希望如此。下面来谈谈个中缘由。

为何要移植到 .NET？
显而易见，我们正在进入 Internet 的下一个阶段。我们正在跨越通常意义上的 Web 页面，并在开发功能强大的 Web 服务。在这一阶段，使资源和信息有计划地得到利用是极为重要的。这样，我们就可以把这些资源和信息作为服务来利用，而不是让其停留在杂乱无章的数据仓库中。

可扩展标记语言 (XML) 是在超级分布式系统之间实现多数据集传输的一种手段。它同时可以使开发人员以更具价值的新型方式聚集和组合各种来源的数据 – 这样用户就可以直接从中受益。

就 Search 而言，我们为多种自定义和本地化 Search 版本设计了在 microsoft.com 上查找信息的核心功能。我们组在如何使数据访问兼备灵活性和可用性方面面临挑战。在 .NET 出现之前，我们确实无法使客户在不使用安全端口上的 DCOM （分布式组件对象模型）的情况下针对我们的功能设计程序，或者客户只得将我们的多种软件版本安装在其服务器上以便访问代码和 COM。

我们组对即将推出的 .NET 技术进行了研究，并认识到可以通过将代码移植到 .NET 框架来解决所有远程性问题。而且，还有一个意外收获，我们还可以实现 HTTP 和 SOAP 的无处不在的连接。对绝大多数人而言，是否有某个人在 Microsoft 或在世界的某个地方，使用我们的 Web 服务在内部开发用于完全不同用途的应用程序，无关紧要。我们对两种情况均予以支持，同时我们也可以免费获得技术方面的好处。

最新的 Search 2.5 版如今运行在 Site Server 3.0 上，并仍然使用 COM 从搜索目录获得结果。该应用程序的其它各个方面都基于 XML。XML 作为一种将数据（例如，Vocabulary 和 Best Bets）发布到 Web 服务器的手段，使我们能够轻而易举地扩大我们的 Web 空间。

我们同时执行了一项缓存客户请求的最为常用的查询和结果的方案，这是通过将这些查询和结果保留在 Web 服务器上来实现的，并因此增强了可扩展性，进一步提高了性能。由于我们的核心体系结构是基于 XML 的，因而，移植到一个将利用 .NET 框架 Web 服务的模型确实非常简单，而这些 .NET 框架 Web 服务是建立在新型 ASP+ 技术基础之上的（ASP+ 技术被称为活动服务器方法 (ASMX) 页面）。

转换
Search 体系结构由三个组件组成：
Word Parsing and Vocabulary
Best Bets
Search Results
Search 的 .NET 端口的体系结构与基于 ASP 的版本相同（参见图 1）。下面让我们深入了解一下各个组件。

图 1.用户提交查询后，(1) 将查询先提交给解析器 (Parser) 进行词条分割和词汇解析，(2) 将找到的项目的显示术语 (Display Term) 传给 Best Bets，(3) 将找到的项目的首选术语 (Preferred Term) 和剩余项目传给 Search Results，(4) 使用 XSL 样式表编译生成的 XML 文档，(5) 给用户的 Web 浏览器提交 HTML。单击以放大。

Word Parsing and Vocabulary _ 这是一个包含一个 C++ COM 对象的 Windows 脚本组件，它暴露出 Search 中所支持的所有语言的各种词条分割程序。这种设计之所以必要是因为词条分割程序的接口不容易编写成脚本，并且通常需要一种 C++ 可编脚本的封装（尽管这是有办法做到的：以后将对此进行详细解释）。在向 .NET 框架移植的过程中，我们使用了 C++ 对象上的类型列表导出程序 (TLBIMP.EXE)，并通过 .NET 中的 Interop 技术对其进行调用，这样您就可以调用现有的 COM 对象了。

Vocabulary Object 运行 Xpath（查询 XML 文档的语言）查询，以便将搜索词条映射到首选术语。它同时去除了干扰词条，并产生一种格式化的数据结构，适合于 Best Bets 和 Search Results 组件进行消耗。一项重要成果是，这个相当复杂的小脚本得以移植到 C#，我们还可以继续从中调用传统对象。下面是 Vocabulary Object 中的一个小代码示例：


// We return an array of VocabularyObjects after parsing the user's search
// text. This ability to create simple typed structures in C# vastly improves
// our code modularity and self-documentation. Here is the definition of
// VocabularyObject:
public struct VocabularyObject {
    public string PREFERREDTERM; // structure members
    public string DISPLAYTERM;
    public bool FOUND;
    public string ORIGPHRASE;
    public bool MULTITERM;
    public bool MULTIWORD;

    // Constructor
    public VocabularyObject(string preferredterm,bool found,string origphrase,
                            bool multiterm,bool multiword,string displayterm) {
        PREFERREDTERM = preferredterm;
        FOUND = found;
        ORIGPHRASE = origphrase;
        MULTITERM = multiterm;
        MULTIWORD = multiword;
&