title: How to render a report using the ReportService2010 namespace
body: <p>I'm working on a project where we will be interacting with the ReportService2010 reporting web service under SQL Server 2008 R2.  In the past, I've worked with the ReportService2005.asmx, and my problem here is, I can't find any reasonable examples on how to render a report with this new (2010) reporting web service.</p>
  
  <p>When using the 2005 web service, there was a "Render" method that was provided when creating your proxy with the wsdl.exe utility.  Is there an equivalent method (or set of methods), to accomplish the same thing using the ReportService2010 service?  Or are there any decent examples of an end-to-end intialization and calling of the new proxy?</p>
  
  <p>Even MSDN doesn't have much information, and in certain parts of the ReportService2010 API docs, there are old snippets of code that were only applicable to the 2005 web service.</p>
  
  <p>UPDATE:  A better question might be how have things changed between SSRS 2008 and SSRS 2008 R2 with regard to calling the report service(s) programmatically...I can see that even under SSRS 2008 R2, there still exists a ReportService2005.asmx, as well as a ReportExecution2005.asmx, but there is not a corresponding ReportExecution2010.asmx.</p>
  
  <p><em>sigh</em></p>
  
  <p>SOLUTION UPDATE:<br>
  After talking to someone at my company, I was informed of the following:</p>
  
  <ol>
  <li>The 2006 web service was introduced to support sharepoint integration in 2008.</li>
  <li>The ReportService2010 web service was introduced to merge all the functionality introduced by 2006 with the 2005 web service.</li>
  <li>ReportService2005 web service will continue to be used for report execution.  I don't know why, but something tells me it has to do with business decisions for backwards compatibility.  My coworker said we are intended to continue to use ReportExecution2005 for rendering, and ReportService2010 for all other functionality (querying the SSRS server for reports, params, etc).</li>
  </ol>
  
  <p>Unfortunately all the above information was culled from a variety of links, none of which concisely stated all of the above.  It's the kind of thing that you would normally assume a vendor to explain to client developers.</p>