报表 Web 服务与非托管 RAS 服务器的对比

本节将详细介绍使用 Business Objects 报表解决方案的 Web 服务的两种方式：

• 报表 Web 服务
• 非托管 RAS 服务器（请参阅“报表应用程序服务器（RAS）”）。

本节将就性能和可伸缩性，对这两种方式进行介绍和比较。

非托管 RAS 服务器通过 Crystal Reports for Visual Studio 改善了性能。在使用非托管 RAS 服务器的系统上，报表引擎通过外部报表服务器进程工作，而不是嵌入到应用程序中。

注意
非托管 RAS 服务器随 Crystal Reports 高级版本一起提供，或者以处理器为基础获得授权。这些产品不再可用。建议您升级到 Crystal Reports Server。有关升级选项的更多信息，请参见“升级选项”。有关非托管 RAS 体系结构的更多信息，请参阅“比较所有 Business Objects 报表解决方案的结构”。

比较报表 Web 服务和非托管 RAS

开发人员问到的有关非托管 RAS 服务器的一个问题是：其体系结构和性能是否优于使用 Crystal Reports for Visual Studio 的报表 Web 服务框架（也就是在一个服务器上发布报表并在另一个服务器上使用报表）的方式。

对此问题的回答包括三步：

1. 报表 Web 服务可用于生成表面上相似的结构：一个从报表服务器检索报表的 Web 服务器。
2. 但是，非托管 RAS 服务器的核心是：它将报表处理完全提取到外部进程中执行。Web 服务器上的 CrystalReportViewer 控件只是传递请求（例如，更改的参数）；非托管 RAS 则是在传递回报表之前在内部执行所有处理。报表 Web 服务则不具有此功能。Web 服务器上的控件必须从其 CrystalReportViewer 对象模型中对报表 Web 服务提供的报表发起多个请求。这会造成在 Web 服务器和报表服务器间拆分报表处理，从而产生通过较慢的、基于文本的协议进行传输的大量流量。

   注意
   RAS 类似于在数据库服务器上使用存储过程，可以将所有数据库处理完全提取到数据库服务器上。报表 Web 服务类似于将多个 SQL 查询字符串传递到远程提供的数据库。

3. 报表 Web 服务并非用来模仿非托管 RAS 框架（通过完全提取报表处理进程来提高性能）。而是用于简化企业与企业之间不受限制的通讯（用于许多企业间扩大通讯的基于 XML 的标准化协议）。

报表 Web 服务与 RAS 服务器相比的性能限制

与非托管 RAS 服务器相比，报表 Web 服务有三个主要性能限制。

性能限制 #1：报表 Web 服务缺少非托管 RAS 服务器的核心结构改进

在 Crystal Reports for Visual Studio 中，报表引擎嵌入在应用程序中。这就造成可以同时访问报表的用户数目存在结构上的限制。非托管 RAS 服务器将报表引擎从应用程序中提取出来，并在单独的报表服务器进程中运行该报表引擎。在提取报表引擎后，体系结构上的限制便不复存在，从而使非托管 RAS 服务器的伸缩性只受许可授权限制制约。

当从单独的服务器提供报表 Web 服务时，这只是正在运行的 Crystal Reports 应用程序的第二个副本。它恰巧提供报表 Web 服务而不是网站，但应用程序是相同的。因此，报表引擎嵌入在应用程序中，性能因可以同时访问报表的用户数存在结构上的限制而受到限制。

性能限制 #2：报表 Web 服务提供报表，而不是报表对象模型

当运行具有 Crystal Reports 的 Web 应用程序时，CrystalReportViewer 控件可以使用“通过 CrystalReportViewer 对象模型进行报表绑定”中介绍的多种方式绑定到报表。

但最重要的一个区别是 CrystalReportViewer 控件是通过路径字符串直接绑定到报表，还是绑定到某个报表对象模型。

注意
有关这些对象模型的更多信息，请参见“应该使用哪种对象模型？”。

最佳做法是让 CrystalReportViewer 控件绑定到报表对象模型。这样，该控件的作用将限于显示报表，而报表对象模型则关注于执行业务逻辑。从而将表示层和基础业务逻辑明确区分开来。因为界限清楚，业务逻辑层的所有好处都将影响对象模型。

当应用于非托管 RAS 服务器时，这种相关性更强。CrystalReportViewer 绑定到 ReportClientDocument 对象模型，后者包含在 RAS 中，因此在单独的报表处理进程中运行。这就使得 RAS 服务器可以在报表处理进程中以独占方式管理 ReportClientDocument 对象模型；CrystalReportViewer 控件只需将参数字符串（例如特定用户或其他显示条件）传递给非托管 RAS，RAS 服务器将与该信息进行交互并返回经过处理的报表。这种层之间清晰的分工将网络流量控制在最低的程度。

但是，如果 CrystalReportViewer 控件不连接到报表对象模型，而是通过文件目录路径字符串或报表 Web 服务 URL 直接连接到报表，则 CrystalReportViewer 控件必须依赖它自己有限的对象模型实现与报表的任何交互。在此模型中，表示层和业务逻辑之间的界限变得模糊；如果源报表在网络上，则问题会愈发严重，因为许多请求必须在 Web 服务器上的 CrystalReportViewer 控件中的对象模型和其他服务器上的报表之间来回传递。

这种方案不仅比 RAS 速度慢；它甚至比不上默认配置（将报表从 Web 服务器的文件目录加载到 ReportDocument 对象模型中）的速度。

性能限制 #3：报表 Web 服务会生成通过较慢的 XML/SOAP（基于文本的）协议传输的大量网络流量

上一个限制中解释了报表 Web 服务中缺少对象模型如何使层之间的分工变得模糊，从而导致较高的网络流量。报表 Web 服务使用 XML/SOAP（速度慢、基于文本的协议）跨网络进行通讯这一情况则使上述问题愈发凸显。

总结

作为简化企业间通过标准协议进行通讯的工具，报表 Web 服务非常有价值。但它们并不是针对性能优化来设计的。

因此：

1. 要建立在 Web 或 Windows 应用程序中提供报表的结构，请启动 Crystal Reports for Visual Studio，将报表封装在 ReportDocument 对象模型内。
2. 要优化性能以提高应用程序的可伸缩性，请考虑升级为非托管 RAS 服务器。
3. 若要在企业间共享报表，请使用报表 Web 服务。

非托管 RAS 和报表 Web 服务的其他比较