details from its consumers. In ODSI, the required merging and mapping of lower-level data services to create higher-level services is achieved by function composition using the XQuery language. 9 (This is very much like defining and layering views in a relational DBMS setting.) Because data service architects often prefer graphical tools to handwriting queries, ODSI provides a graphical query editor to support this activity; the sidebar “Integrated Data Services” describes its usage for this use case in a bit more detail for the interested reader.

Stepping back, Figure 3 depicts a declarative approach to building data services that integrate and service-enable disparate data sources. The external model is a functional model based on XQuery functions. The approach is declarative because the integration logic is specified in a high-level language— the integration query is written in XQuery in the case of ODSI. Because of this approach, suppose the resulting function is subsequently called from a query such as the following, which could either come from an application or from another data service defined on top of this one:

 

for $cust in ics:getAllCustomers( ) where $cust/State = ’Rhode Island’ return $cust/Name

In this case, the data services platform
can see through the function defini-
tion and optimize the query’s execu-
tion by fetching only Rhode Island
customers from the relational data
source and retrieving only the orders
for those customers from the order
management service to compute the
answer. This would not be possible if
the integration logic was instead en-
coded in a procedural language like
Java or a business process language
like BPEL. 32 Moreover, notice that the
query does not request all data for cus-
tomers; instead, it only asks for their
names. Because of this, another opti-
mization is possible: The engine can
answer the query by fetching only the
names of the Rhode Island customers
from the relational source and alto-
gether avoid any order management
system calls. Again, this optimization
is possible because the data integra-
tion logic has been declaratively speci-
fied. Finally, it is important to note
that such function definitions and
query optimizations can be composed
and later decomposed (respectively)
through arbitrary layers of specifi-
cations. This is attractive because it
makes an incremental (piecewise)
data integration methodology possi-
ble, as well as allowing for the creation
of specialized data services for differ-
ent consumers, without implying run-
time penalties due to such layering
when actually answering queries.

figure 4. Data services and cloud storage.

Cloud Data Service API Key/Value Stores

43 NY 14260

43

93

… clip.mpg ……

Sparse Tables

Customers cid state zip …

43 NY

93 14260

… …

SQL RDBMS

Customers cid state zip

43 NY 14260

… …

Cloud Data services

We have described how an enterprise
data source or an integrated set of data
sources can be made available as ser-
vices. Here, we focus on a new class of
data services designed for providing
data management in the cloud.a
The cloud is quickly becoming a
new universal platform for data stor-
age and management. By storing data
in the cloud, application developers
can enjoy a pay-as-you-go charging
model and delegate most administra-
tive tasks to the cloud infrastructure,
which in turn guarantees availabil-
ity and near-infinite scalability. As de-
picted in Figure 4, cloud data services
today offer various external data mod-
els and consuming methods, ranging
from key-value stores to sparse tables
all the way to RDBMSs in the cloud. In
terms of consuming methods (see
Figure 1), key-value stores offer a sim-
ple function-based interface, while
sparse tables are accessed via queries.

More Expressive Query Language

a These service descriptions were current as of mid-2011.