More and more often, up-to-date applications cannot exist in a compartment mode; they constantly interact with the outer world. That is why mechanisms of interaction with other applications are becoming an important part of most of them. Recently interactions between applications are based on XML or other open standards. It gives an opportunity to integrate applications built on different platforms.

In this article one of the platforms to build service-oriented applications ADO.NET Data Services is considered. This platform allows building data access services based on REST methodology with a convenient way.

SOAP and REST are two main approaches to web services construction. Both approaches solve similar problems – the question of distributed systems construction. But they do it in different ways.

SOAP/WS-* approach is used in web services built on the basis of ASP.NET or WCF. There are also other platforms to build SOAP-services. It is supposed that SOAP-service is focused on operations performance. To access to a web service a SOAP-request is generated on the client side and is sent a server. On a server side this request is processed, the operation is preformed and the SOAP-answer comes back. In a SOAP-request there is a method name that should be started on a service side and its parameters. A SOAP-response contains a result of these techniques and, if necessary, output parameters.

It is supposed, that SOAP-messages are data in XML format. However, some platforms propose an alternative way to encode SOAP-messages. For example, Windows Communication Foundation does in a binary format.

REST approach is greatly different. It is focused on getting data from a web service and their modification, unlike SOAP that is focused on operations. This is the reason of REST-services    limitation to work via HTTP/HTTPS that makes it possible to address data modeling address to access a web service. In this case there is no need to build a SOAP-request to access a service, it is necessary to call a defined URI.

Both of these approaches exist together without impeding each other now. They are intended for not the same tasks. The difference between REST and SOAP is evident and it is very important to understand a purpose of each of these approaches and use them according to a designated one. SOAP approach is what you need when any operation should be performed on a service side. For example, to withdraw money from your bank account or do an order in online stores. However, if a web service work is just getting data access from a service and their modification, it is better to use REST approach. For example, it can be a web-service that allows us to get information about goods in an Internet shop.

ADO.NET Data Services is a platform to build services based on REST-approach. It is a complex tool which allows construction of a complicated REST-service thanks to usage of an "out of box" in several minutes.

As it has already been said, REST-services work via HTTP/HTTPS. ADO.NET Data Services work is also based on this protocol. Besides that, a universal syntax URI is supported there. It allows us to address any part of the information from a data model. This is the reason of unavailability to modify format of URI working with web service.

To create a new web service based on ADO.NET Data Services it is necessary to have a ready-made data model. It can be LINQ to SQL, ADO.NET Entity Framework or another data model. As a model of data is ready, you should use tools of Visual Studio to add a new web service in a web application.

Figure 1: Creation ADO.NET Data Services web-service

When you create a service it represents as an inheritor of DataService generic-class. In a generic-parameter it is necessary to specify a type which defines a data context. As a result of a service creation, a static method InitializeService, which is required to configure a web service, appears. An object of IDataServiceConfiguration type, which allows us to change service options, is sent as parameters of this method. Thanks to first acquaintance with ADO.NET Data Services it is necessary to grant full access rights to all collections in data models. In real projects you should specify containers explicitly and they will be accessible via a web service. Thus, the code of a service which gives access to a data model will look as follows.

Listing 1 - Definition of simple web-service

public class WebDataService1 : DataService<NorthwindEntities>
{
      public static void InitializeService(IDataServiceConfiguration config)
      {
            config.SetEntitySetAccessRule("*", EntitySetRights.All);
      }
}     

As a result of access to a service it will generate an answer in AtomPub format. This response will contain a list of accessible tables.

Figure 2: Response from web-service

You can access to any tables of this data model now thanks to changing address. For example, access to the address "http://localhost:9580/WebDataService1.svc/Customers" allows us to receive the list of objects from the table "Customers." When you specify values of a primary key in parentheses, you can get access to a single entity. For example, getting access to the address "http://localhost:9580/WebDataService1.svc/Customers('ALFKI ')" web service will return data only for one entity. More over, it is possible to refer to a field of this entity. To do this you need to specify a name of a field after the slash. For example, you can apply to field "CompanyName" using the address "http://localhost:9580/WebDataService1.svc/Customers('ALFKI') / CompanyName."

Operations of data sets manipulation - sorting, filtration and paging - are accessible on a server side. For these purposes use operators "$orderby," "$filter," "$top," and "$skip." Here we have some examples.

Listing 2 - Sample queries to web-service

/Bookmarks?$orderby=Name
/Bookmarks?$filter=Created gt '2007-05-07'
/Bookmarks?$top=10&$skip=30

Building a service side is only half of a work. An important part is client building. To create a client within .NET applications you can use "Add Service Reference" wizard.

Figure 3: "Add service reference" window

A proxy-class will be generated on a client side as a result of adding a link to a service. This class will translate accesses to the web service and work with them like with a simple collection.

Listing 3 - Sample of client code

var client = new NorthwindEntities(new 
      Uri(@"http://localhost:9580/WebDataService1.svc/"));
foreach (Customers customer in client.Customers)
{
}

In this service all collections implement IQueryable interface. For this reason you need to create a LINQ-queries to these collections; they will be transformed into URI which corresponds to ADO.NET Data Services syntax. For example, you can get a sample page using syntax of LINQ.

Listing 4 - Sample of paging

var client = new NorthwindEntities(new Uri(@"http://localhost:9580/WebDataService1.svc/"));
var query = client.Customers.Skip(40).Take(20);
foreach (Customers customer in query)
{
}

At execution of a similar inquiry, it will be transformed in corresponding URI. It is well visible at the debugging of this code.

Figure 4: Transformation of LINQ-query

After execution of a query, the service returns data in AtomPub format that will be parsed by a client and presented as objects.

As it has been mentioned above, a data source for a web service is an objective model of a data serves. When a web-service handles a client request it works with data provided by this model.

By default, as a data source model, ADO.NET Entity Framework or LINQ to SQL is used. These platforms allow us to give access to relational data without any additional efforts. The only thing you should do to use this model is to specify it in generic-parameter when you organize inheritance from a general base class.

However, there are case when it is impossible to use these approaches. In practice, sometimes you need to use another type of OR/M platform or to give access to nonrelational data. In this case ADO.NET Data Services architecture is very flexible.

To create your own data source you should build a simple class. There is no need to inherit it from standard classes or implement some interfaces in it. This class should contain public properties which return objects of type IQueryable<>. This condition is enough to make the model readable.

An entity passed through web service should have a key field. This key field is defined automatically if there is "ID" or "EntityTypeID" name ("EntityType" is a name of an entity). If a name of a key field differs from the given scheme, it is necessary to mark entity with DataServiceKey attribute where you need to specify a name of a key field in its container.

Listing 5 - The key field defining

[DataServiceKey("ID")]
public class Data
{
      public int ID { get; set; }
      public string Name { get; set; }
}

The described approach allows us to create only readable data models. In order to be able to modify data in a model, it is necessary to implement the interface IUpdatable. As a part of this interface there are descriptions of methods that allow us to apply changes.

In this article ADO.NET Data Services platform was observed which allows us to build web services in REST style conveniently. It is important to notice that creation of such web service does not depend on the size of a data model and is very simple. Following these simple steps to create a web service, you can get great functionality. Moreover, ADO.NET Data Services allows you to control access at an entity level, set the security rules, organize flexible tune a service, etc.  Thus, ADO.NET Data Services is a powerful platform to create web services which allow us to work with data. And all this power can be already used today in real projects.