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.
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:
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:
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.
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:
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.