Concepts Guide
|
 |
 |
|
 |
 |
This section describes data services, the fundamental components of the Liquid Data integration layer. The following topics are covered:
A data service is the Liquid Data component that gives data users access to structured information. Typically, a data service models a unit of information in an enterprise, such as a customer, sales order, or product. The set of data services collectively comprise the data integration layer in an IT environment.
In concrete terms, a data service is a file with a .ds extension that contains XML Query Language instructions for querying and transforming data for data consumers. In many ways, a data service is no different from a conventional Web service. It is modular and reusable. It has a contract made up of public functions for accessing its services. It conceals the details of the service implementation—in this case, generally involving data acquisition and transformation—from the user
However, unlike a conventional Web service, at the core of each data service is an XML data type (shown in the Design View in Figure 3-1). When it acquires and integrates data in response to a request of a data user, the data service transforms the data into the shape defined by the XML data type. The purpose of a data service is to give data consumers access to information in the format of this XML data type.
A service consumer—a client application or another data service—uses read functions defined for the data service to get its information. It can also call a navigation function to get information from a related data service, typically passing an instance of the current data service as an argument. A data service can have any number of read and navigation functions.
Figure 3-1 Workshop Representation of a Data Service
In addition to transforming data as prescribed by its target XML schema, a data service can operate on the data in other ways as well. It can perform mathematical calculations on numeric data, for example, or concatenate text strings. Whatever data-oriented operations you would like to be performed in order to provide a uniform, useful view of the data for its consuming applications can be encapsulated by a data service.
A data service function allows clients to get data from a data service. The data service interface consists of the public functions of the data service, which can be of several types:
Keep in mind that—in accord with the aims of SOA—data services in general (and Liquid Data functions in particular) are intended to provide "course grain" access to data. Coarse grain access alleviates clients from having to identify and aggregate information that collectively makes up a distinct business entity.
In addition to public functions, a data service can have private functions. Private functions can be used only by other functions within the data service. They generally contain common processing logic, that is, operations for use in more than one function in the data service.
For auxiliary functions of interest across multiple data services, you can use function libraries. A function library (.xfl extension) contains operations that can be called from various data services.
Read functions on a data service can be defined to return information in various ways. For example, the data service may define read functions for getting all customers, customers by region, or customers with a minimum order amount.
However, data users often want to access information in ways that are not entirely pre-specified or limited by the design of a data service. The filtering and ordering API allow client applications to control further what data is returned by a data service read function call based on conditions specified at runtime. Instead of having to create a read function for every possible client requirement, the service designer can create generalized read function against which clients can apply their own filtering or ordering conditions at runtime. It is left to the service designer to decide whether to create a narrowly-defined read functions, with access conditions built into the interface, or to create more generic read functions and allow the client to specify filtering conditions.
Between acquiring data from backend systems and presenting that data to clients, a data service usually transforms the data in some way. The nature of the transformation is determined by the XQuery body of the called function.
Transformations can involve simple element mappings, more general shape transformations, data joins, or value modifications by string operators, mathematical operators, or date operators. The structure and data in a transformation can be controlled by logical constructs such as if-then-else statements. The transformation may join data from multiple sources or filter data.
The XQuery Editor (shown in Figure 3-2) enables you to create a transformation query by dragging and dropping nodes between source and target schemas. A target schema is the XML type of the data service, that is, the shape of the data (in XML schema) returned in response to service requests.
Figure 3-2 Graphical XQuery Transformation Designer
The internal language of a data service, XQuery (short for XML Query Language), is an emerging standard language for querying XML-based information. XQuery has many features in common with SQL, such as where clauses. However, unlike SQL, which was intended for working with simple two-dimensional data format (rows and columns), XQuery is designed to work with the richer, Web service data that uses the nested structure approach of XML.
The XQuery functions in a data service determine what data is acquired by the service and how it is transformed. But the transformation is not limited to the format of the data—it can also affect the data value itself, for example, by concatenating strings or calculating mathematical operations on numeric values.
A significant challenge for enterprises is not only in integrating disparate data sources, but in advertising the availability of data in a consistent way. If potential users of a data source do not know it exists, the data is effectively lost. Once a developer has gone to the trouble of creating a unified Customer data service, for example, other developers need to be able to discover and reuse it for their own work.
Liquid Data uses a set of data service descriptors (or metadata) to provide information on data services. The metadata describes the data services—what information they provide and where the information comes from (that is, its lineage).
In addition to documenting services for potential consumers, metadata helps administrators determine what services are affected when inevitable changes occur in the data source layer. If a database changes, the administrator can easily tell which data services are affected by the change.
When changes do occur, a metadata synchronization wizard helps you to absorb data source level changes into the data services layers. The wizard, which is launched from Workshop, detects disparities between the schema of the data source and the physical data services. It highlights differences and allows them to be incorporated with a few clicks.
Those interested in metadata can access it in several ways. The metadata browser (shown in Figure 3-3) provides an HTML interface for browsing and searching metadata in various ways. Also, an API provides programmatic access to the same information.
|
|
|
