Several points
(1)
As you can consume SSRS as a webservice reference, you can create your business logic service than encapsulates working with the reports. You can get the EMF/PDF ..etc representation of the report using webservices and deal with it in your code. I really do not see any problems with SSRS user accessing some specific stored procedures of your DB directly. Usually reports do not intersect with application code
(2)
Another solution might be to use WebServices to generate the data for SSRS. With SSRS 2005-2008, you can use the XML provider to consume data from application's web services for your report and your business logic might provide these data to your reports.
http://msdn.microsoft.com/en-us/library/ms345334.aspx[
^]
(3)
In real life, most clients want way to quickly define and build their own reports. This is something SSRS is good at. You can create a dedicated readonly user that only has access to a set of predefined views of your DB that users can build their reports from. This will allow visitors to use built-in SSRS user functionality for data mining
Conclusion - there is no golden rule - everything depends on your project needs.
Submit an article or tip