Configuring the Runtime Behavior

To fine-tune your application, AquaLogic DSP comes with an Administration console. This console allows users to manage, browse, and monitor all deployed applications. We'll briefly examine some of the security, caching, and monitoring features.

Security

AquaLogic DSP compliments the rich WebLogic Security framework, and also provides fine-grained security at the data level. Security policies can apply at various levels of granularity, including:

Application level: This policy gets applied at the global level for all data services within the deployed AquaLogic DSP application.

Data service level: This policy applies to individual data services within the application.

Element level: Here a user can apply security at the node level of the return type of the data service. For example, specific columns in the data sources may be visible or not visible, according to the set permissions—a great feature!

Let's now walk through a typical security configuration. Refer to the sample tutorial guide for AcquaLogic DSP for more detailed steps.

Navigate to repository/CustomerSummary/getCustomerSummary in the LHS menu.

Under the Security-> Security Policy tab, click "action" and set a permission for the current user from the available options (data service level).

Switch to the Secured Elements tab and check ITEMNUMBER and QUANTITY under CUSTOMER -ORDER –POITEM, and then apply the changes.

Switch to WebLogic Workshop test view for the CustomerSummary-getCustomerSummary function, and execute the function using the credentials of the user for which you have given permission in the AquaLogic DSP console in Step 5.

The user will not see the ITEMNUMBER and QUANTITY in the return shape. This demonstrates the fine-grained security at the data level.

In the above section, we looked at how ADSP 2.0 can perform fine-grained security on the data. Here we applied security on the individual elements of the return shape of the data service. This feature helps the administrator to closely control what the user sees without requiring a single line of custom code to achieve this.

Caching

ADSP can cache results of functions exposed in a data service. This is a very useful feature in the case of distributed queries since network latency is avoided here. If caching is enabled, then the next time a query is invoked using the same parameters, the cached results are returned. The cache expires according to the configuration policy on that particular function. The choice of Time To Live (TTL) is critical and determines how frequently the cache is refreshed. Figure 6 shows configuration of the cache and TTL for data service functions.

Figure 6. Configure cache and TTL for data service functions

Let's look at the cache in action in the OrderManagement application:

In WebLogic Workshop, navigate to CustomerSummary Data Service. Switch to the test view and execute the
getCustomerSummary() function. Note the time to execute.

Expand the LHS menu and click OrderManagement. The Administration control's general page opens.

In the cache section, select Enable Cache and select "
cgDataSource" as the data source JNDI, and "mycache" as the table.

Apply the changes.

Using the LHS navigation tree, navigate to the CustomerSummary data service and check the Enable Cache option, and set the TTL as 300 in the
getCustomerSummary() function.

Apply the changes.

Repeat Step 1 to see the effect of caching.

This section examined a small part of the caching features—in particular, how to configure the caching to the granular level of functions. TTL helps administrators to determine the validity of the cache. This feature is very useful in the case of distributed and slow response data sources where data changes are minimal.

Monitoring

Administrators can monitor the currently running queries and terminate the long-running queries, if required, using the AquaLogic DSP console. This page also provides you with information about the cache and runtime information regarding the same.

You can see the information by selecting OrderManagment-> Monitor.

Metadata Browsing/Searching

You can also view metadata information about all registered data services in an AquaLogic DSP application. Administrators and developers can get metadata information including general information about the data services such as name, type, creation information and their functions and relationships with other data services, where the data service is used, read functions of the given data service, user-defined properties of the data service, and details of the function. The "where used" and relationship data helps administrators understand the lineage and relationship of the data service with other data services.

In addition, you are given the option of data services searching and report generation using various criteria.

XQuery Engine

BEA's streaming XQuery engine forms the heart of AcquaLogic DSP. The XQuery engine was designed to provide high performance for message-processing applications (such as for transforming XML data streams). While designing a robust, efficient machine like the XQuery engine, which pulls data from distributed sources, BEA considered the following elements:

A simple and robust internal representation of XML data.

The use of streaming technology to handle a large volume of data.

The efficient implementation of XQuery transformations.

Scalability of the engine.

Strict adherence to the XQuery language specification.

Figure 7 shows an overview of BEA's XQuery engine. Once an XQuery statement is fed into the engine by the client application, the XQuery is parsed and optimized by the engine. The compiler generates a query plan, which is a tree of operators that consumes data from one another in a cascading fashion. The query plan is interpreted by the runtime components. All XML data is represented as a stream of tokens roughly equivalent to SAX events. The engine's performance is enhanced using streaming, query plan caching, and SQL push-down. The engine also comes with a rich set of custom XQuery functions to supplement the specification.

Figure 7. BEA XQuery engine overview

When we execute a function inside logical or physical data services using the SDO Mediator or ADSP control (the Liquid Data control), the XQuery is delegated to the XQuery engine that analyzes the query, executes the query against different data sources, and aggregates the results. The XQuery engine returns results in the form of XML, which in turn is mapped into SDO-enabled
XMLBeans generated for the particular data service. This SDO is used by clients and if required will update the original data source using the update functionality provided by the SDO implementation.

Conclusion

The AquaLogic Data Service Platform 2.0 offers revolutionary and intuitive features that will make any data steward's life easier. The loosely coupled architecture introduces good control over data services, and easy maintenance and monitoring. It reduces the number of work days in your project by reducing the integration code, and therefore reducing the cost and also development time to a great extent. This article provides a high-level overview and tutorial of some of the features found in the AquaLogic DSP. My hope is that you can build on these examples to explore the full power of this tool.

References

Manu Madhusudhanan R is a member of the Liquid Data team at BEA Systems. His expertise includes design and analysis of enterprise applications. His areas of interest include Design Patterns, Grid Computing and Agile Technologies.