Internet 服务总线

作者：Donald F. Ferguson、Dennis Pilarinos、John Shewchuk

摘要：Web应用程序是非常常见的应用程序模型，它们将变得越来越普遍。几乎所有大中型企业的应用程序都提供Web用户界面。在本文中，我们将使用术语“企业”表示大中型企业、软件供应商和集成商。桌面和客户端/服务器应用程序越来越多地使用浏览器作为UI引擎，并通过Web协议调用数据和服务。

软件、应用程序模型以及Web本身都在进行革命性变革。这场变革对计算机世界的影响与客户端/服务器模型或Web的出现相差无几。Web将从连接用户与站点提供的应用程序的工具发展为具有以下特征的模型：

l 应用程序“在Web中”执行。

l 最终用户开发自己的应用程序访问Web，将其转变为用于访问Web服务的最终用户开发的工作空间。

本文重点介绍变革中的一小部分内容。其他文章将扩展此愿景。

很多技术和趋势都为上述革命性变革提供了动力。比如：多核处理器；虚拟化；联合很多设备的应用程序方案，如手机和平板电脑；面向服务的架构(SOA)和Web服务；Web 2.0；软件即服务(Software as a Service，SaaS)。

我们将讨论某些趋势的影响，但我们主要侧重于SOA、Web 2.0和软件即服务(SaaS)。这些概念及其关系尚未得到广泛了解。通常，这些技术似乎相互矛盾。本文介绍使这些概念成为一个统一体的高级参考架构的元素。

上文所述的很多技术趋势都得到了广泛的认可和关注。本文讨论争议较大的第三个趋势：无处不在的编程功能。很多高等学校和大学毕业生开始参加工作时都有基本的编程技巧，很多学生已经开发了简单的PHP或Visual Basic应用程序并且构建了网站。专业人员的主要工作职责可能不包括编程，但是很多情况下，如果编程能够使他们效率更高，专业人员也会简单的进行编程。他们可能还会开发一些简单的应用程序，因为这样比较“酷”。对于这个概念，我们将使用最终用户编程这个术语。

最终用户编程是机会开发的极端情况，它发生在企业中的各个部分以及业务范围(LOB)中。LOB和团队通常构建简单的“快捷而粗劣的”SharePoint或PHP应用程序，这些应用程序可以通过扩展已封装的应用程序或企业范围核心应用程序解决直接业务问题。

机会开发和系统开发形成了对照。系统开发是模型驱动的，总是需要进行需求收集、用例和股东会谈，包括质量和保证的应用程序开发生命周期等等。系统开发是企业开发团队（“CIO团队”）的主要模型。很多封装的应用程序开发人员（独立软件供应商或ISV）和系统集成商(SI)也提出系统解决方案。

在机会开发和系统开发的企业之间有一个拉力。如果最终用户编程变得很普遍，则这个拉力将会增大。最终用户将不满足于等待系统开发团队开发或修改解决方案。我们介绍的参考架构提供了一个协调机会开发和系统开发的方法。

我们将使用一个方案来演示参考架构。形成和支撑该架构的核心元素是Internet 服务总线(ISB)。参考架构包含很多元素，但是，本文仅提供ISB的详细信息。其他文章将介绍其他元素。

目录

方案以及机会开发和系统开发
软件和服务，以及Internet 服务总线
结束语
参考资料
关于作者

方案以及机开发会和系统开发

Dave 经常出差，他首先要使用酒店和航空公司。在出差的城市中，他使用当地的汽车服务，并且预订餐馆。与朋友、家人和同事的协作也是非常重要的。Dave使用各旅行提供商的网站制订和更改旅行计划。

Dave的旅行管理涉及很多通过网站与旅行提供商进行的手动交互任务。他必须手动协调跨站点的任务，并且必须手动在字段之间剪切和粘贴数据。而且要符合一定的先后顺序逻辑，例如，必须先预订餐馆和汽车服务才能到达餐馆。Dave的行为就像一个复杂的应用程序或企业应用程序集成(EAI)解决方案。手动工作非常单调乏味而且容易出错。Dave有基本的编程技巧，因此他决定编写一个小mashup。此mashup通过客户端网页脚本或简单的HTML剪辑使用旅行提供商的网站（图1(a)）。此mashup使Dave的生活变得更加轻松，并且使Dave的工作效率更高，因为他在管理旅行方面花费的时间更好，而将更多的时间花费在他的工作上。此mashup也非常酷，给他的朋友留下了很深刻的印象。

Mary和Ludwig喜欢这个应用程序，他们从Dave那里获得了代码。他们想拥有不同的UI，但希望共享代码。因此，他们将UI与网站访问分离、编写脚本并通过实现简单的模型视图控制器版本进行缓存，从而改进了这个应用程序（图1(b)）。改进后的程序还可以通过其他设备（如PDA或手机）进行访问以重用代码（图1(c)）。最后，他们决定将模型层移动到部门Web服务器并实现一个简单的Web应用程序。这样便使多个人能够访问信息，以获得帮助。

朋友有机会构建一个复杂的应用程序，这是一个简单的伪EAI解决方案。随着能够编程的专业人员的参与，这些专门的即时应用程序将变得越来越普遍。不仅仅有“酷的因素”，而且应用程序也将简化单调乏味的任务。专业人员还可能为解决短期的业务问题（如约定）构建“即时”应用程序。当用户通过访问现有数据库和核心企业应用程序执行业务任务时，这些应用程序类似于电子表格的角色。

机会情境应用程序（situational application）将对企业系统应用程序交付产生深远的影响。首先它将影响企业应用程序的开发。情境应用程序可能“依赖”核心企业应用程序，或采用意想不到的方法使用核心系统。这将使IT组织将某些“模型层”移动到企业服务器，以提高性能和完整性。

本质上，情境应用程序定义了驱动系统企业应用程序变革的用例。情境应用程序可以替换用于记录用例的简单实体模型，并且可以驱使正式的建模。

很多压力使大量情境应用程序移动到企业服务器。可能有一些合作伙伴需要使用要求企业安全的应用程序。某些应用程序可能是重要业务决策的一部分，比如贷款审批。管理和遵从性将要求记录数据访问和输入，并且保存这些应用程序各个版本的代码。将情境应用程序移动到数据中心具有深远意义。除了核心业务解决方案之外，数据中心还需要支持上百或上千个经常更改的应用程序。数据中心需要管理几十个供大量用户访问的高负载核心应用程序服务器，以及上千个小型团队使用专用应用程序偶尔访问的虚拟服务器。

很多情况下，系统解决方案也使用机会应用程序。Dave认为如果IT使用他的应用程序，这将非常酷。

总之，机会应用程序推动系统解决方案的发展，系统解决方案推动机会应用程序的完善（例如代表性状态传输（Representational State Transfer，REST）-> Web服务）。这些动��还推动软件即服务的发展，更确切的说是软件和服务。软件和服务提供了一个平台，可以将系统解决方案和机会应用程序的开发和交付结合在一起。

企业服务总线

考虑当Dave正在从纽约旅行到达拉斯时，如果航空公司取消了Dave从达拉斯到旧金山的航班将会发生的情况。Dave将不能到达旧金山，他需要在中转机场所在的城市停留一整夜。因此有必要更改酒店、餐馆以及汽车服务预订。Dave在下飞机时可以使用他的mashup简化这些更改。如果在飞行时能够自动重新预订，那最好不过了（“更酷了”）。航空公司和航班监视站提供航班时间表的更新服务。理想情况下，Dave的应用程序将始终动态执行。应用程序将监视这些更新，并使用简单逻辑响应事件，更改路线和计划。

简单的最终用户应用程序未必总是修复路线，但大多数修复非常简单。Dave只需手动处理复杂的情况，还可以批准飞行过程中他的应用程序自动进行的更改。

修复路线的常规应用程序方案是企业中常见的问题类型。例如，类似的问题也可能发生在购买定单和报销单审批方面。下面这个方案就是复合应用程序的一个示例，它实现直接处理(STP)模式（参见参考资料）。企业执行系统方法来解决这些问题。图2概述了如果航空公司、酒店、餐馆、城市汽车以及其他系统位于企业防火墙中时，复合应用程序可能的样式。运行时间相对较长的编排过程预订航班管理系统发出的事件。该过程来回发送消息，并调用现有应用程序取消预订、查询空闲资源以及进行新的预订。由于企业种类的不同，现有应用程序具有各种消息格式（C、COBOL等等）以及通信协议（例如，WebSphere MQ、SAP RFC）。

图2：企业业务过程（单击图片查看大图）

图2所示的修复过程设计非常脆弱。例如，如果添加了另一个航空公司应用程序，则必须更改业务过程。还可以将业务过程与现有应用程序的特定消息格式和语言联系在一起。添加一个常规机制用于记录与某些条件匹配的消息（例如，如果旅行者是管理人员，则记录所有消息）是非常困难的。这种脆弱性导致企业应用程序架构发展为企业服务总线(ESB)。

图3概述了企业服务总线。应用程序适配器将现有格式和协议转换为标准的Web服务。这样便将任何内容与任何内容连接的NxN协议/格式映射问题转变成了N->1映射的问题，即将所有内容都转换为标准。ESB提供了处理服务之间消息流的其他功能。示例包括消息转换、记录和路由。

图3：企业服务总线（单击图片查看大图）

如果Dave公司的企业开发和业务部门决定，实现其旅行应用程序的重要性足以为其提供资金支持，那么这个企业团队可以实现类似于图3的应用程序。开发此系统解决方案有以下几个问题：

1. 无法保证企业会对复合应用程序提供资金支持。可能还有其他更迫切的业务问题。

2. 系统开发涉及用例、某些形式的过程建模、会见股东等。这些都需要时间。

3. 航空公司、酒店以及其他应用程序都在企业之外。企业会非常慎重地考虑建立业务到业务的连接。即使业务合作伙伴实现了Web服务，企业也需要建立Web服务与合作伙伴交互的授权规则和审核。企业将需要支持用户身份管理、联合身份验证以及资料供应，因为不仅管理员工在企业内部的身份，还要管理其在多个航空公司以及酒店中的身份。

4. 针对各个员工的喜好定制解决方案是非常复杂的。员工无法进行“DIY”定制。应用程序位于中央企业服务器上。IT专业人员定义和修改业务过程，而不是Dave。

如果Dave能够实现一个简单的个人版本的系统解决方案，这的确非常酷。如果我们概括ESB并将其视为一种为系统企业开发进行了优化的服务总线，那么我们同样可以设想一种为机会开发进行了优化的服务总线。这就是Interne服务总线（ISB）。ISB更像是一个无处不在的分子。ISB将设备彼此链接、将设备链接到本地服务器、将网站链接到网站、将ESB链接到ESB，而且它本身就是一个ESB。ISB是一个用于“DIY”复合应用程序和业务过程的平台。ISB还是一个软件即服务(SaaS)的示例。

Internet服务总线

图4概述了Internet服务总线的概念。（ISB的一个早期示例为BizTalk Services；请参见参考资料。）ISB提供商类似于PHP网站托管公司。它们都提供在动态的应用程序平台。PHP Web托管站点主要提供用于开发动态网站和与数据库交互的Web服务的平台。相比之下，ISB提供的平台用于创建和部署集成其他站点提供的服务的复合应用程序。ISB、PHP Web托管公司以及服务型存储（如Amazon的S3）都是支持基础结构软件即服务的应用程序的示例。这与Salesforce.com不同，它在一开始就封装为软件即服务的应用程序。

核心ISB概念构建在统一资源标识符(URI)空间上。Dave的团队处理了应用程序注册问题，“拥有”了URI：http://ISB.net/DaveAndTeam。此根目录下的URI表示应用程序集成点，它类似于Java Messaging Service中的目的地、面向消息的中间件中的队列，或者发布/订阅系统中的主题。团队通过将策略和功能与URI相关联开发了一个ISB应用程序。此复合应用程序是一组URI、策略和功能。ISB提供了身份和访问功能，用于控制哪些消息可以由谁发送给URI。身份和访问功能就是将策略与URI关联的示例。

例如，Dave可以选择保留公共网站上某个显示其旅行预订的wiki页面。Dave会希望控制对此wiki页面的访问。在他的个人网站上建立和维护身份验证和授权数据库是非常单调乏味的。如果Dave在多个网站上都有页面和数据，则这个问题会变得更复杂，例如：

l 驱动PHP站点的个人数据库

l 使用http://www.twiki.org/构建的一系列协作门户

l 存在于某个个人空间站点，如Windows Live Spaces (http://home.services.spaces.live.com/)。

图4：Internet服务总线（单击图片查看大图）

Dave的朋友Don可以注册ISB的身份组件并且创建一个用户ID [e-mail]。Dave可以使用该身份组件的Web UI指定Don可以访问Dave的哪个ISB URI。Dave还可以定义组并授予组访问权限。Don登录到ISB之后便可以访问URI。ISB简化了Dave的安全管理，因为他可以维护一个中央数据库，然后授予“ISB”访问其wiki以及其他资源的权限。ISB通过对其前面的ISB URI进行访问控制保护实际资源。ISB的优势在于，Dave拥有一个空间，可以定义和维护Web上所有与其“服务”有关的身份、组、资源以及访问策略。

我们刚刚已经讨论了通过网页的显式用户操作。另一种比较常见的方法是让参与复合应用程序的端点上应用程序使用Web服务API访问ISB。

身份组件还将支持WS-Security的Security Token Service (STS)功能以及与其他STS的联合。这样便允许Dave管理未向ISB注册的身份的访问。如果foo.bar是一个Dave信任并且实现了STS的公司，则Dave可以为经过foo.bar身份验证的身份定义访问策略。

一段时间之后，ISB将提供可以连接到URI的其他策略和实现。示例可能包括WS-Reliable Messaging或隐式消息记录。此概念类似于服务质量策略与面向消息的中间件的关联。

ISB构建于身份和访问功能之上，为应用程序（甚至包括位于防火墙之后的应用程序）提供“安全普遍的连接性”。这包括对广泛的连接性模式和协议的支持。示例包括面向REST的HTTP、WS-*以及很多企业应用程序中的事件驱动模式。确切的说，ISB的连接性组件还提供了三个核心功能：

l 中继，使ISB和防火墙之后的应用程序之间能够通信。有很多技术可实现该功能（Biztalk Labs，请参见参考资料）。中继功能不再需要为简单方案建立系统跨企业连接。

l 协议，提供一组用于交换消息的公共协议，如WS-*或REST。ISB还提供使用不同协议自动连接端点的协议映射。例如，可以将RSS feed连接到WS-*消息连接，而不必修改任何应用程序。

l 功能，支持将简单的类似于ESB的功能与URL关联。示例可能包括多播、WS-Eventing、持久消息等。

连接层在基础结构技术级别上运行。它避免了由于不同的“plumbing”（例如，REST与WS-*）而引起的复杂性，从而简化了解决方案开发。必须在该级别实现的基础结构集成的项目会导致大量成本和风险。ISB解决了这些问题。

连接层不感知应用程序级别元素和消息格式。构建复合应用程序要求适应连接的服务所实现的各种消息格式。ISB功能的一个示例就是将HTTP GET中的参数转换为XML消息中的元素。ISB提供一个简单的工作流程（服务编排），该流程提供对应用程序级别映射的支持（图5）。

图5：ISB消息处理（单击图片查看大图）

ISB为简单的功能提供了一组模板“活动”。工作流程是一个由实例化的活动模板组成的图形。假设航空公司通过RSS feed发出了航班状态，并且Dave的部分应用程序希望收到WS-Eventing通知以便更新。连接层支持将RSS与WS-*集成。仍然有必要将消息负载从RSS格式转换为Dave的应用程序所期望的XML事件格式。通常，ISB将提供一个可配置的、可重复使用的活动模板，用于将RSS转换为XML映射。

另一个常见的活动模板是基于选择的路由。Dave的应用程序可能发出一个取消汽车预订的消息（ID=1234）。如果一个城市汽车服务的预订代码以“LE-”开头并且另一个以“OL”开头，则Dave的应用程序可以将取消事件发送到一个ISB URI。然后，选择器处理该消息并将其路由到相应的端点。

组合这些活动以便处理更复杂的消息是非常有用的，这将是ISB的一个共同功能。作为示例，图6显示了Dave定义的用于接收取消汽车预订消息的URL上的活动：

1. 使用WS-*接收XML格式的取消消息。

2. 提取预订ID元素并在表中查找前缀。

3. 将消息转换为城市汽车服务的期望格式，即

a) 用于某个提供商的HTML电子邮件

b) 用于另一个提供商的HTTP POST。

图6：ISB消息处理（单击图片查看大图）

构建消息处理功能非常简单。很多常见应用程序方案都是模式和模板的简单实例。ISB提供商将提供一个简单的基于Web的应用程序开发工具，该工具允许开发人员通过Web表单选择活动模板并设置配置参数。对于路由，Web表单将允许开发人员指定路由表中路由的消息字段和值。一段时间之后，ISB将提供更强大的工具，如BizTalk中的消息处理工具。

消息处理（路由、转换等等）的功能非常强大，足够供很多应用程序方案使用。但是，对于其他应用程序来说，需要进行简单的顺序和流程控制。考虑当Dave进退两难时在达拉斯预订酒店的任务。该过程的简单描述如下：

1. 向酒店链AAA发送预订请求

2. 接收响应。

3. 如果成功，则退出

4. 向酒店链BBB发送预订请求

5. 如果成功

工作流程活动借助控制流（while、if ... then …等等）的活动模板扩展消息处理。ISB将不断增加对简单工作流程的支持，以扩展基本消息处理。

工作流程似乎是比较复杂的概念，系统企业工作流程解决方案功能强大，但比较复杂。但大多数专用应用程序、机会应用程序的工作流程都非常简单。结构并不比简单的PowerPoint图表复杂。存在很小的一组“剪贴画”用于连接和图形，开发人员在图形上设置属性以表达活动的行为。

大多数工作流程倾向于使用嵌入的列表结构。这样便可以使用简单的工具构建工作流程。简单的XSD可以提供定义嵌入列表的工作流程XML文档的结构。虚拟工具允许开发人员指定活动及其实现，或者对外部服务的连接。很多开发人员都熟悉此模型，原因是Web UI框架通常提供类似的页面流和转换的概念（例如，Struts）。

系统工作流程解决方案通常比较复杂，因为它们都是任务关键型解决方案，支持许多人使用的应用程序。过程建模和引擎必须能够表示过程的所有功能，并且能处理复杂的错误条件、审批等等。相比之下，对于大多数专用机会解决方案，很少人使用此工作流程，因此该团队不断修补它以便进行改进。

服务级别目标

在ISB上部署应用程序的企业希望定义服务级别协议(SLA)，用于指定响应时间、吞吐量、可用性等等。SLA将确定ISB提供商收取的费用。为任意应用程序实现SLA这一常规问题常让人感到棘手。但是，ISB的任务更加简单，因为它不部署任意用户代码。为策略、发布/订阅、工作流程活动等实例化和配置的预定义模板限制了应用程序。这简化了实现SLA、可预测成本以及完整性的过程。

机会应用程序的软件和服务的参考架构

图7展示了一个高级概览，将本文所述的内容结合在一起。首先，Internet服务总线是无处不在的，它连接所有系统和服务器。将存在很多复合应用程序，这些应用程序中的一些元素在“ESB”上，另一些在ISB上。多组织复合应用程序是一个非常明显的示例，它可以动态将元素部署到ISB上。另一种可能是在短时间内存在一个组织复合应用程序。例如，企业使用复合应用程序管理内部会议。与获取、安装、配置和支持硬件和软件以“静态”运行应用程序相比，重新使用预先配置且“动态”安装的软件平台效率更高。

图7：生态系统和业务模型（单击图片查看大图）

如果企业在多个会议中重新使用专用应用程序，则系统解决方案可能来自于机会解决方案。机会解决方案为系统解决方案提供了一组具体的用例。它还可以提供一些指标，用于确定应用程序的哪些方面经常使用。

第三方将增值服务连接到ISB。第一种类型的服务将是基础结构服务，如更强大的工作流程引擎或支持XML查询的数据库。开发人员可以将服务连接到其应用程序中的URI，以在其解决方案中包含这些服务。这些基础结构服务说明了第三方如何通过提供高级基础结构作为服务加入生态系统。

第二种类型的服务将是可重复使用的业务服务，例如，用于维护产品信息和目录的预建服务。另一个示例可能是安排集会的会议室。这个示例说明了第三方如何通过添加应用程序“构建块”服务加入生态系统。ISB复合应用程序可以将复合应用程序中的URI连接到构建块服务，以便使用构建块。

最后，系统集成商和解决方案提供商将提供可配置的、可扩展的解决方案，即模板。第三方可能提供支持很多会议/大会管理功能的可配置的解决方案。封装的应用程序供应商可以支持“试用”。潜在客户只需“动态”实例化某个版本即可，无需发布需要安装应用程序和先决条件的CD。

社区是Web 2.0的一个重要方面。实际上，它是最重要的方面。基础结构服务、基本应用程序构建块以及解决方案模板也将通过与提供和共享代码的ISB关联的社区出现。社区还提供论坛，以支持自助服务并建立“软件即服务”供应商的名誉。

软件+服务

整个“软件即服务”是一个神话。所有有意义的SaaS解决方案最终包含一些内部（on-premise）软件，即它是混合的。实例化解决方案的某些元素将位于总线（例如，工作流程）中，一些元素位于连接到总线的服务中（如XML内容管理系统），一些元素将在内部“安装”。几乎所有使用ISB和SaaS的方案实际上都是内部（on premise）和外部（off-premise）软件的混合。

还有一个例子，请考虑Dave用来在其应用程序中存储路线的数据存储提供商。始终使用远程访问来读取/更新路线容易出现问题。存储提供商将可能提供内部（on-premise）和on-PC软件包，该软件包已通过缓存、复制、版本控制等等优化了数据存储。用一个术语表示混合模型就是“软件+服务”。

结束语

几种趋势集合在一起从根本上改变了Web应用程序模型。目前，Web主要用于帮助人们连接到文档和应用程序。最基本的改变是将Internet和Web作为执行应用程序的平台这一思路。具有基本编程技巧的专业人员编写个人应用程序，通过该程序可以更加有效地利用Web。他们将与没有什么计算机知识的朋友和同事共享这些应用程序。随之出现了社区，它通过社区提供了传播个人解决方案“meme”的另一种方法。

不可避免的是，个人应用程序的元素将“走向全世界”。只要原因将是“虚拟”PC的广泛使用，“虚拟”PC可以根据用户和附近的设备进行组装。虚拟PC不是在酒店房间中使用笔记本，而是通过旅行者的手机和TV、Internet连接以及房间中的键盘组装而成。也有可能组装虚拟机(VM)，��只包含执行特定方案所需的软件。

VM还提供：

l 应用程序隔离

l 实现类似于用户管理个人计算机的方式的概念模型，进行最终用户管理。

l 向外扩展基于多核处理器的自然剥离。

l 会聚这些趋势的企业的优势包括：

l 大大提高员工效率和士气。工作不再单调，业务价值任务更加突出，可能还比较有趣。

l 提高了灵活性和敏感度，因为应用程序开发和修改可能发生在几小时而不是几个月之内。

支持这些改变的主要技术就是Internet服务总线。SOA、Web服务和mashup都能够快速进行复合应用程序开发，这些应用程序集成、定制和扩展了基本的应用程序构建块。在Web中支持这些复合应用程序是下一个重要飞跃，也是Web 2.0的核心方面。实现这个前提的关键元素在于Internet服务总线。除了支持灵活的应用程序开发之外，ISB还支持软件提供商的生态系统。ISB的功能支持“编程”专业人员的加入，尤其支持自下至上通过社区开发长期应用程序。计算领域的统一理论是软件和服务，而ISB是此新应用程序模型的基础。

参考资料

l Biztalk Adapter http://(zh-cn,2.microsoft.com/zh-cn/library/aa744368.aspx

l Biztalk Labs http://labs.biztalk.net

l 企业应用程序集成(EAI) http://en.wikipedia.org/wiki/Enterprise_application_integration

l 企业服务总线http://en.wikipedia.org/wiki/Enterprise_service_bus

l Mashup http://en.wikipedia.org/wiki/Mashup_(web应用程序混合)

l 模型视图控制器http://en.wikipedia.org/wiki/Model_view_controller

l OASIS Web Services Reliable Messaging (WSRM) TC www.oasis-open.org/committees/wsrm/

l SAP RFC http://en.wikipedia.org/wiki/ABAP

l 直接处理http://en.wikipedia.org/wiki/Straight_Through_Processing

l Struts http://struts.apache.org/

l 用例http://en.wikipedia.org/wiki/Use_cases

l WS-Eventing http://www.w3.org/Submission/WS-Eventing/

l WS-Security Security Token Service http://sts.labs.live.com/

l Zorro的ISB博客http://zorroisb.spaces.live.com

关于作者

Donald Ferguson博士是Microsoft CTO办公室负责平台与策略的高级研究员（Technical Fellow）。Don主要从事业务上发展和改革信息技术的角色。加入Microsoft之前，Don曾经是IBM Fellow和IBM软件集团(SWG)的首席架构师，他主持SWG Architecture Board，主要研究产品集成、跨产品计划以及新出现的技术，包括Web服务、模式、Web 2.0以及业务驱动开发。Don的主要爱好是Kenpo空手道。他在2005年12月赢得了黑带。

Dennis Pilarinos是Microsoft的互联系统分部的高级技术主管。您可以从他的博客www.dennispi.com上详细了解有关他的工作。

John Shewchuk领导Microsoft互联系统分部(CSD)的技术战略团队。在CSD中，John已经开发了Microsoft的应用程序平台，包含在应用程序消息技术（如Windows Communication Foundation）、Web服务互操作规范（如WS-Security）以及身份和访问技术（如InfoCard）方面的工作。John协同成立了Indigo团队并且已经成为跨行业互操作方面的主要驱动力。John与Indigo团队的其他人员一起领导了Web服务架构和规范的开发，并管理与广泛行业合作伙伴的技术协商。

软件和服务，以及Internet 服务总线