Comparing SDO DAO

Comparing SDO with DAO
Earlier today, I was asked to explain the difference between SDO and DAO. I did not have a short and succinct answer ready at the
time so I decided to put together this short article for future reference.
I thought it would be useful to start with the descriptions of DAO and SDO from their respective creators.
From the Core J2EE Design Patterns - Java Blueprints Web site:
The Data Access Object (or DAO) pattern:
• separates a data resource's client interface from its data access mechanisms
• adapts a specific data resource's access API to a generic client interface
The DAO pattern allows data access mechanisms to change independently of the code that uses the data.
From the SDO specification:
Service Data Objects (SDO) is a data programming architecture and an API.
The main purpose of SDO is to simplify data programming, so that developers can focus on business logic instead of the underlying
technology.
SDO simplifies data programming by:
• unifying data programming across data source types

• providing support for common application patterns
• enabling applications, tools and frameworks to more easily query, view, bind, update, and introspect data.
So there are some obvious similarities between the goals of DAO and SDO. Most notably:
• Both SDO and DAO provide a language-native API to abstract client code away from underlying data source APIs
• Both SDO and DAO can be used with any data source (database, XML document, enterprise system etc)
However, there are some significant differences:
• DAO is a design pattern and SDO is a specification. This is a huge difference. Because SDO is a specification,
vendors can build standards-compliant tools, drivers, and frameworks. This means that rather than having developers
manually design and code DAO objects from the ground up at the start of each new project it is more likely that
developers will utilize existing tools and frameworks for SDO and significantly reduce development time and costs. It
should be noted that tools, such as FireStorm/DAO, do exist for DAO developers today but because DAO is not
standardized and is not based on a specification, these tools are not liked by some developers.
• SDO offers a disconnected model where a data graph (a hierarchical collection of data objects) can be modified
offline from the data source and easily passed between distributed services (as a Java object or as an XML document)
and then sent back to the Data Access Service later on where the changes will be applied to the data source. The DAO
design pattern does not cater for these requirements.
• SDO offers both a dynamic API and specifies how a static API can be code-generated from the data source’s
schema. This gives the user a choice between dynamic and static API access to their data and both can be used in the
same application. DAO does not offer a dynamic API therefore forcing the developer to drop back down into a lower-
level API, such as JDBC, whenever dynamic access is required.
• SDO defines a set of SDO data types to ensure portability between different data source types and for
compatibility between languages. To date, SDO implementations exist for Java, C++, and PHP. DAO is a Java standard
and does not address these issues.
• SDO is particularly well suited to applications based on the Service Oriented Architecture (SOA) design pattern.
The latest version of the SDO specification was released in conjunction with the Service Component Architecture (SCA)
specification. SCA enables peer-to-peer interactions between services in a distributed SOA architecture. SCA is the
industry response to Microsoft’s Indigo/WCF strategy and is probably the most important development in SOA/Web
Services in the past couple of years.
The most obvious question is when to use DAO and when to use SDO.
DAO is an excellent choice for abstracting away from persistence technologies such as JDBC, EJB CMP, or Hibernate, because it
provides a way to insulate the data access code in an application from the underlying persistence technology (which can be then
changed as required) as well as simplifying application development. When the DAO code is code generated using tools such as
FireStorm/DAO then development time can be drastically reduced.
SDO is an excellent choice for applications that are used in service-oriented architectures, in environments with multiple
programming languages, or where disconnected data access is required.
SDO versus EJB 3.0

The purpose and objectives of the SDO 2.0 and EJB 3.0 (sometimes referred to as Java Persistence API - JPA) specifications are so
different that it is possible to say that they are complementary rather than competing.
SDO is a very ambitious attempt to provide a single, highly flexible API for all types of data in Service Oriented Architectures. EJB
3.0 is aimed making EJB more simple, with the new data persistence support based on Object Relational Mapping (ORM), with
strong contributions from the Hibernate and Oracle ORM tool developers.
Language Support
-EJB 3.0 is Java-only
-The SDO API is published in both Java and C++, but also possible to implement in other programming languages (there's a PHP
implementation). SDO defines a set of SDO data types to ensure portability between different data source types and for
compatibility between languages. To date, SDO implementations exist for Java, C++, and PHP. EJB 3.0 is Java only does not
address multi-language data compatibility.
Data Types and Formats

-EJB 3.0 data persistence is aimed at relational data held in databases
-SDO is for any type of data, with relational data only one example. When developers learn the SDO API, they can access any type
of data supported by the SDO implementation they are using. As well as providing a standardized API for accessing data across
multiple data sources, SDO also provides a common API for accessing metadata about the data source. While the SDO data access
API provides DataGraph and DataObject interfaces for accessing and updating data, the SDO metadata API provides Type and
Property interfaces.
EJB 3.0 is Based on ORM, Whereas SDO is Focused on Data

-EJB 3.0 is strongly based on ORM technology, which is designed for persisting data in an Java objects to a relational database
(known as the 'logic first' approach) or mapping between the Java objects and an existing relational database (known as the
spaghetti junction approach).
-SDO takes a 'data first' approach, where it is assumed that the database will be optimized (and normalized) and may last longer
than the actual business application. Assuming that the database is the focus point for the data, FireStorm/SDO reverse engineers
the database schema to produce the persistence code.
SDO is for Service-Oriented Architectures

-EJB 3.0 is for traditional stand-alone (monolithic) Java applications, typically with client-server architecture
-SDO supports the concept of disconnected programming model, making it ideal for service-oriented architectures. The
disconnected DataGraph means that databases are not locked because data is modified offline.
SCA and J2EE Specifications

-EJB 3.0 is part of JEE (the rebranded J2EE), which has been the dominant application development platform for the past several
years
-The latest version of the SDO specification was released in conjunction with the Service Component Architecture (SCA)
specification. SCA enables peer-to-peer interactions between services in a distributed SOA architecture. SCA is the industry
response to Microsoft's Indigo/WCF strategy and is probably the most important development in SOA/Web Services in the past
couple of years.
Tightly versus Loosely Coupled

-EJB 3.0 is embedded and tightly coupled within an application
-SDO implementations can be designed for a lightweight and distributed architecture. The SDO specification enables both a static
(or strongly typed) programming model and a dynamic (or loosely typed) programming model.
With such different objectives and characteristics, it's not possible to say if EJB 3.0 or SDO are 'better' data persistence
specifications. However, that does make it possible to produce some broad guidelines:
If you are developing a traditional (non SOA) application and only have relational data and are only developing in Java, then EJB
3.0 is a good choice.
If you are developing using a SOA, if you need to access multiple types of data, then SDO is a good choice.

Comparing SDO DAO

Uploaded by

Copyright:

Available Formats

Comparing SDO DAO

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Comparing SDO DAO

Uploaded by

Copyright:

Available Formats

Comparing SDO with DAO

The Data Access Object (or DAO) pattern:

From the SDO specification:

Service Data Objects (SDO) is a data programming architecture and an API.

SDO simplifies data programming by:

• unifying data programming across data source types

However, there are some significant differences:

SDO versus EJB 3.0

Data Types and Formats

EJB 3.0 is Based on ORM, Whereas SDO is Focused on Data

SDO is for Service-Oriented Architectures

SCA and J2EE Specifications

Tightly versus Loosely Coupled

You might also like