.NET Framework 3.0 简介

 

大卫·查佩尔
Chappell & Associates

2006 年 7 月

适用于:
   .NET Framework 3.0 (以前为 WinFX)
   Windows 开发

总结:Microsoft .NET Framework版本 3.0 提供了一组不同的技术,每种技术都解决了当今应用程序开发中的一个重大挑战。 ) (29 个打印页

目录

描述.NET Framework 3.0
应用 .NET Framework 3.0:方案
了解.NET Framework 3.0:技术
获取.NET Framework 3.0:分发选项
结论
其他阅读材料

描述.NET Framework 3.0

应用程序开发的目标始终相同:在最短的时间内创建最好的软件。 然而,随着开发人员构建的平台越来越好,标准不断提高。 例如,在 Windows 中,原始 Win32 接口已被功能更强大的.NET Framework所包含。 2002 年发布的框架版本 1.0 和 2005 年发布的 2.0 版都为设计和编写 Windows 软件的人员提供了一个明显更好、更高效的环境。

.NET Framework 3.0 (以前称为 WinFX) 是此进展的下一步。 可以使用 Visual Studio 2005 创建基于此新版框架构建的应用程序,这让大多数 Windows 开发人员感到熟悉。 但是,.NET Framework 3.0 也是一个演变,增加了框架版本 2.0 已经提供的内容。 .NET Framework 3.0 计划于 2006 年底发布,适用于 Windows Vista、Windows Server 2003 和 Windows XP。

本文提供了 .NET Framework 3.0 及其组件的全局视图。 目标是明确此新版本是什么,研究如何使用其技术,并对这些技术进行简要说明。

构建新式应用程序:挑战

现在创建一个典型的应用程序并不是一项简单的任务, 要求是巨大的。 使用存储的数据以及允许通过 Web 浏览器进行访问等传统问题仍然很重要,但它们已经不够了。 新式应用程序还存在一系列新的挑战,包括:

  • 组织越来越多地采用面向流程的视图来看待其工作。 由于大多数应用程序自动执行业务流程的某个部分,因此在代码中显式执行此过程的步骤可能会很有用。 为此,一种有效的方法是使用工作流技术,这种方法需要 对基于工作流的应用程序提供支持
  • 应用程序通常与组织内外的其他应用程序通信。 新式应用程序通常还必须适合面向服务的体系结构, (SOA) ,将其某些功能公开为其他软件可访问的可互操作服务。 要实现这些目标,需要 支持面向服务的应用程序
  • 使用应用程序的人员通常需要一种方法来传达有关他们是谁的信息。 许多用于定义和使用数字标识的不同技术正在使用中,网络钓鱼等问题很常见。 鉴于此,新式应用程序和使用它的人员可以从 用户对数字标识的一致控制中受益。
  • 对新式用户界面的要求已显著增加。 提供真正的业务价值通常需要使用各种文档、使用二维和三维图形、显示视频等。 所有这些都需要同时适用于本机 Windows 客户端和 Web 浏览器。 满足这些需求需要统一 的用户界面方法

鉴于当今的应用程序通常需要解决其中一些或全部挑战,构建这些应用程序的平台也应该以一致且可行的方式解决所有这些挑战。 .NET Framework 3.0 的目标是对 Windows 应用程序执行此操作。

应对挑战:.NET Framework 3.0 提供的内容

如图 1 所示,.NET Framework版本 3.0 基于上一版本。 事实上,.NET Framework版本 2.0 中没有任何更改,因此为此基础创建的现有应用程序将继续一如既往地工作。 但是,.NET Framework 3.0 确实添加了四个新组件:Windows Workflow Foundation、Windows Communication Foundation、Windows CardSpace 和 Windows Presentation Foundation。 本部分简要介绍 .NET Framework 2.0 以及每个新组件提供的功能。

图 1

.NET Framework 2.0:适用于 Windows 应用程序的General-Purpose基础

虽然仍然可以编写直接使用 Win32 接口的软件,但.NET Framework已成为新 Windows 应用程序的主流环境。 其中最重要的部分包括:

  • ASP.NET,它支持创建可访问 Web 的应用程序。
  • ADO.NET,允许应用程序访问关系数据和其他类型的数据。
  • Windows 窗体,支持为 Windows 应用程序创建图形用户界面 (GUI) 。
  • System.XML,它允许应用程序处理 XML 定义的数据,包括使用 XSLT 和 XPath。

框架版本 2.0 为其前身添加了一些有用内容,包括大幅改进用于创建 ASP.NET Web 应用程序的技术、支持在 64 位版本的 Windows 上运行的 64 位应用程序,以及处理事务的新方法。 尽管 .NET Framework 2.0 的某些部分在很大程度上被版本 3.0 中添加的新组件所取代,但如后文所述,版本 2.0 中的技术仍然是此新版本的基本组成部分。

Windows Workflow Foundation:支持Workflow-Based应用程序

工作流是一个简单的想法:它只是按某种顺序执行的一系列步骤。 人们甚至可能会争辩说,每个应用程序都实现一个工作流,因为每个应用程序都会执行某些进程。 然而,使用 C# 或 Visual Basic 或其他一些编程语言创建应用程序的传统方法是将此过程中的步骤隐式化到代码中。 这当然有效,但它也会将进程本身深入到程序的逻辑中,使该过程更难实现和更改。

使用工作流技术实现流程逻辑是解决此问题的有效方法。 过程中的每个步骤都是显式定义的,然后由 工作流引擎执行,而不是将逻辑与普通代码中相互交织在一起。 结果是进程本身的干净实现。

工作流引擎不是一个新想法;目前有一些适用于 Windows 和其他系统。 Microsoft 甚至在其某些产品中嵌入了工作流引擎。 然而,由于工作流正在成为创建应用程序的主流方法,因此为 Windows 提供单一工作流技术是有意义的。 这正是 Windows Workflow Foundation (WF) 的官方首字母缩略词所执行的操作。 通过为 Windows 提供通用工作流技术,WF 为任何基于工作流的应用程序提供相同的基础来构建。 Microsoft 提供的软件将使用 WF,包括 Microsoft Office 2007 系统和Windows SharePoint Services,以及其他人创建的应用程序。

但是,提供通用工作流技术会带来一些挑战。 例如,单个方法如何满足不同工作流应用程序提出的各种要求? WF 采用的答案是采用非常通用的工作流视图。 如图 2 所示,WF 工作流只是一组由 WF 引擎执行 的活动 。 每个活动实际上是一个类,它可以包含工作流创建者认为必要的任何工作。 活动可能可跨不同的工作流重复使用,从而更轻松地为新问题创建自动化解决方案。

图 2

提供通用工作流技术的另一个挑战源于面向人类的工作流和面向系统的工作流之间的传统划分。 主要供人员使用的工作流应用程序需要灵活,允许对流程进行动态更改等操作。 主要由系统(即软件)使用的那些往往更静态,但必须尽可能高效。 WF 适用于这两种用途,因此它包括面向人的功能,例如对正在运行的工作流进行更改的能力,以及对更多面向系统的行为的支持。

通过为 WF 中的 Windows 提供通用工作流技术,.NET Framework 3.0 使开发人员在构建软件方面提供这一有用的范例。 随着面向流程的软件视图的不断普及,工作流的使用也可能会增加。

Windows Communication Foundation:支持Service-Oriented应用程序

无论是使用工作流还是使用其他方法生成,大多数应用程序都需要与其他应用程序通信。 在过去几年中,这种沟通方式向前迈出了一大步。 经过几十年的分歧,所有主要供应商都同意支持相同的协议进行应用程序通信。 基于 SOAP,此 Web 服务全球协议使基于不同技术平台(例如 J2EE 和 .NET Framework)的应用程序之间的互操作性比以前简单得多。 它还使面向服务的体系结构的概念对于大多数组织而言更加合理。

当然,已经有很多沟通方法了。 例如,在 .NET Framework 2.0 中,选项包括:

  • ASP.NET Web 服务,提供基于 SOAP 的可互操作通信。
  • .NET 远程处理,侧重于 .NET 应用程序之间的通信。
  • 企业服务,支持可缩放的事务性应用程序。
  • System.Messaging,通过 Microsoft 消息队列支持排队消息 (MSMQ) 。
  • Web 服务增强 (WSE) ,这是 ASP.NET Web 服务的扩展,它为 WS-Security 等最新规范提供支持。

所有这些技术都有价值,而且都发挥了作用。 然而,为什么有几种不同的解决方案来解决本质上相同的问题? 为什么不创建基于可互操作服务的应用程序通信的单一基础呢?

这正是 Windows Communication Foundation (WCF) 所执行的操作。 WCF (最初代号为“Indigo”) 提供了一种使用通用 API 的通用方法,而不是要求开发人员使用具有不同应用程序编程接口的不同技术进行每种通信。 在 .NET Framework 3.0 环境中,大多数可能使用了刚才列出的技术之一的应用程序将改为使用 WCF 进行通信。

WCF 通过 SOAP 提供对可互操作通信的有力支持,SOAP 是新式计算的重要组成部分。 这包括对多个 WS-* 规范的支持,包括 WS-Security、WS-ReliableMessaging 和 WS-AtomicTransaction。 但是,WCF 不需要 SOAP,因此也可以使用其他方法,包括优化的二进制协议、使用 MSMQ 排队的消息传送以及基于 REST 的简单通信。 WCF 还采用显式面向服务的通信方法。 WCF 不是尝试在对象之间提供透明通信,而是在通信方之间插接服务略有不同的抽象。 这样做的结果之一是松动了分布式对象系统中可能存在的一些紧密耦合,使交互不容易出错,并且更易于更改。

无论是在组织内部还是跨组织之间,应用程序之间的通信都是新式软件的基本组成部分。 .NET Framework 3.0 通过使用 WCF 的面向服务的方法解决了这一难题。

Windows CardSpace:数字标识的一致用户控制

想想人们今天如何在互联网上代表自己。 在大多数情况下,一个人的数字标识表示为一个简单的用户名。 结合密码,此标识用于访问电子邮件帐户、Internet 商家,甚至在线银行和其他金融机构。 然而,尽管用户名和密码 (简单,) 无处不在,但用户名和密码有几个缺点。 下面是最重要的两个:

  • 人员很难记住他们为不同站点选择的所有用户名和密码。 许多人对不同的站点使用相同的值,这可以缓解内存问题,但会增加安全风险。
  • 网络钓鱼者可能会窃取用户名、密码和其他个人信息。 通过发送欺骗性电子邮件,网络钓鱼者诱使受害者登录到一个看起来像受害者银行网站的网站。 但是,该网站实际上由网络钓鱼者控制,因此,一旦受害者输入其用户名和密码,网络钓鱼者就可以利用此信息伪装成真实站点上的用户。

降低这些问题的严重性需要一种管理数字标识的新方法。 Windows CardSpace 最初代号为“InfoCard”,是该方法的重要组成部分。 为了帮助人们跟踪其数字标识,CardSpace 将每个标识表示为不同的信息卡。 如果网站接受 CardSpace 登录,则尝试登录该网站的用户将看到 CardSpace 选择屏幕,如图 3 所示。 通过选择卡,用户还可以选择将用于访问此站点的数字标识。 用户无需记住大量用户名和密码,只需识别他们要使用的卡。 不同的卡片还可以包含不同的信息,使用户能够准确控制每个站点所了解的内容。

图 3

这些卡表示的标识由一个或多个 标识提供者创建。 任何组织都可以提供标识提供者,每个组织提供的标识通常使用更强大的加密机制来允许用户证明其身份,而不是依赖于简单的用户名和密码。 CardSpace 本身还包括在客户端计算机上运行的自颁发标识提供者。 使用此提供程序,用户可以创建自己的标识,这些标识不依赖于密码进行身份验证。 网站可以接受这些自行颁发的 CardSpace 标识,而不是依赖基于密码的常用方法,从而减少密码带来的问题。

如果未使用密码登录网站,网络钓鱼者将无法窃取这些密码。 不过,如果网络钓鱼者可以诱使用户登录到虚假网站,他们可能能够从用户处获取其他信息,例如敏感的医疗信息。 防止这种情况需要用户能够将真实网站与网络钓鱼者创建的类似假网站区分开来。 若要允许这样做,拥有网站的组织可以获取 高保证证书。 与当今的简单 SSL 证书不同,获取这种新类型的证书涉及更严格的过程,包括更有力的证明,证明申请该证书的组织实际上是其声称的。 高保证证书还可以携带公司的徽标和其他信息,以帮助用户正确确定使用此证书的网站是否合法。 当用户访问新站点时,CardSpace 始终使用标准屏幕显示该站点证书中的信息。 根据收到的证书的强度,此屏幕将指示站点标识的不同保证级别。 目标是强制用户明确决定信任网站,然后帮助他们做出正确的选择,确定信任哪些网站。

Windows CardSpace 实际上是更大 标识元系统的一部分。 此元系统完全基于开放公共协议,定义了一种跨不同平台 (包括 Windows) 以外的操作系统和各种应用程序 ((包括 Internet Explorer) 以外的 Web 浏览器)一致地使用不同的数字标识技术的方法。 通过为 Windows 提供一种选择标识等的常用方法,CardSpace 在元系统中填补了关键角色。 通过解决身份这一根本问题,CardSpace 在.NET Framework 3.0 中也发挥着重要作用。

Windows Presentation Foundation:多样化用户界面的统一方法

用户界面几乎是每个应用程序的重要组成部分。 然而,用户对这些接口的期望已经显著提升。 当然,仍然需要传统的菜单驱动的 GUI,但应用程序可能还需要显示视频、运行动画、使用二维和三维图形以及处理各种文档。 无论是从独立桌面客户端还是通过 Web 浏览器访问应用程序,所有这些操作都必须可行。

传统上,用户界面的所有这些方面在 Windows 上都以不同的方式提供。 例如,开发人员可以使用.NET Framework的一部分Windows 窗体来生成 Windows GUI。 创建 Web 浏览器界面需要使用 HTML,可能还需要使用 Java 小程序或 JavaScript 代码。 显示视频可能依赖于Windows 媒体播放器或软件(如 Adobe 的 Flash Player),而文档格式可能由 Microsoft Word 或 Adobe 的 PDF 或其他内容定义。 开发人员面临的挑战是显而易见的:使用各种技术为不同类型的客户端构建一致的用户界面并不简单。

Windows Presentation Foundation (WPF) (最初代号为“Avalon”)的主要目标是解决这一挑战。 通过为所有这些用户界面方面提供一致的技术基础,WPF 使开发人员的生活更简单。 通过采用更现代的方法(包括支持视频、动画、二维和三维图形以及各种文档),WPF 可以让用户以新的方式处理信息。 通过为桌面客户端和浏览器客户端提供通用基础,WPF 可以更轻松地生成同时处理这两者的应用程序。

图 4 中显示的示例界面包含图像、实时图形、三维视图等,说明了 WPF 提供的一些功能。 现在,可以更一致的方式创建像这样的用户界面,而不是要求开发人员具备各种技术技能。

图 4

用户界面创建者长期以来面临的一个挑战源于构建有效接口所需的不同角色。 软件开发人员需要创建接口背后的逻辑,但他们很少是定义接口外观的最佳人脉。 设计人员(人机交互方面的专家)通常是此角色的更好选择。 然而,Windows 窗体等较旧的技术完全专注于开发人员。 开发人员和设计人员没有真正有效的协作方式。 若要解决此问题,WPF 依赖于可扩展的应用程序标记语言 (XAML) 。 XAML 是一种基于 XML 的语言,它允许以声明方式(而不是在代码中)指定用户界面。 这使得工具更容易根据设计器创建的视觉表示形式生成和使用接口规范。 事实上,Microsoft 正在提供一种新产品 Expression Interactive Designer来做到这一点。 设计人员将能够使用此工具 (和第三方提供的其他工具) 来创建接口的外观,然后为他们生成该接口的 XAML 定义。 开发人员将此定义导入 Visual Studio,然后创建接口所需的逻辑。

当开发人员创建一个独立的 WPF 应用程序(直接在 Windows 上运行)时,他们有权访问 WPF 提供的所有内容。 但是,若要创建在 Web 浏览器中运行的客户端,开发人员可以生成 XAML 浏览器应用程序,通常称为 XBAP。 XBAP 在与独立 WPF 应用程序相同的基础之上构建,允许在可下载的浏览器应用程序中显示相同样式的用户界面。 同一代码可能用于这两种类型的应用程序,这意味着开发人员不再需要桌面和浏览器客户端的不同技能集。 与此类丰富 Internet 应用程序的典型一样,从 Internet 下载的 XBAP 在安全沙盒中运行,这限制了应用程序可以执行的操作。 不过,独立 WPF 应用程序可用的用户界面功能的大部分子集也可用于 XBAP。

WPF 独立应用程序和 XBAP 都可以利用 WPF 的新式图形支持,包括使用硬件加速、对矢量图形的支持等。 通过提供对更强大的图形的支持,WPF 提供了一系列Windows 窗体或其他早期技术无法实现的数据可视化选项。 WPF 还为 XML 纸张规范 (XPS) 奠定了基础,该规范定义了用于查看、分发和打印固定格式文档的标准格式。

用户界面是新式应用程序中复杂且重要的一部分。 通过 WPF,.NET Framework 3.0 为这些接口面临的挑战提供了更完整、更一致的解决方案。 目标是让创建用户界面的人员(开发人员和设计人员)更有效地完成工作。

应用 .NET Framework 3.0:方案

了解一组技术如何协同工作的一种方法是查看如何使用它们的示例。 例如,假设有一个允许客户和代理提交保险申请的应用程序。 如果它是使用 .NET Framework 3.0 实现的,则此应用程序可能类似于图 5。

图 5

图表左上角所示的应用程序业务逻辑是使用 WF 工作流实现的。 处理保险申请是一个多步骤的过程,包括根据该组织的承销规则评估申请,也许检查申请人的信用,甚至可能获得经理的批准。 工作流将上述每个步骤作为活动实现,并根据需要依赖于其他软件。 例如,为了访问存储的数据,此工作流中的活动使用 ADO.NET。

这家保险公司提供呼叫中心,允许其客户通过电话申请保险。 图中右上方所示的呼叫中心人员使用的客户端软件作为独立的 WPF 应用程序实现。 此客户端使用针对 WCF-WCF 通信优化的二进制协议,使用 WCF 与应用程序的业务逻辑进行通信。 如图所示,呼叫中心工作人员依赖于 Windows CardSpace 来选择登录此应用程序时将使用的标识。

客户还可以通过 Web 申请保险,保险代理也可以提交申请。 为了允许此操作,应用程序使用 ASP.NET 与 Web 浏览器通信。 如图表左下角所示,使用 Internet Explorer 通过普通 HTML 界面访问此应用程序的客户仍然可以使用 CardSpace 选择要呈现的标识。 第三方还可以为其他客户端操作系统和浏览器实现标识选择机制,从而允许标识元系统扩展到非 Windows 客户端和 Web 浏览器。

通过 Internet 访问此应用程序的保险代理可能需要功能更强大的接口。 因此,他们可以依赖于 XBAP,而不是简单的 HTML 接口。 如图表的下半部分所示,这为这些客户提供了呼叫中心中使用的 WPF 桌面应用程序提供的大量用户界面功能。 两者都是基于相同的基础构建的,因此应用程序的开发人员可以在两种类型的客户端中重复使用相同的代码。 与其他类型的客户端一样,代理可以使用 CardSpace 来选择要向应用程序呈现的标识。

最后,此应用程序可能需要访问并被其他应用程序访问。 例如,如果批准客户需要信用检查,则很可能通过调用外部服务来完成此操作。 或者,应用程序可能直接接受来自其他软件的请求,公开这些外部应用程序可以调用的服务。 对于此类情况(如图右下角所示),应用程序依赖于 WCF 来使用标准 Web 服务进行通信。 无论这些应用程序基于什么技术,WCF 对 SOAP 的支持都使与它们交互变得简单。

此方案演示了如何在典型应用程序中使用 .NET Framework 3.0 的一些最重要的组件。 省略了不少选项,因此不要将此简单示例视为此技术系列提供的内容的完整说明。 相反,目标是清楚地了解如何协同使用 .NET Framework 3.0 的各个部分来解决实际业务问题。

了解.NET Framework 3.0:技术

若要真正了解 .NET Framework 3.0 提供的功能,深入了解其每个构成技术非常有用。 本部分提供有关 .NET Framework 3.0 的五个部分的简短教程。 有关每个内容的更详细的介绍,请参阅本文末尾的进一步阅读。

.NET Framework 2.0

图 6

.NET Framework 2.0 是当今 Windows 开发的基础部分,也是 .NET Framework 3.0 的基础。 图 6 演示了框架的两个部分:公共语言运行时 (CLR) 和.NET Framework类库。 .NET Framework 3.0 的某些组件(包括 WF、WCF 和 WPF)主要作为.NET Framework类库的扩展实现。 不过,如前所述,虽然类库的许多部分仍然是开发人员世界的重要组成部分,但其他部分则被.NET Framework 3.0 提供的新技术所包含。 例如,ASP.NET 仍然是创建浏览器可访问的应用程序的基础,ADO.NET 仍用于处理存储的数据。 但是,.NET Framework 3.0 开发人员可能使用 WPF 而不是Windows 窗体来创建本机 Windows GUI,他们通常更喜欢 WCF 而不是 ASP.NET Web 服务、.NET 远程处理或企业服务。 尽管发生了这些更改,但请务必了解,即使在 NET Framework 3.0 环境中,以前版本的框架仍然是开发人员生活的核心部分。

Windows Workflow Foundation

由工作流驱动的面向流程的设计可能是相当一部分 Windows 软件的正确方法。 WF 的目的是让开发人员创建和执行这些基于工作流的应用程序。 图 7 显示了 WF 为此提供的组件。

图 7

如前所述,每个工作流都是从一些活动生成的。 工作流和活动都只是类,因此可以直接在代码中创建两者。 WF 还提供工作流Designer,这是一种用于构造工作流的 Visual Studio 托管的图形工具。 但是,创建工作流后,可以从与 WF 一起提供的基本活动库 (BAL) 或任何其他源中提取其活动。

定义工作流后,它最终由 WF 运行时引擎执行。 此引擎依赖于一组运行时服务来保存工作流的状态、跟踪工作流的执行等。 所有这些内容(运行时服务、运行时引擎和工作流本身)都包含在某个主机进程中。 此过程可以是任何 Windows 进程,从桌面上运行的简单控制台或 WPF 应用程序到可缩放的服务器进程。

了解 WF 需要至少了解其所有组件。 以下各节将简要介绍每个部分。

工作流

从本质上看,工作流只不过是一组活动。 WF 为两种工作流样式提供内置支持:

  • 顺序工作流,按定义的顺序执行活动。 与传统流程图一样,顺序工作流可以包含分支、循环和其他控制结构。 但是,默认情况下,活动按顺序执行,一个接一个。
  • 状态机工作流,实现传统的有限状态机。 与任何状态机一样,哪个活动在特定时间执行是由当前状态和已接收的任何事件的组合决定的。

顺序选项适用于定义完善的工作流,例如纯基于软件的流程中使用的工作流。 它们创建和理解相对简单,最初对大多数开发人员来说感觉更自然。 当执行路径不可预测时,状态机工作流是更好的选择。 一个很好的示例是一个涉及与人员交互的工作流,其中任何人员都可以随时取消工作流。 可以使用顺序工作流解决此问题,但每个步骤都可以是一个分支:如果工作流未取消,请执行此操作;如果工作流被取消,则执行其他操作。 使用状态机对此类行为进行建模要简单得多,因为取消工作流的请求只是随时可以接收和处理的另一个事件。

对状态机工作流的支持是 WF 尝试为人工和系统工作流提供支持的一个示例。 另一个示例是 WF 支持更改正在运行的工作流。 人员可能是反复无常的,参与工作流的人员在进行过程中希望添加步骤、删除步骤或进行其他更改的情况并不少见。 为了以受控的方式适应这一点,WF 允许创建工作流的开发人员指定在执行工作流时是否以及如何对其进行修改。

基本活动库

开发人员可以自由创建自定义活动。 事实上,Microsoft 的目标是促进充满可重用活动的 WF 生态系统的增长。 不过,从一组常见的基础活动开始,每个人都可以简化生活。 提供此通用集是基本活动库 (BAL) 的角色。

工作流不需要使用 BAL 中的任何内容。 不过,许多开发人员会发现 BAL 让他们的生活更简单,尤其是一开始。 BAL 中包含的活动如下:

  • IfElse: 根据是否满足条件,执行两个或多个可能路径中包含的活动。
  • While: 重复执行一个或多个活动,前提是条件为 true。
  • Sequence: 按定义的顺序一次执行一组活动。
  • 并行: 并行执行两组或更多组活动。
  • 代码: 执行定义的代码块。
  • 侦听: 等待特定事件,然后在收到该事件时执行一个或多个活动。
  • InvokeWebService: 调用 Web 服务。
  • 状态: 表示工作流状态机中的状态。
  • EventDriven: 定义一个转换,其中包含在收到特定事件时处于特定状态时应执行的一个或多个活动。
  • 策略: 允许使用 WF 提供的规则引擎定义和执行业务规则。

WF 没有定义用于指定工作流的特定语言,而是采用更常规的方法来使用活动。 BAL 提供了一种“语言”,但每个使用 WF 的人也可以自由定义自己的语言。

Windows Workflow Foundation 工具:工作流Designer

使用工作流创建应用程序的优点之一是能够以图形方式定义工作流。 WF 的工作流Designer允许此操作,如图 8 所示。 默认情况下,BAL 中的活动显示在工具箱中,开发人员可将其拖放到工具的设计图面上以创建工作流。

图 8

一些开发人员更喜欢编写代码,他们不喜欢图形设计器。 WF 允许这种方法,太 (,有时需要它:活动通常直接在代码) 中生成。 还可以结合使用这两种方法,使用工作流Designer和直接编码创建工作流。 目标是让开发人员使用对他们最高效的方法。 为了允许更广泛的工具支持,工作流还可以用 XAML(与 WPF 使用的相同语言)表示。 事实上,使用工作流创建的工作流Designer默认为 XAML 定义。

运行时引擎和运行时服务

如前所述,WF 运行时引擎的工作是在工作流中执行活动。 作为执行此操作的一部分,它依赖于一组运行时服务。 WF 包括这些服务的标准实现,但雄心勃勃的开发人员可以根据需要替换它们。 这些服务支持一些不同功能,但其中两项最引人注目:

  • 坚持: 阻止等待某个事件的工作流可以使用此服务将其内存中状态自动保存到磁盘。 事件发生时,服务将自动重新加载工作流的状态并重启执行。 这对于涉及人员的工作流特别有用,因为等待响应时可能需要花费数小时、天数或更长的时间。
  • 跟踪: 工作流中的活动会明确划分其实现的进程执行。 WF 的跟踪服务允许开发人员将有关工作流执行的信息自动写入数据库。 例如,开发人员可能希望跟踪工作流的开始和结束时间、其每个活动的开始和结束时间以及其他信息。

Windows Workflow Foundation 和其他 Microsoft 技术

引入新方法不可避免地会影响已经存在的内容。 .NET Framework 3.0 中的新技术也不例外,每种技术都会对其他 Microsoft 技术产生影响。 使用 WF 时,Windows SharePoint Services、Microsoft Office 2007 系统和BizTalk Server最强烈。

为了让开发人员更轻松地创建用于文档协作和其他类型的信息共享的工作流应用程序,Windows SharePoint Services版本 3 托管 WF 运行时。 Office SharePoint Server 2007 是 Office 2007 系统的一部分,基于 Windows SharePoint Services 中的 WF 支持。 此外,添加此服务器允许在 Office 2007 客户端应用程序中直接显示 InfoPath 表单,并使用一组预定义工作流用于常见方案,例如批准文档。

任何熟悉BizTalk Server的人现在都注意到了该产品的业务流程功能与 WF 提供的功能之间的相似性。 事实上,BizTalk Server 2006 之后的版本将用 WF 替换产品的现有业务流程函数,从而提供工具来帮助将现有业务流程迁移到 WF 工作流。 但是,必须了解 WF 和 2006 BizTalk Server 2006 解决了非常不同的问题:

  • WF 提供了用于创建基于工作流的 Windows 应用程序的常规框架。 它可以托管在任何流程中,使用任何类型的活动,并解决任何类型的业务问题,包括人工和系统工作流。
  • BizTalk Server是一种许可产品,专注于企业应用程序集成、企业到企业集成和管理业务流程。 它提供一组用于连接到各种系统和软件的适配器、用于实现 RosettaNet 和 SWIFT 等标准的加速器,以及对业务活动监视的支持。 BizTalk Server还提供管理基础结构和工具,并支持提高可伸缩性。

由于它是 Windows 的标准工作流技术,因此 WF 将来很可能出现在其他 Microsoft 产品和技术中。 无论 Microsoft 选择做什么,WF 肯定会在其客户创建的多个应用程序中找到一个主页。

Windows Communication Foundation

对面向服务的通信的更改标志着应用程序交互方式的转变。 WCF 显式设计为支持面向服务的应用程序,反映了这种转变。 本部分介绍 WCF 最重要的方面,包括服务和客户端、通信选项以及对安全性、可靠通信和事务的支持。

服务和客户端

图 9

如图 9 所示,WCF 的基本概念很简单:服务公开可由客户端访问的接口。 可以使用 Web 服务描述语言 (WSDL) 来定义该接口,然后将其转换为代码,也可以直接使用 C# 或 Visual Basic 等语言进行定义。 对于公开保险应用程序服务的简单接口,后一种方法可能如下所示:

[ServiceContract]
interface IInsuranceApplication
{
 [OperationContract]
 int Submit(int policyType, string ApplicantName);

 [OperationContract]
 bool CheckStatus(int applicationNumber);

 [OperationContract]
 bool Cancel(int applicationNumber);
}

此 C# 接口的定义用 ServiceContract 属性标记。 此属性指示 WCF 可以将此接口中的方法公开为可远程调用的操作。 公开哪些接口的方法取决于使用 属性标记 OperationContract 的接口方法。 在此简单示例中,每个方法都标有此属性,因此所有方法都将向远程调用方公开。 但是,这不是必需的 —仅应用于 OperationContract 某些接口的方法是合法的。 无论做出哪种选择,应用程序中的某个类都必须实现此接口,为接口定义的方法提供实际代码。 完成此操作后,WCF 会自动使标记有此 OperationContract 服务的客户端可以访问的方法。

图 10 提供了服务实际如何向其客户端公开的稍微详细视图。 客户端而不是直接访问接口,而是连接到特定 终结点。 一个服务可以公开多个终结点,从而可能允许不同的客户端以不同的方式访问它。

图 10

如图所示,每个终结点指定三项内容:

  • 描述可使用此终结点调用的操作的 协定 。 可以仅使用定义这些操作的接口的名称来标识协定,此处为 IInsuranceApplication。
  • 定义如何调用终结点操作的 绑定 。 每个绑定定义了几个内容,包括应使用哪种协议来调用操作、应使用哪种类型的安全性等。 WCF 包括一组预定义的绑定,例如此处显示的 BasicHttpBinding,适用于最常见的情况,还可以定义自定义绑定。 由于单个服务可以公开多个终结点,因此它可以同时允许通过不同的协议和不同的安全选项访问不同类型的客户端。
  • 指示可在何处找到此终结点的 地址 。 如图所示,地址表示为 URL。

WCF 的基础知识很简单。 与大多数通信技术一样,细节可能会变得复杂(有许多选项),但创建普通的 WCF 应用程序并不难。

通信选项

由不同类型的开发人员构建的不同类型的应用程序需要不同的通信方式。 对于大多数开发人员来说,最简单的方法是远程过程调用 (RPC) ,这样客户端就可以像调用本地操作一样调用远程操作。 例如,给定前面所示的接口,客户端可以以通常的同步方式调用任何操作,耐心等待,直到响应返回。 此选项对开发人员来说很容易,在某些情况下是正确的选择。

但是,WCF 还提供其他几个选项。 它们包括以下类型:

  • 没有响应的调用。 使用 属性 OneWay标记 ,这种通信可用于发送事件或其他单向交互。
  • 基于消息的异步通信,通过 XML 消息使用直接发送和接收。
  • 显式操作 SOAP 消息,包括直接在 SOAP 标头中插入元素的功能。

WCF 还允许开发人员控制服务的行为方式的各种本地方面。 ServiceBehavior例如,使用 属性,他们可以设置服务是单线程还是多线程服务、是否为每个调用创建新的服务实例以及其他选项。

安全性、可靠性和事务

基本通信(在系统之间移动数据的能力)很有用,但很少足够。 大多数应用程序需要更多。 例如,大多数分布式应用程序都需要某种安全性。 考虑到目前使用的不同方法和技术的多样性,提供安全性可能非常复杂。 为了让开发人员在不强制他们了解所有详细信息的情况下创建安全的分布式应用程序,WCF 主要依赖于绑定来保证安全性。 例如,可以将前面显示的 BasicHttpBinding 配置为使用 HTTPS 而不是普通 HTTP,而其他绑定提供更多的安全选项。 例如,WsHttpBinding 支持 WS-Security,允许基于 SOAP 的互操作身份验证、数据完整性和数据机密性。 开发人员还可以创建自定义绑定,提供其应用程序所需的确切安全服务。

确保通信可靠对于许多应用程序也至关重要。 传统的 Web 服务方法(通过 HTTP 发送 SOAP)在某些情况下就足够了,在使用基本HttpBinding时,它就是要执行的操作。 但是,在很多情况下,这种广泛使用的选择是不够的。 例如,通过一个或多个 SOAP 中介传递的消息不能依赖于这种简单的方法来实现端到端可靠性。 对于这些情况,WCF 实现 WS-ReliableMessaging。 通过选择支持此选项的绑定(例如 WsHttpBinding),开发人员可以自动获取可互操作的可靠消息传输。

分布式事务在某些应用程序中也很重要。 WCF 基于 System.Transactions(.NET Framework 2.0 的一部分)构建,以允许创建事务性软件。 方法可以使用 OperationBehavior 特性来指示它需要事务并定义该事务的行为方式。 为了允许跨供应商边界互操作的分布式事务,WCF 依赖于WS-AtomicTransaction规范。 使用此多供应商协议中定义的技术,WCF 应用程序可以参与跨各种技术的事务,包括 J2EE 和其他技术。

Windows Communication Foundation 和其他 Microsoft 技术

如前所述,WCF 取代了一些早期用于创建分布式应用程序的 Microsoft 技术。 使用 ASP.NET Web 服务、.NET 远程处理、企业服务、System.Messaging 或 WSE 生成的大多数应用程序都将基于 WCF 生成。 WCF 应用程序可以与 ASP.NET Web 服务应用程序(都支持标准 SOAP)以及基于企业服务、MSMQ 和 WSE 3.0 版构建的应用程序进行互操作。 BIZTALK SERVER 2006 也可以使用 WCF,BizTalk Server的未来版本将更直接地基于 WCF 提供的内容生成。

请务必了解,尽管新的 .NET Framework 3.0 应用程序通常不会使用它们,但 WCF 取代的所有技术仍然是此框架版本的一部分,它们都将像往常一样受到支持。 使用这些技术的早期版本生成的应用程序也将继续正常运行:安装和使用 .NET Framework 3.0 不会破坏现有代码。

Windows CardSpace

无论是通过 Web 浏览器还是某种其他类型的客户端,用户都经常通过网络访问应用程序。 由于这些应用程序通常要求用户以某种方式标识自己,因此不可避免的推论是,人们经常被迫获取身份信息并将其呈现给远程软件。 通过浏览器访问 Internet 应用程序提供了一个非常常见的示例,Intranet 上的用户也经常面临此问题。

如前所述,当今人们最常依赖用户名和密码来获取数字标识,这会带来所有问题。 Windows CardSpace 是较大标识元系统的一部分,提供了解决这些问题的替代方法。 若要更深入地了解 CardSpace 如何执行此操作,首先需要了解标识元系统的基本概念。

Windows CardSpace 和 Identity 元系统

当用户从 Web 浏览器或应用程序特定的客户端或其他内容访问应用程序时,他们通常提供某种数字标识。 数字标识有多种类型,但实际上所有这些标识都通过 安全令牌在网络上表示。 虽然简单的安全令牌可能只是用户名,但更复杂的令牌可能包含 X.509 证书或 XML 文档。 但是,安全令牌是当今在网络上表示数字标识的典型机制。

虽然我们总有一天会采用通用安全令牌格式,但现实情况是,各种方法将继续使用。 正如我们今天在钱包中携带多个身份证(驾驶执照、信用卡、航空公司常客卡等)一样,我们始终拥有由各种安全令牌表示的各种数字标识。 任何一个标识系统都不能提供通用答案,因此始终需要多个安全令牌。

然而,用户仍然需要某种方式来一致地使用其多样化的数字标识。 即使单个标识系统都不够,也可以创建标识系统(标识元系统),以一致的方式使用无数数字标识。 与其他人合作,Microsoft 领导了定义此元系统的过程。 基于开放 Web 服务技术(如 WS-Security 和 WS-Trust),此元系统定义如何获取和使用数字标识,而不管数字标识所依赖的安全令牌类型如何。

颁发、获取和使用数字标识的过程可以视为需要三个不同的角色。 这些角色如下:

  • 用户: 有时称为 主题,用户是具有数字标识的实体。
  • 标识提供者: 标识提供者为用户提供数字标识。 例如,对于雇主分配给你的数字标识,标识提供者通常是一个系统,例如 Active Directory。 对于与 Amazon 一起使用的数字标识,标识提供者实际上是你,因为你定义了自己的用户名和密码。 由不同标识提供者创建的数字标识可以携带不同的信息,并提供不同级别的保证,确保用户确实是他们所声称的身份。
  • 信赖方: 信赖方是某种方式依赖于数字标识的应用程序。 信赖方将经常使用标识 (即此标识的安全令牌中包含的信息) 对用户进行身份验证,然后做出授权决策,例如允许此用户访问某些信息。 信赖方还可能使用该标识来获取信用卡号码、验证同一用户是否在不同的时间访问该标识,或者用于其他目的。 信赖方的典型示例包括 Internet 网站(如银行、在线商家和拍卖网站),以及通过 Web 服务接受请求的任何应用程序。

这三种类型的实体在标识元系统中交互。 图 11 演示了这些交互,以及 CardSpace 的适用位置。

图 11

当用户通过 CardSpace 感知应用程序访问信赖方时,该过程将开始。 若要了解此信赖方将请求哪种类型的安全令牌,应用程序必须获取信赖方的策略 (步骤 1) 。 对于访问网站的浏览器(这可能是最常见的情况),网站的策略以 HTML 表示,并作为网页的一部分发送回来。 但是,对于通过 Web 服务访问的应用程序,应用程序会改用WS-MetadataExchange定义的行业标准协议来请求信赖方提供其策略。 在这种情况下,使用另一个行业标准 WS-SecurityPolicy 来表示策略。 但是获取策略信息时,它始终指示此信赖方将接受哪种类型的安全令牌,以及这些令牌必须包含哪些信息。

CardSpace 知道信赖方需要哪种类型的安全令牌后,它会显示前面显示的标识屏幕。 此用户可用的每个数字标识都表示为此屏幕上卡的信息。 外部信赖方颁发的卡称为 托管 卡,而由 CardSpace 的自发提供程序颁发的卡称为 自发 卡。 这两种卡片都可以在此屏幕上显示,用户可以选择任一类型之一。 为了简化此决策,屏幕会通过灰显不符合资格的卡片来指示哪些标识符合信赖方的要求。 然后,用户选择其中一个作为他想要使用的数字标识 (步骤 2) 。

但是,卡不包含实际的安全令牌。 相反,它保存查找特定标识提供者并为此用户请求安全令牌所需的信息。 (事实上,每个卡最初是由某些标识提供者创建的。) CardSpace 使用用户选择的卡的内容从颁发该标识提供者请求安全令牌卡 (步骤 3) 。 此请求使用 WS-Trust(另一种行业标准协议)发出,用户使用 Kerberos、X.509 证书和数字签名或其他机制向标识提供者进行身份验证。 令牌以加密形式返回,其中还包含一个时间戳,以防止此令牌从网络上被盗并在将来重复使用。

返回请求的安全令牌后,将发送到信赖方 (步骤 4) 。 信赖方如何使用令牌中的信息可能会有所不同。 例如,如果令牌包含 X.509 证书,并且附带数字签名,信赖方可能会使用该令牌对用户进行身份验证。 但是,不需要将令牌用于身份验证或任何其他与安全相关的目的。 (事实上,术语“安全令牌”是一种错误名称。) 令牌可能包含用户年龄证明、在 Internet 购物网站上享受折扣的资格或其他任何信息。 身份验证是安全令牌的一个重要用途,但它不是唯一的选择。

请务必注意,CardSpace 和标识元系统作为一个整体都不知道用于安全令牌的格式或技术。 元系统的目标是提供一种一致的方式来使用基于任何类型的安全令牌的任何数字标识,而不是尝试为数字标识创建新的单一源或安全令牌的标准格式。 通过提供元系统关键部分的 Windows 实现,CardSpace 在实现数字标识的常规方法方面发挥着重要作用。

打击网络钓鱼

标识提供者通常与用户不同,例如,当标识由雇主分配时。 但是,在很多情况下,标识提供者实际上是用户本身。 例如,如果未使用 CardSpace,则访问许多网站需要提供用户名和密码,这两者均由用户定义。 用户创建此标识后,可以稍后提供用户名和密码,然后检查其银行余额、购买书籍或执行此网站允许的任何其他操作。

但是,由于它们依赖于密码,因此,如前所述,此类自我颁发的标识是攻击者的目标。 为了帮助减少这些攻击,CardSpace 提供了另一种创建自我颁发的标识的方法。 此自颁发标识提供者在用户的 Windows 系统上本地运行。 自行颁发的标识提供者创建的安全令牌不是依赖于用户名和密码,而是使用安全断言标记语言 (SAML) (OASIS 定义的标准)。 这些令牌依赖于公钥技术而不是密码来证明用户的身份,如果信赖方接受它们,它们可以发挥与传统用户名和密码相同的作用。 优点是网络钓鱼者不再有密码可以窃取。 减少密码的使用,以及前面所述的高保证证书提供的更有力的站点标识证明,会使网络钓鱼成为一个不那么严重的问题。

Windows CardSpace 和其他 Microsoft 技术

CardSpace 与其他一些 Microsoft 技术相关,包括:

  • Wcf: 由于它依赖于 WS-Security 和 WS-Trust 等 Web 服务标准,因此 CardSpace 使用 WCF 进行通信。 事实上,WCF 应用程序的创建者只需指定特定绑定即可使该应用程序使用 CardSpace。
  • Active Directory: 尽管目前无法实现,但 Active Directory 最终将能够充当元系统中的标识提供者。
  • Windows Live ID (以前称为 Passport) : 与 Active Directory 一样,Microsoft 已宣布其 Live ID 身份验证系统也将进行修改,以充当标识提供者。 请注意,CardSpace 不能替代 Live ID,因为两者解决的问题完全不同。 相反,Live ID 将像任何其他标识提供者一样成为标识元系统的一部分。

Microsoft 还提供其他与标识相关的技术,这些技术可以解决与 CardSpace 不同的问题。 例如,Active Directory 联合身份验证服务 (ADFS) 侧重于跨组织联合标识。 这是一个重要的挑战,许多需要与其他组织合作的公司都面临着这一挑战。 但是,此问题与 CardSpace 和标识元系统解决的更广泛的问题完全不同。

Windows Presentation Foundation

基于工作流的逻辑、面向服务的通信和标识在现代应用程序中都很重要。 然而,用户通常最关心的是他们所看到的内容:用户界面。 WPF 的目标是解决为新式应用程序创建用户界面时面临的挑战。 如下文所述,WPF 提供了一系列执行此操作的功能。

Windows Presentation Foundation的功能

开发人员可以完全使用 C#、Visual Basic 或其他基于 CLR 的语言自由创建 WPF 应用程序的界面。 但是,如前所述,WPF 还允许使用基于 XML 的 XAML 指定接口。 XAML 中的元素和属性直接映射到 WPF 提供的类和属性。 例如,下面是在 XAML 中定义的简单按钮:

<Button Background="Red">
 No
</Button>

此示例创建一个包含文本“否”的红色按钮。也可以使用以下代码生成完全相同的结果:

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";

但定义后,几乎每个 WPF 应用程序都遵循相同的基本模型。 应用程序继承自 WPF 的标准 Application 对象,该对象提供基本方法、事件和属性。 WPF 应用程序可以具有传统的对话驱动的接口或导航界面,使其功能非常类似于浏览器应用程序。 以后一种样式生成的应用程序通常作为一组页面实现,每个页面由 XAML 中定义的用户界面以及代码中定义的一些逻辑组成。 为了将这些页面链接在一起,XAML 提供了一个 Hyperlink 元素,就像 HTML 一样。 应用程序一次显示一个页面,允许用户在其页面之间来回移动,维护历史记录列表等。 尽管导航应用程序可以作为 XBAP 在 Web 浏览器中运行,但这不是必需的;开发人员也可以免费在独立 WPF 应用程序中使用此接口样式。 目标是创建结合了浏览器界面和本机 Windows 界面的最佳方面的软件。

无论其接口使用何种样式,WPF 应用程序都可以依赖 面板 进行基本布局。 每个面板通常包含 控件,WPF 提供的控件包括 ButtonTextBoxComboBoxMenu 等。 这些控件的定位方式取决于选择的面板类型。 例如,Grid 允许将控件定位到指定的网格上,而 Canvas 允许开发人员将控件放置在其边界内的任意位置。 和往常一样,在 GUI 中,用户生成的事件由应用程序中的各种控件和其他类捕获和处理。 还可以将样式和模板应用于控件组,使应用程序更易于具有统一的外观。

WPF 支持的不仅仅是这些基本用户界面函数,包括:

  • 文件: WPF 应用程序可以使用 XAML 的 FixedDocument 标记显示 XPS 文档。 应用程序还可以使用 FlowDocument 标记显示流文档。 流文档的行为可以类似于传统的屏幕文档,允许用户滚动浏览其内容。 但是,通过在此标记上设置各种属性,开发人员可以使文档更适应其周围环境。 文档可以一次显示页面,例如,使读者无需来回滚动。 WPF 还可以根据显示文档的窗口大小自动确定应拆分为多少列。 目标是使屏幕上的文档尽可能可读。
  • 图形: WPF 支持创建二维和三维矢量图形。 对于 2D 工作,WPF 提供标准抽象,如形状、画笔和笔,同时允许 3D 图形定义可分配照明和相机位置信息的模型。 与依赖 GDI+ 进行图形的早期技术(如 Windows 窗体)不同,WPF 图形不会使用开发人员必须理解的一组单独的概念进行分区。 相反,用于图形的 XAML 元素可以自然地与用于用户界面中任何其他元素的元素组合在一起。 按钮可以包含图形内容、文本和图形可以组合,等等。
  • 图像: 使用 XAML 的 Image 标记,WPF 应用程序可以显示各种格式的图像,包括 JPEG、GIF 等。 WPF 依赖于 Windows 图像处理组件 (WIC) 为编解码器、显示和存储图像的软件提供标准框架。 像往常一样, WPF 中,Image 元素可以与其他元素结合使用,从而允许诸如显示图像而不是简单文本标签的按钮之类的内容。
  • 媒体: WPF 应用程序可以使用 MediaElement 标记以各种格式显示视频和音频,包括 WMV、AVI 和 MPEG。 同样,此元素可以与其他 XAML 元素结合使用,从而允许在其两侧显示视频的 3D 立方体等内容。
  • 动画: WPF 为用户界面的大部分部分提供动画的内置支持。 例如,圆圈可以增大和缩小,或者按钮可以平滑地更改大小。 应用程序还可以定义包含时间线的情节提要,从而允许出现协调的动画序列。
  • 数据绑定: 由于许多 WPF 应用程序显示数据,因此自动支持将数据映射到用户界面元素会很有用。 WPF 为对象和其他源中包含的信息提供这种类型的数据绑定。 WPF 数据绑定还允许在显示数据之前对数据进行排序和筛选。

应用Windows Presentation Foundation

WPF 提供了一大组用户界面功能,使开发人员和设计人员能够创建极具吸引力的用户界面。 然而,无论客户端应用程序看起来多么可爱,某些组织都可能会因为部署问题而拒绝使用它。 如果推出新版本的客户端需要物理接触安装了此应用程序的每台台式计算机,则升级成本可能很大。 目前避免此问题的一种常见方法是创建基于浏览器的客户端,而不是本机 Windows 客户端。 然而,与浏览器相比,本机 Windows 客户端通常具有更好、响应更强的用户界面。 若要解决部署这些客户端的挑战,可以使用 ClickOnce 来部署独立的 WPF 应用程序。 ClickOnce 是首次出现在 .NET Framework 2.0 中的一项技术,它允许 Internet Explorer 用户通过 Web 选择应用程序,然后将其自动安装到本地计算机上。 安装后,应用程序还可以在新版本可用时自动更新。 目标是将 Web 客户端部署的简单性和廉价性与独立 WPF 应用程序的强大功能和功能相结合。

尤其是在使用 ClickOnce 部署它们时,在许多情况下,独立 WPF 应用程序是一个很好的客户端选择。 然而,在某些情况下,这种应用程序是不合适的,即使其用户可以受益于 WPF 允许的接口类型。 例如,考虑前面所述的方案中的远程保险代理,或者希望提供 3D 图形、视频和 WPF 支持的其他新式功能的 Internet 商家。 期望此应用程序的用户安装本机 WPF 应用程序来访问站点通常是不合理的。 更好的解决方案是在其 Web 浏览器中为用户提供 WPF 样式的界面。

XAML 浏览器应用程序(XBAP)旨在执行此操作。 Internet Explorer 用户可以将 XBAP 直接下载到浏览器中,而不是部署独立的 WPF 应用程序。 在 Internet Explorer 中运行,此应用程序随后可以向用户显示基于 WPF 的用户界面。 然而,从 Internet 网站下载和运行代码可能很危险。 为了保护用户免受恶意开发人员的侵害,从 Internet 下载的所有 XBAP 都在部分受信任的沙盒中运行。 根据.NET Framework提供的代码访问安全性,此沙盒会限制 XBAP 可以执行的操作。 例如,从 Internet 下载的 XBAP 无法创建独立窗口或启动新窗口、显示 XBAP 本身启动的“保存”对话框,或访问文件系统,除非位于隔离的存储区域。 然而,尽管沙盒施加了限制,XBAP 仍然可以使用大部分 WPF 功能,包括 2D 和 3D 图形、动画、屏幕文档、图像、视频等。

如前所述,WPF 允许应用程序使用 XAML 的 FlowDocument 元素显示自适应文档。 但是,其外观根据显示方式而变化的文档并不总是最佳解决方案。 固定格式的文档(在屏幕上和打印机上看起来始终相同)有时是更好的选择。 WPF 的 XPS 文档解决了此问题。 使用 XAML 的子集定义,可以在提供 XPS 读取器的任何系统上读取 XPS 文档。 它们还为 Windows 提供了新的打印格式,允许以更高的保真度打印复杂的图形。 为了使处理不同类型的文档更加一致,XPS 文档和 Office 2007 文档都使用 Microsoft 的开放打包约定,该约定定义了存储文档内容、对文档进行数字签名等的常见方法。

Windows Presentation Foundation工具

可以使用基本文本编辑器直接在代码和/或 XAML 中创建任何 WPF 用户界面。 但是,大多数人更喜欢使用更好的工具,因此 Microsoft 提供了 Visual Studio 2005 的扩展,使开发人员能够创建 WPF 应用程序。 下一个版本的 Visual Studio(代号为“Orcas”)将为 Windows Presentation Foundation 提供更多的 Visual Designer功能。 使用此工具,开发人员将能够以图形方式创建他们希望看到的用户界面,然后让该工具生成此接口的代码。

然而,开发人员通常不是定义用户界面的最佳人手。 设计师通常更擅长此类工作,因为他们专门从事与人沟通。 不过,大多数设计人员不会编写代码,因此托管在 Visual Studio 中的适用于 Windows Presentation Foundation 的 Visual Designer 不是此组的有效工具。 为了让设计人员在 WPF 世界中有效工作,Microsoft 创建了 Expression Interactive Designer。 设计器可以使用此工具定义界面的外观、指定动画等,然后让该工具生成所创建内容的 XAML 版本。 开发人员可以将此 XAML 导入 Visual Studio,并为处理事件等操作添加代码。 由于 Visual Studio 和 Expression Interactive Designer使用相同的生成系统,因此开发人员和设计人员可以迭代处理项目,每个项目都使用他们熟悉的工具。 目标是帮助设计和软件工程不同学科的人员有效地协同工作。

Windows Presentation Foundation和其他 Microsoft 技术

与其他.NET Framework 3.0 组件一样,WPF 对现有 Microsoft 技术也有影响。 这其中,最重要的是下列功能:

  • Windows 窗体:.NET Framework创建应用程序 GUI 的原始方法,Windows 窗体目前在许多应用程序中都使用。 认识到这一点后,WPF 允许Windows 窗体控件托管在 WPF 应用程序中,而 WPF 控件则托管在Windows 窗体应用程序中。 例如,Windows 窗体应用程序可能承载一个 WPF 控件,该控件提供三维数据可视化效果。 虽然存在一些限制,但创建使用这两种技术的应用程序当然是可能的。 另请注意,现有Windows 窗体应用程序将继续在 .NET Framework 3.0 环境中保持不变地工作。
  • Win32 和 Microsoft 基础类 (MFC) :与 Windows 窗体 一样,可以在使用这些现有技术构建的现有应用程序中托管 WPF 控件,反之亦然。 但是,互操作性比Windows 窗体复杂一些,因为与Windows 窗体不同,基于 Win32 的应用程序和基于 MFC 的应用程序不是基于 CLR 构建的。 因此,与 WPF 的互操作性还需要基于 CLR 的代码和本机 Win32 代码之间的映射。
  • Direct3D: Direct3D 是 DirectX API 系列的一部分,它允许应用程序创建和显示 3D 图形。 随着 .NET Framework 3.0 的出现,主流 Windows 应用程序可以使用 WPF 中的 3D 功能,而不是 Direct3D 提供的更专业化的方法。 不过,某些需要更高性能的应用程序(如 3D 游戏)将继续使用 Direct3D。 事实上,WPF 依赖于 Direct3D 进行所有呈现。
  • Windows Communication Foundation: 如前面的方案所示,WPF 应用程序可以使用 WCF。 但是,XBAP 通常无法使用 WCF,因为 WCF 需要完全信任。 从 Internet 下载的每个 XBAP 都在部分信任沙盒中运行,这会禁止它访问 WCF。 但是,XBAP 可以使用 ASP.NET Web 服务,从而允许它们进行与 WCF 和其他 Web 服务实现互操作的 SOAP 调用。
  • “WPF/E”:WPF 的另外一个方面也值得一提,尽管它不是 .NET Framework 3.0 的一部分。 代码名为“WPF/E”,其目标是在不支持 WPF 本身的系统上支持 WPF 样式的接口。 正如其名称中的“E”所暗示的,这项技术旨在随处可用,包括 Macintoshe、小型设备和其他系统。 WPF/E 计划在 WPF 本身之后的某个时间交付,将提供一部分完整的 WPF 功能,包括 2D 图形、动画和视频。

获取 .NET Framework 3.0:分发选项

若要使应用程序使用 .NET Framework 3.0,必须在运行此应用程序的计算机上安装此版本的 Framework。 对于 Windows Vista,这很简单:默认安装 .NET Framework 3.0。 这意味着安装了 Windows Vista 的新计算机或升级到 Vista 的现有计算机将自动运行 .NET Framework 3.0 应用程序。 但是,.NET Framework 3.0 也可以在 Windows XP 和 Windows Server 2003 上运行。 为了使新的 .NET Framework 3.0 组件可供这些系统的现有用户使用,Microsoft 将免费下载此软件。

结论

.NET Framework 3.0 是 Windows 编程模型的演变。 基于并扩展 .NET Framework 2.0,其目标是支持新式应用程序的创建。 为此,框架版本 3.0 提供了一组不同的技术,每种技术都解决了当今应用程序开发中的重大挑战。 通过在共同的基础上构建这种多样性,Microsoft 正努力使整体大于各个部分的总和,让开发人员以一致的方式创建使用 .NET Framework 3.0 各个部分的应用程序。

无论组织选择采用此新版本的哪个方面,该技术都肯定会对 Windows 软件的世界产生重大影响。 对于在这个世界中工作的任何人(开发人员、架构师或决策者),现在是时候开始了解如何从 .NET Framework 3.0 中受益了。

其他阅读材料

了解 .NET,第二版。 大卫·查佩尔,艾迪森-韦斯利,2006

Windows Workflow Foundation 简介

Windows Communication Foundation 简介

Windows CardSpace 简介

介绍Windows Presentation Foundation: (正在进行)

 

关于作者

大卫·查佩尔是位于加利福尼亚州旧金山的查佩尔 & 协会 (www.davidchappell.com) 的负责人。 通过演讲、写作和咨询,他帮助世界各地的技术专业人员了解、使用企业软件并做出更好的决策。