Using web services as an API to WSS and SPS

Using web services as an API to WSS and SPS

When you want to access SPS or WSS functionality from your application you have three choices.

All of them have some advantages and disadvantages but I think that Web services would be the easiest, most flexible, secure and extendable way to work with sharepoint from your application. It’s very easy to extend web services if you need some additional functionality.

Here are three choices you have to talk to SharePoint from your application.

1. Access the SQL server WSS databases directly. In this case you use the SQL queries to the databases used by SharePoint to get the information about SharePoint site. This method is kind of “hacking” of the SharePoint services and because of that most dangerous. But sometimes this is the only way to get necessary information. For example to start using WSS object model you need to know the URL of the root WSS site. But since all WSS sites don’t know about each other the easiest way is to get them directly from the _Sites DB. Besides this method is definitely the fastest one.
2. Use the WSS and SPS object model. The namespaces: Microsoft.Sharepont (for WSS) and Microsoft.Sharepoint.Portal have a lot of classes that allows to accomplish almost any task but you always have to keep in mind the security issue: You can compile your code on your development environment if you have all necessary assemblies but you can’t run if you don’t have WSS and SPS installed. To run against the production SharePoint services you have to install your code on production server. Even after that your application have to have rights to access the SharePoint services and it means that most probably you will have to impersonate the whole Web application or use Windows API to impersonate calls to SharePoint object model.
3. Use WSS and SPS web services. If you use web services you can put your code on any server, you can debug your code in your developing environment against the production SharePoint services. What you will need is just impersonate the calls the web services that are more secure than impersonate the whole application. You can easily switch between different SharePoint servers by just switching URLs to the web services; you don’t need to redeploy the entire application to the different server. The web services is very easy to extend, you just deploy your .asmx files to the virtual _vti_bin folder of and your .dll files to _vti_bin /bin folder.

All web services are located in the same location relative virtual path that is Site_Root_vti_Bin for example http://www.My_WSS_Site.com/_vti_bin.

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

In your application you just need to is to replace the default user credentials and URL in the proxy generated by VS 2003:

For example for alerts services:

Alerts.Alerts AlertsService = new Alerts.Alerts();

// the user credentials to use

AlertsService.Credentials = new NetworkCredential(UserName, Password, Domain);

AlertsService.Url = SharePointHost + AlertsServiceName;

Alerts.Alerts is the proxy class generated by VS 2003.

SharePointHost is the site root

AlertsServiceName is the relative path to the Alerts web service, which is _vti_bin/Alerts.asmx.

Here is a very good article about Web services that contains downloadable demo code that I used in my project:

http://www.csharphelp.com/archives4/archive602.html