Share via

Comparing Report Web Services to an Unmanaged RAS Server

  • Article

This section examines two approaches to Web services that use Business Objects reporting solutions:

The two approaches are examined and compared to one another, for their performance and scalability.

An unmanaged RAS server improves performance over Crystal Reports for Visual Studio. On a system that uses an unmanaged RAS server, the report engine operates from an external report server process, rather than being embedded in the application.

Note

An unmanaged RAS server was provided with Crystal Reports Advanced edition, or it could be licensed on a processor basis. These products are no longer available. It is recommended that you instead upgrade to Crystal Reports Server. For further information on upgrade options, see Upgrade Options. For more information on the architecture of unmanaged RAS , see Comparing Architectures Across Business Objects Reporting Solutions.

Comparison of Report Web Services and unmanaged RAS

One question that developers ask about the unmanaged RAS server is whether its architecture and performance is superior to what they could build with the Report Web Services framework in Crystal Reports for Visual Studio: in other words, exposing reports on one server and consuming them on another.

The answer to this question is threefold:

  1. Report Web Services could be used to build a superficially similar architecture: a Web server retrieving reports from a report server.

  2. However, the core of an unmanaged RAS server is that it completely extracts report processing into an external process. The CrystalReportViewer control on the Web server simply passes requests (e.g. a changed parameter); unmanaged RAS then performs all processing internally before passing back the report. Report Web Services do not have this capability. The control on the Web server must initiate multiple requests from within its CrystalReportViewer object model to the report served by Report Web Services. This ends up splitting the report processing between Web and report server and generating heavy traffic over a slow, text-based protocol.

    Note

    RAS is analogous to the use of stored procedures on a database server so that all database processing is completely extracted to the database server. Report Web Services is analogous to passing multiple SQL query strings to a remotely served database.

  3. Report Web Services were never designed to mimic the unmanaged RAS framework (performance gains through complete extraction of the reporting process). They were designed to facilitate unrestricted business-to-business communication (standardized XML-based protocol for broadened communication across many companies).

Performance limitations of Report Web Services compared to a RAS Server

Report Web Services has three main performance limitations, when compared to an unmanaged RAS server.

Performance limitation #1: Report Web Services are missing the core architectural improvement of an unmanaged RAS server

In Crystal Reports for Visual Studio, the report engine is embedded within the application. This places an architectural limitation on the number of users that can simultaneously access reports. An unmanaged RAS server extracts the report engine from the application and runs it in a separate report server process. Once the report engine is extracted, the architectural limitation is gone, enabling an unmanaged RAS server to scale based only on licensing limits.

When serving Report Web Services from a separate server, this is simply a second copy of the Crystal Reports application running. It happens to be serving Report Web Services instead of Web sites, but the application is the same. Therefore, the report engine is embedded within the application, limiting performance to the architectural limitation on the number of users that can simultaneously access reports.

Performance limitation #2: Report Web Services expose a report, not a report object model

When running a Web application with Crystal Reports, the CrystalReportViewer control can bind to reports in a wide variety of ways described in Report Binding with CrystalReportViewer Object Model.

But the most important distinction is whether the CrystalReportViewer control is binding directly to a report via a path string, or instead to one of the report object models.

Note

For more information on these object models see Which Object Model Should I Use?.

It is a best practice for the CrystalReportViewer control to bind to a report object model. This limits the role of the control to displaying the report while the report object model concerns itself with performing the business logic. This enables a clear separation of the presentation layer from the underlying business logic. Because the boundaries are not blurred, all the benefits of the business logic layer are accessible to the object model.

This becomes even more relevant when applied to the unmanaged RAS server. The CrystalReportViewer binds to the ReportClientDocument object model, which is contained within RAS and is therefore running in a separate reporting process. This allows the RAS server to exclusively manage the ReportClientDocument object model within the reporting process; the CrystalReportViewer control simply passes parameter strings (such as a particular user or other display criteria) to unmanaged RAS, and the RAS server interacts with that information and returns the processed report. The clear separation of layers keeps network traffic to a minimum.

However, if CrystalReportViewer control does not connect to a report object model but to a report directly via a file directory path string or Report Web Service URL, the CrystalReportViewer control must rely on its own limited object model for any interaction with the report. In this model, the boundary between presentation layer and the business logic becomes blurred; this becomes particularly problematic if the source report is over a network because a number of requests must go back and forth between the object model within the CrystalReportViewer control on the Web server and the report on the other server.

This scenario is not only slower than RAS; it is even slower than the default configuration: loading a report from the file directory of the Web server into the ReportDocument object model.

Performance limitation #3: Report Web Services generate high network traffic over a slow XML/SOAP (text-based) protocol

In the previous limitation it was explained how the lack of an object model in Report Web Services blurs the separation of layers and therefore causing high network traffic. This problem is exacerbated by the fact that Report Web Services use XML/SOAP (a slow, text-based protocol) to communicate across the network.

Conclusion

Report Web Services are invaluable as a tool to facilitate communication over a standard protocol between businesses. They are not designed for performance optimization.

Therefore:

  1. For building an architecture for serving reports in a Web or Windows application: start with Crystal Reports for Visual Studio, and encapsulate your reports within the Report Document object model.
  2. For performance optimization to increase the scalability of your application, consider upgrading to a unmanaged RAS server.
  3. For business-to-business sharing of reports: use Report Web Services.

Additional comparisons of unmanaged RAS and Report Web Services

Unmanaged RAS
Report Web Services
Not limited by SOAP
Limited by SOAP
Access to the ReportClientDocument object model
No access to this object model (view only)
Queuing and caching optimizations
No queuing or caching
Port 1566
Port 80
Using BusinessObjects Enterprise, a RAS server can run on multiple servers
Need multiple copies for multiple servers
Capacity limit can be increased by purchasing additional licensing
Capacity is fixed whenever the report engine is enclosed within the application.