Information Integration Using the AquaLogic Data Services Platform
Pages: 1, 2, 3, 4

Modeling Data Services

AquaLogic DSP promotes model-driven development, supported by the enhanced WebLogic Workshop IDE. Using this, data stewards can visually model data services. You'll see this in action. In the example below, we first generate a physical data service from a physical data source, and then we implement the business logic by integrating data from this physical data service in a logical data service using the XQuery editor.

Building the physical data service

For the purpose of this tutorial we will develop a customer order management application. Now we will quickly model a physical data service in an AquaLogic DSP application:

1. Open WebLogic Workshop.
2. Create a new default project (File->New->Application), and name the application OrderManagment.
3. Right-click OrderManagment, select New->Project->Liquid Data Project, and name it repository.
4. Right-click repository and select Import Source Metadata…. A wizard pops up that can help you create the physical data source. AquaLogic DSP can shred RDBMS, Web services, XML, flat files, and Java classes as data sources. (Start the WebLogic server if you haven't already.)
5. Select Relational, and click Next.
6. Select cgDataSource (cgDataSource is a sample data source that comes with the WebLogic installation) from the Data Source drop-down box (leave default value for others), and click Next.
7. Users can now see a list of all schemas in the data source, as shown in Figure 2. Select CUSTOMERS, PO_CUSTOMERS, PO_ITEMS under WEBLOGIC schema, as shown in Figure 2, click Add, and proceed to Finish.
8. The AquaLogic DSP project's initial version is ready. Now right-click repository, and build the project.

Figure 2. Selecting the data source to import

Now we have three physical data services, CUSTOMERS, PO_CUSTOMERS, and PO_ITEMS. Double-click CUSTOMERS.ds to see the design view of the data service, as displayed in Figure 3. The tree structure in the center of design view represents the return shape of the data service.

Figure 3. Design view of the data service

You can also see the automatically generated XQuery function CUSTOMER in the design view. If there are relationships established at the data source level via foreign keys, then corresponding functions will be generated in the data service.

A data service contains two types of functions:

• Read functions: These functions help in fetching data from the data source. The return shape of all read functions will either be the return shape of the data service or a sequence of these shapes. Customer.ds, for example, will have functions like getAllCustomers() and getCustomerByID().
• Navigation functions: These functions help in establishing relationships between data services. Customer.ds can be related to Order.ds by getAllOrders(), for example.

You can see different views of the data service using the XQuery editor view, source view, test view, and XQuery plan view, besides design view. Click on source view. You can see the XQuery Prolog generated for the physical data source.

Building the logical data service

Now let's develop a logical data service. You can manually develop a logical data service by writing XQuery yourself or by using the XQuery editor in the AquaLogic-enabled WebLogic Workshop. We will develop a data service called CustomerSummary that presents a customer summary of the three data services created earlier:

1. Right-click the repository folder, select New ->Data Service, and enter CustomerSummary as the name.
2. Right-click the repository->schema folder and import the CustomerSummary.xsd supplied with the sample code under the schema folder.
3. Right-click in the design view (expect white space in the center) -> Associate XML Type->Select CustomerSummary.xsd from the schema folder.
4. Right-click in the design view, select Add Function, and enter getCustomerSummary.
5. Switch to the XQuery editor view.
6. Drag and drop the CUSTOMERS(), PO_CUSTOMERS(), and PO_ITEMS() functions into the XQuery editor from the CUSTOMERS, PO_CUSTOMERS, and PO_ITEMS data services, respectively.
7. Map the fields in the functions one by one to the return types shown on the right side to match the return type (for now leave CREDIT* and children in return type).
8. Now we have to join all three data sources. Map CUSTOMERID in CUSTOMERS to CUSTOMERID in PO_CUSTOMERS, and map ORDERID in PO_CUSTOMERS to ORDERID in PO_ITEMS, as shown in Figure 4.
9. Switch to source view. Browse through the code to see the generated code and the join condition formed using the where clause.
10. Switch to test view. Select the getCustomerSummary function and execute the query.

Figure 4. Mapping using the XQuery editor

You should now see the results fetched from all data sources, as Figure 5 shows. Here our logical data source is used to wrap three data sources to give a summary view. Therefore this model is akin to the business model, and as a result, the rapport between the business requirement and application is clearly represented.

Figure 5. Result of the data service function execution from test view

We have now seen how physical data services can be made from data sources and how logical data services can be used to aggregate the information from the physical data services. So this data service layer offers total transparency of the data source to the client. In addition, it provides fine-grained data security, caching, and more, which is discussed later. The clients can talk with the physical data service and logical data service, but it is always good to talk with a logical data service façade to make enhancement/maintenance easy in the future.

The AquaLogic XQuery engine uses an XQuery push-down mechanism to optimize all queries executed against these data sources. This means, for example, that if a particular operation can be performed efficiently in the RDBMS engine, then it is pushed to the RDBMS engine reducing the in-memory operations in the XQuery engine. So when you execute the query from logical data service to aggregate data, the query is analyzed and pushed down to physical data sources as required to optimize the query.