Skip navigation.
Downloads | Product Documentation | Support

Client Application Developer's Guide

# Introducing Liquid Data for Client Applications

This chapter introduces you to developing BEA Liquid Data for WebLogic® client applications. It covers the following topics:

- Simplifying Data Programming
- What is a Liquid Data Client?
- Deciding Which Programming Model to Use
- Service Data Objects (SDO)
- Development Steps
- Security Considerations in Client Applications
- Runtime Client JAR Files
- Enabling Data Source Updates

# Simplifying Data Programming

BEA Liquid Data for WebLogic is a data services platform product that significantly simplifies how client applications access and use data. In a typical organization, data comes from a variety of sources, including distributed databases, files, applications from partners or e-commerce exchange markets. With Liquid Data, 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.

Liquid Data 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.

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, from multiple sources and transform 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 Liquid Data. 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.

This document describes how to create Liquid Data-aware client applications. It explains the various client access mechanisms that Liquid Data 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 Liquid Data update framework.

# What is a Liquid Data Client?

A Liquid Data client is any process that consumes data services from Liquid Data. A client application may be, for example, a Java program, non-Java programs such as .NET applications, BEA WebLogic Workshop applications, or JDBC/ODBC clients.

As illustrated in Figure 1-1, Liquid Data supports several access mechanisms:

- Java clients can use data service functions through the Mediator API.
- Workshop applications (such as portals, business processes, and web applications) can use the Liquid Data control.
- By generating a Web service for data services, you can make Liquid Data services available to a wide array of WebLogic and non-WebLogic applications and integration channels.
- The Liquid Data JDBC driver provides JDBC and ODBC clients, such as reporting tools, with SQL-based access to Liquid Data information.

Whatever the client type, Liquid Data gives developers a uniform, services-oriented mechanism for accessing and modifying heterogeneous data from external sources. Developers can focus on the business logic of the application rather than details of various data source connections and formats.

Figure 1-1 Accessing Liquid Data Services

# Deciding Which Programming Model to Use

Developers can choose from several models for accessing Liquid Data services. The model chosen will depend on the access mechanism you decide to used. The possible access methods are:

- Data Mediator API
- Liquid Data Control
- Web Services
- JDBC/ODBC

Each access method has its own advantages and use. Table 1-2 provides a description of each of these access methods and summarizes the advantages of the various models for accessing Liquid Data services.

Table 1-2 Liquid Data Access Models

Access mechanism | Description | Advantages/When to use...
--- | --- | ---
Data Service Mediator API | A Java interface for using data services. Returns data as data objects, providing full support for Service Data Objects (SDO) programming. For more information, see Accessing Data Services from Java Clients. | Can be developed with standard Java IDEs such as BEA WebLogic Workshop, Eclipse, IntelliJ, JBuilder, and others. Easy-to-use approach to developing Java programs that use external data. Provides several access modes, including a dynamic (untyped) interface, a static (typed) interface, and an ad hoc query interface. Seamless ability to submit data changes.
Liquid Data Control | A WebLogic Workshop control for accessing Liquid Data resources. For more information, see Accessing Data Services from Workshop Applications. | Best suited for BEA WebLogic Workshop applications, including portals, business process workflows, and pageflows. Leverages BEA WebLogic Workshop features for working with controls, such as drag-and-drop method and variable generation. Provides an ad hoc query interface for a highly dynamic approach to querying information. Seamless ability to submit data changes.
Web Service | A data service can be wrapped as a Web service, providing the data service with the benefits of web service features. For more information, see Exposing Data Services through Web Services. | Makes standard Web service features available to data services, such as WS-Security, WSDL descriptors, and more. Makes data services usable from .NET applications, or other non-Java programs. Ideal for XML-based SOA architectures
JDBC/ODBC | Client applications can use JDBC or ODBC to access Liquid Data services using SQL queries. The Liquid Data JDBC driver supports SQL-92. For more information, see Using the Liquid Data JDBC Driver. | Works with applications designed for JDBC access, such as Cognos business intelligence software and Crystal Reports. Enables users to leverage existing SQL skills and resources. Limited to "flat" views of data.

# Service Data Objects (SDO)

Service Data Objects (SDO), a specification proposed jointly by BEA and IBM, is a Java-based architecture and API for data programming. SDO unifies data programming against heterogeneous data sources. 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 graphs. Under this architecture, a client gets a copy of externally persisted data in a data graph, which is a structure for holding data objects. The client operates on the data remotely; that is, disconnected from the data source. If data changes need to be saved to the data source, a connection to the source is re-acquired. Holding connections and locks the data at the source for the minimum time possible in this way maximizes the scalability and performance of applications.

To SDO clients, the data has a uniform appearance no matter where it came from or what its source format is. Enabling this unified view of data in the SDO model is the Data Service 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. Liquid Data serves as such a SDO mediator.

On the client side, information takes the form of data objects. Data objects are the basic unit of information prescribed by the SDO architecture. SDO has both static (or strongly typed) and dynamic (or loosely typed) interfaces for working with data objects.

Static interfaces provide a programmer-friendly model for getting and setting properties in a data object. Accessors are generated for each property in the data type of a data service, for example `get` `CustomerName``()` and `set` `CustomerName``()` for a Customer data object. The dynamic interface, on the other hand, is useful when a predefined static interface is unknown or undefined at runtime. Dynamic interface calls are in the form `get(``"CustomerName"``)` and `set(``"CustomerName"``,` `"J. Dough"``)`.

In keeping with the goals of a service-oriented architecture (SOA), data graphs are self-describing. The metadata API enables applications, tools, and frameworks to inspect information on the data contained in a data graph. The data is described by an XML schema, which describes the names of properties, their types, and more.

For details on using SDO, see Client Programming with Service Data Objects (SDO).

# Development Steps

There are several steps you will take to when developing your application:

1. Choose the data access approach that best suits your needs. (Table 1-2 describes the advantages of the different access mechanisms.)
2. Determine what data services you want to use in your client application by looking at the available services using the Liquid Data Console. The Liquid Data Console acts as a sort of service registry in the Liquid Data architecture—it shows what data services are available and what functions they provide.
3. Make sure you have the required JAR files for developing Liquid Data client applications (see Runtime Client JAR Files, below). To use the typed data service and SDO interfaces, acquire the generated mediator client JAR from the Liquid Data administrator.
4. Develop the Liquid Data client application.

A prior or possibly parallel task is creation of Liquid Data services and their functions, which are accessed by client applications. Development of these entities is described in the Data Services Developer's Guide.

# Security Considerations in Client Applications

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

Access policies for Liquid Data 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.

For complete information on WebLogic security, see:

`http://download.oracle.com/docs/cd/E13222_01/wls/docs81/security/index.html`

# Runtime Client JAR Files

The Liquid Data API includes the packages listed in Table 1-3.

Table 1-3 Required Java Archive Files

Name | Description | Location
--- | --- | ---
[`App`]`-ld-client.jar` | Contains the generated static interfaces for data services and their data types. The name of the file is prefixed by the name of the Liquid Data application from which the typed interface is generated. | (Supplied by your Liquid Data administrator.)
`ld-client.jar` | The dynamic, or untyped, data service APIs, including generic data service interfaces and ad hoc query interfaces. | <bea_home>\weblogic81\liquiddata\lib\
`wlsdo.jar` | The interfaces defined in the SDO specification, including untyped data interfaces and data graph interfaces. | <bea_home>\weblogic81\liquiddata\lib\
`weblogic.jar` | The common WebLogic APIs. | <bea_home>\weblogic81\server\lib\
`xbean.jar` `xqrl.jar wlxbean.jar` | XMLBean classes and interfaces on which the Liquid Data SDO implementation relies. Also enables XPath expressions in untyped data accessors. | <bea_home>\weblogic81\server\lib\

# Enabling Data Source Updates

SDO gives client applications create, read, update, and delete access to external data. Changes to data object property values can be persisted to back-end data sources. The programming details associated with data changes are hidden from the client. The client can update data in several heterogeneous, distributed sources with a single update call.

Liquid Data makes it easy to create data services that can apply changes to information as well as access from back-end data sources. For relational data sources, Liquid Data propagates the updates to the back-end source automatically. For non-relational sources, such as web services, or when you want to customize relational updates, Liquid Data provides an update framework that you can use to implement your own data source updates.

For details on using SDO to update data, see Enabling SDO Data Source Updates.