Michael Herman
EC3 Enterprise Consulting Competency Centers
Microsoft Corporation
2000年10月
摘要:本文探讨 Microsoft .NET 平台,并着重介绍如何使用 .NET 平台、Exchange 2000 Server 和 Microsoft Web 存储系统构建、设计和建立合作 Web 服务。
目录
Microsoft 正致力于开发新一代的软件,即通过革新性的新方法(向开发人员和最终用户提供所需工具,对 Web 和计算过程中的其它各个方面加以改进),将 Web 计算和通信融为一体。我们将此技术称为 Microsoft .NET。
通过 Microsoft .NET 将可以创建真正的分布式 Web 服务,它将集成免费提供的各种服务并与这些服务协同工作,使当今客户的梦想成真。Microsoft .NET 蕴含的基本理念就是将注意力从单独的 Web 站点和与 Internet 相连的各种设备,转移到由各种计算机、设备和服务协同工作的架构之上,从而提供涉及面更广、功能更全面的解决方案。人们将可以控制向这些计算机、设备和服务提供信息的方式和时间,以及提供哪些信息。计算机、设备和服务将能够彼此协同工作,而不再是相互隔绝,只能通过 Web 冲浪协同工作。公司提供其产品和服务的方式将可以令用户和供应商将这些产品和服务无缝地嵌入在其自身的业务进程和日常活动的电子架构之中。
在 Microsoft .NET 平台中具有 5 个组件:
在 .NET Enterprise Server 系列中,Exchange 2000 Server 是可靠的、易于管理的消息传送和合作解决方案,可以将用户和各方面的知识和信息结合在一起。
本文将讲解 Microsoft .NET 平台,并着重介绍如何使用 .NET 平台、Exchange 2000 Server 和 Microsoft Web 存储系统构建、设计和建立合作 Web 服务。同时还对 Microsoft .NET 分布式 Web 结构以及 Microsoft Web 存储系统的主要开发功能加以说明。
此外,我们将介绍 Web 存储系统和 .NET Framework 是如何协同工作,从而构建高价值的合作 Web 服务的。我们将以一个旅行社的日程安排为例,阐述作为一个 Web 设计人员和开发人员,需要考虑的各种实际的基础结构和设计因素。最后,我们将先睹 Exchange 2000 Server 开发小组计划在 Microsoft Web 存储系统的下几个发行版中提供的新增 .NET 功能。
XML
Microsoft .NET 将有助于促进 Internet 上的变革,人们将看到通过采用可编程的基于 XML 的信息,基于 HTML 的显示效果得到极大改善。XML 是由“万维网联盟”(World Wide Web Consortium) 定义的得到广泛支持的行业标准,而正是该组织创建了 Web 浏览器的标准。XML 提供将实际数据与该数据的演示视图区分开来的方法。这种方法将数据分发给各种数字设备,从而允许 Web 站点通过其选择采用的基于 XML 的 Web 服务协同操作。
作为在 XML 和 Internet 协议的标准集成结构基础上建立的平台,Microsoft .NET 平台是开发先进的新一代软件的革新性方法。显然,Microsoft .NET 的设计理念即在于允许在合作解决方案架构内集成或协调 Internet 上的任意资源组。当前,此类集成极为复杂并且成本很高。Microsoft .NET 将使这些类型的合作 Web 解决方案的设计、实施和部署更快捷、更简单。
Web 服务
松散组合的、基于 XML 的 Microsoft .NET 平台引入了基于 XML 的 Web 服务的概念。鉴于当今的 Web 站点还是采用人工维护的方式,并且不进行大量的额外开发就无法与其它站点协同工作,Microsoft .NET 平台提供固有的机制,使任何 Web 站点或服务能够与其它站点无缝地协同工作。
Web 服务最简单的定义是,一种可通过标准 Web 协议访问的可编程的应用组件。
将向 Internet 提供四种 Web 服务:
公用 Web 服务将在 Internet 上出现,并且可以很容易并全面地集成到新的和已有的 Web 解决方案中。某些服务将免费提供,而其它一些服务将需要不同商业模型的支持。需要商业模型支持的 Web 服务称作商用 Building Block Web 服务,并且将由应用服务提供商 (ASP) 以及 Microsoft 提供。Passport 是 Microsoft 的第一个 Building Block 服务,提供单一签入功能(允许用户在多个 Web 站点上使用单一的名称和密码)。以后的 Passport Building Block 服务将包括电子钱包和公用个人信息服务。请访问 Microsoft Passport Web 站点(英文),以了解详细信息。
通过 .NET 平台,开发人员还可以在自己的合作解决方案中充分利用由 Microsoft 和其它软件公司提供的准备好的、可立即投入使用的 Web 服务。
自定义开发的 Web 服务包括由公司开发人员和解决方案合作伙伴开发的、供公司内部使用的 Web 服务。
开发人员将能够在自己的应用程序和服务中充分利用并自定义各种 Microsoft .NET Building Block 服务,从而减少创建具有竞争力的解决方案所需的工作量。这些核心 Microsoft .NET Building Block 服务与 Microsoft 深入研究的各方面的功能相对应,各种开发人员均可以从中获益。Microsoft 正致力于统一这些开发人员构件,以便提供高度分散、可编程的服务,这些服务可以在独立的机器上、公司数据中心中和 Internet 上执行。
通过选择预订这些现成的核心 .NET Building Block 服务,对于想要利用开发资源的开发人员而言,他们可以决定“是购买还是创建”。某些人可能选择自己创建基本的服务功能,而某些人可能更倾向于选择具有强大开发工具支持的良好的打包解决方案,这就象许多开发人员不自己编写打印机驱动程序或窗口系统,而将主要资源投入到其独具特色的高价值解决方案上一样。
Web 服务具有以下特点:
通过 Microsoft .NET 平台创建的分布式 Web 服务既可以联机使用,也可以脱机使用。服务可以在未与 Internet 相连的独立机器上调用,可以由在公司内运行的本地服务器提供,也可以通过 Internet 访问。不同的服务可以通过称作联合的进程协同工作并交换信息,使组织能够在不影响其对服务的控制和访问的前提下,决定是运行其自己的基础结构,还是从外部引入。例如,公司目录服务能够与 Internet 上运行的其它目录 Web 服务联合使用。
Microsoft .NET Building Block 服务可以在支持 XML 的任何平台上使用。Windows、Exchange 2000 Server、Microsoft Web 存储系统和 Visual Studio® 将提供最佳的环境,以便创建和提供合作 Web 解决方案。
Web 用户体验
尽管 Web 服务使开发人员可以很容易地展示某个应用程序的功能,以便其它服务器和客户机的应用程序能够与其相连,但许多应用程序需要通过 Web 用户界面 (UI) 向 Internet 和 Intranet 用户展示此功能的全部或部分。
此外,通过 Microsoft .NET,可以使在 PC 和设备上运行的解决方案能够与包罗万象的 Internet 上的信息和功能紧密结合使用,包括能够联机和脱机工作,并且在使用本地或远程应用程序和服务之间可以透明转换。
Microsoft .NET 将从三个方面影响 Web 用户体验:
从用户界面角度而言,Microsoft .NET 将向用户和开发人员提供以下用户界面技术:
为支持 Web UI 在任何类型的设备(包括最新的 Internet Explorer 和与 HTML 3.2 兼容的浏览器)上透明显示,.NET 平台引入了 ASP+,即下一代 Microsoft 的 Active Server Page 页 (ASP) 技术。对于 Web 设计人员和开发人员,在充分利用现有开发 ASP 应用经验的同时,设计和开发 Web UI 将更为容易。对于 Web 主管,部署和管理 Web 应用程序和服务将更为容易,并且可扩展性、安全性和可靠性均得以提高。
这里使用的主要技术是 ASP+ 服务器控件,新的 Visual Studio .NET 设计器完全支持该技术。开发模型与当今 Visual Basic 开发人员所使用的常用模型完全相同:从工具箱中选择一个控件,在 Web 窗体上绘制它,在其上双击以添加代码来响应用户事件,然后编译您的项目。窗体和代码被自动编译并部署到您的开发 Web 服务器,在该服务器中,ASP+ 服务器控件自动检测用户的浏览器类型,并生成与浏览器类型兼容的纯 DHTML 或 HTML 3.2。将随 Visual Studio .NET 一起提供几种可扩展和可修改的 ASP+ 服务器控件。这些控件类型包括固有的控件(对应于相应的 HTML 控件)、数据感知列表控件、功能丰富的日历和广告轮播器控件、窗体和字段验证控件。
通过将 .NET 平台的 Web 服务与各项 Web UI 功能相结合,能够显著改变我们在 Internet 工作和游戏的方式。例如,在计划外出旅行时,通常要收集以下几方面的信息:偏爱的旅行时间、旅行目的地、特殊的饮食注意事项、是否吸烟、偏爱的租车代理机构、偏爱的飞机座位、常客奖励帐号、偏爱的旅馆、付款信息等。一个旅行社也许已经掌握了上述某些或全部信息,但是这些信息都是最新的信息吗?或者您申请了多家旅行社怎么办?
何必每次都要收集上述这些信息呢?不如简单地在 Outlook® 日历中进行外出旅行预订,让 Exchange 服务器上运行的信息代理与在旅行社的 Web 站点上运行的 Web 服务自动联系。对 Web 服务的调用应包括偏爱的旅行时间和目的地信息。如果旅行社需要与您的旅行偏爱有关的其它信息,为什么旅行社不简单地回调由您的 Exchange 服务器提供的 Web 服务,让 Web 服务自动提供您已经授权与该旅行社共享的信息呢?
一旦旅行社最终设定好您的度假计划,将再次与您的 Exchange 服务器上的 Web 服务联系,以更新最初的日历约会信息。该约会可以自动与您的 Pocket PC 中的日历保持同步,也可通过无线 Pocket PC 设备立即获得这些信息。您可以随时随地获取有关度假的详细信息。
这就是由 Microsoft .NET、Exchange 2000 Server、Web 存储系统和 Visual Studio 实现的全新的合作 Web 服务。本文在旅行社合作日程安排示例中阐述了合作性的日程安排。
为 .NET 平台创建的应用程序和 Web 服务的主要特性包括:
对于设计人员和开发人员而言,还可以快速开发和部署 .NET 应用程序和 Web 服务,并且可以很容易地与其它 Web 服务和现有应用程序集成。
图 1. Microsoft .NET 平台
Windows 操作系统服务
Microsoft .NET 平台是建立在 Windows 2000 Server 系列的可伸缩性、可靠性、安全性和可管理性基础之上的。对于基于 Windows 的 .NET 服务器,Windows 2000 Server 提供高性能的操作系统服务,这些服务包括:
Windows 2000 Professional、Windows NT® Workstation 和 Windows 的普通用户版(Windows 98 和 Windows Me)将继续附带 Internet Explorer,以提供最丰富多彩的 Web 用户体验和 XML 支持。此外,Windows CE 将提供在中小型设备上运行的移动应用程序所需的各种操作系统功能,以支持联机、脱机和无线解决方案。
.NET Orchestration
BizTalk Server 2000 是一种新的 .NET Enterprise Server,提供各种设计工具和运行时环境,以对任意业务进程组和组织内以及各组织间的 Web 服务进行协调。.NET Orchestration 是 .NET Framework 的第二个组件,用于集成 Web 存储系统工作流并将其扩展到可伸缩的合作工作流解决方案结构中。
.NET Orchestration 解决了最为常见的商业问题之一,即如何才能快速推进业务进程并将其与客户和业务合作伙伴结合起来,同时解决由这些进程导致的技术问题,因为这些进程分布在运行于多个硬件平台(运行在多个客户、合作伙伴和服务提供商位置上)的多个软件系统上。
用于解决这些问题的 .NET Orchestration 方案就是将进程定义与其基本实现部分分离。业务进程专家创建并管理业务进程的发展,而开发人员则将主要精力集中在实现支持业务进程的发展所需的基础服务之上。.NET Orchestration 可视化设计器(包括在 BizTalk Server 中)提供进程设计和与外部 Web 服务及消息传送系统集成之间的协调点。
使用 .NET Orchestration 的一种方法是将单独的 Web 存储系统工作流集成到更大的合作工作流解决方案结构之中并对其进行扩展。
.NET Enterprise Server
.NET Enterprise Server 是 Microsoft 的全面服务器系列中的一种,使您可以快速地建立并管理集成的、具有 Web 功能的企业系统。通过在设计中强调可伸缩性以及以任务为中心的性能,.NET Enterprise Servers 使用最新的 Internet Web 和数据标准从头创建,以便实现互操作性。
.NET Enterprise Server 的七大核心包括:
Exchange 2000 Server
在 .NET Enterprise Server 系列中,Exchange 2000 Server 是一种可靠的、容易管理的消息传送和合作解决方案,可以将用户和各方面的知识信息结合在一起。Exchange 2000 Conferencing Server 提供实时聊天、数据、音频、视频和应用程序共享,使用起来就象通过 Outlook 预订会议一样方便。
Exchange 2000 Server 发行版中的一个主要革新就是其分布式 Web 逻辑结构。实际上,根据扩展用户连接数量、中间层处理能力或后端处理需要以及存储要求,能够在自己的实际服务器上运行的前端服务与后端 Exchange 服务和 Web 存储系统区分离。
图 2. Exchange 2000 Server 分布式 Web 体系结构
前端协议服务采用大量 Internet 协议以支持客户机应用程序以及服务器到服务器的通信。客户机协议服务包括 HTML/HTTP、POP3、IMAP4、NNTP 和 WebDAV(基于 HTTP 的 XML)、FrontPage 和 Office Server Extensions 协议、H.323 音频/视频会议和 T.120 数据会议传送。服务器到服务器(和服务器到 Internet)协议服务包括 SMTP、NNTP 和 X.400。
此外,前端协议服务支持 Outlook Web Access for Exchange 2000 Server (OWA 2000),它可以将 Outlook 2000 功能作为基于 HTML/HTTP Web 组件的 Web UI 提供,因此用于 Internet 信息查询、漫游用户和家庭访问等情况十分理想。OWA 2000 可以用作完备的电子邮件客户程序,可以访问电子邮件、日历约会和联系人,另外还可以访问个人和公用文件夹中存储的所有信息。此外,开发人员还可以使用 OWA 2000 Web UI 的每一组件在自己的合作 Web 解决方案中自动提供功能全面的日历、联系人列表、电子邮件和主题讨论。
Exchange 服务实施核心消息传送和协作服务,包括对前端协议服务层、系统管理和服务器到服务器复制的支持。
Web 存储系统采用安全层次结构文件夹模型,用于存储任何类型的无特定结构或半结构化的内容(电子邮件、文档、文件、可执行文件等),并且通过大量的 API、Internet 协议、一个支持同步和异步处理的事件模型以及一个工作流引擎,增加对访问和更新这些内容的支持。后者使 Web 存储系统能够成为可令业务进程自动化的、功能强大的合作 Web 平台。
ADO 2.5 是战略性的 Web 存储系统对象模型,用于访问与文件夹以及文件夹中所包含项目有关的信息,以及单个项目自身的信息。ADO 2.5 随 Windows 2000 附带,使用新的 Web 存储系统 OLE DB 提供程序。其最主要的优点是用唯一的、易于辨识的 URL 标识 Web 存储系统中的每一项目。此外,ADO 2.5 是可用于 Web 存储系统中文件夹和项目的层次结构遍历的对象模型。
一个新的 ADO 2.5 对象(即 ADO 记录)用于检索单个文件夹或项目的属性,并创建新文件夹和项目。新的流对象提供对一个项目的附件(例如 Office 和 XML 文档)以及音频和视频流的有效访问。传统的 ADO 记录集用于检索与项目集合有关的信息。
新的 Web 存储系统合作数据对象 (CDO) 库系列是建立在 ADO 和 OLE DB 的基础之上的,提供对 Web 存储系统和 Exchange 2000 Server 中的项目和管理功能的更高级别的、面向对象的访问。(假如 Web 存储系统 CDO 是在 ADO 和 OLE DB 的基础上实现的,进一步强调 ADO 在跨 Microsoft 平台进行数据访问时所起的重要作用)。
为了与现有的电子邮件客户程序(包括所有版本的 Outlook 和 Outlook Web Access for Exchange Server 5.5)兼容,Web 存储系统还支持 MAPI 和 CDO 1.2 API。
为了与最简单的桌面应用程序兼容,Web 存储系统还提供可安装文件系统 (IFS) 驱动程序,使 Web 存储系统分层文件夹存储的查看方式类似 Windows 资源管理器中的分层文件系统、命令提示或者用来打开和存储文档的标准文件系统对话框。IFS 驱动程序文件夹还可以象普通文件系统文件夹一样共享,并使用传统的服务器消息块 (SMB) 网络文件共享协议访问。
此具有大量的 Web 存储系统 API 和 Internet 协议的集合将使“Tahoe”中提供的新的协作服务集得以实现,“Tahoe”是 Microsoft 的第二个基于 Web 存储系统的协作服务器产品。此外,未来的 Office 版本将附带某一版本的 Web 存储系统,它将运行在本地的客户 PC 机上,并且支持 Active Server Page 以及与在服务器上使用的基于 Web 存储系统产品的直接同步和高速缓存。
.NET Building Block 服务
Building Block Web 服务是由 Microsoft 和其它 Internet 服务提供商提供的商业 Web 服务,开发人员将能够在自己开发的应用程序和 Web 服务中充分利用这些服务。核心 Microsoft .NET Building Block Web 服务将包括:
“标识”服务是建立在前面所述的 Passport 服务的基础之上的。通知和消息传送是统一的服务,它综合了即时消息传送、电子邮件、传真、语音邮件和其它形式的通知。个性化服务控制发送通知和消息的方式和时间,以及在多个设备上应如何对信息进行协调。.NET Storage 服务就是 Internet 上的数字存储服务,相当于当前银行的保险箱服务。用户将保留密钥并控制访问。
日历是涵盖您的工作、社交和家庭日历的综合性服务,它与实时提供的数据相结合,使其它 Web 服务可以确定您的当前情况。通过目录和搜索,可以查找服务和人员。此外,开发人员和应用程序将能够使用基于架构的查询来询问与这些服务有关的问题。动态传送服务使 Microsoft、ISV、解决方案合作伙伴和其它开发商在无需用户安装和配置的情况下,能够根据要求增加更多级别的功能并提供可靠的自动升级。
通用说明、发现和集成 (UDDI) 是由 Microsoft、IBM 和 Ariba 在最近合作开发的,UDDI 是用于 Web 服务的、基于 XML 的分布式信息注册的规格和基准工具。UDDI 注册使您可以描述和发现由一个组织提供的 Web 服务。每个 UDDI 注册项目都包括与其提供的服务有关的业务和技术信息的说明。请访问 UDDI Web 站点(英文)以获得更详细信息。
.NET Framework
.NET Framework 包括开发人员将对其进行编程的 5 种基本组件:
图 3. .NET Framework:应用程序提供 Web 服务和 Web UI
公共语言运行时
公共语言运行时 (CLR) 的设计目标是:
公共语言运行时允许所有的编程语言获得同样的功能,并且同样积极参与 .NET 开发环境。这意味着在 .NET Framework 上不仅可以运行 C++®、Visual Basic、C#™ 和 JScript® 等功能强大的 Microsoft .NET 语言,而且 Microsoft 合作伙伴还可以在 .NET Framework 上运行 20 多种其它语言。
此开发工作要借助于两个关键的功能。首先,将所有语言编译成一种中间语言 (IL)。与伪代码或 Java 字节代码的概念类似,所有语言实际上编译成一种元语言。然后,CLR 可以随时编译 IL(或提前编译),以便在任何环境和任何 CPU 上运行。此外,支持 CLR 的所有语言执行工具将自动继承 Visual Studio .NET 的所有功能,包括撰写、调试、编译、对象模型和新的服务器资源管理器功能等各项功能,还对自身的运行时间、.NET 基类库和第三方调试程序、横向全面调节器、代码有效区域分析器和文档工具等进行了改进。
此外,CLR 避免了许多不必要的工作,例如组件注册、GUID、IDL 文件、HRESULT、 IUnknown、AddRef/Release 和 CoCreateInstance。所有 CLR 语言都是面向对象的语言,并且完全支持对各种语言的继承,包括对以前视作非 OO 语言(例如 Visual Basic 和 COBOL)的继承。这包括从用第二种或第三种 CLR 语言编写的超类中派生用一种语言编写的类。最后,所有 .NET 对象都是通过新的多代标记并压缩无用信息收集程序来自动收集无用信息的。
基类
为了替换在典型桌面计算机或服务器上存在的各种类库和应用程序框架,已经开发了 .NET 基类,用来为所有 .NET CLR 语言提供单一的、公用的运行时类集合,并且充分利用 CLR 和 .NET 平台的各种功能。
顶级基类层次结构包括:
数据和 XML
.NET Framework 的数据和 XML 组件涉及在新的和现有组件、Web 服务和应用程序之间传输信息的方式。
ADO+ 是关键的 .NET 革新,同时还代表对 ADO(ActiveX® 数据对象)的重大改进。ADO+ 是用于创建分布式数据共享应用程序的标准编程模型。此技术的核心是 ADO+ 数据集,可以在内存中存储多个数据库表和表关系。ADO+ 表可以作为 XmlDataDocument 以及关系表和 XML DOM 对象同时访问(与 ADO+ 不同的是,ADO 数据集更象单个表,并且只具有有限的 XML 支持)。
数据集是与 XML 或数据库数据断开的视图(意指数据集在内存中存在,但没有与基础数据服务器的有效连接)。它们可以存入本地数据服务器的高速缓存中,也可以向外扩展到您的解决方案体系结构的任意层。如果需要为断开的脱机解决方案存储数据集,XML 既可用作传输格式,也可用作保留格式。
除了支持数据向外扩展到中间层或客户机的高速缓存中,ADO+ 还对基础数据服务器的所有修改进行协调,包括表创建、架构修改、关系和限制管理、并行性管理和事务。其它 ADO+ 修改包括从表或 XmlDataDocument 添加、选择、编辑、删除和移去数据。
ADO+ 数据集和基础数据存储之间的接口或适配器称作受管提供程序。.NET 平台将附带有用于 SQL Server、XML 和 ADO 的受管提供程序。Web 存储系统受管提供程序不久即将提供。
在当前技术上的扩展
尽管 .NET 平台是用来创建集成的合作解决方案的新平台,但它是建立在现有技术的基础之上的,并且努力简化其设计、执行、部署和管理。下面对典型的 .NET 服务器或服务器模型进行了说明。
图 4. .NET 服务器模型体系结构
此模型体系结构是在当前大多数 Windows 服务器中广泛使用的体系结构。但是,.NET 平台可以使展示数据、XML、Web UI 和 Web 服务更容易。.NET 公共语言运行时和基类提供了所有 CLR 编程语言通用的完全面向对象的受管内存环境,从而更容易、更快捷地创建更为强大的组件、子系统和应用程序。ADO+ 是在 ADO 的基础上创建的,提供可扩展的数据集高速缓存和永久存储模型,用来管理断开的联机情况和断开的脱机情况中的数据。.NET 应用程序提供与用户进行交流的 Web UI 和 Web 服务,使开发人员可以更容易地展现应用程序的功能,以便其它服务器和客户机应用程序能够与其相连。
Web 存储系统采用分层文件夹模型,用于存储任何类型的无特定结构的或半结构化的内容(电子邮件、文档、文件、可执行文件等),并且通过大量的 API、Internet 协议、一个支持同步和异步处理的事件模型以及一个工作流引擎,增加对访问和更新这些内容的支持。
Web 存储系统支持以下 API 和 Internet 协议:
此外,Exchange 2000 Server、Exchange 2000 Conferencing Server 和 Active Directory™ 支持以下 API 和 Internet 协议:
图 5. Web 存储系统:API 和 Internet 协议
通过此组 API 和 Internet 协议,Exchange 2000 Server 和 Microsoft Web 存储系统成为可提供自动业务解决方案的功能强大的合作解决方案平台。
分层对象存储
Web 存储系统中的文件夹可视作:
理解这些不同方面的关键是了解有关文件夹、子文件夹、项目和属性的基础知识。对于大多数用户而言,他们对文件夹和项目的 Web 存储系统概念的理解是建立在由 Outlook 2000 或类似的个人信息管理器提供的列表和窗体基础之上的。理解这些概念更基本的含义是十分重要的。
文件夹的层次结构(起始于该层次结构的最顶层文件夹)称作 Web 存储系统中的顶层层次结构 (TLH)。Web 存储系统文件夹用于存储项目集合。项目具有一组与其相关的属性。属性就是一个简单的 name=value 对,其中的值可以是单值,也可以是多值。属性的名称由其所属的 XML 名称空间限定,例如 DAV: 或 urn:content-classes。项目及其属性的列表可以作为 ADO 数据集或 WebDAV XML 文档检索。这就是使 Web 存储系统文件夹近似数据库表的原因。
此外,文件夹中的每个项目不必与文件夹中的其它项目的属性集完全相同。可以将一个属性动态添加到任意单独项目中,而与该文件夹中的其它项目完全无关。
图 6. Web 存储系统:文件夹、项目和属性
某些属性具有特殊的、定义明晰的含义和重要性。一个主要属性就是布尔属性 DAV:isfolder。isfolder 属性决定一个项目是简单项目还是代表更多项目的集合(或子文件夹)。Web 存储系统的分层文件夹存储就是通过该属性实现的。即,文件夹中的某些项目的 isfolder 属性值为真,表示该项目是逻辑子文件夹。然后,可以在该项目的记录对象上调用 ADO GetChildren 方法,以返回子文件夹中各项目的列表。
Web 存储系统中的每一项目都具有唯一的、用户友好的 URL,可用于标识和访问该项目。对于个人邮箱中的项目,URL 的格式为:
对于 TLH 下的项目,格式为:
项目也可以是任意文档,包括电子邮件信件、日历约会、联系人、任意 Office 文档、HTML 页、ASP 页、XML 文档或音频或视频流。下面介绍一些更贴近现实生活的例子。
我的个人收件箱中电子邮件的 URL 类似以下形式:
公用文件夹中联系人项目的 URL 类似以下形式:
作为可供使用的 Web 存储对象的项目和内容类
另一个主要项目属性是 DAV:contentclass。对于在 Exchange 2000 Server 和 Web 存储系统上建立的大多数应用程序和服务而言,它们使用一个项目的内容类属性来确定该项目所代表的对象的类型。例如,urn:content-classes:message 的内容类值表示该项目是电子邮件信件,并且应该从那些适合于电子邮件信件的属性中选择其属性。其它重要的内容类包括:urn:content-classes:appointment、urn:content-classes:person 和 urn:schemas-microsoft-com:exchange:workflowprocessdefinition。person 是用于联系人项目的内容类值。Web 存储系统提供 30 多个常用对象内容类的架构和属性定义。与属性名类似,内容类名称也是由其所属于的 XML 名称空间(或者是某一固有的 Web 存储系统名称空间,或者是针对于您自己的自定义的应用程序或组织的名称空间)限定的。
MAPI 应用程序(例如 Outlook 2000)支持称作 PR_MESSAGE_CLASS(正式的介绍在 http://schemas.microsoft.com/exchange/outlookmessageclass(英文))的类似项目属性。客户机应用程序可以使用内容类属性来确定应向用户显示一个项目(及其属性列表)的方式。如果内容类是 person,则 OWA 2000 使用 HTML 将该项目作为联系人提供,而 Outlook 2000 将使用内置的 Outlook 联系人窗体来显示该项目的属性。在 Outlook 2000 示例中,等价的 PR_MESSAGE_CLASS 值是 IPM.Contact。要使 OWA 2000 和 Outlook 2000 窗体正确用于相同的联系人项目集,则该内容类和 PR_MESSAGE_CLASS 属性值都必须正确设置。
就 Exchange 2000 Server 和 Web 存储系统而论,文件夹的内容就是项目的列表 — 每个项目及其相关属性的列表。此外,某些项目可能将 isfolder 属性设置为 True,表明它们是其它项目的子文件夹。
要避免出现混乱,内容类名称还可用于命名基于 XML 的架构项目(称为内容类定义)。内容类定义对文件夹存储中特定对象类预期的属性列表进行定义。客户机应用程序选择用来显示一个项目的方式完全适合于该应用程序(和标准使用惯例)。一个项目的内容类属性只是提供该项目的对象类的名称。
也可以从固有的内容类导出新的针对解决方案的内容类架构,或者从头开始创建全新的内容类。正如您可能会猜到的那样,架构和属性定义自身只不过是具有其自己的特殊内容类(urn:content-classes:contentclassdef 和 urn:content-classes:propertydef)的项目。
按照预想,大多数应用程序可以创建其自己的架构文件夹,该文件夹仅对于此特定解决方案的实例而言是全局的。
ADO 还是 WebDAV?由您来选择
除了使用 URL 直接访问 Web 存储系统中的项目或对象外,还可以对文件夹存储执行查询。不管您是选择使用 ADO 还是 WebDAV 协议,相同的基本查询处理器全部可以处理。大多数 Windows 开发人员很熟悉 ADO,但对 Web 存储系统的 Exchange 2000 Server 版本却并不熟悉,它具有这样的限制,即只能由与 Web 存储系统在同一台计算机上运行的客户机或服务器应用程序使用,因此 Web 存储系统 OLE DB 提供程序不是自然就可以远程访问的。
对于熟悉 ADO 的开发人员,可以使用称作 OLE DB Provider for Internet Publishing (MSDAIPP) 的提供程序,该程序运行在支持远程 ADO 连接的 WebDAV(以及 FrontPage WEC 协议)的顶层。您可以阅读关于 OLE DB Provider for Internet Publishing 指南(英文)以了解详细信息。
注意: CDO 的 Web 存储系统版本不可通过 Web 存储系统或 MADAIPP OLE DB 进行远程访问。
WebDAV 是一组对 HTTP 的扩展,可以通过定义进行远程访问,并且扩展请求的参数格式为 XML 文档。在查询处理器对文件夹存储执行查询后,它将向发出请求的应用程序返回 XML 文档形式的结果。
对于 ADO 和 WebDAV 查询,可以使用大家熟悉的 SQL 查询语言语法。支持 SELECT *、LIKE、WHERE、ORDER BY、GROUP BY、CONTAINS、FREETEXT 和列别名,但不支持 JOIN 和 MAX、MIN、SUM 等。此外,FROM 子句的 SCOPE 选项可用于指定是只搜索当前文件夹(不包含子文件夹),还是搜索当前文件夹及其所有子文件夹。前者称作 SHALLOW 搜索,而后者称作 DEEP 搜索。下面是搜索的示例:
SELECT Name, WorkPhone, CellPhone FROM SCOPE('DEEP TRAVERSAL OF "<folder URL>"')
拓展 Web 存储系统功能
许多类型的解决方案可以通过前面介绍的数据访问方法进行开发。但是,这通常需要拓展 Web 存储系统的功能。可以通过两种机制对功能进行拓展:
前端 Web 服务组件:参见图 4,中间层或前端 Web 服务组件用于通过附加的功能将任意固有或自定义的对象放入文件夹存储中;就 Web 服务而言,通常用于将类或类组的功能作为 .NET Web 服务提供。
事件驱动的后端组件:尽管中间层组件可用于强制执行业务规则,但它们只适用于实际调用中间层组件的那些应用程序。一个更为有效的方法是使用如图 4 所示的事件驱动的后端组件。
对 Web 存储系统中项目的任何更改,不管该项目是简单项目还是一个文件夹,都可能会激发一个事件,导致执行某些自定义的代码。所执行的代码称作事件池。在 Web 存储系统的 Exchange 2000 Server 版本中,事件池作为 COM+ 或脚本化的组件执行。
当事件池被注册为特定文件夹中的特定事件时,Web 存储系统传递事件信息结构,其中包括已创建、更改或删除的项目的 ADO 记录。此外,事件池注册规定相对于对该项目所做的更改,该池是同步执行还是异步执行。
支持工作流的 Web 存储对象
除了能够开发上述的存储级别的事件池外,Exchange 2000 Server 工作流引擎和 Workflow Designer for Exchange 2000 Server 可以协同工作,执行更高级别的工作流事件服务集。
工作流引擎
在 Web 存储系统的 Exchange 2000 Server 版本中,工作流引擎作为 COM+ 组件实现。除了在 COM+ 下运行工作流引擎固有的性能和易管理优势外,Web 存储系统充分利用了基于角色的 COM+ 的安全模型,以确定谁能够通过工作流激活特定文件夹中的 Web 存储系统对象。
工作流引擎采用低级别的存储事件池界面,以便只要支持工作流的文件夹中发生更改,就会调用该引擎。同时,工作流引擎为 Workflow Designer 提供一组较高级别的工作流事件。
Workflow Designer for Exchange 2000 Server
Workflow Designer for Exchange 2000 Server 是用于通过工作流激活 Web 存储系统文件夹和项目的可视化设计器。它作为 Microsoft Office 2000 Developer 1.5 版的一部分提供。设计层面用于绘制代表业务流程的状态转换图。节点代表特定项目或文档在指定时刻所处的状态。如果业务流程的角度需要,即应在两种状态之间绘制箭头。箭头表示从一个状态转换到另一个状态。转换是受一定条件限制的,该条件控制何时允许一个项目从当前状态更改为新状态。通常,该条件将测试所更改项目的 ADO 记录对象的一个或多个属性,该记录对象在激发工作流事件时自动提供。作为从当前状态转换到下一个状态的转换进程的一部分,可以执行 Visual Basic Script 操作脚本来访问某些外部功能,例如,发送电子邮件通知或与 BizTalk Server 的 .NET Orchestration 进程集成功能相集成。
在移动设备或脱机解决方案中使用 Web 存储系统
当前,Web 存储系统仅作为随 Exchange 2000 Server 附带的服务器端技术提供,不过将来会在 Tahoe 发行版中提供,Tahoe 是 Microsoft 的基于 Web 存储系统的合作服务器产品。
未来的 Office 版本还将包括用于客户机的 Web 存储系统版本,它将支持用于服务器的 Web 存储系统内容的自动高速缓存,并且还支持通用 Web 内容。此外,本地 Web 存储系统还将支持基于预订的将服务器内容复制到本地存储上。另外,本地 Web 存储系统能够通过在客户机上支持 Active Server Page (ASP),从而完全动态地保留 Web 站点。通过该功能,将能够利用许多完全可操作的、动态的、未连接的移动设备或脱机解决方案情况的新类别。
图片说明
下图描述了三种类型的客户机应用程序是如何能够访问和更新一个项目的属性的。
图 7a. 客户机功能图片说明
以 Outlook 2000 为例,MAPI 客户机能够创建新项目、更新现有项目的属性、或删除单独的项目或项目属性。同样,通过使用 Web 存储系统大量的 API 和 Internet 协议集、传统的 Visual Basic 以及 Web 服务器应用程序,能够与完全相同的项目的单个实例进行交互操作并更改该实例。
此外,由这些客户机应用程序进行的项目更改能够触发事件驱动的后端逻辑指令,包括在 Exchange 2000 Server 工作流引擎中执行的工作流进程。Workflow Designer for Exchange 2000 用于创建并更新在工作流定义 (WFD) 文件中保存的业务流程。WFD 文件可以存储在每个支持工作流的文件夹中,或者存储在公用应用程序文件夹中(类似于共享内容类架构项目)。下图描述了事件驱动的后端工作流逻辑指令如何能够响应创建新项目或更改现有项目的事件。
图 7b. 后端事件驱动的图片说明
当用户双击或指出他们想要打开一个项目时,应用程序会首先查看内容类(即 PR_MESSAGE_CLASS)和浏览器参数,以确定使用合适的 Web UI 或窗体来显示所选项目的属性。
下图介绍了 Web 存储系统是如何满足当今 .NET Framework 的需要的。在下一部分前景展望中,概要介绍了一些新 .NET 功能,这些新功能预计将由 Exchange 开发小组在 Web 存储系统的下几个发行版中提供。
图 8. Web 存储系统和 .NET 架构
Web 服务
SOAP Toolkit for Visual Studio 6 现在可用来快速开发用于 Web 存储系统的自定义 Web 服务。位于 http://msdn.microsoft.com/exchange/(英文)和 http://msdn.microsoft.com/xml/general/toolkit_intro.asp(英文)的 Exchange Server 下载都是极佳的资源。尽管 SOAP Toolkit 使开发 Web 服务和与 Web 服务建立连接更为容易,但 SOAP 协议标准系列不需要特定的工具包或平台来实现 Web 服务的种种优点。
在 SOAP Toolkit 中包括在 Windows 操作系统上提供 SOAP Web 服务所需的基础结构,该基础结构也是通过 Visual Studio 6.0 使用这些服务所需要的。SOAP Toolkit 使创建 Web 服务所需的所有关键步骤自动进行。
如果已有某个 COM 组件,SOAP Toolkit 可以很容易地将该组件转换成 Web 服务,并在应用程序(例如 Visual Basic)中使用。SOAP Toolkit 包括将从现有 COM 组件中提取类型库并将其转换成 SOAP 协议语言 (SCL) 协议(代表该组件的功能,例如接口、方法和属性)的工具。同时还将生成各种实现供其它应用程序使用的服务所必需的文件。您还可以手动生成此协议。
一旦您具有协议,该工具包将包括对 Visual Studio 的扩展,会自动将该协议转换成一个代理,您能够象本地 COM 组件一样对该代理进行编程。该工具包还包含 SOAP 监听程序,可以接收 SOAP 调用并将它们转到相应的服务上。
最为常见的是使用传统的 SOAP 远程方法调用协议对 Web 服务进行调用。以下基于 XML 的标准支持 SOAP:用于架构定义的 XML 架构数据类型 (XSD)、SOAP 发现协议、服务协议语言 (SCL) 和简单对象访问协议 (SOAP) 协议本身。此外,数据远程 Web 服务使用 XML/HTTP 协议,例如 WebDAV。请参见“数据和 XML”部分以了解详细信息。
Web UI
为了支持 Web UI 的快速开发,Web 存储系统包括三种主要技术:
表单注册属性存储在称作“表单注册”的单独项目或对象中。表单注册属性根据项目的内容类和各种其它条件(包括用户的浏览器类型、请求类型、查询字符串参数等)来决定显示该项目属性要使用的 Web UI。要使用的 Web UI 可以由传统的 URL 或 Web 存储系统服务器的自定义表单生成器 DLL 的路径标识。自定义表单生成器 DLL 作为对 ISAPI 应用程序的扩展执行,表示它们是可执行的并且是可扩展的。Outlook Web Access for Exchange 2000 Server 作为其中一个 DLL 执行。固有的或自定义的表单提供程序可以访问 HTTP 请求标头集合,以及由用户浏览器请求的项目属性的 ADO 记录。
Web 存储系统附带有固有的表单提供程序 EXWFORM Web Storage System Forms。开发人员创建 Web 存储系统表单的方式与创建使用 DHTML 动态数据绑定的 ASP 页或 Web 页相同。EXWFORM 表单提供一组快捷方式,从而减少或避免在页中使用任意实际脚本代码的需要。所有 Web 存储系统表单提供程序(固有的或自定义的)都在服务器上执行。
最终,OWA 2000 将大多数 Outlook 2000 的客户机功能作为基于 Web 组件的 Web UI 提供。OWA 2000 可以用作完备的电子邮件客户程序,可以访问电子邮件、日历约会和联系人,另外还可以访问您所有的个人和公用文件夹。此外,开发人员还可以使用 OWA 2000 Web UI 的每一组件在自己的合作 Web 解决方案中自动提供功能全面的日历、联系人列表、电子邮件和主题讨论。
数据和 XML
要通过 .NET Framework 支持关系数据和 XML 的传输,Web 存储系统需支持 ADO 2.5、WebDAV 和 Web 服务。
ADO 提供大多数 Visual Basic 和 ASP 开发人员所熟悉的服务器端数据访问对象模型。WebDAV(W3C 分布式编写和出版协议)支持使用基于 XML 的 HTTP 请求和响应协议远程访问数据。由 WebDAV 请求返回的数据可以通过 XML 文档对象模型 (DOM) 访问,也可以通过 OLE DB Provider for Internet Publishing (MSDAIPP)(有时称作“Rosebud”)作为远程 ADO 记录集访问。有关详细信息,请参见本文的“分层对象存储”部分。
最后,应用程序可以使用基于 XML/HTTP 的 SOAP 协议套件,以便对运行在远程 Web 服务器上的各个服务执行方法调用,结果将作为 SOAP 格式的 XML 文档返回。
组件运行时环境
对于 Web 存储系统的 Exchange 2000 Server 版本,支持的组件运行时环境是 COM+。
基类
不包括服务器到服务器传输协议,在 Web 存储系统的 Exchange 2000 Server 版本中共支持六种基类:
有关属于各组的 API 和协议的详细信息,可以在本文的“Microsoft Web 存储系统”部分找到。
Visual Studio 和 Office
要缩短应用程序的开发周期、提高开发人员的工作效率,功能强大的工具和平台是必不可少的。目前,要建立 .NET 应用程序和服务,Visual Studio 6.0 和 Office 2000 Developer Edition(包括 Outlook 2000、FrontPage 2000 和 Workflow Designer for Exchange 2000 Server)是主要工具。
通过 Web 服务建立合作解决方案有两种主要途径:简单和联合。简单 Web 服务在单个 Web 服务器上实现,并且只提供单个 Web 服务。在图 9 中,服务器 X、服务器 Y 和 Travel Broker Web 站点提供简单 Web 服务和应用程序,直接调用由这些 Web 服务提供的方法。
随着 Web 服务的发展,无论从功能或横向发展角度,或从可靠性角度,均将以特定服务器承担特定职责的形式实现专门化。下图以服务器 X 和服务器 Y 为例。但是,当 Web 服务从一台服务器转到第二台服务器或第三台服务器时,对于开发人员、操作人员和使用应用程序的 Web 服务而言,这一情况会使形势变复杂。解除这一烦恼的“良药”就是联合 Web 服务和 UDDI。
联合 Web 服务在单一的、众所周知的前端 Web 服务器(称作主 Web 服务器)上通告,而 Web 服务组件可以在任意数目的中间层服务器上执行。希望连接到 Web 服务的应用程序只需访问主 Web 服务器上的 SOAP 协议,远程方法调用将自动对相应的中间层服务器执行。许多类型用户的主 Web 服务器的极佳选择将是 Exchange 前端消息传送和合作服务器。随着 Web 服务的发展,UDDI 注册将成为用来通告有关一个组织的 Web 服务的有关业务和技术信息的当然之选。
在 Exchange 服务器上通告的联合 Web 服务可以包括:
该情况在图 9 中介绍。
图 9. 多联合 Web 服务模型
图 9 中描述的最后一种情况是分派调用。当一个 Web 服务代表原主调应用程序调用另一个 Web 服务时,会发生分派调用。在图 9 中,Exchange 服务器提供由 Outlook 调用的联合 Web 服务。如果由 Outlook 用户请求的操作是外出旅行预订请求,Exchange 服务器将该调用分派给在旅行社的 Web 站点上运行的 Web 服务。
此外,Web 服务联合允许组织在不损害其控制或访问 Web 服务能力的前提下,决定是运行自己的基础结构还是从外部装入基础结构。
旅行社合作日程安排示例
让我们首先看一下在“Web 用户体验”部分介绍的外出旅行预订情况吧。某个 Outlook 用户希望计划一次旅行。在理论上,可能需要以下部分或全部信息来完成旅行社的预订过程:
旅行社可能已拥有上述部分或全部信息。但是,这些信息不一定是最新的信息,或者该人士可能通过从来不办理个人旅行业务的旅行社进行预订。我们将首先看到充分利用联合 Web 服务的设计范例,然后再看一下另一种效率低下的方法。
多联合 Web 服务示例
在上面的多联合服务模型中,Outlook 用户具有已针对个人旅行进行自定义的 Outlook 约会表单或 Web 表单。首先,该表单将需要通过新的内容类(即 urn:content-classes:vacationbooking)进行注册。还需要正确设置 Outlook outlookmessageclass。此内容类的架构可能会为上述列表中的每一条信息包含一个属性,但我们为什么要如此繁琐呢?对于大多数外出旅行而言,只有前三条或四条信息是唯一的。我们要什么时候出发?我们要去哪里?我们要在哪里停留?我们是否要租车?
需要这些属性来作为外出旅行预订内容类架构的一部分。但是,如果外出旅行预订内容类是从约会内容类中导出的,则仅需要将目的地、旅馆和租车属性添加到新架构和新外出旅行预订约会表单中。
在将新项目添加到 Outlook 用户的日历中时,将执行工作流引擎中的事件池,并通过一个条件检查新项目的内容类的值是否为外出旅行预订。如果该值是外出旅行预订,则该项目的工作流将转换为业务流程中的下一个状态,并且执行与该转换相关的操作脚本。操作脚本将启动分派调用过程,将调用分派给由旅行社的 Web 站点提供的 Web 服务,传送四条由外出旅行预订表单收集的信息。
然后,任何好的旅行社都会询问有关您的其它偏好的信息,还会询问您的付款方式。这是如何实现的呢?如果旅行社回电话或发送电子邮件,该信息同样也已在原始的外出旅行预订表单上输入。不过,实际的实现方式是旅行社的应用程序对 Outlook 用户的 Exchange 服务器上的第二个 Web 服务执行自己的远程方法或数据访问调用。该服务向授权的用户(如旅行社)提供用户的个人偏好信息。个人偏好信息作为 Outlook 用户的个人文件夹中的一个项目存储在一个位置。该信息始终是最新的和安全的。
效率低下的 Web 服务体系结构
为了强调上述方法的优点,您可以看一下图 10 中所介绍的相同外出旅行预订情况下效率低下的 Web 服务体系结构。在此情况中,没有工作流,不可能将调用分派给旅行社的 Web 服务,并且 Exchange 服务器上没有用于提供个人偏好信息的回调 Web 服务。
图 10. 效率低下的 Web 服务体系结构
在此情况中,附加的客户端代码将把所有所需的信息汇集到对旅行社的 Web 服务的较大的远程方法调用中。如果需要任何其它个人偏爱方面的信息,旅行社的应用程序应该向哪里回调呢?根据推测,应用程序应该调用在 Outlook 客户机内执行的外出旅行预订代码。但可能性更大的是,旅行社发电子邮件或打电话以索取这些信息,而 Outlook 用户将手工从其个人文件夹的项目中获得这些信息,因此导致时间的浪费和延误。
这两种方案突出说明了 .NET 平台和框架的作用,并着重了介绍 Web 服务的价值。
预计在 Web 存储系统的下几个发行版中,将提供其它一些对 .NET Framework 的每一组件的支持。
从 Web UI 角度而言,Web 存储系统表单将通过与 ASP+ 的集成继续得以发展。Forms Registry 和 Outlook Web Access for Exchange 2000 Server Web UI 组件的实现也将继续加以改进。
从数据和 XML 传输角度而言,Exchange 受管提供程序将提供对 ADO+ 数据集的支持,包括支持数据向外扩展到解决方案体系结构任何层中高速缓存和永久存储。在 ADO+ 表内的数据可以作为关系表(类似于 ADO 数据集)、ADO+ XML 数据文档、或作为传统的 XML DOM 对象访问。
此外,预计 Web 存储系统与 .NET 公共语言运行时的集成将更为紧密。
Microsoft .NET 平台作为充分利用计算和通信优势的第一个平台,将在 21 世纪的头十年极大推进计算和通信技术的革命。它将为新一代 Internet 服务的兴起推波助澜,并且使数以万计的开发商能够创建用于联机服务和业务的革命性的软件。它将使您可以重新控制或更好地控制您的隐私、数字标识和数据。
Exchange 2000 Server 产品小组十分希望了解您对 Exchange 2000 Server 的 Microsoft .NET 策略的反馈。请将您的意见发送到 [email protected]。
有关详细信息:
http://www.microsoft.com/china/exchange/(中文)
http://msdn.microsoft.com/exchange/(英文)
http://msdn.microsoft.com/wss/(英文)
Microsoft Outlook 和 Exchange 编程,第二版(英文)
致谢
在此向 Exchange 2000 Server 产品小组、Gordon Mangione、Alex Hopmann、Brent Ingraham、Harry Katz、Keith McCall、Chris Vandenberg、Thomas Rizzo、Lyle Curry、Jeff Wierer、Kevin Hunter、Bill Skilton 和 Microsoft EC3 Enterprise Consulting Competency Centers 小组致谢,没有他们的大力支持、鼓励和关爱,本文是不可能呈现在您面前的。
本文档只是初步阐述作者观点,并在最终用于商业出版前可能会进行较大的修改。本文档仅用于提供信息,Microsoft 对本文中的信息不做任何明示或暗示的保证。本文档中的信息如有更改,恕不另行通知。使用本文档的全部风险和后果均由用户自行承担。本文所引用的公司、组织、产品、人员和事件示例均属虚构。不应有意或推测与任何真实的公司、组织、产品、人员或事件有任何关联。用户有责任遵守所有适用的版权法。不限于版权法所规定的权限,未经 Microsoft Corporation 明确书面许可,不得向可检索系统复制、存储或引入本文档的任何部分,也不得为任何目的、以任何形式或手段(电子、机械、影印、录制等)进行传播。
Microsoft 对本文档中涉及的主题拥有专利权、专利应用权、商标权、版权或其它相关的知识产权。除非获得明确的 Microsoft 书面许可协议,否则本文档中提供的内容并不意味着授予您拥有这些专利、商标、版权或其它知识产权的许可。
未出版的作品。© 2000 Microsoft Corporation。保留所有权利。
Microsoft、Exchange、Outlook 和 Windows 是 Microsoft Corporation 在美国和/或其它国家(地区)的注册商标或商标。
此处提到的真实的公司和产品名称可能是其各自所有者的商标。
本文地址:http://com.8s8s.com/it/it46254.htm