.net framework3.0

描述 .NET Framework 3.0应用程序开发的目标始终如一,就是在最短时间内制作出最好的软件。然而,随着开发平台的性能越来越高,制作软件的壁垒也相应提高了。以 Windows 为例,原来的 Win32 接口已经融入到功能更强的 .NET Framework 中。2002 年发布的 Framework 1.0 和 2005 年发布的 Framework 2.0 为设计和编写 Windows 软件的开发人员提供了更好的工作环境,效率也更高。

.NET Framework 3.0(以前称为 WinFX)就是我们前进路上的下一个目标。建立在这一新版 Framework 上的应用程序可通过 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 版是在以前版本的基础上完善而成。事实上,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(http://msdn2.microsoft.com/zh-cn/library/Aa479861.intronet30_01(zh-cn,MSDN.10).gif )

.NET Framework 2.0:Windows 应用程序通用基础
尽管仍然可以通过 Win32 界面直接编写软件,而事实上却是,.NET Framework 已经成为编写新 Windows 应用程序的主流环境。如下所示为.NET Framework 最重要的组成部分:

• ASP.NET,支持可 Web 访问的应用程序的开发。

• ADO.NET,允许应用程序访问相关的其他类型数据。

• Windows Forms,支持建立 Windows 应用程序的图形用户界面 (GUI)。

• System.XML,使应用程序能够使用 XML 定义的数据,包括 XSLT 和 XPath。

Framework 的 2.0 版本在以前版本的基础上添加了几项实用功能,包括对开发 ASP.NET Web 应用程序的技术改进,支持在 64 位 Windows 上运行的 64 位应用程序,还增加了处理事务的新方法。虽然 .NET Framework 2.0 中的部分组件为 3.0 版本中新增组件所取代,但是 2.0 版本的技术仍然是新发布的 3.0 版本的基础,请见随后的详细介绍。

Windows Workflow Foundation:支持基于工作流的应用程序
工作流是一个简单思路:按照特定顺序执行的一系列步骤。您甚至可以认为每个应用程序都在执行工作流,因为每个应用程序都执行某些过程。但是,在使用 C#、Visual Basic.NET 或其他编程语言等传统方法开发的应用程序中,这些过程都隐含在代码中。这样做没问题,但是这些过程被深深地嵌入程序逻辑中,使得其执行或更改愈加困难。

使用工作流技术执行过程逻辑可以有效地解决这一问题。采用工作流技术后,逻辑与普通代码就不会纠缠在一起,过程中的每一步骤都会明确定义,然后由工作流引擎执行。这样做的结果就是,过程执行清楚明确。

工作流引擎不是什么新概念,有些已经在 Windows 和其他系统中得到应用。Microsoft 已经在部分产品中嵌入了工作流引擎。但是,随着工作流日渐成为开发应用程序的主流方法,提供适用于 Windows 的单一工作流技术已经势在必行。这也正是 Windows Workflow Foundation(正式缩写是 WF )的设计初衷。由于其提供了适用于 Windows 的通用工作流技术,WF 已成为所有基于工作流应用程序的统一创建基础。Microsoft 的 Microsoft Office 2007 系统、Windows SharePoint Services 等软件,以及许多其他公司的应用程序也会使用 WF。

但是,提供通用的工作流技术之路却是困难重重。举例来说,如何使用一种方法来满足不同工作流应用程序的各种要求?WF 给出的答案是,从全局视角来看待工作流。如图 2 所示,WF 工作流只是一组由 WF 引擎执行的活动。一个活动就是一个类,它可以包含工作流创建者认为有必要的任何工作。活动可以在不同的工作流中重复使用,因此,在针对新问题创建自动化的解决方案时,过程将会更加容易。
图 2(http://msdn2.microsoft.com/zh-cn/library/Aa479861.intronet30_02(zh-cn,MSDN.10).gif )

提供通用工作流技术面临另一个困难是,面向人员工作流和面向系统工作流的传统分歧。通常来说,工作人员使用的工作流应用程序需要有较高的灵活性,能够进行实时更改。而一般由系统,也就是由软件使用的工作流应用程序则相对更加静态,但要求尽可能高效。WF 综合考虑了这两种不同的使用情况,不仅包括面向人员的功能(如更改运行中工作流的功能),同时还支持更多面向系统的操作。

通过 WF 的 Windows 通用工作流技术,.NET Framework 3.0 为广大开发人员提供了一种非常有用的软件开发模式。随着面向流程的软件继续风行,工作流技术也会随之推广。

Windows Communication Foundation:支持面向服务的应用程序
无论是通过工作流还是其他方式开发,绝大多数应用程序都需要与其他应用程序进行通信。近几年来,应用程序间的通信技术发展迅速。在长达数十年的不统一之后,主要供应商之间最终达成了一致的应用程序通信协议。根据 SOAP 这一全球 Web 服务协议,基于 J2EE、.NET Framework 等不同技术平台开发的应用程序间的互操作性相比以前大为简化。它还会使面向服务的架构这一思想为更多的组织接受。

当然,现在的通信方式已经不少了。以 .NET Framework 2.0 为例,您可以选择以下几种通信方式:

• ASP.NET Web 服务,提供基于 SOAP 的交互通信。

• .NET Remoting,主要用于 .NET 应用程序之间的通信。

• Enterprise Services,支持可扩展的事务性应用程序。

• System.Messaging,通过 Microsoft Message Queuing (MSMQ) 支持队列消息。

• Web Services Enhancements (WSE),它是 ASP.NET Web 服务的扩展,支持 WS-Security 等新规范。

这些技术都有其自身的价值,在实际应用中也有着各自的地位。可是,既然问题是一样的,为什么要采用好几种不同的解决方案呢?为什么不根据交互服务来建立一个单一的应用程序通信基础?

这正是 Windows Communication Foundation (WCF) 的设计初衷。有了 WCF,开发人员不必再像从前一样,处理每一类通信都要使用到不同的应用程序编程接口技术 - WCF (最初的代号为“Indigo”)以通用的 API 提供通用的方法。在 .NET Framework 3.0 环境下,大多数使用上述技术之一的应用程序将会代而使用 WCF。

WCF 通过 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(http://msdn2.microsoft.com/zh-cn/library/Aa479861.intronet30_03(zh-cn,MSDN.10).gif)

信息卡表示的这些标识是由一个或多个标识提供者创建而成的。组织可以有自己的标识提供者,而不必依赖于简单的用户名和密码。每个标识提供者都会采用更加强大的加密机制,让用户来验证他们的标识。CardSpace 本身也包含一个自发行的标识提供者,可以在客户端计算机上运行。使用这一提供程序,用户可以创建自己的标识,且标识也不必依赖密码进行身份验证。网站接受这些自发行 CardSpace 标识,这样就不必再依赖常见的密码方法,自然会减少因密码而带来的诸多问题。

不用密码登录网站,网页仿冒者也就无密码可偷了!但是,如果网页仿冒者成功诱使受害者访问假冒网站的话,他们还是会窃取用户的其他信息,如敏感的医疗信息等。要杜绝这种情况,就要求用户自己能够区别假冒网站和真网站。为帮助用户识别网站,拥有网站的组织应获取“高度确认认证”。与现在的 SSL 简单认证不同,新的认证方式涉及到更多、更严格的流程,其中包括采用更严格的方式来证明申请该项认证的组织的身份。高度确认认证上还可以带有公司徽标和其他信息,帮助用户准确识别使用证书的网站是否合法。用户访问新网站时,CardSpace 会始终以标准屏幕显示该网站的证书信息。根据认证的接受程度,屏幕上会自动显示出对网站标识的确认程度。其目的是,强制用户明确界定网站是否可信,然后帮助他们作出正确选择。

Windows CardSpace 实际上是更大的标识元系统的一部分。标识元系统完全基于开放的公共协议,它定义了一种全新的方式,能够使不同的数字标识技术在各个不同的平台(包括 Windows 以外的操作系统)和应用程序(包括 Internet Explorer 以外的 Web 浏览器)上使用。CardSpace 采取通用的方法来选择标识和其他 Windows 信息,因而在元系统中扮演着重要角色。并且,由于解决了基本的标识问题,CardSpace 也已经成为 .NET Framework 3.0 的重要组成部分。

Windows Presentation Foundation:适用于不同用户界面的统一方法
对几乎所有的应用程序来说,用户界面都是重要的组成部分。现在,用户对这些界面的要求越来越高了。当然,我们仍然需要传统的菜单驱动式 GUI。但是除此之外,许多应用程序还需要能够播放视频、运行动画、采用二维或三维图形,以及调用不同的文档。无论是通过安装的桌面客户端还是通过 Web 浏览器来访问应用程序,上述功能都必须可以正常使用。

一直以来,Windows 上的这些用户界面功能都是以不同方式提供的。例如,开发人员可以使用 .NET Framework 中的 Windows Forms 来创建 Windows GUI,使用 HTML、Java 小程序或 Javas cript 代码创建 Web 浏览器界面,或是使用 Windows Media Player、Adobe 的 Flash Player 等软件播放视频,文档格式则以 Microsoft Word、Adobe PDF 或其他软件进行定义。很明显,开发人员面临着巨大的挑战:如何使用不同的技术,为不同的客户端创建一致的用户界面。这相当困难。

Windows Presentation Foundation (WPF),最初代号为“Avalon”,就是为解决这一难题而设计。WPF 为所有的这些用户界面提供一致的技术基础,从而大幅简化了开发人员的工作。WPF 采用更为现代的方法,支持视频、动画、二维或三维图形以及各种类型的文档,从而可以让用户以全新的方式处理信息。此外,WPF 还为桌面客户端和浏览器客户端提供了通用基础,大大简化了二者的应用程序开发工作。

让我们以图 4 中的界面(其中包含了图像、现场图、三维视图等等)为例说明 WPF 的部分功能。过去,开发人员需要懂得各种技术才能进行工作;而现在通过这种更为一致的方法,开发人员可以轻松制作出类似示例中的用户界面。
图 4(http://msdn2.microsoft.com/zh-cn/library/Aa479861.intronet30_04(zh-cn,MSDN.10).gif)

另外一个长期困扰用户界面开发人员的问题是,如何创建高效界面需要的不同角色。软件开发人员需要编写相应的界面逻辑,但是,他们并不是定义界面感观的最佳人选。一般来说,人机交互领域的设计人员和专家更适合这一工作。但是在以前的技术(如 Windows Forms)背景下,这些问题完全由开发人员决定。开发人员和设计人员之间没有实现真正有效的协作。WPF 借助于可扩展应用程序标记语言 (XAML) 解决这一问题。XAML 是一种基于 XML 的语言,允许以声明方式指定用户界面 -而非代码。这就,开发工具就能够根据设计人员创建的可视化显示,更加容易地生成和使用界面规范。实际上,Microsoft 的一款新产品 Expression Interactive Designer 就是为此而设计。使用这一工具(其他的由第三方提供),设计人员可以创建界面外观,然后生成他们所创建界面的 XAML 定义。开发人员将这些定义导入 Visual Studio 之后,就可以着手构建界面所要求的逻辑了。

开发人员创建了直接在 Windows 上运行的安装版 WPF 应用程序后,就可以使用 WPF 提供的全部功能了。但是,若要创建在 Web 浏览器内部运行的客户端程序,开发人员应创建一个 XAML 浏览器应用程序,我们通常称之为 XBAP。与安装版 WPF 应用程序的基本原理相同,XBAP 允许在可下载的浏览器应用程序中表示与用户界面相同的样式。两种应用程序可以使用相同的代码,这也就意味着开发人员不再需要针对桌面和浏览器客户端的不同技术集。特别是按照此类丰富 Internet 应用程序的现状,在安全沙箱内运行从 Internet 下载的 XBAP,将会限制应用程序的功能。但是,安装版 WPF 应用程序中提供的大量用户界面功能子集也可用于 XBAP。

WPF 安装版应用程序和 XBAP 都可以利用 WPF 的现代图形支持,其中包括使用硬件加速、支持矢量图形以及其他更多功能。通过提供更强大的图形支持功能,WPF 使得一系列数据可视化选项成为可能,而这依靠 Windows Forms 或其他的早期技术是不可能实现的。WPF 还提供了 XML Paper Specification (XPS) 的基础,可定义查看、分发和打印固定格式文档的标准格式。

用户界面是现代应用程序中复杂而重要的组成部分。通过 WPF,.NET Framework 3.0 提供了一种比较完整和一致的解决方案,用于应对用户界面方面的难题。其目标是使构建用户界面的相关人员(包括开发人员和设计人员)能够更有效的进行工作。

应用 .NET Framework 3.0:设想理解一组技术如何协同工作的最好方式,就是查看其使用方式的示例。现在假设,一款应用程序要求客户和代理提交保单。如果使用 .NET Framework 3.0 执行,则会有图 5 所示的工作流程。
图 5(http://msdn2.microsoft.com/zh-cn/library/Aa479861.intronet30_05(zh-cn,MSDN.10).gif)

图表左上角所显示的应用程序业务逻辑,是使用 WF 工作流得以实现的。处理保单是一项多步骤流程,包括根据组织的保险规则来评估此保单,或许要检查投保人的信用,甚至还要获得其上司的批准。工作流依靠所需要的其他软件,以活动方式实现流程中的每一个步骤。如果要访问存储数据,工作流中的活动可以使用 ADO.NET。

保险公司可以提供一个呼叫中心,使客户可以通过电话进行投保。呼叫中心员工使用的客户端软件显示在图表的右上角,是由安装版 WPF 应用程序实现的。客户端使用 WCF 与应用程序业务逻辑进行通信,采用的是经过 WCF-WCF 通信优化的二进制协议。如图所示,呼叫中心工作人员依靠 Windows CardSpace 来选择他们在登录该应用程序时将要使用的标识。

客户还可以通过网络进行投保,而保险代理商也可以通过网络提交保单。为便于网络操作,该应用程序使用 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 3.0 的五个部分提供了一个简明教程。有关各部分的更详细介绍,请参阅本文末尾的“更多参考资料”。

.NET Framework 2.0
图 6(http://msdn2.microsoft.com/zh-cn/library/Aa479861.intronet30_06(zh-cn,MSDN.10).gif)

.NET Framework 2.0 是目前 Windows 开发的基础,同时也是 .NET Framework 3.0 的基础。图 6 介绍了 Framework 的两个组成部分:公共语言运行库 (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 Forms 来创建本机 Windows GUI,但与 ASP.NET Web Services、.NET Remoting 或 Enterprise Services 相比,他们通常更喜欢 WCF。尽管存在这些变化,但也应该了解即使在 .NET Framework 3.0 世界中,早期版本的 Framework 仍然是开发人员所使用的核心部分,这一点非常重要。

Windows Workflow Foundation
由工作流驱动的、面向流程的设计,是 Windows 软件重要部分的正确开发方式。WF 的目的是让开发人员创建并执行这些基于工作流的应用程序。图 7 显示 WF 提供的用于进行该项工作的组件。
图 7(http://msdn2.microsoft.com/zh-cn/library/Aa479861.intronet30_07(zh-cn,MSDN.10).gif)

如前文所述,每个工作流都通过一定数量的活动创建。工作流和活动都属于类,所以两者均可由代码直接创建。WF 也提供了工作流设计器,这是一个用于构建工作流的 Visual Studio 托管图形工具。但是创建工作流后,其活动就可以从 WF 附带的基本活动程序库 (BAL) 或其他任何来源得到。

一旦定义了一个工作流,最终就会由 WF 运行时引擎来执行。该引擎所依赖的是一组运行时服务,用于保持工作流状态、跟踪工作流执行等。运行时服务、运行时引擎和工作流本身,所有这些都包含在某个主机进程中。该进程可以是任何 Windows 进程,从正在桌面上运行的简单的控制台或 WPF 应用程序,到可扩展的服务器进程。

要了解 WF,需要至少具有一点其组件的知识。以下部分将对各组件进行简述。

工作流
从本质上说,工作流就是一组活动。WF 对两种样式的工作流提供内置支持:

可以按定义的顺序执行活动的顺序工作流。类似于传统的流程图,顺序工作流中包含分支、循环和其他控制结构。但默认情况下,活动会按顺序依次执行。

可以实现传统有限状态机的状态机工作流。类似于任何的状态机,特定时间所执行的活动由当前状态和已收到的事件共同决定。

顺序选项可用于定义明确的工作流,例如完全基于软件的进程中的工作流。创建并理解这些工作流相对简单,而且一开始就让大多数开发人员觉得非常容易。当执行路径不太容易预测时,可以选择状态机工作流。一个典型的例子就是涉及与人进行交互的工作流,任何人在任何地方都可以取消该工作流。通过顺序工作流可应对该状况,但每个步骤都会成为一个分支:若工作流未取消,则应该执行;若已取消,则应该执行其他活动。使用状态机对这种行为建模会简单许多,因为取消工作流的请求恰恰是另一个可以在任何时间接收并处理的事件。

对状态机工作流的支持,是 WF 如何尝试为人和系统工作流提供支持的一个例子。另一个相关的例子是,WF 对更改正在运行的工作流的支持。人的要求千变万化,某个工作流的相关人员,在进程运行当中添加步骤、删除步骤或进行其他更改的行为并不罕见。为了以受控方式适应这种状况,WF 允许创建工作流的开发人员在执行工作流时指明是否要修改以及如何修改。

基本活动程序库
开发人员可以随意创建自定义活动。事实上,Microsoft 的目标是促进满含可重用活动的 WF 生态系统的开发。而且,从一个普通的基本活动集着手会让每个人都觉得更加容易。基本活动程序库 (BAL) 的作用就是提供这个普通集。

无论使用 BAL 中的哪些活动,工作流都不是必需的。而且,许多开发人员会发现 BAL 使他们的工作变得更简单,尤其是在开始的时候。BAL 中包含的活动如下:

• IfElse:根据是否满足某个条件,执行两个或更多可能路径中包含的活动。

• While:只要某个条件为真,就反复执行一个或多个活动。

• Sequence:以定义的顺序,一次执行一组活动。

• Parallel:并行执行两组或多组活动。

• Code:执行定义的代码块。

• Listen:等待一个特定事件,收到后再执行一个或多个活动。

• InvokeWebService:调用一个 Web 服务。

• state:表示工作流状态机中的一个状态。

• EventDriven:定义包含一个或多个活动的转换,该转换需处于特殊状态,并在收到特定事件后执行。

• Policy:允许使用 WF 提供的规则引擎定义并执行业务规则。

WF 采用了较一般的方式来使用活动,而并非为指定的工作流定义特定语言。BAL 提供了一种“语言”,但任何人都可以使用 WF 随意定义自己的语言。

Windows Workflow Foundation 工具:工作流设计器
使用工作流创建应用程序的一个优势是可以图形化地定义工作流。WF 的工作流设计器允许使用该功能,如图 8 所示。默认情况下,开发人员可将工具框中出现的 BAL 活动拖放到该工具的设计界面上,以创建工作流。
图 8(http://msdn2.microsoft.com/zh-cn/library/Aa479861.intronet30_08(zh-cn,MSDN.10).gif)

一些开发人员不喜欢图形设计器,他们更愿意编写代码。WF 也允许使用这种方法(并且有时需要该方法:一般是直接从代码构建的活动)。也可以将这两种方法结合使用,如同时使用工作流设计器和直接编码的方法创建工作流。其目的是让开发人员使用最有效率的方法。并且为实现更广泛的工具支持,也可以通过 XAML 语言表达工作流,这也是 WPF 所使用的语言。事实上,使用工作流设计器创建的工作流默认为是 XAML 定义的。

运行时引擎和运行时服务
如前文所述,WF 运行时引擎具有执行工作流中的活动的职责。作为执行该职责的一个部分,它依赖于一组运行时服务。WF 包含这些服务的标准实现,但是有能力的开发人员可以根据需要更换。这些服务支持几种不同的功能,其中有两种最值得注意:

• 持久性:因等待某个事件受到阻塞的工作流,可以使用该服务将其内存状态自动保存到磁盘。当事件发生时,该服务会自动重新加载工作流的状态并重新开始执行。这对于涉及到人员的工作流尤其有用,因为等待一个响应可能需要几个小时、几天或更长时间。

• 跟踪:工作流中的活动清楚地区分了其实现进程的执行。WF 的跟踪服务允许开发人员将工作流的执行信息自动写入数据库中。例如,开发人员希望跟踪工作流的起始时间、它的每个活动的起始时间和其他信息。

Windows Workflow Foundation 和其他 Microsoft 技术
引入新方法肯定会影响现有方法。.NET Framework 3.0 中的新技术也不例外,每项技术都会对 Microsoft 的其他技术产生影响。当使用 WF 时,对 Windows SharePoint Services、Microsoft Office 2007 系统和 BizTalk Server 的初始影响最大。

为了使开发人员更容易地创建文档合作和其他种类信息共享的工作流应用程序,3 版 的 Windows SharePoint Services 托管了 WF 运行时。Office SharePoint Server 2007 是 Office 2007 系统的组成部分,基于 WF 支持,构建于 Windows SharePoint Services 中。此外,添加该服务器后,就可以直接在 Office 2007 客户端应用程序中显示 InfoPath 窗体,而且可以在一些普通方案(如批准一个文档)中使用一组预定义的工作流。

任何熟悉 BizTalk Server 的人现在一定已经注意到了该产品的编排功能和 WF 提供功能之间的相似性。事实上,BizTalk Server 2006 发布后,将通过 WF 替换该产品现有的编排功能,并提供可帮助将现有编排服务迁移到 WF 工作流的工具。但有一点很重要,即应了解 WF 和 BizTalk Server 2006 解决的问题是截然不同的:

• WF 提供了一个通用框架,用于创建基于工作流的 Windows 应用程序。它可以被托管在任何进程中,使用任何种类的活动,并解决任何种类的业务问题,其中包括人员和系统工作流。

• BizTalk Server 是面向企业应用程序集成、企业对企业集成和管理业务流程的许可产品。它提供了大量用于连接不同系统和软件的适配器、用于实现诸如 RosettaNet 和 SWIFT 等标准的加速器以及对企业活动监控的支持。BizTalk Server 还提供了管理基础结构和工具,以及对增长的可扩展性的支持。

因为它是 Windows 标准的工作流技术,因此 WF 以后很可能会出现在其他 Microsoft 产品和技术中。无论 Microsoft 做出什么样的选择,在客户创建的大量应用程序中都肯定会出现 WF 的身影。

Windows Communication Foundation
面向服务的通信的变化,标志着在应用程序交互方式上的进步。WCF 专为支持面向服务的应用程序而设计,正好体现了这种进步。本节将介绍 WCF 最重要的方面,包括服务和客户端、通信选项以及对安全性、可靠通信和事务的支持。

服务和客户端
图 9(http://msdn2.microsoft.com/zh-cn/library/Aa479861.intronet30_09(zh-cn,MSDN.10).gif)

如图 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(http://msdn2.microsoft.com/zh-cn/library/Aa479861.intronet30_10(zh-cn,MSDN.10).gif)

如图所示,每个端点都具有以下三个属性:

• 合约,说明使用该端点可以调用的操作。该合约只需使用定义这些操作的接口名即可识别,此处是 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,在某些情况下完全可以胜任,当使用 BasicHttpBinding 时会用到该方法。但在大多数情况下,这种广泛使用的方法显得力不从心。例如,经由一个或多个 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 Services、.NET Remoting、Enterprise Services、System.Messaging 或 WSE 构建的应用程序,将转而通过 WCF 进行构建。WCF 应用程序可以与 ASP.NET Web Services 应用程序交互,两者都支持标准 SOAP,也可与其他构建在 Enterprise Services、MSMQ 和 3.0 版的 WSE 上的应用程序交互。BizTalk Server 2006 也可以使用 WCF,而且未来版本的 BizTalk Server 会更直接地构建在 WCF 提供的架构上。

有一点非常重要,即使新的 .NET Framework 3.0 应用程序不常使用 WCF,但其取代的所有技术仍是该版 Framework 的组成部分,而且仍被照常支持。使用这些技术的早期版本构建的应用程序,还会继续正常运行;安装和使用 .NET Framework 3.0 不会破坏现有代码。

Windows CardSpace
无论是通过 Web 浏览器还是其他种类的客户端,用户通常会跨网络访问应用程序。这些应用程序通常需要用户以某种方式标识自己,因此结果肯定是人们必须定期获取并提供远程软件的标识信息。通过浏览器访问 Internet 应用程序,就是一个很常见的示例,内联网上的用户通常也会面临该问题。

如前文所述,现在多数人经常依赖用户名和密码进行数字识别,由此产生了诸多问题。Windows CardSpace 作为较大的标识元系统的组成部分,提供了解决这些问题的可选方法。若要更深入地了解 CardSpace 是如何实现的,应从了解标识元系统的基本概念入手。

Windows CardSpace 和标识元系统
当用户访问应用程序时,无论所使用的是 Web 浏览器还是应用程序特定的客户端,或者其他形式,一般都会提供某种数字标识。数字标识各种各样,但实际上都可由网路上的一个安全令牌表示。简单的安全令牌可能只是一个用户名,复杂的令牌则可能包含一个 X.509 证书或一个 XML 文档。无论通过何种方式,安全令牌都是目前网络上表示数字标识的典型机制。

我们可以美好地憧憬,总有一天所有人都会采用相同的安全令牌格式,但实际上各种方式仍将继续使用。现在我们会在钱包中携带各种标识卡,如驾驶执照、信用卡、航空公司常飞旅客积分卡等,与此类似,我们会始终使用由各种安全令牌表示的数字标识。没有单个标识系统可以提供通用的方案,所以多个安全令牌将始终是必需的。

然而,用户仍需要某种方式来一致地处理不同的数字标识。即使没有单个标识系统可以胜任,也可以创建一个标识系统的子系统,即标识元系统,从而以一致的方式使用各种数字标识。Microsoft 与其他公司通力协作,引领着定义该元系统的进程。该元系统基于开放的 Web 服务技术,如 WS-Security 和 WS-Trust 等,可定义数字标识的获取与使用方式,而无需考虑其所依赖的安全令牌类型。

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

• 用户:有时称为主体,用户是具有数字标识的实体。

• 标识提供者:标识提供者可以为用户提供数字标识。例如,对雇主分配给您的数字标识而言,标识提供者一般是诸如 Active Directory 的系统。对于您使用的 Amazon 数字标识而言,标识提供者将只对您有效,因为您可以定义自己的用户名和密码。不同标识提供者所创建的数字标识可以包含不同的信息,并提供不同的用户真实身份保证级别。

• 依赖方:依赖方是一个应用程序,以某种方式依赖于数字标识。依赖方将频繁使用标识(即该标识安全令牌中包含的信息)来验证用户,然后作出授权决定,如批准该用户访问某信息等。依赖方也会使用该标识获得信用卡号,来验证不同时间或出于不同目的而进行访问的同一用户。依赖方的典型示例包括 Internet 网站,如银行、网上商店和拍卖站点,以及其他通过 Web 服务接受请求的所有应用程序。

这三种实体在标识元系统中进行交互。图 11 说明了这种交互作用,以及 CardSpace 的适当位置。
图 11(http://msdn2.microsoft.com/zh-cn/library/Aa479861.intronet30_11(zh-cn,MSDN.10).gif)

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

一旦 CardSpace 了解到依赖方需要的安全令牌类型后,会显示之前所示的标识屏幕。对该用户可用的每个数字标识在此屏幕上表示为一个信息卡。由外部依赖方发行的卡称之为受管卡,而由 CardSpace 自发行提供程序发行的卡称之为自发行卡。两种卡都在此屏幕上显示,用户可以任选其一。为了更加方便做出选择,屏幕会将所有不符合要求的信息卡显示为灰色,从而指示出能够满足依赖方要求的标识。然后,用户就可以从中任意选择一个作为要使用的数字标识(步骤 2)。

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

请求的安全令牌返回后会发送到依赖方(步骤 4)。依赖方使用令牌信息的方式有所不同。例如,如果令牌中包含一个 X.509 证书,并附带数字签名,则依赖方将有可能使用令牌来验证用户。但是,使用令牌验证或进行其他任何安全相关目的操作时没有任何要求。(实际上,术语“安全令牌”本身就是用词不当。)令牌中可以含有如用户年龄证明、购物网站享受优惠资格以及其他信息。身份验证是安全令牌一种重要但非唯一的使用目的。

需要十分注意的是,作为整体来讲,无论是 CardSpace 还是标识元系统都不了解用于安全令牌的格式或技术。元系统的目标是提供一致的方法来使用基于任何类型安全令牌的所有数字标识,而不仅仅是尝试为数字标识创建新的单一源或为安全令牌创建标准格式。通过提供元系统关键部分的 Windows 实现,CardSpace 在实现数字标识的常规方法过程中扮演着一个很重要的角色。

防止网页仿冒
标识提供者通常与用户不同,例如在标识由雇主分配时。但是在很多情况下,标识提供者即为用户自身。例如,如果没有使用 CardSpace,则访问许多网站都需要提供用户名和密码,而这两者都是由用户定义的。一旦用户创建标识之后,他们就可以将其用于提供用名和密码,然后可以查询银行余额、购买书籍或进行站点允许的其他任何操作。

但是如上所述,由于他们仍然依赖密码,所以这种自发行标识容易成为攻击者的目标,。为帮助减少此类攻击,CardSpace 提供了另外一种创建自发行标识的方法。该自发行标识提供者在用户的 Windows 系统上本地运行。自发行标识提供者创建的安全令牌不是依赖于用户名和密码,而是使用安全声明标记语言(SAML,一种 OASIS 定义的标准)进行定义。这些令牌依靠公钥技术而不是依靠密码来验证用户标识。如果依赖方接受他们,则他们就可以起到与传统用户名和密码相同的作用。好处是将不再存在网页仿冒者可以盗取的密码。减少密码的使用,再有如上所述高度保险认证提供更严格的网站标识证明,能够大幅降低网页仿冒所造成的危害。

Windows CardSpace 和其他 Microsoft 技术
CardSpace 涉及到数项其他 Microsoft 技术,其中包括:

• WCF:由于依赖 Web 服务标准,例如 WS-Security 和 WS-Trust,因此 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 Federation Services (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>

该示例创建了一个包含文本“No”的红色按钮。使用如下代码也可以达到完全相同的效果:

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

无论如何定义,实际上所有 WPF 应用程序都遵循相同的基本模型。应用程序可继承 WPF 的标准应用程序对象,以提供基本方法、事件和属性。WPF 应用程序既可以拥有传统的对话框驱动界面,也可以拥有导航式界面,其功能更类似于一个浏览器应用程序。以后者样式构建的应用程序通常作为一组页面实现,每个页面中包含以 XAML 定义的用户界面和以代码定义的某些逻辑关系。为了将这些页面链接在一起,XAML 还提供了一个与 HTML 十分类似的超链接元素。应用程序每次显示一个页面,可使用户在这些页面之间前进或后退、维护历史记录列表以及其他功能等。尽管不需要,导航应用程序还是可以作为 XBAP 在 Web 浏览器内运行;开发人员也可以在安装版 WPF 应用程序中自由使用该界面样式。其目的是构建出融合浏览器界面与本地 Windows 界面最佳特点的软件。

无论其界面使用哪种样式,WPF 应用程序都可以通过面板进行基本布局。每个面板通常包含多个控件,这些由 WPF 提供的控件包括按钮、文本框、组合框、菜单以及其他对象。这些控件如何放置取决于所选择的面板类型。例如,Grid 允许将控件放在指定的网格上,而 Canvas 则允许开发人员将控件放在其界限范围内的任何位置。在 GUI 中,通常用户生成的事件由应用程序中的不同控件和其他类进行捕获和处理。还可以将样式和模板应用到控件组,这样就可以非常容易使应用程序具有一致的外观。

免责声明：本站文字信息和图片素材来源于互联网，仅用于学习参考，如内容侵权与违规，请联系我们进行删除，我们将在三个工作日内处理。联系邮箱：chuangshanghai#qq.com（把#换成@）