SQL Server Reporting Services

Synopsis

Microsoft® SQL Server™ 2000 Reporting Services is a new server-based reporting platform that you can use to create and manage tabular, matrix, graphical, and free-form reports that contain data from relational and multidimensional data sources. The reports that you create can be viewed and managed over a Web-based connection.

Reporting Services provides a complete set of services, tools, and application programming interfaces (APIs), but you do not have to be a programmer to use Reporting Services. You can use the applications and tools included in Reporting Services to author, publish, and manage reports. There is a tool or application that supports each phase of the report lifecycle. For those who do program, an API is available to extend or integrate report capabilities into custom solutions.

Reporting Services Overview

To be successful in today's competitive marketplace, organizations need to extend information beyond the walls of their organization and seamlessly interact with customers, partners, and suppliers in real time. Microsoft SQL Server Reporting Services enables organizations to transform valuable enterprise data into shared information for insightful, timely decisions at a lower total cost of ownership.

SQL Server Reporting Services is a comprehensive, server-based solution that enables the creation, management, and delivery of both traditional, paper-oriented reports and interactive, Web-based reports. An integrated part of the Microsoft business intelligence framework, Reporting Services combines the data management capabilities of SQL Server and Microsoft Windows Server with familiar and powerful Microsoft Office System applications to deliver real-time information to support daily operations and drive decisions.

An Integrated Architecture
SQL Server Reporting Services supports a wide range of common data sources, such as OLE DB and Open Database Connectivity (ODBC), as well as multiple output formats such as familiar Web browsers and Microsoft Office System applications. Using Microsoft Visual Studio .NET and the Microsoft .NET Framework, developers can leverage the capabilities of their existing information systems and connect to custom data sources, produce additional output formats, and deliver to a variety of devices.

Full Reporting Life Cycle Support

SQL Server Reporting Services supports the full reporting life cycle, including:

• Report authoring. Report developers can create reports to be published to the Report Server using Microsoft or other design tools that use Report Definition Language (RDL), an XML-based industry standard used to define reports. 
• Report management. Report definitions, folders, and resources are published and managed as a Web service. Managed reports can be executed either on demand or on a specified schedule, and are cached for consistency and performance. New in SQL Server 2005 Reporting Services, administrators can use the Management Studio to organize reports and data sources, schedule report execution and delivery, and track reporting history.
• Report delivery. SQL Server Reporting Services supports both on-demand (pull) and event-based (push) delivery of reports. Users can view reports in a Web-based format or in e-mail. 
• Report security. SQL Server Reporting Services implements a flexible, role-based security model to protect reports and reporting resources. The product includes extensible interfaces for integrating other security models as well.
  

Key Reporting Scenarios

SQL Server Reporting Services combines a single, complete reporting platform with a scalable and extensible architecture to meet a wide variety of reporting needs, including: 

• Enterprise reporting. Enterprises can use Reporting Services for their operational reporting or business intelligence applications. Using Reporting Services, corporate IT staff can design a variety of reports and deploy them to individual throughout the enterprise. 
• Ad-hoc reporting. SQL Server 2005 Reporting Services includes Report Builder, a new ad-hoc reporting tool that enables business users to create their own reports and explore corporate data. Report Builder incorporates a user-friendly business query model that enables users to build reports without deep technical understanding of the underlying data sources. 
• Embedded reporting. Organizations can access pre-defined or ad-hoc reports from third-party applications that use Reporting Services and use these reports as-is, customize them, or create new ones for specific business needs.
• Web-based reporting for partners and customers. Organizations can deploy interactive Web-based reports to deliver information to customers or partners over extranets of the Internet. Reporting Services isolates report consumers from the complexity of the underlying data sources, while providing personalization and interactivity.
  
  

Advantages of Web-enabled Reporting
You can build a reporting environment on top of your existing database server and Web server infrastructure. Reporting Services provides a middle-tier server that runs under Internet Information Services. You can build reports that draw data from the data servers you have in place for any data source type that has a .NET managed data provider, OLE DB provider, or ODBC data source.

Report deployment can also leverage existing infrastructure and skills. Users can access reports and management tools using a browser and navigation skills they already have. Reports are accessed from a central store that is represented as a folder hierarchy. You can create a reporting environment that organizes reports and collateral content in a folder hierarchy that you design. Navigation, search, and subscription features help users locate and run the reports they need.

Reports can be rendered in both desktop and Web-oriented formats. You can build a wide range of reports that combine the strengths of Web-based features and traditional reporting. You can create interactive, tabular, or free-form reports that retrieve data at scheduled intervals or on-demand when the user opens a report. Matrix reports can summarize data for high-level reviews, while providing supporting detail in drilldown reports. Parameterized reports can be used to filter data based on values that are provided at run time. Users can choose from a variety of viewing formats to render reports on the fly in preferred formats for data manipulation or printing.

Why Server-based Reporting?
Server-based reporting provides a way to centralize report storage and management, set policies and secure access to reports and folders, control how reports are processed and distributed, and standardize how reports are used in your business.

Reporting Services is scaleable. You can install report servers on single-server, distributed, and Web farm configurations. 

About the Platform
Reporting Services has a modular architecture. The platform is based on a report server engine that consists of processors and services that obtain and process data. Processing is distributed across multiple components that can be extended or integrated into custom solutions. Presentation processing occurs after the data is retrieved and is decoupled from data processing. This feature allows multiple users to review the same report simultaneously in formats designed for different devices or quickly change the viewing format of the report. With a single click, HTML becomes PDF or Microsoft Excel or XML.

The architecture is designed to support new kinds of data sources or output formats. The rendering extensions included with Reporting Services are used to render reports in HTML and other formats for desktop applications such as Adobe Acrobat (PDF) and Microsoft Excel, but developers can create other rendering extensions to take advantage of printer or device capabilities.

Developers can include reporting functionality in custom applications or extend reporting functionality to support custom features. An API exposed as a Web service provides Simple Object Access Protocol (SOAP) and URL endpoints for easy integration with new or existing applications and portals.

Designing and Creating Reports
Microsoft® SQL Server™ 2000 Reporting Services stores report definitions in the report server database. These report definitions are created using Report Definition Language (RDL), an XML format that describes each element in a report, including the data model, format, and expressions. 

Reporting Services includes Report Designer, a tool for creating and publishing report definitions. Report Designer resides in the Microsoft Visual Studio® .NET shell and provides access to all report definition features. Developers can also create custom tools for creating, publishing, and managing reports. 

You do not have to know RDL or how Reporting Services stores reports and resources in order to use Report Designer to create and publish reports. 

Report Design Basics
Report design is usually a two-part process that consists of defining data and arranging items on a page. With Microsoft® SQL Server® Reporting Services, data definition involves specifying a data source and defining a query. You can then use data regions such as tables, matrixes, lists, and charts to display the data on the report and add other report items to the report layout. All report items have properties that determine how the items appear on the report. You can also add functionality that allows users to interact with a rendered report.

Working with Data
When you write a report, you usually begin with the underlying report data. This includes setting up a connection to a data source, defining a query, and defining a list of fields that you want to use in the report. Reporting Services uses data sources, datasets, and fields to define the data behind a report.

Data Sources
A Reporting Services data source contains information about a connection to a database. This includes information such as a server name, a database name, and user credentials. The information contained within a data source varies depending on the type of database. Reporting Services supports SQL Server, Analysis Services, Oracle, ODBC, and OLE DB. OLE DB can be used to connect to a variety of databases. Reporting Services is also extensible; developers can create additional data processing extensions that data sources can use to connect to other sources of data.

A data source can be contained solely within a single report, or it can be shared by several reports. The definition for a report-specific data source is stored within the report itself, while the definition for a shared data source is stored in a separate file on the report server. A report can contain one data source (report-specific or shared) or many.

Datasets
A Reporting Services dataset contains information about the query to be used by a report. A dataset includes a pointer to a data source, the query, and information about the data, such as collation and case sensitivity. A dataset also includes a list of fields to be used by the report.

A report can contain multiple datasets. These datasets can be used by different data regions on the report, or they can be used to provide dynamic lists of parameters. 

Fields
Each dataset in a report contains a list of fields. Typically, the fields refer to columns or fields returned by the query in the dataset. Fields that refer to database fields contain a pointer to the database field and a name property. You can use the name property to provide a friendly name in place of the name of the database field. In addition to database fields, the fields list can contain calculated fields. Calculated fields contain a name and an expression. The expression can be as simple as a concatenation of two database fields (for example, first name and last name), or it can be used to perform complex calculations.

Some query languages are flexible enough so that a query can be written to return friendly field names and perform calculations, making changes to the fields list unnecessary. The fields list is especially useful when using a database or query language that does not provide this flexibility.

Understanding Report Layout and Rendering
A report consists of three main areas: a page header, a page footer, and the body. The page header and footer repeat the same content at the top and bottom of each page of the report. You can place report items such as images, text boxes, and lines in headers and footers. The body of the report contains the report data. In addition to the report items that you can place in a header or footer, you can place data regions, which display the data from a dataset, anywhere in the report body. 

The placement of report items in a report is completely freeform. With Reporting Services, you are not limited to "bands" of data in a report. You can place data regions with different sets of data side-by-side. Certain report items can also contain other report items. For data regions, this means that you can nest groups of data within other groups. For more information about data regions, see Understanding Data Regions. For more information about report items, see Working with Items in a Report. 

Rendering
When you run a report, the report server combines the layout from the report definition with the data from the data source, and renders the report in a specified format. The report server uses extensions to perform much of this work: a data processing extension is used to retrieve the data based on the type of data source, and a rendering extension is used to provide report output based on the selected format. Different extensions can change the way data is processed and the report is rendered. For more information, see Design Considerations for Rendering.

Pagination
Pagination in a report is determined by the page size of the report and any page breaks placed on report items. Rendering extensions that support page size, such as image and PDF, format the data in the report to fit within each page. Rendering extensions that do not support page size, such as HTML, render all data between page breaks on a single page. All rendering extensions that support page breaks on items will start a new page after each page break in the report. For more information about working with page size and page breaks, and the formats that support each, see Working with Multiple Pages.

Understanding Data Regions
Data regions are report items that display repeated rows of data from underlying datasets. These rows can be displayed in a table, matrix, list, or chart.

Table
A table is a data region that presents data row by row. Table columns are static. Table rows expand downwards to accommodate the data. You can add groups to tables, which organize data by selected fields or expressions.  

Matrix
A matrix is also known as a crosstab. A matrix data region contains both columns and rows that expand to accommodate the data. A matrix can have dynamic columns and rows, which are repeated with groups of data; and static columns and rows, which are fixed. Columns or rows can be contained within other columns or rows, which can be used to group data. 

List
A list is a data region that presents data arranged in a freeform fashion. You can arrange report items to create a form, with text boxes, images, and other data regions placed anywhere within the list. 

Chart 
A chart presents data graphically. Examples of charts include bar, pie, and line charts, but many more styles are supported. 

Nested Data Regions
You can nest data regions within other data regions. For example, if you want to create a sales record for each sales person in a database, you can create a list with text boxes and an image to display information about the employee, and then add table and chart data regions to show the employee's sales record.

Grouping and Sorting
All data regions support grouping and sorting. Table, matrix, and list elements each have their own grouping and sorting properties. 

While tables and matrices provide multiple levels of grouping within a single data region, lists have only one group. To create nested groups using lists, you place a list within another list. 

Working with Items in a Report
A report in Reporting Services uses report items to display data and graphical elements. In addition to the data regions table, matrix, list, and chart, report items also include text box, image, line, rectangle, and subreport.

Text Box
Text boxes display all text data in a report. A table or matrix cell include a text boxes by default to display data. Text boxes can be placed anywhere on a report and can contain labels, fields, or calculated data. You use expressions to define data in text boxes. 

Image
Images display binary image data in a report. An image report item can use a URL to display an image stored on a Web server, display embedded image data, or display an image from binary data in a database. Reporting Services supports .bmp, .jpeg, .gif, and .png files. 

Line
Lines are graphical elements that you can place anywhere on a page. A line is defined with a start and end point and can have a number of styles (for example, weight and color) assigned to it. A line has no data associated with it. 

Rectangle
Rectangles can be used in two ways: as a graphical element and as a container for other report items. When you place report items within a rectangle, you can move them with the rectangle. This is useful for keeping numerous text boxes and other items together in a report. 

Subreport
A subreport is an item in a report that points to another report on the report server. The report that the subreport refers to can be a full report that can also run on its own, or it can be a report that looks best when embedded within the main report. When you define a subreport, you can also define parameters to filter data in the subreport.

When deciding whether to use a subreport, you may want to consider using a data region instead. Because the report server processes each instance of a subreport as a separate report, performance can be an issue. Data regions provide much of the same functionality and flexibility as subreports, but with better performance.


Item Properties
All items in a report, including groups, table and matrix columns and rows, the above items, and the report itself, have properties associated with it. These properties govern the appearance and behavior of the item. 

Providing User Interactivity
You can design reports that provide users with a way to interact with the data. In environments that support interactivity, such as HTML 4.0, users can select parameters to filter data, click links that take them to other reports, expand and collapse rows in a table or matrix, or use a document map to navigate through the report.

Parameters
You can use report parameters to solicit values from the user. These values can be passed to a parameter in a query, passed to a filter, or they can be used in expressions within the report. A report parameter can provide a simple text box into which a user types a value, or it can provide a list of valid values from which the user must choose. This list can be static, or it can be updated dynamically with data from a dataset.

You can also define a default value to be used by a report when it runs, which can be a static value or one retrieved from a dataset. 

Filters
You can use filters to filter report data after it has been retrieved from the data source. You can place filters on datasets and data regions. 

Filters are different than query parameters in that when you use a query parameter, the returned data is filtered at the source. When you use a filter, the entire data set is retrieved, and then the filter is applied to retrieved data. This is useful for snapshot reports, in which the data is retrieved and stored with the snapshot report. Using filters, you can still limit the data the report displays, while still using the static snapshot data. Filters are also useful when the data source does not support the use of query parameters to filter data.


Links
You can also add links to a report. When you add a link to a text box or image, you can specify one of three types of links: 

A drillthrough report link provides a link to another report on the report server, and can pass parameter values to the report. 
A link to a URL provides a link to a Web page, typically outside the report server. 
A bookmark link provides a link to a bookmark, or anchor, within the current report. 

Hiding Items
Each item in a report has a set of properties that determine whether the item is visible or hidden. You can use these properties to hide items on a report, conditionally hide data based on other data in the report, and provide an item that the user clicks to toggle items between visible and hidden. For example, you can create a drilldown report that shows summary data when the report is first loaded and shows detail rows when users click a particular text box. 


Document Map
Another way a user can interact with a report is through a document map. In HTML Viewer, a document map appears as a table of contents next to the report. Users can click an item in the table, and the browser jumps to that item in the report. 

To add items to a document map, you associate a document map label with each item. 


Reporting Services Programming
You have several programming opportunities available to you through Microsoft® SQL Server™ Reporting Services. You can use the existing features and capabilities of Reporting Services to build custom reporting and management tools into Web sites and Windows applications, or you can extend the Reporting Services platform.

Extending the Reporting Services platform includes creating new components and resources that can be used for data access, report delivery and more. You can market these components and resources to companies that are using Reporting Services in their organization.

Introducing Reporting Services Programming
Reporting Services provides a full-featured set of APIs that you can use to integrate Reporting Services with custom business applications and extend its functionality. The following sections summarize the programmable aspects of Reporting Services.

Full-Featured Web Service
The Reporting Services Web service provides a single entry point to the full functionality of the report server. The Web service uses Simple Object Access Protocol (SOAP) over HTTP and is designed to act as a communications interface between client programs and the report server. The Web service and its methods expose the functionality of the report server and allow you to create custom tools for any part of the report lifecycle, from management to execution. For more information about developing applications using the Reporting Services Web service, see Reporting Services Web Service.

URL-Based Commands
Reporting Services supports a rich set of URL-based requests that you can use as a quick and easy access point for report navigation and viewing. You can use this technology in conjunction with the Reporting Services Web service to integrate a complete reporting solution into your custom business applications. URL access is particularly useful when integrating reports as part of a Web portal or when viewing reports from a Web browser. For more information about accessing reports using URL access, see URL Access.

Comprehensive WMI Provider
The Reporting Services WMI provider is built on standard Windows Management Instrumentation (WMI) technology for accessing control and management information in an enterprise environment. The WMI provider for Reporting Services serves as an instance provider, mapping the Report Server XML configuration elements to a series of classes, which include methods that you can call to add, remove, or modify report server configuration information. The Reporting Services WMI provider is an excellent tool with which to build customized report server management applications. For more information about using the WMI provider, see Using the Reporting Services WMI Provider.

Modular Extensions
The modular architecture of Reporting Services is designed for extensibility. A managed code API is available so that you can easily develop, install, and manage extensions consumed by many Reporting Services components. You can create assemblies using the Microsoft .NET Framework and add new Reporting Services rendering, security, delivery, and data processing functionality to meet your evolving business needs. For more information about creating and implementing Reporting Services extensions, see Extending Reporting Services.

Report Definition Language Programming
Report Definition Language (RDL) is a set of instructions that describe layout and query information for a report. RDL is composed of Extensible Markup Language (XML) elements that conform to an XML grammar created for Reporting Services. RDL describes the XML elements, which encompass all possible variations that a report can assume. You can add your own custom functions for controlling report item values, styles, and formatting by accessing code assemblies from within report definition files. Moreover, RDL can be generated programmatically. You can build third-party tools and applications that generate RDL in much the same way that Report Designer generates RDL. For more information about using custom assemblies with reports, see Using Custom Assemblies with Reports. For more information about generating RDL with custom applications, see Generating Report Definition Language Programmatically.

Integrating Reporting Services into Applications
Reporting Services is an open and extensible reporting platform, designed to provide developers with a comprehensive set of APIs for developing solutions built on Reporting Services. There are two options for integrating Reporting Services into custom applications: URL access and the Reporting Services Web service, also known as the Reporting Services SOAP API. You must decide how your application will use the report server technology and what functionality you will be providing your users before you can settle on a programming approach. Certain facets of Reporting Services programmability are better suited for particular integration scenarios. For example, if your application requires only that users view and navigate individually rendered reports, you should consider using URL access. Direct URL access provides report navigation functionality in a Web browser or supported HTML viewer. It is the fastest, most efficient way to render reports. URL access does not use the Web service interface, but rather provides direct access to the server. URL access is straightforward, quick, and efficient. It is your best choice for integrating the viewing of reports into your applications.

The Web service provides similar rendering and viewing capabilities through a variety of Web operations. However, the Web service provides additional functionality for managing the contents of a report server through an extensive set of Web methods that are not available through URL access. For scenarios in which the management of reports, subscriptions, data sources, and other report server database items is a requirement, the Web service is the best integration choice. The Web service is a single entry point to the full report-management functionality of the report server.

In some cases, integrating Reporting Services into your custom business applications requires a combination of the two programming approaches. Report Manager, the report access and management Web application that is included with Reporting Services, is an example of one such application. Report Manager is a comprehensive report viewing and management tool. Report Manager uses Web service methods to enable users to create and manage reports, folders, linked reports, report history, schedules, data sources, and subscriptions. Users can also use Report Manager to set properties, report parameters and to manage role definitions and assignments that control user authentication. Whereas the Web service is used to provide access to management functionality in Report Manager, report viewing and navigation is accomplished through URL access. Report Manager is one such application that uses the versatility and comprehensiveness of the Web service methods for report management and the efficiency of direct URL access for report viewing.

Reporting Services Web Service
The Reporting Services Web service is an Extensible Markup Language (XML) Web service with a Simple Object Access Protocol (SOAP) API. You can use the Web service to add the functionality of Reporting Services to your business applications.

Introducing the Web Service
Microsoft® SQL Server™ Reporting Services provides a single entry point to the full functionality of the report server: the Reporting Services Web service. The Web service uses Simple Object Access Protocol (SOAP) over HTTP and acts as a communications interface between client programs and the report server. The Web service and its methods expose the functionality of the report server and allow you to create custom tools for any part of the report life cycle, from management to execution.

There are three primary ways to develop Reporting Services applications based on the Web service. You can: 

Develop applications using Visual Studio .NET and the .NET Framework SDK. For more information about using the .NET Framework to build Web service applications, see Building Applications Using the Web Service and the .NET Framework. 
Develop applications using the rs utility (RS.exe) tool, the Reporting Services script environment. With Reporting Services and Visual Basic scripts, you can run any of the Reporting Services Web service operations. For more information about scripting in Reporting Services, see Scripting with the rs Utility and the Web Service. 
Develop applications using any SOAP-enabled set of development tools. For more information, see The Role of SOAP in Reporting Services. 

Programming Diagram

Web Service Features
The Reporting Services Web service encompasses several categories of methods that are based on component features. These methods are members of the ReportingService class, which is generated through a proxy class tool such as wsdl.exe that ships with the Microsoft .NET Framework SDK. For more information about the Reporting Services Web service and the .NET Framework.

The Role of SOAP in Reporting Services
The Reporting Services Web Service uses Simple Object Access Protocol (SOAP) messaging to send text-based commands over a network. These commands take the form of XML text that is sent over the World Wide Web using HTTP. By using SOAP as its communication protocol, the Reporting Services Web service allows applications and components to exchange data with the report server using an open and widely accepted infrastructure. The SOAP standard is defined at http://www.w3.org/TR/SOAP.

Any client application can act as a SOAP client as long as it is SOAP-aware and can send SOAP requests. Report Manager is one such SOAP client. It provides an interface to the report server database in which all reports and report-related content is stored. End users can use the application to browse through and manage reports and folders in the report server namespace. Report Manager is built on the Reporting Services Web service infrastructure.

A report server acts as a SOAP server, a SOAP-aware service that can accept requests from SOAP clients and create appropriate responses. The server handles the requests and sends encoded responses back to the client.

SOAP messages in Reporting Services take many different forms, depending on the type of request made by the client. The following example represents a simple SOAP client request to remove an item from the report server database:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<DeleteItem xmlns="http://www.microsoft.com/sql/ReportingServer">
<item>/Samples/Report1</item>
</DeleteItem>
</soap:Body>
</soap:Envelope>
The SOAP itself requires that messages be put into an envelope, with the bulk of the message inside a Body element. In this example, the body contains a call to the DeleteItem method, which takes a string parameter representing the path of the item to delete. You can create a .NET client proxy class that encapsulates all SOAP operations into methods. The following C# method represents the SOAP example given earlier:

public void DeleteItem(string item);
The response from the server might look like the following:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<DeleteItemResponse xmlns="http://www.microsoft.com/sql/ReportingServer" />
</soap:Body>
</soap:Envelope>
The DeleteItem method as part of a proxy class has no return value, so an empty response is returned. 

Accessing the SOAP API
The Reporting Services Web service is an XML Web service with a Simple Object Access Protocol (SOAP) API that consists of methods and a set of complex type objects that you can use to access the complete functionality of Reporting Services. To call the service, you must reference the Reporting Services Web Services Description Language (WSDL).

Referencing the Reporting Services WSDL
To call a Web service successfully, you must know how to access the service, what operations the service supports, what parameters the service expects, and what the service returns. WSDL provides this information in an XML document that can be read or processed by a computer.

WSDL can be consumed by development kits that support SOAP and Web services, such as the Microsoft .NET Framework SDK.

The following examples shows the format of the URL to the Reporting Services WSDL file:

http://server/reportserver/ReportService.asmx
The following table describes each element in the URL.


URL element Description 
server The name of the server on which the report server is deployed. 
reportserver The name of the folder that contains the XML Web service. This is configured during setup. 
ReportService.asmx The Uniform Resource Indicator (URI) to the Reporting Services Web service.. 

User Requirements for Web Service Development
Developing applications using the Reporting Services Web service requires: 

• A deployment computer that has Internet Information Services (IIS) 5.0 or higher, a network connection, the capability to send requests using SOAP 1.1 and HTTP 1.1 protocols, and the capability to parse XML. 
• Microsoft Internet Explorer 5.5 or later installed on a computer with an Internet connection to access the report server. 
  Microsoft Visual Studio .NET or the Microsoft .NET Framework SDK installed on a computer if you want to develop and deploy Reporting Services applications using the Microsoft .NET Framework. 
• An in-depth understanding of Microsoft Reporting Services features and capabilities. 
  A firm understanding of SOAP and XML Web services. 
• Development experience in a .NET Framework language such as C# or Visual Basic, if you plan to use the .NET Framework as your development platform. 
  

Building Applications Using the Web Service and the .NET Framework
With the Microsoft® .NET Framework, you can use familiar programming constructs, such as methods, primitive types, and user-defined complex types to work with Web services. The .NET Framework contains an infrastructure and tools you can use to create Web service clients that can call any World Wide Web Consortium (W3C) standards-compliant Web service.

A Reporting Services Web service client is any component or application that communicates with a report server using Simple Object Access Protocol (SOAP) messages.

To create a Reporting Services Web service client using the .NET Framework, follow these basic steps: 

Create a proxy class for the Web service. 
To do this, add a proxy class or Web reference to your development project, reference the proxy class in your client code, and create an instance of that proxy. For more information, see Creating the Web Service Proxy. 

Authenticate the Web service client with the report server. 
To do this, set the service object's Credentials property equal to the credentials of an authenticated user on the report server. For more information, see Web Service Authentication. 

Call the method of the proxy class corresponding to the Web service operation that you want to invoke. 
To do this, call a Web service method and supply the necessary arguments. For more information about the Web service methods, see Web Service Features. For more information about calling the methods, see Calling Web Service Methods. 

For a step-by-step walkthrough explaining how to access the Reporting Services Web service, see Walkthrough – Accessing the Reporting Services Web Service Using Visual Basic or Visual C#.

URL Access
The report server is accessible through URL requests. URL requests contain parameters that are processed by the report server. The way in which the report server handles URL requests depends on the parameters, parameter prefixes, and type of item that are included in the URL. For more information about specific parameter prefixes, see Using Parameter Prefixes on a URL.

You can use URL access to embed hyperlinks to reports and other report server items in the applications that you develop. Report server URLs adhere to the URL formatting guidelines as proposed by the joint World Wide Web Consortium W3C/IETF draft standard. URL access is compatible with most Internet browsers or applications that support standard URL addressing.


URL Access Syntax
You can access the report server by using a URL. URL requests can contain multiple parameters that are listed in any order. Parameters are separated by an ampersand (&) and name/value pairs are separated by an equal sign (=). 

Syntax:    http://server/virtualroot?[/pathinfo]&prefix:param=value[&prefix:param=value]...n]

Arguments
server 
The name of the computer on which the report server is running. 
vitualroot 
The name of the virtual root of the report server. 
? 
Denotes the item path and parameter portion of the URL. 
[/pathinfo] 
The full path name of the item being accessed in the report server database. 
& 
Used to separate name and value pairs of parameters 
prefix 
Optional. A parameter prefix that accesses a specific process running within the report server. If a parameter prefix for a parameter is not included, the parameter is processed by the report server as a report parameter. 

Note If you include a report parameter in a URL, do not preface the report parameter with a parameter prefix.

param 
The parameter name. 
value 
URL text corresponding to the value of the parameter being used. 
Example
The following example renders a report in the HTML 4.0 format:

http://servername/reportserver?/SampleReports/Employee Sales Summary&rs:Command=Render&rs:format=HTML4.0

Note Any space characters in the URL string are replaced with the characters "%20," according to URL encoding standards. Similarly, a space character in the parameter portion of the URL is replaced with a plus character (+) and a semicolon in any portion of the string is replaced with the characters "%3A." Browsers should automatically perform the proper URL encoding. You do not have to encode any of the characters manually.