by Manu Madhusudhanan R
Introducing a data services layer can dramatically reduce the challenges of integrating and aggregating data from disparate, distributed data sources. Making XQuery part of the solution can reduce even further the complexity of accessing this data. This approach is described in Integration Using Data Services. Let's now look at how the BEA AquaLogic Data Services Platform 2.0 (AquaLogic DSP 2.0) can help to achieve this. The AquaLogic DSP, formerly known as Liquid Data, is an Enterprise Information Integration (EII) solution that takes a data service layer-based approach to data integration. The data access layer is a virtual layer in the sense that, except for caching, data is not stored in any AquaLogic DSP or BEA WebLogic Server component. This article provides a brief introduction to the platform, followed by examples of how to model a data service, build a client, and configure the runtime behavior of the service.
This article assumes you have BEA WebLogic Server Service Pack 4 and AquaLogic DSP 2.0 installed on your computer.
The AquaLogic Data Services Platform 2.0 s part of the BEA AquaLogic Platform Suite. AquaLogic DSP uses the BEA WebLogic Server as a runtime platform and BEA WebLogic Workshop as a development environment for the data integration. The data service layer infrastructure provided by AquaLogic DSP can fetch/update data from multiple data sources, and consumers have local transparency regarding the origin of the data.
Data stewards can use the AquaLogic DSP-enabled WebLogic Workshop IDE to model different data sources and build the business logic around these virtual data sources (data services). These then can be deployed to WebLogic Server instances as an AquaLogic DSP application. Each application can contain multiple AquaLogic DSP projects and other applications like Web applications and portals. Users can have any number of AquaLogic DSP applications deployed on a WebLogic Server instance, where each deployment represents a different enterprise application.
The core of the AquaLogic DSP runtime component is the XQuery processing engine, a sophisticated, optimized distributed query processor with parallel execution capabilities. AquaLogic DSP is useful to data stewards because of the model-oriented WebLogic Workshop IDE, caching framework, fine-grained security framework, client APIs, and administration console, all of which are supported by a robust XQuery engine. This article discusses many of these features later. Figure 1 shows the architecture of AquaLogic DSP.
Figure 1. AquaLogic DSP architecture
Data integration is achieved by encapsulating interfaces to data sources, which we call data services. As I explained in my previous article, a data service is a file that contains XML Query Prolog (XQuery) instructions for retrieving, aggregating, and transforming data. An AquaLogic DSP project typically contains many data services.
Data modelers can model two types of data services in AquaLogic DSP:
If you compare this to the EJB world, the physical data services are like entity beans, while logical data services are like session beans. AquaLogic DSP supports a wide variety of physical data sources such a s RDBMS, XML, Web services, delimited files, and Java classes. The availability of Java classes as a data source makes it possible to fetch data from any kind of data source that has a Java API.
Integration using AquaLogic DSP involves design-time and runtime activities. As mentioned above, design-time activities are performed using WebLogic Workshop, and runtime is managed by WebLogic severs, which adds a fat layer of additional, supporting services like scalability and clustering.
The following sections examine how to model a data service, how to build a client to interact with the data service, and finally how to configure the runtime behavior of the data service. While doing this, we will build a simple application using WebLogic Workshop and AquaLogic DSP.