Sdílet prostřednictvím

  • Článek

Service Architecture (Reporting Services)

In Reporting Services, a report server is implemented as a Windows service that consists of distinct feature areas that run in separate application domains. The service hosts Report Manager, the Report Server Web service, and background processing feature areas. This topic describes the composition of the service so that you can make informed choices about which features to enable and how to troubleshoot any issues that occur.

Architecture Diagram

The following diagram shows the service architecture in Reporting Services.

Service architecture diagram

Note

Not all report server capabilities are reflected in the architecture diagram. For example, initialization and reversible encryption are critical server operations that exist outside the scope of the three feature areas illustrated in the diagram.

Service and Infrastructure

The Report Server Windows service is a consolidated set of applications that run in a single process, under a single account, with access to a single report server database and set of configuration files. Configuration settings for the whole service are stored in RSeportServer.config, ReportServerServices.exe.config, and the report server database.

Within the service, Report Manager, the Web service, and background processing run in separate application domains. Although all three feature areas are enabled by default, you can configure which parts of the service are available at any given time. For example, you can turn off the Web service if you do not want to support on-demand or interactive reporting.

Although server feature areas are isolated into separate application domains, memory management and process health is managed for the service as a whole. Memory thresholds are configured for the service in its entirety. The report server handles recycle actions as internal operations. You cannot recycle individual parts of the service on demand. However, you can specify configuration settings that specify how long persistent connections are kept open.

If you segment the feature areas of a service among multiple instances (for example, enable Report Manager in one instance, the Web service in a second instance, and background processing in a third instance), the memory and configuration settings are scoped to the applications that run in that particular instance. Note that even if you segment the feature areas of the service, they are some interdependencies. A complete report server installation typically uses all three. For more information, see How to: Turn Reporting Services Features On or Off.

HTTP Listener

Reporting Services includes an HTTP listener that monitors incoming requests directed to HTTP.SYS on a specific port on the local computer. The host name and port are specified on a URL reservation when you configure the server. Depending on the operating system you are using, the port you specify can be shared with other applications. 

The HTTP listener implements the HTTP 1.1 protocol. It uses the HTTP.SYS capabilities that are built into the operating system. It is for this reason that Reporting Services requires operating systems that include HTTP.SYS as an internal component.

When the HTTP listener processes a request, it forwards it to the authentication layer to verify the user identity. The Report Server Web service is called after the request is authenticated.

The HTTP Listener uses version 1.0 of the HTTP Server API. For more information, see HTTP Server API on MSDN.

Authentication Layer

Reporting Services includes an authentication layer that verifies the identity of the user or application that makes the request. The following authentication types are supported: Windows integrated security, NTLM authentication, Basic authentication, Forms or custom authentication, and Anonymous access. Reporting Services uses Windows integrated security and NTLM authentication by default, but you can specify a different authentication type in the configuration files. Each report server instance can be configured for exactly one authentication type. If you have a scale-out deployment configuration, each node in the environment must use the same authentication type.

Report server authentication operates within the context of your network security settings and client applications. The successful use of a particular authentication type depends on browser and network security features. For example, using Windows integrated security requires that you use Internet Explorer, you have Kerberos network authentication, and impersonation is enabled. Furthermore, if you want to use integrated security for report data source connections, you must also have delegation enabled to allow for subsequent connections to remote data sources.

For more information about authentication in Reporting Services, see Configuring Authentication in Reporting Services.

Report Manager

Report Manager is a zero-footprint client that provides Web front-end access to the Report Server Web service. It is the out-of-the-box tool for viewing and managing report server content and operations.

By default, it provides front-end access to the Web service that runs in the same server instance. If the Web service is not enabled in the server instance, you can point Report Manager to a Report Server Web service in a different instance or computer by setting a URL in the configuration files.

Report Manager runs within a browser session on the client computer. There are no application files or settings that are stored on the client. Session state is preserved as long as the browser window is open. User-specific settings are saved to the report server database and re-used whenever the user connects to Report Manager.

Report Manager can accommodate custom delivery extension settings in the subscription definition pages. If you create and deploy custom delivery extensions, Report Manager can present options and display text for that extension dynamically.

To use Report Manager, you must define a URL to the application. You can effectively disable Report Manager by not creating the URL in the first place. If you installed Reporting Services in the default configuration, the URL is already created and you must delete it if you decide to turn the application off.

If you configure the report server to run in SharePoint integrated mode, Report Manager is turned off. You cannot use Report Manager on a report server that runs in SharePoint integrated mode, even if you previously configured the URL.

For more information about Report Manager, see Report Manager and How to: Configure Report Manager.

Report Server Web Service

The Report Server Web service is the core engine for all on-demand report and model processing requests that are initiated by a user or application in real-time, including most requests that are directed to and from Report Manager.

The Report Server Web service performs end-to-end processing for reports that run on demand. To support interactive processing, the Web service authenticates the user and checks the authorization rules prior to handing a request. The Web service supports default Windows security extension and custom authentication extensions.

The Web service is also the primary programmatic interface for custom applications that integrate with the report server. If you are providing a custom user interface, you can use the Web service without Report Manager.

For more information, see Report Server Web Service.

Background Processing

Background processing refers to operations that run in the background and are initiated by the report server. Most background processing consists of scheduled report processing and subscription delivery, but it also includes report server database maintenance tasks.

Background processing for scheduling, subscription, and delivery is configurable and can be turned off through the Surface Area Configuration for Reporting Services facet of Policy-Based Management in Management Studio. If you turn those operations off, scheduled report or model processing will not be available in the current service instance. Database maintenance is a core task that cannot be turned off as it keeps the server in a working state. 

Background processing operations depend on a front-end application or the Web service for definition. Specifically, schedules and subscriptions are created in the application pages of Report Manager or on a SharePoint site if the report server is configured for SharePoint integration, and then forwarded to the Web service, which creates and stores the definitions in the report server database.

If you are providing custom code that requires programmatic access to backend processing, use the Reporting Services WMI provider. For more information, see Reporting Services WMI Provider. To learn more about scheduling and delivery processing features, see Scheduling and Delivery Processor.

Authentication and Memory Management for Background Processing

As the service architecture diagram illustrates, background processing handles authentication and memory management differently than Report Manager and the Web service. Background processes use Authz.dll to verify whether the user account that was used to create the subscription still has the correct permissions to view the report. This check ensures that the user who is about to receive the report is a valid Windows user in the domain. All other report and model processing that runs as a background process is requested under the identity of the unattended execution account.