| Reporting Services is composed of several functional blocks. Each block performs one or more specific tasks or has different responsibilities in terms of the full solution. Reporting functionalities cover different areas, and Reporting Services' architecture has been designed to be flexible. Therefore, components are spread over different areas inside the solution server (or servers), as shown in Figure 12-1. Figure 12-1. Microsoft SQL Server 2005 Reporting Services architecture. 
Server Components Reporting Services is a server product thus, the majority of its components reside on the server itself. Reporting Services databases Reporting Services databases store solution metadata, saved reports, session-related information, and everything necessary to maintain the server state. Reporting Services manages two databases: ReportServer, which includes all persistent information, and ReportServerTempDB, which includes all temporary information. You will find them in the SQL Server databases catalog just like any ordinary database. Report Server This virtual component is responsible for processing reports by requesting help from all "extension" blocks. It is implemented as two big blocks: Reporting Services Windows Service The Reporting Services Windows Service is responsible for initialization and server maintenance and also for scheduling processes and delivering output, assisted by the available delivery extensions. Reporting Services Web Services Reporting Services interacts with the outside world mainly through its Web Services interface. Indeed, Report Manager uses this interface to perform its duties. There are two available Web services: ReportingServices2005 (for management) and ReportExecutionService (for report execution).
These two blocks rely on several functional modules, including various processors and extensions: The Report Server Processor This module does all the core work of parsing the report definition, requesting data from the data processing extensions, performing calculations, and sending the output to the rendering extension to format the output as needed. The Scheduling and Delivery Processor This module is in charge of firing and maintaining all scheduled and expired processes and for sending the output to the appropriate delivery extension. This module is assisted by the Report Server Processor and by SQL Server Agent. The Authentication Extension This module is responsible for authenticating and authorizing users accessing Reporting Services. You should create and register your own assemblies for using custom or unsupported authentication mechanisms. The Data Processing Extension This module is responsible for handling interaction with data sources. Out-of-the-box supported data sources are SQL Server, Analysis Services, Oracle, OLE DB, ODBC, ADO.NET data providers, and XML. You should create and register your own assemblies for accessing unsupported databases. The Rendering Extension Reporting Services uses this extension to generate final rendered reports in the chosen format. Reporting Services includes several rendering extensions: HTML, PDF, Excel, comma-separated values (CSV), XML, and Image. You should create and register your own assemblies for rendering reports in additional formats. SQL Server Agent Reporting Services leverages SQL Server Agent to handle all scheduling-related tasks. Reporting Services creates and deletes SQL Server Agent jobs at its convenience. Reporting Services generates job names beginning with a GUID; you can see these in the SQL Server Agent Job list. These jobs do something very simple: they insert a "schedule fired" row in the Reporting Services database. This row insertion initiates the activities bound to that schedule on the Report Server. Configuration files Although Reporting Services and SQL Server configuration tools will do the job in the majority of cases, you should be aware that several configuration files exist (*.config .NET files) and that certain settings can be changed only by editing those configuration files directly. Complementary components Some reporting-related tasks, like authentication or delivery, depend on third-party applications or servers to perform their duties. For instance, e-mail delivery will need the assistance of an SMTP Server, and authentication will require some kind of authentication authority to be available. Therefore, a reporting installation might be affected if communication with those elements malfunctions.
Client Components Reporting Services provides interfaces to allow external applications to communicate with the server. Available interfaces include direct URL Access and a Web services API. Therefore, there's no limit to the number of possible client components. The out-of-the-box SQL Server and Reporting Services installation includes the following client tools: Report Manager Although this module actually runs on the server because it is an ASP.NET application, it is included here because it acts as a client. Report Manager allows end users to access and manage reports according to their authorization permissions. Report Manager is the managing web application for Reporting Services administrators. Reporting Services Configuration Manager As mentioned, configuration is a critical aspect of Reporting Services. Apart from editing configuration files directly, you can leverage Reporting Services Configuration Manager to edit most of the configuration settings from a centralized place. SQL Server Configuration Manager Using this tool, you will be able to start and stop the Reporting Services' Windows Service and to access Reporting Services Configuration Manager. SQL Server Management Studio SQL Server Management Studio allows for handling some aspects of Reporting Services, such as maintaining which users are authorized for accessing Reporting Services, roles, Shared Schedules, Reporting Services folders, and objects, as well as generating SMDL (Semantic Model Definition Language) report models. SQL Server Management Studio should be considered an administrator's alternative to Report Manager.
More Info See the SQL Server Books Online topic "Reporting Services Component Overview" for further information about each component.
Scalability Although details about how to scale a Reporting Services installation from one server to its full strength is out of the scope of this book, mentioning scalability options is worthwhile. Reporting Services is built on standard Microsoft technologies like SQL Server databases, ASP.NET, and Internet Information Server (IIS), as you have learned in the previous paragraphs. Thus, Reporting Services can leverage the scalability options provided by these technologies. Without delving into details, think of Reporting Services as being able to expand over a Web farm, just as any IIS installation can, and to stand over a SQL Server cluster, just as any enterprise setup can. More Info See the SQL Server Books Online topics "Planning a Reporting Services Deployment," "How to: Install a Local Report Server and Remote Report Server Database," and "Configuring a Report Server Scale-Out Deployment" for further information about how to scale out Reporting Services.
|
