Reporting Services: The Main Components
In a nutshell, to author a report, the developer creates a report definition using the Report Designer add-in to Visual Studio .NET 2003 or a third-party authoring tool.  While under development, each report definition is maintained in its own XML file, which is given the file extension of "RDL". We'll tell you more about RDL later on; however, succinctly, RDL files contain the layout, graphics, connection, and query information as well as Report Parameter definitions and almost all other report logic. Using the Report Designer, developers can author, tune, and refine reports without having to access the Report Server. At design time, reports can be "previewed" using the Report Designer, which provides a close approximation of what the finished report will look like when rendered by the Report Processor.
Delving into the intermediate language (IL) of these components (which is, of course, expected of a potty-trained geek like me) leads one to conclude that C# was the developer's language of choice.
Once a report definition is complete, the report is published, or "deployed," to a Report Server where it becomes a compiled managed report. At this point, the DBA or report administrator can decide how and to whom a report is to be made available.
Yes, but those folks were C++ geeks and not smart enough to learn Visual Basic .NET.
The Report Server exposes a SOAP  interface, through which these managed reports can be programmatically manipulated. Straight out of the box, there is a fully functional Report Manager. This is an ASP-based application that sits on top of the Report Server's SOAP interface and provides a user-friendly GUI environment with which to manage reports. Additionally, there is a Report Scripting Utility (rs.exe) that enables you to execute scripts that make calls to the SOAP interface.
OK, Bill, I'll let you win. The Visual Basic .NET geeks can be smarter, if that's what you want, but the C# geeks will remain richer. "Developers who program primarily in C# earn 26 percent more than those who develop primarily in Visual Basic .NET."
We'll show you how to launch managed reports from code or simply tune up or customize the existing Report Manager. When it's time to view a managed report, the compiled report definition is fed to the Report Processor, which fetches the data, merges it with the report layout, renders the report into a selected format, and streams back the result. Reports can be processed on demand or according to customizable schedules. It's all really very simple. But don't close the book yet. There are a few more details that you'll want to know.
Yes, but C# programs take 28 percent longer to write, so they spend more time at the office while the Visual Basic programmers are out having a life.
Reporting Services is composed of a number of well-integrated components, most of which are written in .NET managed code. Some of these components we'll be exploring, and we shall see that they consist of open and extensible subcomponents. The overall look and feel of the Reporting Services Report Designer is reminiscent of web (ASP) application development in Visual Studio .NET or the Report Designer in Microsoft Accessbut it's far more flexible. To build a report you first define the location of the source of its data, lay out some controls on the report surface, and bind those controls to the data. For much of this, it's all drag and drop. When the report is generated, the Report Server extrudes the report in much the same way that the ASP.NET engine returns HTML from a web page. But Reporting Services does not stop there. It can also render reports in a variety of other ways, as we'll soon explain.
Nice try, but if you read the article, this was based on hourly rates.
Here are the main components of Reporting Services:
A Visual Studio .NET 2003 add-in Report Designer for authoring reports. As we'll show you in Chapters 3, 6, and 7, this is alarmingly reminiscent of the Report Designer in Microsoft Access.  It extends Visual Studio .NET 2003 to permit developers to define Reporting Services DataSets, specify a query and layout, and preview and deploy the report definitions, which are saved to report definition (RDL) files in the project and then when deployed, are saved to the Report Server database as intermediate language (IL).
An ASP.NET XML Web Servicebased Report Server works in conjunction with a .NET Windows System ReportServer Service to process and provide managed reports in a variety of rendered output streams and stores its configuration, processing information, and other metadata in SQL Server.
An ASP.NET web applicationbased Report Manager for centralized report management is an important tool for DBAs, developers, and users. It's designed for report management and is an ideal and secure platform for users to select and launch reports. The Report Manager permits developers or database administrators (DBAs) to define or modify Data Sources, locate and organize reports, and create Subscriptions, which permit reports to be e-mailed on a scheduled basis. We detail the Report Manager in Chapter 4.
Figure 1.1 gives you the basic idea how the basic Reporting Services components fit together.
Figure 1.1 SQL Server Reporting Services Overview