ents is performed during each service request based on the model mapping of the data service. The information used to guide this mapping is provided at design time by the data service implementer. The syntax in which data service output is returned to clients varies from JSON31 to XML to AtomPub, 28 as shown in Figure 1.

A last point that needs clarification is how the external model is made available to the clients of data services. Apart from their regular data-returning functions and queries, data service frameworks generally provide a set of special functions and queries that return a description of the external model in order to guide clients in consuming a service’s interconnected functions and/or queries in a meaningful way.

In contrast, traditional Web services have a much simpler architecture: they are purely functional and their implementations are opaque. Some traditional Web services rely on WSDL19 to describe the provided operations, where the input messages accepted and the output messages expected are defined, but these operations are semantically disconnected from the client’s point of view, with each one providing independent functionality. Therefore, the presence of a data model is distinctive to data services.

 

service-enabling Data stores

In the basic data service usage scenario, the owners of a data store enable Web clients and other applications to access their otherwise externally inaccessible data by publishing a set of data services, thus service-enabling their data store. Microsoft’s WCF Data Services framework35 and Oracle’s ODSI38 are two of a number of commercial frameworks that can be used to achieve this goal. (A survey of such frameworks is beyond the scope of this article.)

To illustrate the key concepts involved in service-enabling a data store, we will use the WCF Data Services framework as an example. We show how the framework can be used to service-enable a relational data store ( although in principle any data store can be used.) Figure 2 shows a relational database that stores information about customers, the orders they have placed, and the items comprising these orders. The owners map this internal relation-

Data service
frameworks
generally provide
a set of special
functions and
queries that return
a description
of the external
model in order
to guide clients
in consuming
a service’s
interconnected
functions
and/or queries in a
meaningful way.

al schema to an external model that includes entity types Customer, Order and Item. Foreign key constraints are mapped to navigation properties of these entity types, as shown by the arrows in the external model of Figure 2. Hence, given an Order entity, its Items and its Customer can be accessed.

WCF Data Services implements the Open Data Protocol (OData), 37 which is an effort to standardize the creation of data services. OData uses the Entity Data Model (EDM) as the external model, which is an object-extended E/R model with strong typing, identity, inheritance and support for scalar and complex properties. EDM is part of Microsoft’s Entity Framework, an object-relational mapping (ORM) framework, 2 which provides a declarative mapping language and utilities to generate EDM models and mappings given a relational database schema.

Clients consuming OData services, such as those produced by the WCF Data Services framework, can retrieve a Service Metadata Document37 describing the underlying EDM model by issuing the following request that will return the entity types and their relationships:

 

http://<service _ uri>/ SalesDS.svc/ $metadata

 

OData services provide a uniform, URI-based querying interface and map CRUD (Create, Retrieve, Update, and Delete) operations to standard HTTP verbs. 22 Specifically, to create, read, update or delete an entity, the client needs to submit an HTTP POST, GET, PUT or DELETE request, respectively. For example, the following HTTP GET request will retrieve the open Orders and Items for the Customer with cid equal to C43:

 

http://<service _ uri>/ SalesDS.svc/ Customers(’C43’)/Orders? $filter=status eq ’open’& $expand=Items

 

The second line of the above request selects the Customer entity with key C43 and navigates to its Order entities. The $filter construct on the third line selects only the “open” Order entities, and the $expand on the