SOA Web Services - Data Access Service

Close Window
Print Story
SOA Web Services - Data Access Service
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 (seehttp://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 inFigure 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:
Execute SQL queries and return results as a graph of Data Objects 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
There are a couple of things we‘d like to point out here. The first one has nothing to do with convention but it‘s very cool. What has been generated here is a "partial update." That is, rather than generating a complete update statement that covers every column in the table, the statement only updates columns that relate to changed data object properties (i.e., just the last name).
Partial updates may not be the right way to go for some applications so CUD generation can be overridden with user-supplied CUD statements. However, partial update is a good fit for many applications and with it you can avoid a great deal of configuration or additional programming. Not only that, partial updates provide a performance boost for updates to tables with very wide rows and are also useful for avoiding database triggers.
The other point we want to make has to do with the "where" clause ("where ID =") of the generated update statement. Since we mean to update the specific table row that‘s associated with the modified data object, we need to qualify the update statement with a unique row identifier. So this is where another piece of convention is used. If the DAS isn‘t provided with configuration that defines a unique identifier for the data object Type then the DAS will look for one. There‘s no magic here; if there‘s a property named ID then the DAS will assume it‘s unique and use it in the "where" clause.
We‘ve provided a description of the convention currently employed by the DAS. But there‘s more on the way. We‘re currently looking to add more capability based on conventions for generated columns, optimistic concurrency control, and relationship definition.
The use of convention isn‘t revolutionary or even new, but it is gaining renewed respect. This may be a reaction to the configuration-heavy frameworks we‘ve been using in recent years. Notably, Ruby on Rails, Maven, JUnit, Wiki and many other "agile" frameworks make considerable use of convention over configuration. It‘s amazing what can be done easily, and how much coding and configuration can be avoided with these tools by adhering to simple conventions.
We‘ve explained how the DAS leverages the capabilities of SDO and makes use of convention to provide a progressive programming model. Now we‘ll walk through a complete example that demonstrates a few more RDB DAS capabilities.
A Complete Example (CompanyWeb)
In this example we‘ll display the steps involved in writing a simple application to work with companies and their related departments. First we need to introduce a new DAS concept; the DAS Configuration model. Although we‘re adding more options for leveraging conventions, there are still capabilities in the DAS that require configuration such as relationship definitions and database-generated IDs.
The DAS Configuration can be built up programmatically or loaded via an XML file. In this example we‘ll use the XML file approach.
We‘ll begin by accessing data from the Company table, defined as follows:
COMPANY:
ID NAME
We start by creating an XML file and add descriptive information for the database tables and columns. The snippet of XML below tells the DAS that the COMPANY table has a primary key column named ID that is auto-generated by the database:



Notice that we do not define the NAME column. There‘s nothing special about this column so we‘ll just take the conventional behavior offered by the DAS.
In the earlier examples we had the client pass a connection instance to the DAS for use during execution. An alternative is to define connection properties in the Config and have the DAS manage the connection for us. Here we choose to use a DataSource and provide the JNDI name:

Finally, we‘ll define a Command that the DAS will use to access the data. The following command will retrieve all companies from the database:

Now we can write an application to access the data and create a class called CompanyClient to handle interaction with the DAS. However, first we‘ll introduce a new DAS concept: the CommandGroup.
A CommandGroup is a logical grouping of commands and associated configuration data that serves two main purposes. Applications will often define commands that require the same configuration information and a CommandGroup binds the defined commands and the provided configuration data. For example, commands in the same CommandGroup will share the same connection properties and relationship definitions.
Secondly, a CommandGroup is initialized with Commands that it provides by name. Since the client retrieves commands by name and then executes them, the SQL-specific configuration can be contained in the group and isolated from the application. In theory, the same application could switch to using some other data store technology by changing the way the Config is initialized. For example, a Config could be initialized to use static SQL or even a non-relational back-end.
Since our application will use commands that share configuration, we‘ll use a CommandGroup and create one CommandGroup instance in CompanyClient and initialize it with our XML file.
private CommandGroup commandGroup = CommandGroup.FACTORY.createCommandGroup(getConfig("CompanyConfig.xml"));
private InputStream getConfig(String fileName) {
return getClass().getClassLoader().getResourceAsStream(fileName);
}
Now we‘ll create a method to return a List of Company DataObjects:
public List getCompanies() {
Command read = commandGroup.getCommand("all companies");
DataObject root = read.executeQuery();
return root.getList("COMPANY");
}
At this point, we have an application capable of returning a list of all companies in the database. Now let‘s add in another database table, Department:
DEPARTMENT:
ID NAME LOCATION NUMBER COMPANYID
The Department table is also using a primary key named "ID" that is auto-generated by the database, so its table definition will be similar to that of Company:



We have to define the relationship between Company and Department so that the DAS can construct a dynamic SDO model with a relationship between the two and correctly maintain those relationships in the database. The following XML snippet names the relationship, associates the keys, and specifies the cardinality:
foreignKeyTable="DEPARTMENT" many="true">


Now we can add a command to return all companies and departments:
SQL="select * from COMPANY left outer join DEPARTMENT on COMPANY.ID =
DEPARTMENT.COMPANYID" kind="Select"/>
Next we add a method to CompanyClient to access and execute this command. This method returns a list of Company data objects, but since the command employs a join with Departments, each Company will have its related Department data objects associated with it.
public final List getCompaniesWithDepartments() {
Command read = commandGroup.getCommand("all companies and departments");
DataObject root = read.executeQuery();
return root.getList("COMPANY");
}
Next we‘ll add the ability to retrieve a single company and all its departments. The configuration file is updated with this command definition:
SQL="select * from COMPANY left join DEPARTMENT on COMPANY.ID =
DEPARTMENT.COMPANYID where COMPANY.ID = :ID" kind="Select"/>
Note that we have defined a named parameter ":ID" in the SQL query. The CompanyClient uses the code below to access this command:
public final List getDepartmentsForCompany(int id) {
Command read = commandGroup.getCommand("all departments for company");
read.setParameterValue("ID", new Integer(id));
DataObject root = read.executeQuery();
return root.getList("COMPANY[1]\departments");
}
Now we‘ll add a write capability to CompanyClient. Since we‘ll let the DAS generate the CUD statements, no additions are necessary to the configuration file.
public final void addDepartmentToFirstCompany() {
Command read = commandGroup.getCommand("all companies and departments");
DataObject root = read.executeQuery();
DataObject firstCustomer = root.getDataObject("COMPANY[1]");
DataObject newDepartment = root.createDataObject("DEPARTMENT");
newDepartment.setString("NAME", "Default Name");
firstCustomer.getList("departments").add(newDepartment);
ApplyChangesCommand apply = commandGroup.getApplyChangesCommand();
apply.execute(root);
}
A complete example based on this company and department scenario, including a Web application used to access the CompanyClient, is available at the Apache Tuscany incubator project. The readme is available athttp://incubator.apache.org/tuscany/samples/java/samples/das/companyweb/readme.htm. The complete source is here:http://svn.apache.org/repos/asf/incubator/tuscany/java/samples/das/companyweb/
In the space of this article we‘ve shown some of the main capabilities of the Relational Database Data Access Service being developed at Apache‘s Tuscany incubator project. Here are other important supported capabilities:
Statically typed (generated) SDO DataObjects Optimistic concurrency control Stored procedures External transaction participation Write-operation ordering (database constraints) Simple name mapping (Table/Column -> SDO Type/property) Column-type conversions Paging
Business Benefits
Object-to-Relational Data Access - The RDB DAS provides a capable and flexible data access mechanism to applications integrating SDO technology. By employing the DAS, developers avoid developing a custom data access framework, a task that‘s tedious, complex, and error-prone.
Integrated with SDO - The Transfer Object pattern is often used by applications to move persistent state from one part of the application architecture to another. This is especially true if the data movement requires serialization. Such an application can employ some object-to-relational technology (JDO, EJB, Entity beans, etc.) to retrieve the data from a back-end data store and then copy the data to the DTO for transfer around the application.
The creation of separate TOs isn‘t necessary for an SDO-integrated application using the DAS because the SDOs themselves are easily serialized to XML. As a bonus to the TO pattern, the SDOs "remember" changes made to them and this memory is preserved through serialization/de-serialization.
Conclusion
The RDB DAS and SDO provide a simple and powerful way to access and work with relational data. The RDB DAS lets developers work with SDO without building custom data access solutions since the DAS works in terms of SDOs. It simplifies data access by hiding many of its complexities while still letting developers harness more powerful features in complex scenarios.
Because the RDB DAS integrates SDO technology, it‘s a natural fit for data access in the SCA framework. In fact, an RDB DAS implementation is evolving as part of the "Tuscany" SOA Apache incubator project along with implementations of SCA and SDO. The DAS is also on the roadmap for the upcoming SDO 3.0 specification.
The examples and code included in this article can be had from the Apache Software Foundation and licensed according to the terms of the 2.0 Apache License.
More information about the RDB DAS and the implementation under development can be found athttp://incubator.apache.org/projects/tuscany.
 
© 2007 SYS-CON Media Inc.