Reporting might not be the sexiest DBA task, but it's essential for every company and every department that stores information in a database. Many people use front-end tools such as Microsoft Excel and Access to get reports from SQL Server and other databases. Microsoft also offers development tools that you can use to build your own reports. But strangely, Redmond has stayed out of the reporting space, ceding this lucrative market to a variety of third-party vendors—until now.
By the end of the year, Microsoft will roll out a new SQL Server product called Reporting Services that will let you manage the entire reporting life cycle, from authoring, to management, to delivery. The company says it developed Reporting Services in response to customers who've been asking for a reporting platform that is built on the Microsoft .NET Framework, integrates well with other Microsoft applications, works great with SQL Server and other database systems, and can be extended by third-party developers. Like many Microsoft offerings, Reporting Services—formerly code-named Rosetta and originally expected as part of the Yukon release of SQL Server—is designed as a platform play. Microsoft wants to own the core reporting platform while leaving enough gaps in the offering to encourage a rich vendor add-on and partner market, as we've seen develop in the larger SQL Server space and in the Analysis Services OLAP arena. Let's look at the three core areas of the reporting life cycle and see how Reporting Services fits in.
Report authoring. Reporting Services will provide a WYSIWYG designer for defining a report's layout. You'll also be able to lay out data in a variety of formats and create powerful banded reports that incorporate tabular and visual representations of data on the same printed page or online display.
However, Reporting Services' authoring capabilities run much deeper because Microsoft is publishing the XML-based Report Definition Language (RDL) that the product uses under the covers. With RDL exposed, Reporting Services becomes a genuine server platform that corporate IT shops and commercial software vendors can develop against. For example, vendors could create visual authoring environments for end users, who would then be able to create custom reports and integrate their existing reporting products with Reporting Services. Such add-ons, in fact, will be welcome because Microsoft's initial authoring support seems tailored more for developers and IT professionals than for end users.
Reporting Services will also let you easily create heterogeneous reports based on multiple data sources, including relational, flat file, and OLAP. Today, most people use manual processes of some sort to build their multisource reports. For example, you might paste data from multiple sources into an Excel spreadsheet before doing further pivoting or analysis on the integrated data sets. Of course, reporting products from such companies as Business Objects, Cognos, and Crystal Decisions make reporting from heterogeneous data sources easier, but these products are invariably expensive and lock users into a particular reporting platform paradigm. This is where RDL's openness becomes so important: You'll be able to easily extend the core Reporting Services' platform by using third-party tools or homegrown development efforts.
Report management. Report management encompasses scalability, security, and scheduling of reports. Microsoft implemented Reporting Services as a Win32 service that will allow multithreaded processing of complex reports that pull data from multiple data sources in parallel. This approach provides much better response time and throughput for complex reports than querying heterogeneous sources serially.
In addition, Microsoft built Reporting Services to be stateless with respect to user connections asking for reports. This statelessness will let you create a scalable Web farm of report servers that can service thousands or perhaps tens of thousands of connected users. IT architects will be able to deploy one logical image of a Reporting Services solution that could comprise multiple physical machines. Consider large telecommunications or utility companies that want to provide sophisticated reporting solutions to customers and deliver those reports through email or Web phones to home PCs. These companies might have more than tens of thousands of customers who all want to look at their monthly bill at the same time. Scalable reporting farms suddenly become an important architectural feature.
You'll be able to achieve additional scalability through Reporting Services' ability to provide on-demand reports that are either live or cached. A live report queries the underlying data source in realtime to retrieve data, whereas a cached report maintains a cached version of the report's data set for a defined period of time. Suppose that five users all want to run an expensive report. With cached versions of the report, your system could generate the data set once, then reuse that data set for the other four users requesting the same data. You could also use Reporting Services' scheduling capabilities to run the report every Monday at 8 a.m., then all users could simply grab the cached copy.
Prev. page
[1]
2
next page 
