Mike Carey, Satish Thatte interviewed by Lauren Cooney
Earlier this week, Lauren Cooney spoke to Mike Carey and Sachin Thatte about the BEA AquaLogic Data Services Platform (AL DSP), looking for a summary of what's new in this product, and why we should pay attention. Mike is the server team manager of the AquaLogic Data Services Platform, and Sachin is the tools and APIs team manager.
In a nutshell, can you describe the BEA AquaLogic Data Services Platform (AL DSP)?
Many enterprises have a number of diverse, distributed sources of information. The AquaLogic Data Services Platform enables a single unified view of data from any of these sources across the enterprise. To quote the product blurb, "BEA AquaLogic Data Services Platform allows data services to function as single access points for unified and consistent information—for easier data access, aggregation and updates, better data consistency, and simpler application development."
What do you see as the top three features of the BEA AquaLogic Data Services Platform (AL DSP) that will help developers create data services?
Data Services Modeling Framework, declarative definitions, and query optimization. In particular:
Data Services Modeling Framework
The Data Services Modeling Framework provides a conceptual framework for designing data services and a set of design-time tools that support the framework.
Declarative definitions for read and update data services
This feature enables developers to quickly create and deploy data services, focusing on "what" each data service should do, not "how" it should do it.
Query optimization for distributed read services
AL DSP optimizes data services so that developers don't have to worry about coming up with an optimal plan to retrieve data. Thus, the simplification that DSP provides for data services construction is similar to what SQL provides for database application development.
How is the current release of the AquaLogic Data Services Platform different from the original Liquid Data product? What additional benefits does this provide to developers and data architects?
AL DSP isn't simply a rebranding of Liquid Data. We've made a number of important enhancements to the base product:
Data services modeling and metadata management
Modeling and metadata management provides structure to the problem of data services development, thus enabling and encouraging reuse of existing services.
Support for full CRUD (Create, Read, Update, Delete) operations on data services
In addition to read services, AL DSP now supports the full lifecycle of enterprise data, including create, update, and delete operations in write services.
Fine-grained security—Element level and data driven
AL DSP's security features are fully integrated with BEA Platform security, thus enabling integration with AquaLogic Enterprise Security. This allows the administrator to control access to enterprise data based on both context- and content-sensitive policies.
Rich graphical editing of declarative data services
This feature makes it easy for the data architect to graphically construct data services that integrate data from a variety of heterogeneous enterprise sources.
Two-way editing (graphical and source view)
This feature allows the data architect to freely move back and forth between the graphical editing tool and source editing as he/she desires.
BEA WebLogic Workshop integration with DSP tools
This provides a uniform experience for BEA Platform developers, allowing them to develop, test, and deploy data services and incorporate them into their BEA Platform applications.
Service Data Objects (SDO) programming model
This provides a disconnected programming model so that applications can retrieve information from data services, locally update the information, and return the changes to the data services layer for propagation back to the data sources. SDO automatically tracks the changes made to the data, and includes support for a variety of optimistic concurrency policies to control change propagation in the face of concurrent access to the underlying systems.
JDBC/SQL access to data services for reporting tools
This enables standard reporting tools, which issue SQL to retrieve data for reports, to access data in the data services layer.
Which standards and specifications are supported by the AquaLogic Data Services Platform?
AL DSP is fully standards-based. Important supported standards and specifications include:
How does this specifically simplify application development? Can you provide a "deep dive" into code and data services reuse and how this works with this product?
The platform simplifies the day-to-day activities of data architects (creators of data services), application developers (consumers of data services), and data services administrators. We'll go through each of these in turn:
Data architects are provided with powerful tools for modeling data services and defining the logic for these data services declaratively. AL DSP gives data architects a uniform view of all the enterprise data sources, a view upon which he/she can easily build logical data services models that integrate data from disparate physical data sources. The resulting single view of enterprise data can be used across multiple applications. The declarative approach relieves the data architect from having to write and optimize data access code against multiple APIs and data formats. During runtime, the AL DSP optimizer will deduce the best plan to efficiently gather this data. The declarative approach also enables AL DSP to infer data lineage and propagate updates to the view down to the underlying physical data services. Data architects can optionally customize updates to the data services via the update override feature. Data architects can also plug in a workflow for long-running update transactions and can design compensating transactions when necessary.
Application developers can focus on building application logic without being concerned with the complexities of how the underlying heterogeneous data is accessed, assembled, or updated. Application developers can choose from several APIs to access the data services. The Mediator API feature provides typed access to data services and supports the SDO programming model for handling the disconnected data sets that are commonly needed in building scalable Web applications. The AL DSP Control (also known as the Liquid Data Control) provides similar capabilities, integrated into BEA WebLogic Workshop, for WebLogic Workshop-based applications. The application developer can easily expose data services as Web services to be used in an SOA environment. AL DSP also provides JDBC/SQL access to the data services layer for use by reporting applications.
Data services administrators are provided with a Web-based console for managing, securing, and tuning the data services layer. Data services administrators have the option to grant or deny access to the data services and/or to individual data elements returned by the services. Data services administrators can also monitor performance of the data services, and have the ability to selectively terminate requests made against the data services layer. Data services administrators can also choose to configure certain data service results to be cached to reduce latency and/or to offload back-end systems.
How does the AquaLogic Data Service Platform fit into the strategy of the overall AquaLogic Platform?
The AquaLogic Data Services Platform is the data component of the AquaLogic Platform. Data is the foundation of any Service Oriented Architecture (SOA), and AL DSP provides a comprehensive design time and runtime framework for building, deploying, and managing the data services within the overall SOA.
Finally, how does this product integrate with WebLogic Workshop?
AL DSP tooling is fully integrated with BEA WebLogic Workshop. This includes development, testing, and deployment of data services. The AquaLogic Data Services Platform integrates with the rest of the WebLogic Workshop components through the Controls framework via the Data Services Control (also known as Liquid Data Control). The SDO programming model integrates with Page Flows, so users can graphically build forms based on SDO objects. Data services can be easily turned into WebLogic Workshop Web services, thus enabling data services for SOA.
Lauren Cooney is a Senior Manager in BEA�s Developer Relations group. She works closely with developers on several programs and started the BEA User Group Program, the BEA Technical Director Program, and dev2dev Live, BEA�s online event center.
Mike Carey is a BEA AquaLogic technical director. He currently manages the BEA XQuery engineering team and is the architect for the AquaLogic Data Services Platform product.