Introducing Microsoft Reporting Services, Page 4
1.2.7 Deployment features
Because it is server-based, RS has zero deployment requirements for integrating with client applications. For this reason, any type of client applications can target RS, not only .NET-based applications. Because you can access RS through the two most popular web protocols, HTTP-GET and Simple Object Access Protocol (SOAP), any web-capable application can be integrated with RS, regardless of the targeted platform and development language.
DEFINITIONS The Hypertext Transfer Protocol (HTTP), on which the Internet is based, comes in two flavors: HTTP-GET and HTTP-POST. While HTTP-GET passes request parameters as a part of the URL, HTTP-POST passes them as name/value pairs inside the actual message.
Simple Object Access Protocol (SOAP) is a lightweight XML-based protocol, layered on top of HTTP, for exchanging structured and type information on the Web. In recent years, SOAP has become the industry-standard protocol for communicating with web services.
Integrating your applications with RS requires a good grasp of its architecture. The next section outlines the major RS building blocks.
1.3 RS ARCHITECTURE
An important feature of the RS architecture is that it is service-oriented as opposed to object-oriented. Don Box, a Microsoft prominent architect working on the next-generation web services, outlines the following four characteristics of a service-oriented architecture:
- Boundaries are explicit. Cross-application communication uses explicit messaging rather than implicit method call invocation.
- Services are autonomous. The lifetime of a service-oriented application is not controlled by its clients.
- Services share schema and contract, not class. Service-oriented applications advertise their functionality to the outside world using XML-based schemas.
- Service compatibility is determined based on policies. By using policies, service-oriented applications indicate which conditions must be true in order for the service to function properly.
You may have used object-oriented reporting tools in the past in which the report consumer instantiates an object instance of the report provider. A characteristic of this model is that both the report consumer and the report provider instances share the same process space. For example, to render a Microsoft Access report, you need to instantiate an object of type Access.Application. Then, you use OLE automation to instruct Access to open the report database and render the report.
You will probably agree that as useful and widespread as the object-oriented model is, it is subject to some well-known shortcomings. For example, both the consumer and provider are usually installed on the same machine. As a consequence, the reports hosted by the report provider are not easily accessible by geographically dispersed clients. For instance, only COM-capable clients can interface with Microsoft Access.
A second shortcoming involves application interdependencies. Object-oriented applications are typically deployed as a unit. All Microsoft Access clients, for example, need to have the Access type library installed locally in order to establish a reference to it.
To address these shortcomings, RS departs radically from the object-oriented paradigm. In terms of reporting, the RS service-oriented architecture offers two distinct advantages: (1) Administrators can centralize the report storage and management in one place, and (2) it promotes application interoperability.report consumers can request reports over standard web protocols, such as HTTP—GET and SOAP.
The RS service-oriented architecture can be better explained in the context of a three-tier application deployment view, as shown in figure 1.3.
Figure 1.3 Report consumers submit report requests to the Report Server, which queries data sources to retrieve the report data and generate the report.
The RS architecture includes the following main components:
- The Report Server, whose main task is to generate reports
- The Report Server Configuration Database (the report catalog), which serves as a centralized report repository
- The Report Manager, a web-based tool for managing the report catalog and requesting reports.
Let's explain the role of each component in more detail, starting with the Report Server.
1.3.1 The Report Server
At the heart of the RS architecture is the Report Server engine. The Report Server performs the following main tasks:
- Handles the report requests sent by the report consumers. I will use the term "report consumer" to describe any client application that requests reports from the Report Server. Once again, this could be any application regardless of the language in which it was written or the platform it runs on.
- Performs all chores needed to process the report, including executing and rendering the report, as we discuss in detail shortly.
- Provides additional services, such as snapshots and report caching, authorization and security policy enforcement, session management, scheduling, and subscribed delivery.
DEFINITION We will use the term "report request" to refer to the set of input arguments that the report consumer has to pass to the Report Server to generate a report successfully. At minimum, the report request must specify the path to the report and the report name. Other arguments can be passed as report parameters, including rendering format, whether the report should include the standard toolbar, and so forth.
Looking at figure 1.3, you can see that the Report Server encompasses several components, including the Report Processor, Windows Service, and extensions. From an implementation standpoint, perhaps the best way to describe the Report Server is to say that it is implemented as a set of .NET assemblies located in the C:\Program Files\Microsoft SQL Server\MSSQL\RS\ReportServer\bin folder.
NOTE An interesting fact about the Report Server is that it is 100% written in C# code. As far as I can tell, this qualifies it as the first true .NET server. No, unfortunately the source code is not provided. Moreover, the Report Server assemblies are obfuscated to prevent reverse engineering, reuse, and abuse.
As you know, the Report Server's main role is to generate reports. To accomplish this, the server retrieves the report definition from the report catalog, combines it with data from the data source, and generates the report.
Figure 1.3 and the product documentation indicate that the Report Processor component is responsible for report processing. The implementation details of the processor are not disclosed at the time of this writing, but most likely the majority of its functionality is encapsulated in the Microsoft.ReportingServices.Processing.dll assembly. For the remainder of this book we use the terms Report Processor and Report Server interchangeably.
Section 1.4 explains the purpose of each of the Report Server components and shows how they relate to report processing.
From an integration standpoint, perhaps the most important observation that you need to draw from figure 1.3 is that the Report Server has two web-based communication façades that expose its functionality to external clients: HTTP Handler, which accepts URL-based report requests submitted via HTTP-GET, and the Web service (shown in figure 1.3 as RS WS), which handles SOAP requests. You will see how these fagades impact the report-delivery process in section 1.5.