Enterprise

Digg This!

Page 1 of 2   next page »

Service Data Objects (SDOs) have become a foundation technology for Service Oriented Architecture (SOA). Recently, BEA, IBM, Oracle, SAP, Iona, Siebel, and Sybase announced their support for an SOA-enabling framework specification named Service Component Architecture (SCA). SD O provides the primary data representation in this framework.

Although not addressed by the current SDO or SCA specifications, there's a definite need for a generic data access service that operates in terms of SDOs. The alternative to this service would be the tedious and error-prone development of a custom mapping between the back-end data representation and Service Data Objects.

The Relational Database Data Access Service (RDB DAS) obviates the need for this custom development by providing a robust data access utility built around SDO. Because of its tight integration with SDO, the RDB DAS is also a perfect solution for data access in an SCA-based application.

By employing the RDB DAS, applications avoid the details and complications of working directly with a relational database and also the complex transformation between relational rows/columns and Data Object types/properties.

Background
Since the release of the specification in late 2003, SDO has proven itself a flexible and robust technology for data representation. Its inherent support for disconnected operations and heterogeneous data sources offers strong support for the needs of modern software architectures. For these reasons, SDO has found its way into several commercial products from major vendors and these same characteristics have led to its inclusion in SCA as a foundation technology.

SDO provides the general case mechanism for moving data around an SCA-enabled application. However, the reality is that most of this data must originate in some database at one edge of the application and be stored in some database at another edge. Unfortunately, database access isn't currently either SDO or SCA. (An early version SDO Data Access Service specification is in progress.)

This leaves the developer with a serious undertaking since there's a fundamental mismatch between the objects that an application works with and the tables and rows of a relational database that provide the persistent store for the object's state (see http://en.wikipedia.org/wiki/object-relational_impedance_mismatch).

For example, let's consider a simple query against a relational database for customers in a certain age range and their related orders.

An SDO-enabled application could most easily and naturally work with a normalized graph of Data Objects representing the query. Figure 1 illustrates this graph of connected Data Objects.

This in-memory graph of data objects brings to bear all of the capabilities of SDO.

• It's a disconnected representation of the queried data
• It provides simple traversal between related elements
• It tracks all changes from its original form via the SDO change summary
• It contains no redundant information
• It's easily serialized to XML

But unfortunately the relational database returns a tabular representation of the query result complete with redundant customer information as shown in Figure 2.

The transformation required to convert from tabular format to a graph of interconnected data objects is complicated and the reverse (transforming graph changes to a sequence of SQL inserts/updates and deletes) is even more so.

Because of the difficulties inherent in the transformation between the database and the application object space, an application development project can easily spend a third of its development resources on functions related to moving object state in and out of the database.

Business application developers shouldn't be burdened with this task and should instead be allowed to focus on business functionality.

Solution
The RDB DAS offers a solution to the problems mentioned above by providing two major capabilities. The RDB DAS can:

1. Execute SQL queries and return results as a graph of Data Objects
2. Reflect changes made to a graph of Data Objects back to the database

Figure 3 illustrates these two capabilities in a typical client interaction. The client starts by reading a graph of data specified by some query. The client then makes modifications to the graph, possibly by adding elements, and then requests the DAS to push the changes back to the database.

The DAS provides an intuitive interface and is designed so that simple tasks are simple to complete while more complicated tasks are just a little less simple.

The application interface to the DAS is based on the familiar Command Pattern and interaction with the DAS consists of acquiring command instances and executing them (see Design Patterns by Erich Gamma, et al). The following example demonstrates the simplest possible read of data.

Command read = Command.FACTORY.createCommand("select * from CUSTOMER where ID = 10021");
read.setConnection(getConnection());
DataObject root = read.executeQuery();

In this case the command is created programmatically from a Command factory and the only input necessary is the SQL SELECT statement. Executing the read command returns the root of the resulting data graph and data can be extracted from the graph using the SDO dynamic API.

String lastName = root.getString("CUSTOMER[1]/LASTNAME");

Pushing changes back to the database can be equally straightforward. Continuing with this example we can modify the customer object and then direct the DAS to send the modifications to the database. This line uses the SDO dynamic API to change the last name of the retrieved customer.

root.setString ("CUSTOMER[1]/LASTNAME", "Williams");

Now that we have a modified graph, we can synchronize the changes with the database by passing the data graph to an "apply changes command" and asking it to execute.

ApplyChangesCommand apply = Command.FACTORY.createApplyChangesCommand();
apply.setConnection(getConnection());
apply.execute(root);

As you may have noticed, the read and write examples each required three lines of code (except the code to get the connection object). So those of you familiar with O/R frameworks might be asking yourself a few questions. What is going on here? Where did you define all the configuration data? I didn't see a deployment descriptor? Where is the object-relational mapping information? Where are the static domain classes like Customer? The answers to these questions are based on two significant SDO capabilities and one design philosophy:

• Dynamic SDO
• SDO Change History
• DAS use of convention

Dynamic SDO
The reason you don't see a Customer interface or class used in this example is because the DAS can work with dynamic SDO data objects. This is a very powerful and often overlooked SDO capability.

Many applications today use the Transfer Object(TO) pattern to move data around tiers within an application (see Core J2EE Patterns by Deepak Alur, et al). Since these TOs typically have no behavior, there's little justification for Java interfaces and classes to implement the TO. These artifacts just represent more code to write, maintain, and manage.

One argument for TOs as Java interfaces/classes is the potentially cleaner API:

Static API
customer.setLastName("Williams") Dynamic API
customer.setString("lastName", "Williams")

However, the SDO dynamic API is straightforward and can even be simpler to read than a static equivalent. For example, we can use the SDO XPath capability to access properties like this:

amount = customer.getFloat("orders[17]/price");

The equivalent, with normal static Java APIs, would look something like this:

amount = ((Order)customer.getOrders().get(17)).getPrice();

The dynamic API can also be useful in applications where the data model is likely to change often during development. It lets developers use the full breadth of Data Object function without having to generate a new static model (Java classes and interfaces) every time a change is made.

SDO Change History
The change history feature of SDO data graphs is another reason that SDO data objects can be thought of as transfer objects on steroids. Not only do data objects provide a snappy dynamic API and XML serialization, SDO data objects also remember any changes that have been made to them.

The change history capability means that SDO data objects aren't dependent on a container or some persistence manager to track their state. In fact, since the change history is serialized along with the associated data objects, a graph of SDO data objects can flow through different tiers of a distributed application remembering all the changes that may occur along the way. Later, when it's time to reflect those changes back to the database, the DAS can process the change history and build the set of create/update/delete commands needed to flush the accumulated changes.

The Change History tracks changes made to all data object properties including fields and relationships. Using this information, the DAS can handle the complex task of reflecting object graph changes back to the database without exposing this complexity to users. The DAS translates object property changes into database column updates and object relationship changes into database foreign key updates.

Use of Convention over Configuration
The DAS makes use of convention to simplify the programming model. For instance, in the simple read example above we have this statement to access the last name of a customer:

String lastName = root.getString("CUSTOMER[1]/LASTNAME");

Notice the path name: "CUSTOMER[1]/LASTNAME". This suggests that there is an SDO Type named CUSTOMER with a property named LASTNAME. If you remember, the command used to read this data was created like this:

Command read = Command.FACTORY.createCommand("select * from CUSTOMER where ID = 10021");

The RDB DAS, by convention, creates an SDO Type for each database table represented in the query result. In addition, it creates a property for each table column represented in the query result. In the absence of any additional configuration data, the names of these Types and Properties will exactly match the names of the database Tables and Columns. So given the SELECT statement above and the knowledge that the CUSTOMER table has a column named LASTNAME, we can assume that the data graph returned will be populated with instances of Type CUSTOMER that have a property LASTNAME. This capability is made possible by using the metadata associated with the ResultSet returned from the query execution.

If the application developer wants the names of Types and Properties to vary from the names of the Tables and Columns then he or she can override this convention with a bit of configuration. We'll get into the details of providing configuration to the DAS a little later.

Another bit of convention that this example demonstrates is exploited when flushing graph changes to the database:

ApplyChangesCommand apply = Command.FACTORY.createApplyChangesCommand();
apply.setConnection(getConnection());
apply.execute(root);

In the absence of instruction (configuration) to do otherwise, the DAS will scan the change history and generate the create/update/delete (CUD) statements necessary to flush the changes to the database. Since we just changed a single property of a single data object, the change history processing produces a single statement to be executed:

update CUSTOMER set LASTNAME = 'Williams' where ID = 10021

Page 1 of 2   next page »