I recently completed a project in which I think I utilized every API and every extensibility point available within Sql Server 2005 Reporting Services and walked away from the experience feeling soiled, smelly, and dirty. This wasnt my first time exploring this territory, since my last job utilized Sql Server 2000 Reporting Services, and involved several custom data extensions and some custom "function assemblies" for creating barcodes an other custom functionality within from reports. However, this time I think i really gained a better sense of how close the whole system is to being really good and how disappointing it is that the Sql Server 2005 team seemed to focus more on new features than on improving the integration and extension story.
This time, my main area of interest and eventual angst was the Security Extension framework. I really like the ACL-based solution they went with. I can't speak highly of its performance, but from an integration viewpoint, I really like how it really decouples the eventual authentication and authorization framework from how it is mapped-on to the underlying Catalog Item's.
However, this framework quickly becomes incredibly chatty and expensive (frequent deserialization & lack of much caching) due to how granular and limited they made the API and eventual webservice methods that utilize this framework. If you throw a debugger on the Report Manager & Report Server websites and watch how many times it calls the LogonUser, GetPermissions, and CheckAccess methods for a single report-listing, its pretty incredible. I imagine that with a little work on the webservice API, you could include support for batching multiple requests, and potentially add a bit of smart-caching of ACL maps. Sadly, none of this appears to have improved from v1.0.
In addition, it shocked me was that there is no "in-box" support for Forms-Authentication. The best they could offer was a prebuilt sample extension that really is barely even a useful start beyond offering "an" example of how to build a Security Extension. Without the help from Teo Lachev's "Harden MS Reporting Services Using Custom Extensions" articles (especially Part 2) on DevX, I would have given up.
So, my first request to the Dev team at Microsoft is:
"Address the extension & integration story in the next version instead of just layering on more and more new features!!!"
Dont get me wrong, I think they did a great job with the concepts and implementation around SSAS integration, Custom Report Items, Report Models & Report Builder - in fact, I hope these technologies evolve into something really fantastic in the next version. BUT, the team's seemingly insatiable desire to catchup with the competing Business Objects' featureset appears to be causing them to neglect the core system. I respect Brian Welcker and what his teams have accomplished in such a short time, but someone please keep your eye on the ball here.
Another major concern I have is with the "Enterprise Focus" of Sql Reporting. Okay, I "get it" that Microsoft has focused on delivering for the Enterprise in a real way. But, some of these same enterprises also run internet sites, extranet sites, and other nontraditional intranet sites that could benefit from a reporting engine too. Yeah, I know your gonna say that the focus right now is on Office, Sharepoint, and intranet integration for workflow apps like those from K2 but why limit it to these areas? The engine just needs some tweaking to address the neccessary performance and scaleability neccessary to support using it on internet websites. If you accomplish that, then you have taken your customer base from just a few thousand enterprise clients, to hundreds of thousands of clients. Right now, the product's success is limited by; A) the number of Sql Server licensees, and B) the number of enterprise-level intranet sites that need reporting. My argument is that there are plenty of other customers who could benefit that you are ignoring by being so single-mindedly focused on your limited view of the "Enterprise space".
So, my second request is:
"Change your strategy from building only a enterprise intranet service to building a core engine for ANY reporting need in any sphere."
Okay, I can probably go on and on and on, but you get the point....
I recently wanted to retry the idea of using virtual development environments instead of developing locally on my PC so that I can have several pre-built development and test environments that are tailored to each deployment target. Having dabbled at this a couple times before, I already had some images available to use.
In the past, I was mostly using VMWare Workstation and the, now free, VMWare GSK Server. However, now that the equally free Virtual PC 2007 has RTM'd, I wanted to give it a try again. The only problem is that I dread the time required to install the OS, Sql Server 2005, VisualStudio.NET 2005, and various other dev tools again. So, I started looking for a way to convert my old VMWare images to Virtual PC images.
It seems that I'm not the only one to run into this problem. Solutions are now available via the VMDK to VHD Converter at vmToolkit.com, and an article by RoudyBob.NET on how to "Convert VMWare Images to VirtualPC 2004" that shows several methods of conversion mostly involving installing one virtualization technology within another virtual instance, or using a PC imaging software like Ghost from within the virtual instance.
Also, for going the opposite direction, VMWare Workstation 5(+) offers a VPW Image converter, or you can download the free VMWare Converter to convert any "real" PC to a VMWare image.