Introducing Data Services for Client Applications

This chapter provides an overview of ALDSP for client application developers. It includes the following topics:

Introduction

BEA AquaLogic Data Services Platform (ALDSP) brings data access into the world of service-oriented architecture (SOA). ALDSP enables organizations to consolidate, integrate, transform, and service-enable disparate data sources scattered throughout their enterprise, making enterprise data available as an easy-to-access, reusable commodity: a data service.

From the perspective of a client application, a data service typically represents a distinct business entity, such as a customer or order. Behind the scenes, the data service may aggregate the data that comprises a single view of the data, for example, assembling it from multiple sources and transforming it in a number of ways. A data service may be related to other data services, and it is easy to follow these relationships in ALDSP. Data services insulate the client application from the details of the composition of each business entity. The client application only has to know the public interface of the data service.

With ALDSP, client applications can use heterogeneous data through a unified service layer without having to contend with the complexity of working with distributed data sources using various connection mechanisms and data formats. For client developers, ALDSP provides a uniform, consolidated interface for accessing and updating heterogeneous back-end data. It enables a services-oriented approach to information access using data services.

This document describes how to create ALDSP-aware client applications. It explains the various client access mechanisms that ALDSP supports and its main client-side data programming model, including Service Data Objects (SDO). It also describes how to create update-capable data services using the ALDSP update framework.

What Is a Data Service?

From a high-level perspective, a data service defines a distinct business entity such as a customer and the customer’s orders. The data service defines a unified view of the business entity by aggregating data from any number of sources — relational database management systems (RDBMS), Web services, enterprise applications, flat files, and XML files, for example. Data services can also transform data from the original sources as needed.

In order to use data services as a client, you need know only a few details, such as:

Data service client applications can use data services in the same way that a web service client application invokes the operations of a Web service.

What is an ALDSP Client Application?

An ALDSP client application is any application that invokes data service routines. Client applications can include Java programs, non-Java programs such as Microsoft ADO.NET applications, BEA WebLogic Workshop applications, JDBC/ODBC, or web-service based applications in any programming language.

Java client applications can use data service functions and procedures through the Data Services Mediator API (also known simply as the Mediator API).
Java-based web service applications can use the Mediator API.
WebLogic Workshop applications (such as portals, business processes, and Web applications) can leverage data services by means of ALDSP Controls. (Controls are reusable Java components that can be used in WebLogic Workshop applications.) ALDSP Controls can be used as the basis of many ALDSP-enabled application scenarios. For example:

ALDSP Controls can be added to Web services, portal projects, and Web projects.
ALDSP Controls can be used to generate Web services that can make ALDSP services available to a wide variety of WebLogic and non-WebLogic applications and integration channels.
ALDSP Controls can be used within a JPD (Java process definition, a workflow component).

The ALDSP JDBC driver provides JDBC clients, such as reporting tools, with SQL-based read access to ALDSP data. (ODBC clients can use a JDBC bridge to connect to the data.)
Other web-service based applications can access data service operations through ALDSP’s web services API.

Regardless of the client type, ALDSP provides a uniform, service-oriented mechanism for accessing and modifying distributed, heterogeneous data. Developers can focus on business logic rather than on the details of various data source connections and formats.

In your client application code, a client simply invokes the data service routine; in turn, ALDSP:

The ALDSP data objects conform to the Service Data Object (SDO 2.1) specification, a Java-based API for data programming that is the result of joint effort by BEA, IBM, Oracle, SAP, and others.

Choosing a Client Programming Model

Application developers can choose from among several client API models for accessing ALDSP services. The model chosen will depend on the desired access mechanism. Each access method has its own advantages and uses. Table 1-2 provides a description of each of these access methods and summarizes the advantages of the various programming models for accessing ALDSP data services.

Table 1-2 Summary of Techniques for Exposing Data Services to Clients
Data Access Technique	Description	Advantages	Other Details
Java Data Service Mediator	Instantiate a remote data service interface and invoke public methods on the interface. See Invoking Data Services from Java Clients.	Full read/write access to data.	Requires adequate Java programming skills.
Web services	Data services can be directly mapped to web services. Clients have access to data through SOAP messages and/or SDOs. See Invoking Data Services Through Web Services.	Read/write access to data. Industry standard.	N/A
SQL	Data service functions first need to be published as SQL objects. These SQL objects are then available to your application through JDBC. See Using SQL to Access Data Services.	Accepted by commonly used reporting tools.	Read-only, and for use SQL-based clients only.
Excel	The ALDSP Excel add-in lets you invoke data service operations from Microsoft® Excel®. See Using Excel to Access Data Services.	Real-time data can be quickly rendered in the familiar Microsoft Excel format.	Requires Data Services Studio
ADO.NET	Allows interoperability between ALDSP data services and ADO.NET. See Supporting ADO.NET Clients.	Enables ALDSP data services to be used in Microsoft ADO.NET client applications.	Specific to ADO.NET applications.

Introducing Service Data Objects (SDO)

Service Data Objects (SDO), a specification proposed jointly by BEA, IBM, Oracle, SAP, and others, is a Java-based API for data programming. SDO simplifies data programming against data sources of different types. It simplifies data access, giving data consumers a consistent, uniform approach to using data whether it comes from a database, web service, application, or any other system.

SDO uses the concept of disconnected data. Under this architecture, a client gets a copy of externally persisted data in an SDO data object or data graph, which is a structure for holding data. The client operates on the data remotely; that is, while disconnected from the data source.

If the client makes data changes that need to be saved to the data source, a connection to the source is re-acquired later. Keeping connections active for the minimum time possible maximizes scalability and performance of web and service-oriented applications.

To SDO clients, the data has a uniform appearance no matter where it originated or what its underlying source format is. Enabling this unified view of data in the SDO model is the concept of a data mediator. The mediator is the intermediary between data clients and back-end systems. It allows clients to access data services and invoke their functions to acquire data or submit data changes. ALDSP implements such an SDO mediator.

Introducing The Data Service Mediator API

The SDO specification allows for many types of mediators, each intended for a particular type of query language or back-end system. ALDSP provides a Data Service Mediator API, a server-side component of the ALDSP XQuery processing engine that serves as the intermediary between data services and client applications or processes.

The Data Service Mediator facilitates access and updates to the various data sources that comprise any data service. The Mediator is also the core mechanism for the data service update framework. For details on using the Mediator API for web services clients and for Java clients, see:

Typical Client Application Development Process

Identify the data services you want to use in your application. The Data Services Platform Console can be used to find all services available on your WebLogic Server. The DSP Console serves as a data service registry within the ALDSP architecture; it shows available data services, including the specific functions and procedures that each data service provides.
Choose the data access approach that best suits your needs. ( Table 1-2, Summary of Techniques for Exposing Data Services to Clients, on page 1-5 describes the advantages of the different access mechanisms.) The approach you choose also depends on how the data service has been deployed.

For example, if the data service has been mapped out as a web service, you can develop a Web service client application using Java in conjunction with the service’s WSDL file.

Similarly, if the data service is incorporated in a portal, business process, or Web application, your client application development process may take place entirely in the context of the server, as a set of pageflows or other server-side artifacts, using a control.

Obtain the required JAR files. (See specific chapters in this guide for JAR file requirements.)

Security Considerations in Client Applications

ALDSP administrators can control access to deployed ALDSP resources through role-based security policies. ALDSP leverages and extends the security features of the underlying WebLogic platform. Roles can be set up in the WebLogic Administration Console. (See the ALDSP Administration Guide for detailed information about the DSP Console.)

Access policies for resources can be defined at any level — on all data services in a deployment, individual data services, individual data service functions, or even on individual elements returned by the functions of a data service.

Performance Considerations

Data service performance is the result of the end-to-end components that make up the entire system, including:

Data service design. The number, types, and capabilities of data sources, complexity of logical data source aggregation, and other data service design considerations can affect performance.
Number of clients accessing the data service. The number of simultaneous clients can affect performance.
Performance of the underlying data sources. Since data services access underlying data, the performance and availability of those systems can affect performance.
Hardware resources. The number of servers, processing power, memory, network structure, and other factors for each and every platform throughout the system, client and server alike, can affect performance.

Before creating a client application for a data service, it is recommended that you be aware of the performance of each underlying data source and benchmark the performance of the data services as you develop them. Use load-testing tools to determine the maximum number of clients that your deployed data services can support.

You can use ALDSP’s auditing capabilities to obtain performance profile information that you can use to identify and resolve performance problems if they occur. For detailed information on ALDSP audit capabilities see ALDSP Administration Guide.

Client Classpath Settings

Java Mediator API Clients

Client applications using the ALDSP Mediator API need one of the following classpath settings:

CLASSPATH=
 <app-static-client>.jar <= this is generated static client jar
 <ALDSP_HOME>/lib/sdo.jar
 <ALDSP_HOME>/lib/ld-client.jar
 <WL_HOME>/common/lib/apache_xbean.jar
 <WL_HOME>/server/lib/weblogic.jar

CLASSPATH=
 <ALDSP_HOME>/lib/sdo.jar
 <ALDSP_HOME>/lib/ld-client.jar
 <WL_HOME>/common/lib/apache_xbean.jar
 <WL_HOME>/server/lib/weblogic.jar

Web Services Clients

Client applications using the ALDSP Native Web Services feature need one of the following classpath settings:

CLASSPATH=
 <app-static-client>.jar <= this is generated static client jar
 <ALDSP_HOME>/lib/sdo.jar
 <WL_HOME>/common/lib/apache_xbean.jar
 <WL_HOME>/server/lib/weblogic.jar

CLASSPATH=
 <ALDSP_HOME>/lib/sdo.jar
 <ALDSP_HOME>/lib/ld-client.jar
 <WL_HOME>/common/lib/apache_xbean.jar
 <WL_HOME>/server/lib/weblogic.jar

JMX Mbean Management API Client Classpath

CLASSPATH=
 <ALDSP_HOME>/lib/ld-server-core.jar
 <ALDSP_HOME>/lib/ld-client.jar
 <WL_HOME>/common/lib/apache_xbean.jar
 <WL_HOME>/server/lib/weblogic.jar

ALDSP JDBC API Client Classpath

CLASSPATH=
 <ALDSP_HOME>/lib/ldjbc.jar
 <ALDSP_HOME>/lib/ld-client.jar
 <WL_HOME>/server/lib/weblogic.jar

Backward Compatibility

ALDSP 2.5 provided an interoperability JAR file (wls90interop.jar) that allowed WebLogic Server 9.2 clients to access ALDSP 2.x data services. After upgrading to ALDSP 3.0, you need to remove all uses of wls90interop.jar from both the WLS 9.2 based client CLASSPATH and the ALDSP 2.5 client CLASSPATH.

Client Application Developer’s Guide