2004 年 2 月 27 日.NET Show：Longhorn Indigo（翻译）[Microsoft版权所有]
2004 年 2 月 27 日.NET Show：Longhorn Indigo（翻译）[Microsoft版权所有]
详情参见http://www.microsoft.com/china/msdn/events/webcasts/theshow/Episode040/LonghornIndigo.mspx
介绍
--------------------------------------------------------------------------------
Robert Hess，Microsoft 公司小组经理，节目主持人。
ROBERT HESS：欢迎收看新一期的 .NET 专题片。这一次我们要深入研究 Longhorn。在上一期专题片中，我们给出了该技术的概述；现在我们将逐一讲述它的主要方面。在本专题片中，我们将谈一谈 Indigo：它是什么，为什么很重要，最重要的一点是，我们将如何使用它来编程。首先请收看 Erica 带来的新闻。
MSDN 最新新闻
--------------------------------------------------------------------------------
由程序经理 Erica Wiechers 主持。
ERICA WIECHERS：大家好，我是 Erica Wiechers。欢迎收看 MSDN 最新新闻。
MSDN 为 Microsoft 博客们开办站点在 1 月初，MSDN 开办了自己的网络日记站点 — blogs.msdn.com。在这里您可以了解到最新事件，如实地看到微软人的内心世界。这个网站使用了与 weblogs.asp.NET 相同的网络日记基础结构，因此您在这两个网站中都能看到所列出的 Microsoft 博客。
Bill Gates 获得荣誉爵士称号也是在 1 月，英国宣布将授予 Microsoft 主席 Bill Gates 荣誉爵士称号，以表彰他对英国企业界的贡献。因为不是英国公民，Gates 不能在名字之前使用 "Sir"（爵士），但是他可以在名字之后加上 KBE。KBE 是 Knight Commander of the British Empire 的缩写，代表不列颠帝国勋爵士。
DevDays 2004今年 3 月，DevDays 2004 在美国 32 个城市举行。该活动主要关注使用 Microsoft Visual Studio .NET 构建安全的智能客户端程序和 Web 应用程序，帮助开发人员增加应用程序的功能和安全性。会议提供了几个课程，开发人员能够看到当地专家创建实际的应用程序，看到程序的运行，最后还能够得到代码。
Microsoft Tech·Ed 2004今年的 Tech·Ed 于 5 月 23 日在加州的圣迭戈举行，为期 6 天。这次大会为 IT 专业人士、网络和系统管理员、消息处理和安全性专业人士、架构师和开发人员提供了 400 多场技术会议。Microsoft 技术精英与一些业界顶尖专家为您展示了最新的 Microsoft 产品、技术和技巧、最佳实践和实际的演示。在 4 月 16 日之前注册可以比正常价格优惠 300 美元。
这里是 MSDN 最新新闻。我是 Erica Wiechers。
有关以上新闻的更多信息，请参考以下链接：
--------------------------------------------------------------------------------
Bill Gates 获得荣誉爵士称号
阅读 eWEEK 的文章：
http://www.eweek.com/article2/0,4149,1460012,00.asp
MSDN 为 Microsoft 博客们开办站点
访问 MSDN 网络日记站点：
http://blogs.msdn.com/
DevDays 2004
注册 DevDays 2004：
http://msdn.microsoft.com/events/devdays/
Microsoft Tech·Ed 2004
注册 Tech·Ed 2004：
http://www.microsoft.com/seminar/teched2004/default.mspx
技术探讨
--------------------------------------------------------------------------------
Robert Hess 与 John Shewchuk 谈论 Indigo 以及它的体系结构是如何演变以满足高级应用程序的通讯需要的。
ROBERT HESS：欢迎回来。我前面说过，我们在本节目中将把注意力集中在 Indigo 以及它与 Longhorn 技术的关系上。在未来的专题节目中，我们将讨论 Longhorn 的其他方面，但是让我们先从 Indigo 开始吧，我想，关于它，许多人有很多问题。为了讨论这些问题，我请到了 John Shewchuk。John，谢谢您参加我们的节目。
JOHN SHEWCHUK：谢谢 Robert。
ROBERT HESS：现在您在 Indigo 中的角色是什么？
JOHN SHEWCHUK：嗯，在我们完成了 Visual Studio .NET 和 .NET 框架以后，Brad Lovering、我和其他的几位架构师注意到，虽然我们已经有了面向服务体系结构的雏形，但是还有更多的工作有待我们去完成。我们知道需要抓住 Web 服务这个概念，真正地使它可靠、安全、具备事务性，真正地使体系结构完备起来，这样我们就能异步地发送消息了。因此 Brad、我和 Robert Wahbe 组建了 Indigo 小组，我扮演的角色包括：确定需要从事的领域，帮助充实技术，与其他公司（例如，IBM 和 BEA）就 Web 服务规范进行谈判。因此我在 Indigo 项目的整个实施过程中扮演了多个角色。
ROBERT HESS：那么，最初有哪些东西启发了您认为这个面向服务的体系结构会成功呢？
JOHN SHEWCHUK：嗯，您可以回想一下，当我们构建整个 Visual Studio .NET 和 .NET 框架项目的时候，Microsoft 创建分布式对象技术已经很久了。我们有 DCOM，它实际上是系统通讯的基础。Microsoft 在这些技术上投入了巨资，而与此同时，其他许多人使用类似的技术（例如，CORBA）进行构建，这时候，Web 出现了。Web 真正代表了另一种不同的方式。在 Web 上，我们使用过消息和包含有定义良好的格式（例如，HTML ）的 http 请求，而这个模型具有的特色是系统之间极好的可伸缩性和互操作性。所以如果有浏览器，我们定义好 HTML 格式后，就可以从 Netscape 浏览器、Opera 浏览器和 IE 查看，而且它可由许多不同种类的服务器提供。任何人都可以参与进来，因为我们理解这种架构和这些消息的格式。不仅如此，还有极为有趣的一面，那就是消息在系统中的传输方式。例如，一个路由器可以看到进入的消息，并决定应该跨不同机器进行负载平衡，以提供请求响应服务。因此我们可以进行基于内容的路由；可以进行负载平衡；可以进行 Akami 执行的操作（将信息分布到系统中去）。所有这一切都是因为这个中心的概念：面向消息、结构良好的通讯模式。
我们注意到整个事情的发展。从一方面来说，我们有 DCOM，有非常丰富的基础结构，具备可靠性、安全性、事务支持、完整的异步通讯，而另一方面我们又有了用完全面向消息的 Web 来完成任务的新方式。可是问题在于，我们能将它们融合起来吗？实际上，Web 服务正代表着两种重要方式的结合。面向服务的体系结构代表着将这些技术结合的顶点。因此说面向服务的体系结构（其中服务的概念包括定义良好的接口，我们可以通过消息与之通讯，消息通过 XSD 描述，消息模式通过 WSDL 之类的东西描述）为我们提供了一个真正优秀的、用于构建分布式应用程序的体系结构，还为我们提供了一种确保应用程序能够跨基于 IBM WebSphere 解决方案、基于 BEA 解决方案或者基于 Microsoft 解决方案的系统工作。因此它真的为人们提供了一种将以前无法融合的内容组成整体的方式。
ROBERT HESS：您在这个项目中干了多长时间？
JOHN SHEWCHUK：嗯，让我想一想。我在奥兰多的 PDC 之后离开，那应该是 2000 年，我想，我们几个就开始组建 Indigo 小组，此后就一直在干。
ROBERT HESS：Indigo 这个名字是怎么来的？
JOHN SHEWCHUK：啊，这个问题问得很好。我们到了加利福尼亚，我们一路开着车，思考着应该如何将解决方案合起来。我们在一辆车里，有 Robert Wahbe，我们去和加利福尼亚的一些公司交流，我们不停地想着项目的代号，我们想这个代号应该给我们提供一些灵活的感觉。我们不知道项目到底将变成什么样。因此我们决定应该取一个中性的名字；我们不断地乱起一些名字；颜色最后成了我们想到的东西之一，而恰好 Indigo 这个名字似乎对我们正合适。
ROBERT HESS：那时候没有人穿着靛青色衣服或者开靛青色的车吗？
JOHN SHEWCHUK：没有。
ROBERT HESS：现在我懂了，我们实际上提出了一种称为 Indigo 的技术，某种 Web 服务体系结构，它们也被称为 GXA 之类。这是如何适合 Indigo 整个远景的呢？
JOHN SHEWCHUK：当我们开始时，我们想让 Web 服务这个概念更进一步，加入安全性、可靠性、事务和异步模式。我们开始继续，写下怎么实现这些概念，这时一个非常有趣的想法浮现出来，我们可以实现，我们可以将其构建到 Microsoft 的产品中，但是我们不断从客户那里地听到以下声音：我们想使用您的技术，但是我们却处在由不同系统组成的环境中。不仅系统是构建在其他平台上，例如，Java、Apple 技术或者其他任何内容，而且我们还有旧式系统，有不同的版本，较老的基于分布式对象的方式实际依赖于与底层运行时非常紧密的耦合。随之而来的讨论是，如果我们要实现这个技术，需要确保与其他平台通讯，这样我们就必须与其他公司合作将其标准化。
导致这一想法的因素之一还包括我在 IBM 的工作经历；我为 IBM 工作时在 XWindows 系统上开发了 Athena 项目。我知道 IBM 是真正深刻关心面向服务的体系结构的其他公司之一。我认为我们应该与 IBM 沟通，这是我们以前没有做过的事情。第一个项目是安全方面的项目，我们说，让我们和他们谈谈我们关于安全性的想法吧。于是我们请到了许多 IBM 的人 — 包括经理和技术人员，还有 Maryann Hondo 这样的人，我曾经在 IBM 和他交谈过，以及 Tony Nadalin 和其他人 — 我们会聚一堂，我们这边拟定出要构建一个真正可伸缩的分布式安全系统都需要什么。有意思的是他们很喜欢。我们勾勒了一些基本概念；他们做出了回应；他们把意见都摆到桌面上；我们把一些各自开发的规范拿出来；我们把这些事情都合在一起，其结果就是 WS 安全规范。
这真的成为我们认为的业界有史以来最有趣的合作的基础。我们两个公司都有深厚的构建分布式系统的历史。在各种情况下我们都能畅所欲言，使具备领域专才的人在一起合作 — 比如安全领域的 VeriSign，还有 Tibco 的人在刚刚发布的事件处理规范中的合作 — 通过与这些领域的专家一起工作，我们能够将我们认为应该作为分布式面向服务体系结构基础的规范集中起来，这能使我们在未来 10 到 15 年立于不败之地。
ROBERT HESS：现在既然问题的关键在于与其他基础结构之类的内容进行通讯，那就意味着您必须与许多致力于此方面的其他公司合作，我知道在 Microsoft 内部我们的小组中做出这种决定是多么困难。似乎与其他公司合作是个很大的问题，无论他们是否与我们友好。整个情况是怎样的呢？
JOHN SHEWCHUK：好的，当我们与其他公司合作的时候，显然大家对系统应该如何工作的思路都不同。刚开始这确实是个大挑战。我们的思维方式太不同了，比如说，安全性的原理，或者是我们处理端点的方式，应该通过 URL 还是其他东西。解决问题的唯一方式就是坐下来，确认我们要从面向服务的体系结构中获得什么，处理细节，慢慢地，我们得到了越来越多体系结构的核心部分，实际上这开始变得简单了，因为我们不仅仅是分别处理每个部分。我们已经制定的规范中很棒的一点是，虽然每个规范本身很简单，很容易实现，还很小，但是有底层的整体结构，在我们开始构建系统的时候，我们逐渐意识到一组指导原则，这对于我们把所有新东西组合起来非常有帮助。所以令人激动的是，我们现在真的有了核心体系结构，大多数应用程序服务器厂商和业界的其他人对此都达成了共识，由此继续，基于核心部分构建更高层的系统部分就更加容易了。
ROBERT HESS：到目前为止有多少个规范了？
JOHN SHEWCHUK：我不知道确切数字，我们还在继续确认人们需要哪些新功能，但是核心部分可能通过一些基本功能就可以运行了。所有这些的基础就是大多数人都很熟悉的一组规范：用于描述消息交换模式的 WSDL；用于传输消息的 SOAP 技术；和基于它们的其他规范。通过 WSDL 和 SOAP，我们真正获得了通讯的基础。我们在构建一些更复杂的系统时学会的挑战之一是，SOAP 在其最早的版本中与 http 的耦合非常紧密。正如您所知道的，http 也是面向请求/响应的模式。而且，关于 SOAP 消息需要了解的关键信息之一，就是将执行什么操作。那是嵌入在 http 标头中的，还是一种请求/响应模型。因此下一个出现的概念就是 WS 寻址，WS 寻址提供了使消息无需采用请求/响应模型就能传送的基础结构。因此我们可以发送单向消息，它可以从一个方向发给您，我们经常称之为一个事件或者通知。它还能为我们提供一种方式来获取通常在 http 标头中的信息 — to、from 和 action，并在安全等条件下将它们转移到 SOAP 体中。
ROBERT HESS：因此这是一种类似于标准 Web 风格的请求，我获得了文档的 HTML，此外我还获得了描述路径和过程的标头，这是两个截然相反的东西。您谈到它们都放到一起了，因此差不多像是包容一切的 HTML。
JOHN SHEWCHUK：是的，我们从 HTTP 部分抽出，然后放入体内 — 噢，不是体内，是在 SOAP 消息本身里，在标头中 — 然后和 SOAP 体一起传送。因此我们最后得到的是一个完全自成一体的信息，与 SOAP 信息集保持一致，可以通过网络传递，当您收到它的时候，就获得了需要了解的所有东西，包括如何处理，来自哪里，去往何处 — 如果它不是给您的，您还需要将其转发。因此这其实是把东西都打包在一起。这是体系结构的关键部分，有趣的是它在整个结构中来得有些晚。
在此基础之上，我们已经获得了发送消息的能力，我们还有描述它们的元数据，WSDL，此外还有我们非常需要的东西，安全性、可靠性和事务。因此无论如何我们都要为此工作。安全性是最早的，然后我们开始充实事务规范。事务（尤其是协调规范）实际上是驱动 WS 寻址的组件，我们刚刚谈到了。然后是在此基础上的可靠消息处理。整个过程中，我们需要一种方式描述服务能够支持的各种选项，于是 WS 策略规范又应运而生了。因此这些都是非常关键的部分。寻址，WS 安全性和相关规范，WS 事务和协调等等相关规范，然后是 WS RM 规范，都与 WSDL 和策略相关。
ROBERT HESS：让我们花几秒钟分别谈一谈安全性、事务和可靠性，这样大家能够理解它们提供了什么，又是如何实现的。当您谈到安全性的时候，它可以意味着各种不同的意思。它可以意味着针对病毒的安全性，它可以是针对本不应该阅读消息的阅读者的安全性，也可以是知道消息到了哪里的安全性，但是我所假设的是如何可靠地处理消息。那么当您说安全性的时候，包含如何实现吗？
JOHN SHEWCHUK：嗯，分布式、面向服务的体系结构中的安全性是一个非常有趣的事情。如果您观察一下分布式对象系统，也就是传统上人们构建的那种系统，会发现这并不总是如此，但这里的假设是，这个概念意味着，在我与其他对象连接后，如果是安全的，就可以与它们通讯。当我们转移到真正分布式的世界以后，一切都可能在 Internet 上进行，是的，安全性需求更高了。我们需要确保对服务的所有通讯进行检查，是否有相应的凭证。但是这种环境中的一个挑战，就是如何足够快地进行这种安全处理？我们大多数现有的系统都是根据访问控制列表的概念构建的，其中我们获取某人的身份，然后查看表，看看是否他们有权限进行我们允许的操作。
但是现在想象一下您在分布式世界里，每秒钟都要看到成千上万，乃至成百万的消息。如果每次每个消息到来的时候，您都需要进行整个过程的话，事情就太糟了。验证消息从哪里来，到哪里去，是否有权限，是否没有修改，进行加密确保传输中没有人能够看到。如果我们有一种办法将一些如实际的权限之类的东西（一种能做某些事情的能力）直接与消息相关联，这不是很好吗？如果有一种大家都赞同的通用方式 — 既可以加密消息又可以签署消息，不是很好吗？这实际上就是 WS 安全能够支持的功能，这也是安全系统的核心模块。
ROBERT HESS：那么这本质上是给消息附加上一个证书了？
JOHN SHEWCHUK：是的，将证书想象成驾驶执照或者信用卡。我可以将它附加在 SOAP 消息的标头，其方式可以保证如果您将其取出，就能发现消息被修改了。如果您试图改变 SOAP 体，您能够发现 SOAP 体已经被改变，它不能匹配其中的签名。您需要能够做的是将其加密，这样就能确保机密性。现在人们已经有了很多加密方式，我们有 https，它是一种传输信息的极佳方式。但是 https 面临的挑战是，它的许多特性与 http 的相同，这使它与 http 传输而不是消息绑定得更紧。
想象一下以下场景，在大公司中总会发生的。他们从一个供应商那里得到一条消息，他们在 Web 服务器所在的网络外围获得。他们看到了它，决定，哦，您知道他们会决定什么？我们的一个姊妹公司，我们的伙伴之一，实际上已经处理了这件事，他们会转发消息的。好吧，如果他们真的能转发，那么与安全信息与消息无关，但是如果反过来它与传输有关，此时如果是 http，我们就不知道它从哪里来。它似乎来自我们的伙伴公司，如果我们有信任关系，还好。但是它限制了我们对 WS 安全的使用。
ROBERT HESS：这又牵涉到前面谈到的从传输标头中获取信息，并将其放入实际的消息体中。
JOHN SHEWCHUK：完全正确。现在，这都在进行，我们已经开发了这些规范，我们试图构建这个可以互操作的面向服务的体系结构。与此同时，我们构建了一个软件套件，构建了 Indigo。Indigo 的设计宗旨是成为性能极高的消息处理系统。它在消息的传输、加密和交换方面非常灵活。我们构建时考虑的因素之一就是确保能够很好地处理消息，我们还拥有了一个编程环境，建立在处理引擎之上，使开发人员使用 WS 安全极为容易。所以您可以想象，如果要获得我们谈到的这些规范，从头读一读，就能看到所有这些冗长的关于 XSD 和 WSDL 的叙述，要怎么看分组标头，要怎么去加密和规范化 XML，有很多代码要编写。事实上，我们曾经在 IBM 做过一个小试验，我们用这些规范构建一个托管供应链应用程序，计算代码行数，大约有 60，000 行，是您见过的最复杂的代码。我们请来了安全性、事务和可靠消息处理方面的专家，工作量真的不小。
因此 Indigo 的关键是我们获得了所有这些专门技能，我们将其构建到一组库中，使得 — 我们的目的是使得实现这些功能变得极为容易。那么举一个例子，您现在可以使用 .NET 框架，可以用它构建 WS 安全。您可以完全手工进行。您必须编写一些安全代码，还有许多其他东西，我们使它更加容易了。因为我们有了一个工具集，我的小组称之为 WSE，即 .NET 的 Web 服务扩展，它提供了一些极好的安全库，大大简化了安全代码的编写。但是 Indigo 所做的不仅是提供运行时消息处理环境，而且还提供一个真正伟大的编程环境，这构建在我们在企业级服务和基于属性的编程上所做的工作上，因此我们可以到我们代码中的一个入口点，我们可以用一个属性修饰它，也就是说，我需要它的机密性。属性所描述的指令将向 Indigo 消息处理引擎描述应该如何将相应凭证与消息关联起来，应该如何签署消息，然后以兼容和可互操作的方式在线上传输。
ROBERT HESS：这与编写一个 Web 服务的方式相同，您将 Web 方法附加修饰符。现在您附加修饰符。我们将在本专题节目后面看到实际的代码示例。
JOHN SHEWCHUK：是的，Steve 将为我们逐行展示代码。实际上我的意思是，Steve 是至关重要的“司机”之一。是的，他干得非常棒。他带来了低级的面向消息的世界，以及我们围绕企业级服务构建的模型，他们将其集合到根据以下简单概念构建的一个无缝、一致的整体中：端口、消息、信道和服务（它们作为构建块，供人们在丰富的环境中构建具有 Web 服务特征的应用程序）。
ROBERT HESS：好吧，我们接触到了安全方面的问题，以及其他相关问题。我们可能还要简单地触及事务和可靠消息处理，以及如何适合人们在其应用程序中的实际需要。
JOHN SHEWCHUK：很好。您知道，想一想今天的 Web。如果我正在构建一个 Web 站点，我想执行从 Web 订购比萨这样的功能，我不知道会怎么样，会有一些棘手的问题。如果我访问这个 Web 站点，输入我的信用卡，说我想订购比萨，我单击“订购”，可能不会立即返回。人们会怎么做呢？
ROBERT HESS：再次单击。
JOHN SHEWCHUK：他们很容易再次单击。所以现在我们发送了两条消息给服务器。
ROBERT HESS：我们知道自己并不想再次单击。我等啊等啊等啊，最后只好给人打电话问道，您收到我的订单没有？
JOHN SHEWCHUK：没有。
ROBERT HESS：是的。
JOHN SHEWCHUK：是的。所以今天开发人员必须为此开发一些逻辑，这很容易。弄一些用于传输的协议（例如，序列号或者唯一的 ID），以便进行对比，并编写代码。还需要将其存入数据库，以便获得某种数据库同步，然后获取订单，转帐，其中往往涉及事务。而且这种事务随处可见。因此我们听到了人们问的一些有关事务的问题，我要告诉您，一共有两个。一个是，嗯，您知道，就是我有多个现有系统，比如说我有一个用于处理公司财务操作的 IBM 主框架，而我可能有一些用于在制造板上进行制造的 Windows 框。我不会轻易更新财务数据库，除非我确定定单已输入到制造系统中。所以我会跨这些系统构建分布式事务。而这是我们的客户不太常见的，尤其是在企业内部。因此我们编写了称为 WS 事务的规范，其中的关键部分是已经独立成文的子规范 — WS 原子事务。而且它是一种以可互操作方式构建传统的两相提交样式事务的方法。我们所知的另一个问题是，假设您处在分布式环境中，而您却想跨公司构建原子事务，实际上，没有人这样做，他们只是构建能够理解如何进行补偿的业务逻辑。所以如果我发送给您一个定单，但随后我决定取消定单，这时我不会用事务来撤销定单，我要发送一则关于取消定单的消息，而且我会仔细检查取消定单的过程，这可能涉及到多个步骤。所以我们制定了一个名为 WS 业务活动的规范，用于描述如何构建一些面对补偿的系统。
因此我们认为，在事务空间中，人们需要一些基本设施与现有的系统互操作，尤其是进行两阶段提交的系统。我们有了很好的框架能够开始构建这些补偿事务。因此我们有了一个称为WS可靠消息处理的规范。我们的工作就是在 Indigo 中包含所有这些规范，构建到消息处理引擎中，提供丰富的容易使用的编程环境，这一点 Steve 将展示。这是围绕 Web 服务和 Indigo 的总计划。
ROBERT HESS：现在您不断地称 Indigo 为一种，我想是引擎，没有更好的词了。因此规范并不是 Indigo；Indigo 是实现了规范的引擎？
JOHN SHEWCHUK：没错。这些规范可以在各种平台上以各种不同方式实现。
ROBERT HESS：很有好处。
JOHN SHEWCHUK：是的，完全正确。因此 IBM 将它们构建到 WebSphere；BEA 将它们构建到他们的应用程序服务器中；我们与各种不同公司合作。有 SAP，他们在为其环境构建对协议的支持。而我们所做的是和其他人一样构建与这些规范兼容的软件，我们希望我们构建的软件和消息处理引擎能够非常快、非常灵活、功能强大。因此我们还要开发一个编程环境 — 我们认为这种组合是非常具有杀伤力的。
我们非常兴奋，认为已经在使用它们了。如果您构建一个分布式系统，包含公司内的应用程序，要与其他公司通讯，想使用面向服务的体系结构。传统上，人们需要编写一些协议，购买 MSMQ 或者 IBM MQ Series 这样昂贵的产品。而现在我们有了通用的解决方案。我认为面向服务的体系结构和 Web 服务的好处是结合了所有这些技术，我们将其平台化了。
ROBERT HESS：您提到了编程上的简化。您说这不仅是服务器端，而且也包括客户端。其好处是，现在我们不需要了解其他公司的细节，只要他们也使用基于 Web 的服务器体系结构就行。只要他们也遵守这些协议和规范，现在就可以非常容易地编程了。
JOHN SHEWCHUK：是的。此外，您使用了我们有点敏感的两个词：客户端和服务器。
ROBERT HESS：好吧。您可以谈一谈。
JOHN SHEWCHUK：我们不认为这些技术仅仅局限于客户端和服务器。因此我们使用术语服务，我们认为服务应该无处不在。我们的手机应该是服务，而人们传统上认为它是客户端。因此服务可以运行在各种环境，包括对等拓扑结构，传统的客户端－服务器拓扑结构等等。
ROBERT HESS：各种东西。
JOHN SHEWCHUK：任何东西。任何时候您的应用程序想通讯，我们认为都是可能的。因此 Don Box 在 PDC 演讲中做了一件有趣的事情。
ROBERT HESS：他总是干些有趣的事情。
JOHN SHEWCHUK：是的，那就是 Don。
ROBERT HESS：我相信那就是上一次节目中他所演示的。
JOHN SHEWCHUK：完全正确。而且，今天您通常采用的实际上是类似本地 RPC 机制或者命名管道。令人惊奇的是，Indigo 采用了以往不同的方式 — 不是套接字、命名管道、系统消息处理，我们的 MSMQ 技术，ASP.NET 风格的 Web 方法技术，远程处理，企业级服务 — 它把所有这些用一种可以互操作的、简单、易用的方式打包在一起了，它完成了整个体系。
ROBERT HESS：因此您知道如何从应用程序与边栏中的组件通讯，您还知道您需要去做什么与您的应用程序通讯，与另一个应用程序，跨越世界。
JOHN SHEWCHUK：确实如此。
ROBERT HESS：是的。现在当我们和人们谈到 Longhorn 的时候，他们总是会说，呀呀，Longhorn 好像还早着呢。他们想知道今天应该如何为 Longhorn 技术做好准备，才能使刚刚编写的代码不会到 Longhorn 到来的时候过时。编写要面向 Indigo 模型的代码时，最佳的过程应该是怎么样的？
JOHN SHEWCHUK：有几件事情大家可以做。头一件可以做的就是，现在可以不理会具体的发布日期，现在就开始了解它。今年我们还会发布另一个版本；我们希望它能更好。
人们可以做的另一件事情是，他们现在就要用面向服务的体系结构实现 Web 服务技术。这是可以的。您可以用 .NET 框架来构建 Web 服务，它很好地支持 WSDL 和 SOAP，将这些系统合一，您可以立即实现。现在我们还有了一个工具集，我前面提到过，.NET 框架 Web 服务扩展，增加了对诸如 WS 安全和 WS 策略等等的支持。
ROBERT HESS：规范变得真正重要了，因为大家都要遵守规范，那是跨网络的。
JOHN SHEWCHUK：是的。所以从这个意义上来说又回到了 HTML 和 http。只要我们获得了正确的网络上格式，我们就非常确信您能够使用浏览器查看它。
ROBERT HESS：以前，应用程序也想跨系统通讯，只是因为要求太高而无法实现。现在突然能够了。突然，您知道，计算器可以使用 Indigo 跨系统通讯，将我计算器上计算的数字发送给其他系统。
JOHN SHEWCHUK：好吧 — 我们就拿计算器做例子好了。假设您可以编写计算器，实现许多本地功能，但是它的功能不能太多，比如它能接受货币信息吗？或者它能够使用位置服务，这样您的手机不仅可以从银行查询货币，还能知道当前的位置，能够调用一个服务，找到我的当前位置，使用它来确定当地的货币，还能在计算器中提供更多功能。我认为有许多可能，但是人们不会在计算器中这样做，只不过因为这有些小材大用了。而如果我们能够让底层的工作分离 — 因为很显然应该与应用程序集成 — 但是如果我们能够移出许多基础结构工作，我想人们就更能把这些集成功能放入应用程序中。
这种技术的另一个例子是游戏技术或者流音乐技术。当 Microsoft 的人想构建流媒体技术时，最开始的设计是以 TCP 的使用为中心的，因为 TCP 给了您许多基础结构。但是您知道吗？TCP 不能完全提供媒体所需。TCP 有一个特性，如果您错过了一个分组，就会使管道停止，要求分组重发。这对于音乐而言可不好。那么怎么办呢？转而使用 UDP 的话，工作量很大，对不对？而通过使用 Indigo 这样的技术，使用预定义的规范，比如可靠消息处理，我们能够制定一个协议，比如更适于您的应用程序的流传输协议，无需进行底层网络工作。
ROBERT HESS：今天我们知道我们有了 .NET Alerts 和类似东西，它支持这些功能，但是这要求在信道之外有中间人。您实际上在谈 Indigo 对它的支持，我们称为客户端到服务器或者服务……
JOHN SHEWCHUK：完全正确。
ROBERT HESS：……无论创建的是什么，它们都依赖于第三方支持。
JOHN SHEWCHUK：是的。所以许多大型的企业级应用程序依赖于基于事件的、面向消息的解决方案。Tibco 是非常流行的产品，用于分发股票信息。同样的模型，同样的面向服务的模型，我可以说，我对这种信息、这种信息感兴趣，而生成这些信息的人不用知道谁可能获得这些信息。这样耦合就松散多了。这就是为什么我们称之为消息总线的原因。
ROBERT HESS：连接到总线。
JOHN SHEWCHUK：是的，连接到总线，这样您可以获得所有的消息发送方式。实际上，Indigo 提供给您的是总线连接器。因此您要与端口连接，Steve 谈到过，它给您一个网络空间中的地址，然后您通过端口、信道获取并接收消息，等等。这是一种连接各种东西的极佳方式。
ROBERT HESS：非常感谢。我真的很高兴与您谈论 Indigo，我搞清楚了很多问题。作为 Indigo 教父，如果您要总结一下自己的思想，对观众说一句话，告诉他们 Indigo 是什么，为什么应该关注，该怎么说呢？
JOHN SHEWCHUK：噢，我不知道。我的意思是谈论它有很多种方式，但是如果您真的想更加简洁，就应该把它想象成通用的通讯器。它是您工具箱中应该有的一个小工具，可以与任何东西连接起来，我们认为连接性将是未来的方向。
ROBERT HESS：好吧。非常感谢来到我们的节目，John。
JOHN SHEWCHUK：非常感谢，Robert。
ROBERT HESS：希望这能够使您理解 Indigo 是什么，以及它在应用程序的通讯基础结构中的角色。下面我们将实际地看到一些应用程序编程，以及 Indigo 开发的应用程序是如何在各种平台上与其他应用程序通讯的。请不要走开，等一会儿我们再回来谈一谈编程。
轻松时刻
--------------------------------------------------------------------------------
防火墙安全视频
走进编程人员的世界
--------------------------------------------------------------------------------
Robert Hess 对 Steve Swartz 进行了访谈，讨论如何容易地用“Indigo”为您的 .NET 应用程序添加安全性、事务性、可靠的消息处理。
ROBERT HESS：欢迎回来。现在您已经从体系结构的观点了解了 Indigo，现在该是我们深入和实际地展示编程和代码的时候了。我们都知道，如果不能编程的话，我们就无法使用它。这里和我们谈话并使用 Indigo 编程的是 Steve Swartz。嗨，Steve，感谢您来到我们的节目。
STEVE SWARTZ：嗨，你怎么样？
ROBERT HESS：非常好。现在我理解了您负责的是与 Indigo 相关的某种编程体系结构。
STEVE SWARTZ：是的，我的小组负责 Indigo 顶层的编程模型。还负责基础结构，如何从获得从 A 点到 B 点的消息，编写所有传输。我的小组在其上构建了一个编程模型，使得构建应用程序更加容易，所以我的层次很高。
ROBERT HESS：编程模型是什么意思？我是说 John 谈到了 Indigo 的规范，可以想象成分组、传输和其他东西。但是说实际一些，屏幕上的代码如何真正地获得这些 Indigo 消息呢？
STEVE SWARTZ：我的工作就是如 John 所说的在不知道规范之类的情况下实现整件事情。而实际上，我们只想构建一个事务处理应用程序，或者构建一个安全的应用程序。我们的目标与之类似。首先我们有许多产品，我们有 ASP.NET Web 方法、.NET 远程处理和企业级服务。我的一个设计目标是让熟悉这些产品中任何一种的程序员了解 Indigo，并且说，啊，这是我的产品的下一步，我将获胜。因此我希望一个 .NET 远程处理技术人员能够说，啊，这看上去很熟悉呀。对熟悉企业级服务和 ASP.NET 的人也是如此。
ROBERT HESS：这不像一个 Win 32 程序员学习如何进行 Ole 编程那样。
STEVE SWARTZ：是的。我们努力尽可能避免这种情况。恰恰相反，我们认为每个这些产品都有用。因此我们所做的是把所有有用的东西放在一个模型中，但是您不用买 6 本不同的书。我们想让一个产品完成所有功能。
ROBERT HESS：可是图书出版商要对此抱怨了，对不对？
STEVE SWARTZ：我可不是出版商。当然我有一些最好的朋友是。我们的第二个目标是，在大多数其他编程模型中，需要不断在高层的编程和基础结构之间跳跃。编写 .NET 远程处理代码是很容易的，但是如果您开始学习添加您自己的传输时，复杂层次就有很大的跳跃。我们想让基础结构的每一步都非常简单。您不用把我们的高层编程模型远远地丢在身后，可以一次获得所有这些模型。
ROBERT HESS：这听上去似乎很难。
STEVE SWARTZ：这很有趣。
ROBERT HESS：让我们来看看代码吧。
STEVE SWARTZ：好吧。第一个例子是 — 我这里有三四个例子。代码既有用于客户端的，也有用于服务器端的。我们将首先演示服务器端，因为服务器端通常定义协定，然后演示与之通讯的客户端。
ROBERT HESS：你知道，John 说清楚了客户端/服务器的问题，然后提出了服务概念，因此我们将演示相交互的服务。
STEVE SWARTZ：没错。我是个守旧派，因此我提到“服务器”一词的时候，说的就是些代码 — 等待指示它们要做些什么。
ROBERT HESS：那就说代码吧。
STEVE SWARTZ：就说代码。有意思。那么如果我想将其变成一个服务，该怎么做呢？我添加一个服务属性，就是一个简单的服务属性，告诉系统我可以将这个类注册为服务了。如果我不添加任何其他东西的话，它就是一个空服务，没有方法。为了使服务中有方法，我使用服务方法属性，将其放在这个方法上。这样我就定义了一个 CLR 构造，一个包含隐含端口类型和方法的服务。
[Service]
public class OrderProcessor
{
[ServiceMethod]
public void Place (string CustomerNames, string ProductName, int Quantity);
{
// Process Order
}
}
ROBERT HESS：您谈到过端口类型，端口类型是一个定单处理器吗，它们是从哪儿来的？
STEVE SWARTZ：这是为了使例子最简单，您不需要显式定义端口类型，我们会为您定义一个包含服务上所有服务方法的端口类型，但是在这个最简单的示例中，我们假设一个服务只能实现一个端口，您也不需要写入该接口，您可以构建类。当您使用一个产品，而且不想进行复杂操作时，采用的就是这一模式。因此接下来我会看看缺失的类；该类是实现将宿主该特定服务的主群组的类。所以当我运行该类时，会启动服务。现在 Indigo 也使用 ASP.NET 宿主模式，使用与其相同的语法，而且在第一行使用一个小尖括号通知 ASP.NET 进行编译并加载特征。这里我要为您演示如何在您喜欢的进程中宿主 Indigo。该进程可以是 Windows 服务、控制台应用程序等等。现在我们要看一下 John 谈到的内容。在启动 Indigo 应用程序时我首先要创建一个端口。这里我已经创建了一个新端口，我使用一个地址创建了这个端口，我要使其在 myServer 可用，这就是我们谈到的端口。
public class Host
{
public static void Main(string[] args)
{
Port port = new Port(new PortAddress("http://myServer"));
port.Services.Add(new ServiceAddress("/OrderProcessor")，typeof(OrderProcessor));
}
}
ROBERT HESS：我们有了一个 http 地址，myServer。现在实际上它是一个物理名，与这个机器关联的 DNS，还只是一个名字而已？
STEVE SWARTZ：只是名字而已。它是这个机器的虚拟根。
ROBERT HESS：因此它与命名管道不同，其他应用程序能够知道这个名字实际上是个物理访问地址。
STEVE SWARTZ：是的。为了保护这些内容（它们涉及到脱机通讯，显然十分重要）的安全，ASP.NET 小组和 IIS 小组正着力使其和命名管道一样容易。所以当我安装该系统时，我能自动添加 vroot，由此我获得了简单的 XCOPY 安装，和使用 ASP.NET 获得的一样，但这是自动添加的。然而，如果我手动进行添加，就必须建立可供系统脱机查看的地址。然后我们来看看端口，好的，该端口有许多集合。这些集合和方法可用于处理各种内容。为了宿主服务，我要获得服务集合，并将其服务类型添加到该端口。所以我继续创建端口，这个特殊服务将运行在 myServer（该端口的地址）上，以及 myServer 下的 OrderProcessor 中。这里我已经获得了一个服务地址和命令处理器类的类型，而且我已经将它们添加到了该端口。这非常简单。我创建了一个端口，它是网络空间中的命名位置，这里是 myServer。然后我在其自身的一个特殊位置添加了一个服务。我执行该操作时，该类正等待消息的到来，随后它会处理和应答它们。因此说我是在编写一个类并将属性放入其中，然后我创建一个端口并添加该类。这是构建服务的基本机制。
ROBERT HESS：然后我假设所有您所做的就是一个 port.place，它会在定单处理器中调用 place 对象吗？
STEVE SWARTZ：等一会儿我们会在客户端看到。
ROBERT HESS：好吧。
STEVE SWARTZ：但是还有一件事情很有趣，值得思考。如果我想让这个服务是安全的，只要添加一个称为 ServiceSecurity 的属性便可。如果我想执行此操作，可以使用该属性上的多种属性值进行保密、集成或加密设置。因此为了使其安全、可靠或是经事务处理的，只需在适当的地方添加适当的属性便可。因此如果我想使整个服务都安全，则可以放入 ServiceSecurity 属性。如果我想将事务添加到某个特定方法，则可以使用 TransactedCoupling 属性，这使我能够继续在此放入属性，它们会表明我想将事务从一个服务传递到另一个服务，如果我是本机用户，就可以执行该操作。如果我要同远方的人进行会话，也可以说不想进行此传递。因此对于 John 所谈到的有关添加应用于不同标准的协议和标头的操作，您只需将某个属性添加到适当位置，便可以使用该系统中的这个功能。
[ServiceSecurity()]
[Service]
public class OrderProcessor
{
[TransactCoupling()]
[ServiceMethod]
public void Place (string CustomerName, string ProductName, int Quantity);
{
// Process Order
}
}
ROBERT HESS：实际上使用这些端口和服务业务逻辑不必更改；因为您已经在那里进行了声明，即所有内容以和以前同样的方式传递。
STEVE SWARTZ：是的，所以说，这是用于添加这些行为的企业级服务策略。企业级服务有一个模型，您的应用程序实际上只关心业务逻辑就行。要具有强健的应用程序，您还需构建一整套其它内容，例如，可靠的消息处理、安全性系统、事务系统和实例池等。这些内容在 Indigo 中都是作为属性实现的，所以开发人员不必考虑如何构建它们；它们只能使用属性来获得这些功能。现在让我们来回答您的有关从客户端使用该功能的问题。客户端是一个相当简单的内容。在启动的服务器端，实际上我必须具有该服务的实现，这样才能在定单到达时处理它们。当我启动服务器端时，我需要接口，因为我要利用接口进行方法调用，而且将发送一则消息使得客户端上完成该操作。在 ASP.NET 中有一个非常类似于 WSDL 工具的工具，它叫做 WSDL.gen，用于查看服务器上的协定信息、策略和 WSDL，并且能生成响应该服务的接口。这不仅仅是您能使用的方式；我们稍后将为您显示如何在客户端使用各种不同的接口。如果您正在同时部署服务器和客户端，则可以从服务器中携带该接口来使用。但重要的是，在客户端上，您只有表示此处已有方法的接口，本例中是 Place 方法。它也是一个服务方法。但是这里使用的是称为 IOrderProcessor 的一个接口。
[ServiceInterface]
public class IOrderProcessor
{
[ServiceMethod]
public void Place (string CustomerName，string ProductName，int Quantity);
{
// Process Order
}
}
现在我还可以构建一个称为 IOrderProcessorChannel 的接口，它实现了 IOrderProcessor 的应用程序方法和 IChannel 上的基础结构方法。IChannel 是一个用于和信道会话的接口。服务器端上有服务和端口，它们是 Indigo 中的头两大要素。我们现在看到的是信道，它是 Indigo 中的第三大要素。
public interface IOrderProcessorChannel : IOrderProcessor，IChannel
{
}
它的一个方便之处是，当我使用信道时，我想调用我自己的应用程序方法，通知下这个定单，但是我还需要在完成后关闭信道，从而释放在操作系统中使用的用于此传送机制的资源。因此我可以将这两个接口合而为一，只要我有 IOrderProcessor 的方法；事实上我可以使用任意接口，使用它是很方便的，因为我避免了类型转换。因此这是我初始端和客户端上的应用程序，我有 Main 函数，这里我将创建一个新的端口。我只是创建默认端口，然后有配置信息，它将告诉我端口在什么位置。我不必关心这一点，因为我并不接收消息。这运行在我家里的机器中，我不想任何人发送消息来启动工作，我只是在与其他人进行会话。然后我继续创建一个 IOrderProcessorChannel。这是一个刚才演示过的接口，我能使用它的方法与用于直接处理信道的服务和方法进行会话。我打开了该端口，并写下 CreateChannel。因为 Indigo 运行在 Windbey 上，所以我有特定于该接口的 CreateChannel，而且我将它传递到该服务的地址，请记住是 myServer/OrderProcessor。因此我创建端口，创建信道，然后调用方法，您可以看到这些方法调用的外观和它在其他 CLR 上下文中的一样。完成该服务时，我关闭了它。因此过程是创建端口，创建信道，使用信道，关闭信道。
public class Buyer
{
public static void Main(string[] args)
{
Port port = new Port();
IOrderProcessorChannel Service =
port.CreateChannel("http://myServer/OrderProcessor");
Service.Place("Ryan", "Laptop", 1);
Service.Close();
}
}
ROBERT HESS：然后您实际上使用信道的时候，实际上幕后是在把这些东西封装到一个 XML 消息包中，调用标准 Web 服务，跨越网络发送数据包，调用另一端的接口，如果有响应返回就处理响应。
STEVE SWARTZ：完全正确。在最简单的情形下，我没有安全性、事务或可靠性需求，这个方法调用就变成了一个标准的 XML SOAP 体，而且我们有各种方式供您控制是否进行 DOC 或 RPC，不同系统使用的所有内容，我们需要它来进行交互操作。但我只想获取该调用，并将它转换为一个 SOAP 消息。放置于这里的标头不是该系统常用的标头，而且这里也没有该消息。如果我在另一个端上具有事务和安全性，则它们会作为策略显示在元数据中，比如说，我要接收您传来一个事务，那么您最好为我提供一个标识，因为我需要安全性。因此结果是那些属性也会显示在该接口上，系统将为您生成它们，而且这些属性将使得该系统根据执行那些功能的标准添加标头。因此如果我具有一个该方法的事务属性，在我进行调用之前，该事务属性将使得代码运行，这会将该标头放入该消息中。所以说这都是关于底层消息的，而如您所知，这是无关紧要的。
让我们看下一个示例，它更复杂一些，能够说明几件事情。首先说明了我使用很简单的结构，例如，int 或者散列表（CLR 类型），系统就知道如何将其自动换为 XML。但是如果我构建的是我自己的类型，我就需要告诉系统如何转换。Indigo 中的一个革新之处就是序列化机制，您可以看到我放在类中的 DataContract 如何使用这种机制。因此说类本身有 DataContract 属性。我使用的、要显示在网络上和其他端上的每个成员都有 DataMember 属性。
[DataContract]
public class OrderInfo
{
[DataMember]
public string CustomerName;
[DataMember]
public string ProductName;
[DataMember]
public int Quantity;
}
现在很明显可以看出，当这些类型从网络的一端移动到另一端时，Indigo 只关注 DataContract 匹配。在另一端，我可以使用一个包含这三种属性以及其他内容的类型。该系统对此不会太介意，因为它可以在一个端上获取该类，并将它转换为网络表示形式，然后在另一端将其转换回类。必须匹配的内容是 DataContract。因此让我们想一下，如果我们能执行 .NET 的 CLR 操作，则可以在一个调用的两端共享同一类型。我们也可以执行 ASP.NET 的操作，它总会为您创建类型，以便您的会话的两端去耦合并版本化。
ROBERT HESS：因此这两者中的任一个都可以。
STEVE SWARTZ：您可以选择。当您运行 WSDL.gen 并设置服务时，可以指示它以去耦合的方式运行，在本例中，我们会演示隐藏遗留类型的 ASP.NET 技巧，如果您愿意，也可以在使用同一类型的两端进行 .NET 远程调用。要进行该操作，只需考虑去耦的方式，类型共享方便与否，以及成本的高低。
现在服务器端我显式声明了我的接口。请记住，在第一个示例中我只有一个服务，而且我说明了接口的概念。现在我说这是一个用作两端之间协定的接口。这称为 IOrderStatus。有趣的是，与上面不同的，这个服务方法调用中，这个属性将它告诉给 OneWay。因此我有一个 OneWay = true 属性。常规的服务方法是具有请求/响应模式的 RPC 方法。当我使用 OneWay = true 时，这些方法就变成了 Fire 和 Forget。
[ServiceInterface]
public interface IOrderStatus
{
[ServiceMethod(OneWay = true)]
void Accepted();
[ServiceMethod(OneWay = true)]
void Rejected();
}
您需要在客户端调用方法，并且发送消息。然后该服务会获得消息，如果在比较近的网络上，它只需花上几秒，如果有队列，可能花上几天。因此它是异步的，它并不是请求/响应类型的异步 CLR，而是 OneWay 方法。您可以看到，实际上这里有两个此类接口，对于异步编程来说，比较有趣的是，当我使用 Fire and Forget（发后不理）模式，实际上，我只想给您发送信息而不想获得响应的情况是很少的。因此我要设置一个名为 IOrderProcessor 的服务接口，它会获取传入的空间请求，我们前面已经见过了，但它是一个 OneWay 请求。而且当我想和您通讯时，它会声明我要用在 IOrderStatus 上进行。所以说我的 DuplexContract（表示我的返回协定）是 IOrderStatus，而 IncomingContract 是 IOrderProcessor。您可以看到，我们现有产品的功能是很新颖的。它们是基于 RPC 的，易于设置发收消息的模式，比如我给您发送三个消息，您给我发送两个消息；我们处在点对点状况下。我要告知您，我们要谈论更加灵活的消息处理模式了，因为我们是在真正地进行消息处理。
[ServiceInterface]
public interface IOrderProcessor : IDuplexContract
{
[ServiceMethod(OneWay = true)]
void Place(OrderInfo order);
}
ROBERT HESS：是的。
STEVE SWARTZ：通过使用 OneWay = true，我们从 RPC 模式转环到了消息处理模式。这是一个我和您说过的例子，我只是添加一个带属性值的属性，以便转换模式，这正是我们的目标之一。我们认为，要获得这些功能，不必转换到另一个编程模式或是一种完全不同的策略。只需在属性中加以改动就好了。因此现在我们已经实现了更加复杂的接口。我们获得的第一个 Place 是一个简单的请求/响应模式。我在其中给您发送一个下定单的消息，您给我发送回一个 Accepted 方法或 Rejected 方法。因此这使我的服务更加复杂。使用它们时，我实现了一个 Callback 属性，它是 IDuplexContract 的一部分，当我运行服务时，我对每个调用使用了 Callback 接口，这些调用足可以使我发送回消息。当我将服务作为侦听器启动时（我只是接收消息），在消息到达后，接收时我使用了常规的响应方法，即 Place 方法，但我能获得 Callback 属性，转而调用其上的方法与发送方通讯。我不必与发送方重新建立连接，因为这次连接是我自动获得的。这是一个双向通讯模式，其中带有的任意消息处理模式都是由该协定定义的。
ROBERT HESS：那是嵌入在您开始获得的数据包中的。
STEVE SWARTZ：完全正确。数据包会告诉基础结构如何进行获取。基础的 Indigo 传输足够聪明，比如说，如果您使用 http，我会知道如何将消息传回给您；如果您使用 TCP，很容易双向发送消息。它根据所使用的传输相应地进行处理。因此我可以在基础结构中使用 Callback 属性，以便使消息调用返回给发送方。想一想在 .NET 远程处理中该怎么做。我必须给您传递一个接口，您才能回调我。这是个非常简单的机制。因此，我已经说过了，在我的 Place 结构中，Place 调用可以在队列上发送，也可以用任何一种机制发送；客户端可以长时间脱机。我继续象以前一样进行处理，而现在我没有执行请求/响应，实际上，我使用 Callback 将发送回一个消息，以通知他们我是接受了定单，还是拒绝了定单。当然，宿主还是一样的；我的定单处理器都是在这个极其简单的宿主模式下运行的。
[Service]
public class OrderProcessor : IOrderProcessor
{
private IOrderStatus _Callback;
public IOrderStatus Callback
{
get { return _Callback; }
set { _Callback = Callback; }
}
public void Place(OrderInfo order)
{
bool OrderStatus = true;
//Process order
if (OrderStatus)
{
_Callback.Accepted();
}
else
{
_Callback.Rejected();
}
}
}
ROBERT HESS：嗯。这里有些代码我们以前见过。
STEVE SWARTZ：是的，完全正确。如果我需要自动宿主的话，这也可以在 ASP.NET 中完成。因此说，在客户端上，我仍然有同样的信息，而且 WSDL.gen 工具将为您构建 DataContract 和 DataDefinition，而不是像在 ASP.NET 中那样构建类，这对于与服务通讯是必要的。ServiceInterface 也是必须构建的。因此开头的代码定义了数据对象，这是协定的一部分，还有三个 DataMember，这与前面一样。这是与该接口相关的代码，该接口用于将消息发送给我。这里我有两个 OneWay 消息，即 Accepted 和 Rejected，现在我要获得它们。最后，这里是我用来给其他人发送消息的接口的代码。现在我要创建 OrderProcessor 接口，或者和以前一样创建 OrderProcessorChannel 接口。这次我没有使用请求/响应实现来发送消息，而是使用了 OneWay Place 接口和 Callback 接口。所以现在我必须在客户端上实现 Accepted 和 Rejected。因此我必须给系统提供该接口的一个实现，以便消息到来时，我能捕获消息，并对其进行处理。
这样，我的 Buyer 对象也更加复杂了。在我的 Buyer 对象的 Main 函数中，我创建了端口和服务，与以前一样，但是现在我必须给它一个带有代码的新版本，以便处理返回的消息。因此我使用了 Callback 属性，并分配了一个新的 Buyer 服务。在和往常一样使用过该服务后，我填充了该膝上型电脑对象，并进行了调用。此处的不同在于，我现在创建的实例需要挂起等待才能捕获消息。所以在调用 Accepted 或 Reject 时，会调用此处的方法，关闭服务后操作结束。这里我要创建接口，就象我在 RPC 模式中进行创建一样，但是我也必须创建一个实例，以便捕获返回的消息，然后我要处理返回的消息。这个示例可能不是很有趣，您会觉得它的功能和请求/响应模式差不多，但是如果您考虑一下更复杂的消息处理模式 ，就会发现它的魅力所在。
public static void Main(string[] args)
{
Port port = new Port();
IOrderProcessorChannel Service =
port.CreateChannel("http://myServer/OrderProcessor");
Service.Callback = (IOrderStatus) new Buyer(Service);
OrderInfo laptop = new OrderInfo();
laptop.CustomerName = "Ryan";
laptop.ProductName = "Laptop";
laptop.Quantity = 1;
Service.Place(laptop);
}
public void Accepted()
{
// Process successful order
_Service.Close();
}
public void Rejected()
{
// Process failed order
_Service.Close();
}
ROBERT HESS：嗯。这确实有些意思，当我编写代码实现这个 Accept 和 Reject 模型的时候，我得重新思考如何编写我的应用程序，但是需要考虑的也并不多。
STEVE SWARTZ：确实如此。您不妨想一想，无论您何时构建分布式应用程序，总是必须考虑你、我之间使用的协定。因此若使用老技术，我需要考虑 DCOM 接口，当我用 Ole 编程的时候，还要考虑类型库和 ITL。如今我通过在代码中添加属性，就指定了协定。我有一个工具将这个代码转换成 WSDL。WSDL 是真正的协定语言。虽然我必须仔细思考它，但比较理想的是，它更为显而易见。因此无论您何时构建分布式应用程序，都必须首先考虑协定。与现有模式相比，它的唯一复杂之处是具有更多的协定支持。在 ASP.NET 中，我可以使用请求/响应模式；这里我可以使用任何消息处理模式，而且如果我需要更复杂的消息处理模式，也可以轻易获得。
它类似于 VB 编码器，您可以从中获取来自于系统的大量事件和随机命令。您需要能够在一个又一个事件到来时思考出到底发生了什么，在这种情况下，进行消息处理时，通常是使用一小段独立代码来处理特殊消息。如果您想不清楚涉及的状态机，它会变得非常复杂。还有一点比较重要，需要您牢记，那就是如果想使该应用程序安全、可靠或是经事务处理的，则要使用我在 RPC 示例中用过的属性。我已经将它们放在描述服务器上接口的方法上了，而且内置于发送给客户端的 WSDL.gen 工具中。只需添加这些属性，便可以添加以下所有行为 — 安全、可靠或是经事务处理的消息处理，一切都是这么的轻而易举。
ROBERT HESS：现在如果您在一端设计了一些接口，有人使用这些接口，然后您决定使接口变得安全、可靠或是经事务处理的，等等，会发生什么呢？需要别人在其端上重新编译或生成实例吗？
STEVE SWARTZ：这个问题的答案是可能需要。我们需要考虑我们谈的是什么。如果我们能够本地改变无需了解的行为，例如我想开始使用另一个传输，系统协商传输，而实际的代码没有意识到。这样我就能够在服务器端添加那种行为，而不会导致客户端发生更改，但是使用属性添加的其他行为实际上定义了你、我之间的耦合关系。例如，如果我需要您传一个事务给我，您必须了解自己正在创建一个事务，您事务域中的所有的其他错误需要与我的事务协调。因此您在编写应用程序的时候需要了解这一点。您不能不做考虑就向系统中添加事务。那是需要在开发时了解的东西。
因此不能简单地用是或者不是回答您的问题。有些 Indigo 功能不涉及耦合的增加，只是以不同的方式使用数据。但是其他功能比如方法的签名，我要添加方法签名的话，您是需要知道的。安全属于第一阵营。但是事务属于第二个阵营，因为如果您在处理事务性系统的话，您需要在开发时做好计划。
ROBERT HESS：因为这是不同的过程，您需要知道如何打开事务之类的内容。
STEVE SWARTZ：完全正确。因此我们来看第三个示例。这是一个将显示各种我们能使用的不同签名的示例。到目前为止，我们已经看到了非常简单的签名，其中我们传送的内容类型与 CLR 类型很像。因此这个示例会朝那个方向更进一步。在我这次构建的类中我实现了一个小的路由器。我实现的类是一个 Route 类，我已经用来自 ASP.NET 产品的序列化器将其转换为可序列化为 XML 的内容。我之所以选择这个序列化器，而没有选择标准的 CLR 序列化器，是因为后者是使用 DataContract 实现的，旨在获取 CLR 间的内容，或是转换类型等等。如果您的协定是面向类型和编程模型的，使用该序列化器就对了。相反，如果您必须对一个预存在的特殊协定进行编码，或者某个行业联盟已经定义了下定单的方式，或者有较难表示的特定 XML 协定时，可以使用 XML 序列化器创建数据，以便针对该特殊方法将架构赋予给系统，并且以正确的方式将对象的内容序列化为架构。因此如果您要处理特殊的协定，应该使用该系统。
[XmlTypeAttribute(Namespace = "http://schemas.Routing.com")]
[XmlRootAttribute("Route", Namespace = "http://schemas.Routing.com")]
public class Route
{
[XMLAttribute]
publid string Name;
[XMLAttribute]
public string Action;
}
[CLSCompliant(false)]
[Service]
public class Router
{
[ServiceMethod(Format = ServiceFormatter.XmlSerializer)]
public void AddRoute(Route route)
{
//Add Route to Router Table
}
[ServiceMethod(OneWay = true, unmachedmessagehandler = true, Format = ServiceFormatter.message)]
public void AllOtherMessage(Message message)
{
//Route message
}
现在我有一个 Router 类了，这个 Router 类很有趣。其工作方式是，其中有一个 AddRoute 方法可以调用，当然当您调用的时候，我添加了一个路由。因此我按名称获取该路由，然后使用一个规则来确定在何处发送消息。但是该系统能够获取您可以发送的任何其他消息，以及目前的任何方法，它将其作为 Indigo 消息来处理，然后路由它们。因此说，第一种方法看起来与其在前面示例中的功能非常类似。ServiceMethod 调用上有 XML 序列化器属性，我正在路由中使用它。我使用了一个不同的序列化器，这是因为我必须考虑将签名转换为消息。我必须清楚一个事实，那就是它正在进行自己的序列化。这样如果这个类获取了称为 AddRoute 的消息，就调用这个方法，路由表中就添加了该路由。
第二个方法更有趣一些； 它是一个 OneWay 方法，名为 UnmatchedMessageHandler。其意义是任何到达这个服务的消息都不是 AddRoute，更一般的情况下，任何来到的消息，如果我以前不知道，都会使用这个方法来处理。因此有了该方法，您可以发送给这个服务任何内容。如果您看到第三类内容，它会显示说那个消息格式是一个消息。这意味着，我不会获取原始 Indigo 消息，而要将该消息作为一组 CLR 类型、三种整型和字符串来获取。因此当调用此方法时，签名只是一个带有实参的简单调用，这里的实参是消息，而且是全内核 Indigo 消息。它具有体 XML 体阅读器，您可以使用 XML 编程工具获取任何感兴趣的数据。它上面有 SOAP 消息标头，其中包含安全性信息。因此在这一层编程时，要自己动手进行此类操作。我的许多朋友都喜欢这种编程，但这的确十分复杂。要写很多代码，而且用的都是极限语言。进行这种编程的人疯狂得都快飞起来的，这就像您在 MTV 中看到的一样。但是它也有一个优点，那就是它允许我设置路由器，此外，它会将接收到的任何消息发送给知道如何处理的人。
因此，客户端上的签名可以完全不同于此。所以如果我继续看一下该客户端，我会以一个特别方式使用该路由器，与使用其它东西的方式都不同。在头两个示例中，我使用的签名与服务实现的签名多少有些相同，然而此处我可以使用一个仍然知道如何进行路由的应用程序，它有几个使用路由器的方法。因此我还是用这个 Route 类，我可以使用其他东西，只要有同样的 DataContract，但是本例中我只是复制了它。现在我构建了一个接口，我要用它进行通讯，而且我知道，对于路由器而言，该端口类型称为 IRouter，因此我必须使用相同的端口类型。但是我将使用完全不同的接口。我的接口仍然实现了 AddRoute 方法，因为如果要与路由器通讯的话，就必须如此。但是此外我还要处理所有其他的消息方法，我打算处理 Greetings 和 Salutations 方法。Greeting 方法发送一条欢迎词，Salutation 方法发送许多条。因此该签名非常非常不同。我多多少少将使用的服务去耦了。
[ServiceInterface(ActionBaseUri = "IRouter")]
public interface ISendGreetings
{
[ServiceMethod(Format = ServiceFormatter.XmlSerializer)]
void AddRoute(Route route);
[ServiceMethod(OneWay = true)]
void Greeting(string greeting);
[ServiceMethod(OneWay = true)]
void Salutations(int count, string greeting);
但是使用这个接口与其他任何 Indigo 接口似乎一样。我要连接端口，我要创建信道，当我编写这些路由的时候 — 在这个示例中我添加了两个路由 — 这些代码与我通常情况下使用的代码一样。但是看一看吧，我能够用 Greeting 签名或 Salutation 签名进行调用；服务对此一无所知。它把它们当成原始消息处理了。
Port port = new Port();
ISendGreetingsChannel Service =
port.CreateChannel("http://myServer/SendGreetings");
Route route = new Route();
route.Name = "Greeting";
route.Action = "action*=Greeting,route=NewEngland";
Channel.ddRoute(route);
route.Name = "Salute";
route.Action = "action*=Salutations,route=SouteEast";
Service.AddRoute(route);
这个技术可以用于处理非结构化数据，如果我要发送给您一个 Word 文档，我可以在 SendWordDocument 上发送。另一端上的人可以将它作为 Indigo 消息来接收，并且使用常规 XML 工具分析它。这是个关于在 Indigo 应用程序中如何使客户端和服务器去耦的示例。这里的情况和 ASP.NET 中的不一样，在 ASP.NET 中，WSDL 工具需要创建正确匹配公布的 WSDL 的代理。而在 .NET 远程处理中，两端要具有相同类型才可以使用它。如果我选择我仍然能共享类型，就像我所说的一样，那么我就能具有在两端不匹配的签名，条件是我要理解基础协定，并且确保服务上有代码，该服务能够处理程序中生成的请求。现在有一个示例说明 CLR 异步概念与 Indigo 异步概念的不同。因此这里我获得了一些使用 CLR 所需的内容。我有一种异步结果类。我并不认为它很有趣；您以前见过它。但是我有一个 Service 类，它有三个方法。第一个方法是一个请求/响应标准方法，称为 ServiceMethod，它将按名字处理定单，并返回 42。
[Service]
public class OrderProcessor
{
[ServiceMethod]
public void PlaceOrderByName(string CustomerName, string ProductName, int Quantity)
{
// Process order
return 42;
}
它总是用 42 回答每个问题。现在第二个办法设置为使用异步模式，因此这里我有两个方法，BeginPlaceOrderByNumber 和 EndPlaceOrderByNumber，对于客户端而言，它似乎是同步调用，一个请求/响应调用，但是在服务器上我能够异步地处理它。
[ServiceMethod(AsyncPattern = true)]
public IAsyncResult BeginPlaceOrderByNumber(string CustomerName,
int ProductNumber,
int Quantity,
AsyncCallback callback,
Objectstate)
{
OrderAsyncResult orderResult = new OrderAsyncResult(...);
return orderResult;
}
[ServiceMethod]
public void EndPlaceOrderByNumber(IAsyncResult result)
{
OrderAsyncResult asyncResult = (OrderAsyncResult)result;
asyncResult.AsyncWaitHandle.WaitOne();
}
我可以返回它所调用的线程，使进程入队列，工作一会儿，然后唤醒，并使用响应回调调用者。同时，可怜的调用者在整个队列过程中只能干坐着，但是我们异步地实现了，对外声明的还是一个同步方法。
这和协定中第三个方法是不同的，我在前面提到过，它是一个 OneWay 服务方法。
[ServiceMethod(OneWay = true)]
public void EmailStatus(string CustomerName，string EmailAddress)
{
// Queue request to email customer their status at some point
}
在这个示例中，我们看到，如果我需要您用电子邮件给我发送东西，我可以发送一个称为 email 的消息，告诉我的状态，您可以明天再处理。我并不是马上需要它。我立即进行回复，然后您将该请求放入队列，但是却丝毫没有给出响应的意思，而只是给我发电子邮件。这种异步模式和 CLR 异步模式的区别在于，CLR 模式允许服务器使用另一个线程，而客户端只能挂起，而在 Indigo 异步中，它是 Fire and Forget 模式。因此我能给您发送一个消息，然后不去理会它，您可以稍后进行处理，您需要使用某个机制来响应我。这些实现策略的使用要依据具体情况来进行。因此在外部看上去，该服务象两个请求/响应和一个 OneWay 调用，但是在内部，这三个方法中有两个是异步实现的。
客户端上使用的是不同的模式。此处比较明智的做法是记住纯粹的请求/响应方法是如何获得的。客户端可以通过任何此类请求/响应方法选择使用客户端异步模式。例如，我在服务器端使用两个请求/响应方法，客户端发现其中挂起的一个已永远挂起，这时它也能使用客户端异步。因此我们仍然能使用请求/响应方法，以便将回答和请求相关。我可以问你一个问题，比如说关于业务，守候我查看响应，获取回复信息，知道它匹配我的请求，或者，我可以使用纯粹的异步消息处理。但是此处客户端上异步模式的工作方式与服务器上的相同。我在接口上设置了它。请注意，这里的 PlaceOrderByName 同步、异步使用都可以。
[ServiceMethod]
int PlaceOrderByName(string CustomerName，
string ProductName，
int Quantity);
[ServiceMethod(AsyncPattern = true)]
IAsyncResult BeginPlaceOrderByName(string CustomerName，
string ProductName，
int Quantity，
AsyncCallback callback，
ObjectasyncState) ;
因为我设置的缘故，按服务器端异步实现的是一个客户端同步。
[ServiceMethod]
int PlaceOrderByNumber(string CustomerName，
int ProductNumber，
int Quantity);
因此这里客户端如何决定使用同步模式，以及服务器如何使用它这两者之间是没有关系的。当您对 Indigo 编程时，您拥有了所有异步行为的标准模式，它们在当前的 CLR 以及 System.Messaging 中纯粹的消息处理模型中可用。
ROBERT HESS：现在我们注定要使用 Longhorn 吗？我们何时能够在 Longhorn 编程环境中进行这种编程呢？
STEVE SWARTZ：我在 Microsoft 工作很久了，我不相信预测发布日期的人，也不相信负责长途运输的人。我们小组有自己的进度表。Indigo 正处在构建之中；我们不受制于 Longhorn 进度表、Whidbey 进度表或任何其他进度表。可以说，我们的 Indigo 是条大鱼。正如 John 所说的，我认为我们的编码工作夏天就会结束，那时将会有一个 beta 版。到时候我们会广泛发行，不会单单针对某些人，而且我们要抓另一条大鱼，可能是 Whidbey，也可能是 OS 或 Longhorn 上的一个功能补丁。当然，这也会包含在 Longhorn 中，不过我们可能在它之前发行。我只是不知道所有的进度，变数太大了。我不喜欢对这种事情发表意见，您最好去和我们的市场人员谈一谈。
ROBERT HESS：我宁愿不。如果有人对有关 Indigo 、编程模型和属性以及其他内容感兴趣的话，您推荐他们去哪里学习呢？
STEVE SWARTZ：好的，现在我记不起来了，但是有整套的 Indigo 新闻组，大家可以去那里学习。可以通过 MSDN 获得 PDC 材料，所有的 Longhorn 更新版本中都有最新的 Indigo 材料。我们正在和许多人合作著书。目前在欧洲有许多关于这些内容的讲演。有一群人在各地分发极好的 PDC 资料，也会进行一些有关 Indigo 的讲演。此外还有许多关于 Indigo 的网络日记，您可以通过点击 Indigo 小组的网络日记作者进行阅读，其中也包括我的，内容很丰富。我想，随着该产品日趋稳定，有关它的信息会越来越多。我们正位于最后一个里程碑处；整个开发过程共分四个部分进行，本周一我们启动了第二部分的编码工作，我想，截至五月或六月，我们就能完成 V1 最终版本的编码。
ROBERT HESS：嗯，好吧，我保证在脚本里贴上一些关于网络日记和其他信息的链接。如果您还觉得有什么其他信息值得看看的，请给我发邮件，我再补充到脚本里，因为我自己也记不得那么多了。
STEVE SWARTZ：很好。
ROBERT HESS：还有什么话最后要对我们的观众说的吗？
STEVE SWARTZ：我想，花时间看一看我们的指导是非常值得的，因为将 Indigo 看做是一次巨大的变化，有些新东西，或者完全是新东西都是不妥的，它是基础结构的替换，只要您看一看，就会立即喜欢上它，它是一种编程模型的演进，一种简化和统一。我们认为我们将达到一个层次，其中这个分布式编程模型能够在非常近的距离内工作，就像我们以前在 Word 中使用 DCOM，也能够在极远的距离上工作，因此想一下我们能够将所有这些都简化，该是多么令人兴奋，而且您再想想，使用具备良好体系结构原则的产品来适应未来发展的需要，不是非常有趣的事吗？
ROBERT HESS：非常感谢您，Steve。
STEVE SWARTZ：谢谢您。
ROBERT HESS：谢谢您。好的，观众朋友们，您已经看到了 Indigo 编程模型的外观，而且了解到，一旦 Indigo 或适当的编程模型可用于操作系统，您便可以通过简单地将其添加到应用程序中而获益。Steve，感谢您参加我们的节目，谢谢您为我们介绍 Indigo 编程模型。
STEVE SWARTZ：谢谢您邀请我。
ROBERT HESS：好的，希望本次访谈真正为大家提供了理解 Indigo 编程模型，及其对编程产生的影响所需的深入知识。如果您正在使用 .NET 框架和托管代码，那您已经知道得差不多了。在以后的专题片中，我们将讨论其他技术，请继续关注，我们以后见。
Somebody@Microsoft.com
--------------------------------------------------------------------------------
Erica Wiechers，程序经理，Microsoft Corporation 访谈……
ERICA WIECHERS：紧扣 Longhorn 主题，今天与我在一起的是 Kevin Gjerstad，他是 Avalon 小组的主程序经理。Kevin，欢迎您。
KEVIN GJERSTAD：谢谢您。非常感谢。
ERICA WIECHERS：请大致介绍一下 Avalon 小组的工作，以及您在其中的角色好吗？
KEVIN GJERSTAD： 好的。Avalon 是我们称之为 Longhorn 项目四大支柱中的一个。Avalon 负责新的显示子系统，还有其他的内容，比如用于数据存储的 WIN FS，用于通讯的 Indigo 和用于应用程序模型和安全性等等的基础。因此 Avalon 代表的就是我们从头重建显示子系统的工作。
ERICA WIECHERS：好的。作为主程序经理您负责什么？
KEVIN GJERSTAD：我管理着一个有 6 个程序经理的小组，负责 Avalon 中的 UI 框架。其中包括像组件模型、编辑、输入、布局等等内容。我还管理着一个由设计人员和开发人员组成的小组，从事演示软件和原型软件的开发制作。
ERICA WIECHERS：这么说，他们主要是在为 Longhorn 构建新的 UI 表示层喽？
KEVIN GJERSTAD：是的。
ERICA WIECHERS：现在您的小组负责设计 UI 吗？您们从客户反馈或者可用性测试中获取信息吗？否则又是怎么工作的呢？
KEVIN GJERSTAD：我的小组实际上并不设计 UI。那个工作主要由 Shell 小组来完成。我们实际上是在开发表示框架，而 UI 是从其中构建的。
ERICA WIECHERS：好吧，因此您们是为那些开发人员构建一些功能或者说特性，这些开发人员构建的是……
KEVIN GJERSTAD：组件和 UI 库之类的东西。
ERICA WIECHERS：好吧。您能谈一谈目前在开发什么吗？
KEVIN GJERSTAD：好的，实际上我们刚刚才完成了一个内部的开发里程碑，我们进行了许多稳定性工作、修补了错误等等，此外还对规范评审进行了规划，并为下一个内部开发里程碑做了准备。
ERICA WIECHERS：您能说说 — 您认为 Avalon 的最酷之处在哪里吗？
KEVIN GJERSTAD：我想它确实很酷，因为我们实际上得到了从头重新编写的机会，而不用渐进地更改。这是我们长期梦想着要做的事情，因此我们能够，比如，利用今天优秀的 PC 硬件，融入一些功能和技术。
ERICA WIECHERS：到 Microsoft Avalon 小组之前您在哪里？在其他地方吗？
KEVIN GJERSTAD：实际上我一直在这个小组 — 您是问在加盟 Microsoft 之前吗？
ERICA WIECHERS：是在 Microsoft 内部。
KEVIN GJERSTAD：好吧，我在 1994 年加入 Microsoft 的 Windows 95 小组，其间我开发了 Windows 的一些国际版本，主要是日文版，然后我参与开发了 Internet Explorer 3、4 和 5，然后我做了新输入框架的主程序经理，该产品在 XP 中发布了，Tablet 和 Speech 小组都在使用。
ERICA WIECHERS：这样算有十年了，您一定看到了公司的巨大进步。
KEVIN GJERSTAD：噢，是的。很大的变化。
ERICA WIECHERS：许多产品。
KEVIN GJERSTAD：嗯。
ERICA WIECHERS：这很好。那么您是直接从学校进入高技术行业的吗，您在来 Microsoft 之前在别的地方工作过吗？
KEVIN GJERSTAD：没有，实际上大学毕业之后我直接去了日本，在那里呆了两年，学习和工作。实际上有不少时间花在了学习语言上，我最开始只想呆一年，但是随后就被陷住了，呆了两年。此后我来到俄罗斯，花了两年工作，在远东的一个学校教书。
ERICA WIECHERS：哇。
KEVIN GJERSTAD：那时俄罗斯刚刚开发，所以……
ERICA WIECHERS：所以您还能说日语和俄语？
KEVIN GJERSTAD：是的，我能。我的日语这几年比较生了，但是俄语我一直没有扔。
ERICA WIECHERS：这很好。这能帮助您获得 Microsoft 涉及国际方面的工作。
KEVIN GJERSTAD： 哦，是的，是的。
ERICA WIECHERS： 这很好。非常棒。您在目前这个工作期间有机会旅行吗？
KEVIN GJERSTAD： 不太多。我出差去过日本几次，但仅此而已。
ERICA WIECHERS：工作之余您喜欢做些什么呢？
KEVIN GJERSTAD： 我刚刚和我两岁大的儿子在一起度过了许多时间；他总是让我忙得不得了。除此之外，我喜欢进行山地自行车、高山滑雪、远足之类的运动。
ERICA WIECHERS：您的活动场所真是不错。
KEVIN GJERSTAD：是的，是的。
ERICA WIECHERS： 您是西北人吗？
KEVIN GJERSTAD：是的。除了在国外呆的四年，我一直在这里生活。
ERICA WIECHERS：很好。我想，这样您可以算是公司里为数不多的本地人了。
KEVIN GJERSTAD： 是的。像我这样的人在 Microsoft 越来越少了。
ERICA WIECHERS：今年冬天您有机会外出，玩滑雪吗？
KEVIN GJERSTAD：机会不多。我今年一直忙于 Longhorn 项目。
ERICA WIECHERS：哦。我听说今年的雪很不错。
KEVIN GJERSTAD：是的，我很快就会去的。
ERICA WIECHERS：您觉得自己在 Microsoft 的下一个任务是什么？您想尽量和 Longhorn 小组在一起吗？
KEVIN GJERSTAD：您知道，我还没有想这么多。我喜欢集中精力干手头的工作，Longhorn 足够我忙的了。此后我肯定会去干其他事情，但是现在还没有任何想法。
ERICA WIECHERS： 很好。这么说来，现在的活儿您肯定还要干上一阵子。
KEVIN GJERSTAD：是的，时间长了一些。
ERICA WIECHERS：好了，Kevin，这非常好，感谢您接受我们的访问。
KEVIN GJERSTAD：谢谢您邀请我。
KEVIN GJERSTAD：我带领着一组程序经理工作，我们负责 Avalon UI 框架，其中包括布局、组件模型、用户交互服务和元素/树服务。我还领导着一小组开发人员和设计人员，致力于开发框架上的原型应用程序（例如，Bill Gates 在 PDC 主旨发言中使用的法律应用程序示例）。
有关 Longhorn Avalon 的最新信息，请参阅以下联接：
PDC 2003 Avalon 概览： http://msdn.microsoft.com/longhorn/pdcmaterials/pdctalksavalon/
Avalon 社区讨论： http://msdn.microsoft.com/longhorn/community/newsgroups/default.aspx?dg=microsoft.public.windows.developer.winfx.avalon&lang=en&cr=US
Longhorn 网络日记： http://www.longhornblogs.com/
结束语
--------------------------------------------------------------------------------
ROBERT HESS：又到了 .NET 专题片和您说再见的时候了。
ERICA WIECHERS：请继续关注下一期专题片，届时我们将讨论 Win FS。
ROBERT HESS：到时网上见。
进一步信息的链接
--------------------------------------------------------------------------------
Longhorn 开发人员中心：Indigo
http://msdn.microsoft.com/Longhorn/understanding/pillars/indigo/
“Indigo”是一组用于构建和运行互联系统的 .NET 技术。它是围绕 Web 服务体系结构构建的一种新的通讯基础结构。Indigo 中的高级 Web 服务支持提供安全、可靠和经事务处理的消息处理以及互操作性。Indigo 的面向服务的编程模型是建立在 Microsoft .NET 框架之上的，简化了互联系统的开发。Indigo 用一种可编写、可扩展的体系结构统一了多种分布式系统功能，跨越了传输、安全系统、消息处理模式、编码、网络拓扑和宿主模型。Indigo 将成为 Windows“Longhorn”不可或缺的功能之一，也将在 Windows XP 和 Windows Server 2003 上得到支持。
使用 Visual Studio .NET Whidbey 的 PDC 版本创建 Indigo 应用程序
作者：Yasser Shohoud
http://msdn.microsoft.com/library/en-us/dnlingo/html/indigolingo01062004.asp
本文是 Indigo Lingo 专栏的第一篇文章，其中 Yasser Shohoud 探讨了用于创建 Indigo 应用程序的 Visual Studio .NET 项目模板。
MSDN Magazine
用 Indigo 开发和运行互联系统指南
本文描述了“Longhorn”（即将推出的 Windows 版本）中一组新的编程框架。“Indigo”是这个框架的代号，提供了丰富的对面向服务设计的支持，对传统的面向对象方法是一种补充。Indigo 与 .NET 远程处理、ASMX 和 .NET 企业级服务很好地结合，构成了一个统一的编程和管理模型。Indigo 具有对标准协议（包括 HTTP、XML 和 SOAP）的深入支持，使得无需牺牲安全性或者可靠性而集成应用程序和服务更加容易。
PDC 讲演：Indigo
http://msdn.microsoft.com/longhorn/pdcmaterials/pdctalksindigo/
Microsoft 于 2003 年推出了 6 场技术会议，有超过 120 个分会。寻找您感兴趣的 WinFS 相关会议的 PowerPoint 幻灯片、流视频和演示代码吧。
Serviced，Steve Swartz 的网络日记
http://www.stevesw.com/blog/default.aspx
meta-douglasp，Doug Purdy 的网络日记
http://www.douglasp.com/default.aspx
Yasser Shohoud 的网络日记
http://weblogs.asp.NET/yassers/
Don Box 的网络日记 — Spoutlet
http://www.gotdotnet.com/team/dbox/
Don Box 在开发人员圈子里颇有知名度。他目前在一个 Indigo 小组工作，致力于为这个重要技术定义体系结构，以便系统之间深入地相互通讯。
IRhetoric — Karsten Januszewski 的网络日记
http://blogs.msdn.com/karstenj/
Karsten 是平台策略组的技术推广人，他在网络日记中讨论了各种与 Longhorn 相关的有趣技术，您经常可以发现他共享各种与 Indigo 相关的新知识。
