CodeFutures News & Industry Commentary Blog

I have had several requests for an SDO code sample. The SDO code samples below have been published elsewhere on the CodeFutures site, but I am providing them here as well for reference purposes.

If you really want a proper SDO code sample, the best way is to do an SDO download and generate your own SDO code sample using FireStorm/DAO

SDO Code Sample for Dynamic SDO API

DataGraph graph = db.executeQuery( “select * from customer” );
DataObject root = graph.getRootObject();

// use xpath to get the name of the first customer
String firstCustName = root.getString( “customer[0]/name” );

// iterate through all customers
Iterator iter = root.getList( “customer” ).iterator();
while (iter.hasNext()) {
DataObject dataObject = (DataObject) iter.next();
String custName = dataObject.getString( “name” );

SDO Code Sample for Static SDO API

In the SDO code sample below, customer is a generated class that extends DataObject).

// iterate through all customers
Iterator iter = root.getList( “customer” ).iterator();
while (iter.hasNext()) {
Customer customer = (Customer) iter.next();
String custName = customer.getName();

PJ Murray
CodeFutures Software

The SDO metadata API is a good example of the features of the SDO specification that make it the obvious choice for SOA data access. Andy Grove has already written about a short technical note on SDO metadata, but there is almost nothing written about the business value of the SDO metadata API.

One of the best articles on metadata provides information on the value of metadata that is mostly applicable to the SDO metadata API. The article is written in the context of general metadata, but is mostly applicable to SOA data services in general, where the SDO metadata API should be useful.

PJ Murray
CodeFutures Software

The idea of a PHP SDO is nothing new. In fact, Zend Technologies, often considered the top PHP company, has been supporting a PHP SDO for some time. Although the PHP SDO API is not yet part of the specification, there is no reason why it can not be added. The recent story in searchWebServices about IBM investing in PHP SDO is interesting, because it raises the possibility that a PHP SDO API will be added to the specification.

Brein Nally of searchWebServices provides a very nice summary of the value proposition of a PHP SDO (or in fact, any SDO implementation):

SDO can work with data regardless of the source, unifies it within the context of an SOA and integrates it with XML.

While the additional IBM support for SDO in the form of the PHP SDO is welcome, it would probably be much hotter industry news if IBM announced the integration of AJAX and SDO.

PJ Murray
CodeFutures Software

The status of the SDO JSR - known as JSR 235 - is unclear. It was promoted by BEA and IBM in the JCP and approved very quickly. However, the second version of the SDO specification was not submitted to JCP. In fact, the scope and context of the SDO specification has changed completely:

• SDO is now a multi-language specification, with the second version including a C++ SDO API and unofficial PHP implementations already available.
• SDO is now supported by several of the major industry vendors, including Oracle, Rogue Wave Software, SAP, and Siebel.
• SDO is now positioned as the SOA data services API. The lack of a standard API for data access in SOA was an unusual situation. The Java-only SDO JSR was not really in a position to become the standard API.
• SDO is now directly associated with Service Component Architecture, which is considered by industry analysts to be a very important strategic move by several vendors outside the JCP

This all means that the SDO JSR is probably finished. Version 2.0 and onwards of the specification will not be submitted to the JCP.

PJ Murray
CodeFutures Software

The C+ SDO API has been pretty much ignored in most of the material written so far about the SDO, even articles about the SDO API do not mention the C++ SDO API. The primary focus has been on the key benefit of SDO - a single API for any type of data, specifically designed for use in Service Oriented Architectures. It is usually overlooked that there is a C++ SDO API in version 2.0 of the specification and CodeFutures has been equally guility of overlooking the C++ SDO API since our focus is exclusively Java. I'm sure there are many large enterprises with many (if not most) of their mission critical systems still written in C++ and with no plans to rewrite them in Java (if it's not broken, don't try to fix it....). So it's good that IBM's developerWorks has recently published a good article by Ed Slattery and Pete Robbins on the C++ SDO API.

PJ Murray

CodeFutures Software

There's a great new article by Michi Henning in ACM queue about "The Rise and Fall of CORBA" that is the best account I've read so far of how the technology failed so quickly. The writer is fairly gentle with Microsoft and DCOM, which in fact was a huge focus of bitterness from CORBA vendors.

One of best discussions on the failure of CORBA is here.

The CORBA story provides many lessons in general for industry standardization, but particularly for SOA.

PJ Murray
CodeFutures Software

IBM staffers Anh-Khoa Phan and Eric Herness have written a short technical paper on Java SCA Invocation Styles.

An abstract is provided:

This article offers an overview of Java usage within the Service Component Architecture's (SCA) Plain Old Java Object (POJO) component and the data flow in and out of POJO components. You will see the effects of different invocation styles when they are used within a POJO component.

The paper describes two styles of Java SCA invocation: dynamic invocation interface (DII) and strongly typed.

PJ Murray
CodeFutures Software

David L. Margulius has written an interesting article in Inforworld on the problems with the market for grid computing as a solution to providing high performance and scalability. Some of the problems associated with grid computing are summarized in one paragraph of the article.

So, is grid swimming against the tide of simplicity here? Kind of, according to the 451 Group. Grid-enablement means writing or rewriting apps and all the associated APIs, the report says. Challenges include job splitting, division and queuing, shared memory, and data management, as well as managing the potential for a “deadly embrace” or “deadlocking” between two apps sharing the same infrastructure. And, the report continues, “managing the output from a job run on a grid is another pain point, as are caching and the wider integration between storage, compute, and network resources.”

The article refers to some research from The 451 Group that indicates that the challenges of using grid computing include:

• Running an application in a distributed environment creates challenges related to job splitting, division and queuing, as well as with shared memory and data management.
• Running a job across a grid requires the use of shared infrastructure, presenting the danger that two applications will want the same resource at the same time, which is known as 'deadly embrace' or 'deadlocking.'
• Managing the output from a job run on a grid is another

The 451 Group has published a 68-page report, including what I presume must be horror stories from early adaptors, given the tone of the conclusions in the press release.

It's good to see solid research finally coming out about grid computing. It sounds like the technology has a long way to go before it is mainstream.

PJ Murray
CodeFutures Software

Edward J. Correia of SD Times has written a interesting article on SDO and SCA called With Objects, App Components Ready for SOA, Data Is Next on Tap. The article does a very good job of explaining the purpose and significance of SDO and SCA. It is also the first time that a major industry magazine has published a leading story on SDO and SCA. What is also interesting is that several articles have been published on SDO and SCA in the past few weeks, including overviews on SDO and SCA on SearchWebServices (called A primer on Service Component Architecture and SDO - Service Data Objects, both well written by Daniel Rubio). The increased press interest in SDO and SCA is probably because major vendors are now preparing for the launch of SDO and SCA-based products later this year.

PJ Murray
CodeFutures Software

Tim Bray (famous for writing the XML specification and the first XML processor) has published an interesting article on grid technology that is maily focussed on Tim's specialist area of XML and Web technologies. One of the most interesting comments Tim makes is that:

Memory space and compute cycles are pretty cheap. Disk space is effectively free. Moving data around in large quantities is expensive.

So why what has this got to do with SDO implementations?

There are two architectural approaches to implementing a product based on SDO: the centralized platform approach or the lightweight/distributed approach.

The SDO Data Services Platform

The 'platorm approach' where there is a central SDO platform. This is the approach used by BEA's SDO product, the Aqualogic Data Services Platform. The central SDO server handles all incoming SDO requests and has multiple Data Access Services for multiple types of data. The benefit of this approach is that BEA's starting price is $20,000 per CPU, which is great for large enterprise size sales. A key drawback of the platform approach is that it means moving data in a network via a centralized hub. This is the same hub-and-spoke architecture that is used in traditional EAI products. If you have data at point A in the network and an application that needs to access that data in point B, the request needs to pass through the centralized data platform. That means moving a lot more data around the network, which Tim Bray has pointed out is very expensive.

The Lightweight and Distributed SDO

-'distributed approach' where the SDO implementation is lightweight and generally is highly focussed on the type of data is handled. This approach implies that you deploy the SDO implementations throughout the network beside the datasouce and application (if possible), or alternatively beside either the data source or application. There's no centralized SDO server and therefore no data traffic to third-party servers.

The Vendor Dilema

A problem with the centralized platform approach is that it becomes a performance bottleneck. Of course, you could distribute the centralized data services platform everywhere you need data access, but that's not lightweight (a larger deployment footprint, for example, will leave less memory available for the actual application, reducing overall performance) . Selling an entire platform rather than a lightweight component does have the advantage of generating lots of extra revenue for product vendors like CodeFutures. After all, it's always profitable to insist on a higher price because you sell functionality that is not going to be used.

PJ Murray
CodeFutures Software

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.

PJ Murray
CodeFutures Software