Andy Grove's Weblog

SDO 2.1 Specifications

Thu, 26 Oct 2006 09:29:28 +0000

SDO 2.1 Specifications are now available in draft versions for both Java and C++ from the OSOA web site:

http://www.osoa.org/display/Main/Service+Data+Objects+Specifications

Open Service Oriented Architecture (OSOA)

Thu, 27 Jul 2006 09:24:54 +0000

The Open Service Oriented Architecture (OSOA) collaboration have launched a new web site. Draft versions of the latest SCA and SDO specifications are now available from this site.

Google Office

Mon, 24 Jul 2006 19:47:37 +0000

My last blog post was about my new PDA, the O2 XDA Exec, which runs Windows Mobile 2005. After a few experiments with different approaches to email using the XDA I've finally settled on using gmail's web interface. Why? Well, because of the volume of emails I receive (and yes, the bulk of it is spam) it takes too long (and is too expensive) to download emails when I'm away from home (there could literally be thousands of emails if it's been a few days since I last checked email on the phone). Using Gmail, I can instantly see the most recent emails and then scroll down to see older ones. Gmail has a special version of its web interface for use on mobile phones and PDAs so it's pretty quick. Since using this approach I've realised that Gmail is actually much easier and faster to use than Outlook on my laptop too, and because I do some of my development work on a linux desktop it makes sense to use it there as well. It doesn't take much of a leap to see that having an online word processor (see Google's acquisition of Writely) and online document storage (rumours abound about the "G" drive) would make life much easier for users who travel frequently and/or have multiple machines that they need to use. With this infrastructure in place I really would have little reason not to buy a MacBook Pro for my next laptop.

O2 XDA Exec

Fri, 30 Jun 2006 10:32:25 +0000

I've been wanting a mobile device with good email capabilities for a while now and I finally settled on the XDA Exec from o2 in the UK. The features that sold me on the product, in order of importance:

WiFi connectivity
3G
Full QWERTY keyboard
Windows Mobile 2005 with Outlook + Push Email
Mobile versions of Outlook, Word, Excel
PDF viewer
It looks cool ;-)

I can now pick up emails at no cost using my WiFi connection at home or in the garden. Also, at WiFi hotspots I can download emails and surf the internet much faster than when using a phone connection.

Another cool benefit is that I can run Skype on the phone so I can get cheap international calls if I'm in a WiFi hotspot.

The keyboard is by far the best keyboard I have used on a mobile device and it's actually feasible to write short emails on it.

If you decide to buy one of these you definitely need to set aside at least half a day to get it fully setup. I ran into some issues getting ActiveSync to work. It wouldn't work at all on 2 PCs but did work on the 3rd PC I tried. All of the PCs are running Windows XP Pro SP2 and the only difference I can think of is that the two that failed to work have USB2 ports rather than original USB. I had to apply the following XP patch so that the device is still recognized after a reboot (of either the device or the PC)

http://support.microsoft.com/?kbid=838989

I then downloaded the software update from the o2 site that brings the CE image up to version 1.30.107. The update is available here:

http://xda.o2.co.uk/xdaExecSoftware.aspx

The update gives a warning about not disconnecting the device until the upate is finished as it could leave the device in an usable state. Imagine my horror when a few seconds into the install the device appeared to power down and the installer failed with a connection error. The device hadn't powered down but had gone into some boot state with the text "USB" and "v1.00" at the top and bottom of the screen respectively. I was unable to power the device back up to its normal state after this so I tried running the software update installer again and this time it worked correctly.

SDO Metadata

Thu, 09 Mar 2006 10:20:46 +0000

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.

A code sample speaks a thousand words, as they say, so here's an example for accessing metadata about a database table using the SDO metadata API:

// create the Data Access Service
SQLDataAccessService das = SQLDataAccessServiceFactory.create( "sampledb" );

// select some rows from the customer table
DataGraph data = das.selectRows( "customer", "state = ?", new Object[] { "MA" } );
DataObject root = data.getRootObject();

// retrieve a customer and query its type
DataObject customer = root.getDataObject( "customer.0" );
Type customerType = customer.getType();

// look up a property (column) of the customer object
Property idProp = customerType.getProperty( "id" );

// examine the data type of the "id" property
assertEquals( "commonj.sdo", idProp.getType().getURI() );
assertEquals( "Int", idProp.getType().getName() );

This is a simple example, but the capability is demonstrated well enough. It is possible to query the type of any DataObject and then get a list of properties supported by that type. This makes it possible to build dynamic applications for interacting with SDO data sources (for instance, a data browser/explorer interface) regardless of the type of data source (relational database, XML repository, etc.).

SDO also defines its own data types to ensure that applications can be built in a portable way between languages and data sources. Mappings between SDO data types and Java data types are defined in the SDO for Java specification.

Comparing SDO with DAO

Wed, 01 Mar 2006 20:30:28 +0000

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.

Scripting with SDO

Tue, 21 Feb 2006 14:10:28 +0000

One of the nice things about SDO is that the dynamic DataObject API provides an ideal way of passing structured data into rendering engines or JSP pages. It also enables much easier scripting of database driven web apps with ease of use to rival, if not better, scripting languages such as PHP.

Here’s an example of a JSP page to display the contents of a particular table:

<%@ include file="header.jsp"%>

Customers

<%
// get a list of customer objects
List list = das.getTableRows( "customer", "1=1" );

// iterate through the list
Iterator iter = list.iterator();
while (iter.hasNext()) {
DataObject customer = (DataObject) iter.next();
%>

<%
}
%>

Customer Name	Country	Licenses
<%= customer.getString( "name") %>	<%= customer.getString( "country") %>	<%= customer.getString( "licenses") %>

<%@ include file="footer.jsp"%>

In this example, the header.jsp contains some basic layout and the necessary Java imports and code to initialise the data access service (the ‘das’ variable).

The beauty of this approach compared to using JDBC directly, apart from the drastic reduction in source code, is the fact that there is no need to manage connections or close our resources. Also, the DataObject can be stored in a session, modified in subsequent pages and then can be passed back into the DAS to update the database.

Here’s a JSP scriptlet to perform an update (this would likely be in a page which is the target action of an HTML form).

<%
DataObject customer = (DataObject) request.getSession().getAttribute("customer");

customer.setString( "name”, request.getParameter("name") );
customer.setString( "country”, request.getParameter("country”) );
customer.setString( "licenses”, request.getParameter("licenses") );

das.applyChanges( customer );
%>

For enterprise web applications using servlets and/or a web framework such as Struts or Spring MVC, much of this code would be encapsulated in action classes but the SDO DataObject can still be used as a convenient way of passing data to a JSP page for rendering.

JUnit 4.0 Design Madness

Thu, 16 Feb 2006 15:23:57 +0000

Like most Java developers, I'm a big fan of JUnit as it provides such an easy way to build standardized test cases and integrate them with Ant-based build systems. There is a thread on TSS today announcing the release of JUnit 4.0 and I could hardly believe what I was reading. I quote:

"The architecture of JUnit 4.0 is a substantial departure from that of earlier releases. Instead of tagging test classes by subclassing junit.framework.TestCase and tagging test methods by starting their name with 'test', you now tag test methods with the @Test annotation."

In short, to use JUnit 4.0 we must re-write all of our existing test cases to use annotations rather than extending TestCase! Not only that, but JUnit 4.0 only works with JDK 1.5 due to the use of annotations!

Did anyone out there actually *not* like the simple design of JUnit? What exactly was wrong with extending TestCase? What benefit does this new design offer over that approach?

I really can't fathom the logic behind this. Surely it would have been possible to support the current model of extending TestCase in addition to being able to use annotations. For such a popular library with such a large install base I find this truly shocking. I'm really hoping that the TSS thread is misleading and that the annotation feature is an optional extra on top of the existing functionality. If not, then its time for someone to fork JUnit 3.8.1 ...

FireStorm/SDO: Service Data Object

Tue, 31 Jan 2006 19:38:48 +0000

Today we announce the Early Access Program for a new product, FireStorm/SDO, which is based on the Service Data Object (SDO) specification.

FireStorm/SDO consists of an SDO code generator and an SDO runtime.

The Service Data Object specification is relatively new but I believe that SDO is going to become a major standard for accessing data from Java, particularly in applications that use a Service Oriented Architecture (SOA).

SDO offers a number of compelling features:

• Single API for accessing data from any data source
• Access and update data using XPath expressions
• Choice of Dynamic API or Static (code-generated) API
• Can be used as connected or disconnected model
• Integrates well with SOA applications

Overview of the Service Data Object API

The SDO runtime uses the DataGraph and DataObject interfaces to represent data. These are conceptually similar to the Document and Element classes used to model XML documents. The DataGraph contains a single root DataObject. A DataObject can contain simple properties and can contain other DataObjects.

The DataGraph keeps track of any changes made to the data objects it contains and can then provide the SDO runtime with enough information for it to update the data store at the end of a transaction.

Code Sample using Dynamic API

The SDO API is dynamic in nature, allowing applications to be built without the need for code generation.

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” );
}

Code Sample using Code Generated Static API

FireStorm/SDO can generate static classes that extend DataObject and provide schema-specific type-safe methods for accessing data while still allowing the dynamic API methods to be used.

Using the code-generated classes, it is possible to cast DataObjects to specific application classes (in this example, 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();
}

The beauty of either of these approaches is that it not only abstracts the end user away from the mechanics of JDBC and SQL for most common tasks but that it also abstracts away from the fact that the user is dealing with a database, rather than say, an XML document. Indeed, moving data between databases and XML (and therefore Web Services) ought to be a lot easier with SDO.

Resources:

New Laptop

Sat, 28 Jan 2006 15:03:26 +0000

I ordered a Sony Vaio S5XP/B from Laptops Direct yesterday at 4pm and it arrived this morning at 9am. Now that's service!

Its much smaller than my last laptop which was a huge 4kg desktop replacement. The new one weighs in at 1.9kg and has a 2GHz Pentium M processor, 2GB RAM, and a 100GB SATA HDD. The widescreen display will take a bit of getting used to but I'm pretty happy with the machine so far. It came pre-installed with XP and I've now set it up as a dual boot system with Ubuntu as the other O/S. Ubuntu installed pretty smoothly on this machine.

In terms of raw CPU power it's not as fast as I would have liked but the small size makes it ideal for when I'm on the road compared to my last laptop, which was really only usable when I had a desk available due to its bulky size.

Anyone got a spare laptop?

Fri, 27 Jan 2006 12:26:49 +0000

My previous posting was prompted by a corrupt hard drive on my desktop machine which I have now resolved.

And now, with just 8 days to go until a business trip to the US, my 3 year old Sony Vaio has decided to stop working. It's developed some sort of hardware fault with its screen that has made it unusable. Sony are picking it up on Monday to investigate and give me a quote for repairing it but there's no way they can do it in time for my trip.

3 years is a pretty good life span for a laptop and I have been frustrated with its performance lately so it was probably about time to upgrade anyway.

Sony have just launched their next-generation Vaio SZ which looks like the ideal replacement (dual core, big disk, 7 hours battery life etc.) but they won't be available in time. The frustrating thing is that they look to be reasonably priced and will probably even be available during my trip to the states but that doesn't help me at all.

Ideally I need a laptop by Wednesday morning to give me enough time to get everything set up that I need for the trip. The timing couldn't be much worse.

Essential Software

Wed, 18 Jan 2006 11:30:29 +0000

Unfortunately a corrupted hard drive meant I had to reinstall my main desktop machine from scratch on Monday. My most important data - my source code - is always backed up in version control and on build machines so I wasn't too worried about the risk of losing anything but the real cost was 24 hours lost productivity. However, it did hit home that I don't have adequate backups of my Outlook PST files (more than 2GB worth) so I'm going to take steps to improve that soon.

My machine is running fine now. In fact it's running much faster - as is the way just after a fresh install. I might even invest in a copy of Norton Ghost and a DVD burner for this machine so I can do fresh installs more easily in the future.

Over the year or so since I installed this machine I've built up the usual collection of software products that bloat the machine and a reinstall is the perfect time to reflect on what's actually essential, useful, or redundant.

The essentials are pretty unsurprising:

Windows XP Professional SP2
Norton Antivirus
Microsoft Office
Cloudmark Spam Filter
Firefox
Trillian
Skype
WinZip Pro

Then the main development tools:

After that, there's a whole host of open source Java class libraries and products too numerous to mention here but most of these are in version control anyway so I don't need to reinstall them individually.

And what will I leave off this time? Basically all the gadgets, toolbars, and background processes that slowly but surely reduce system performance and increase memory usage. The only product that I'll miss in this category is Google Desktop but since I only have two places to look for data - My Documents and Outlook - I'll just have to learn to be more organized and a bit more patient when searching for data.

CodeFutures forms alliance with Rogue Wave Software

Fri, 16 Dec 2005 09:45:49 +0000

CodeFutures has announced a strategic alliance with Rogue Wave Software to produce new products complementary to their recently announced SOA platform, known as Rogue Wave Hydra.

Those of you from a C++ background will no doubt already know about Rogue Wave and their reputation for producing excellent cross-platform development tools. I am pleased to see Rogue Wave moving into the SOA and Java space and even more pleased to be a part of that effort.

As a first step, we will be extending FireStorm/DAO so that it can generate DAO services that can be directly deployed into the Hydra platform, enabling rapid assembly of business processes. We are also busy evaluating ideas for new products that are complementary to Hydra.

FireStorm/DAO will remain core to our strategy going forward and we are already working on the feature list for the next release.

The full press release can be found here:
http://www.codefutures.com/rogue-wave-hydra-alliance/

John Crupi blogs about FireStorm/DAO

Fri, 09 Dec 2005 08:50:25 +0000

John Crupi has blogged about FireStorm/DAO. John is CTO of the Enterprise Web Service Practice at Sun Microsystems.

Rogue Wave Hydra Announced

Wed, 07 Dec 2005 13:29:41 +0000

Rogue Wave Hydra has been announced this week. Here's the product description from Rogue Wave's web site:

Rogue Wave Hydra is a standards-based distributed SOA framework that enables an order of magnitude performance improvement in your enterprise applications–new or existing.

I have been working with an early access version of Hydra for a few weeks now and I'm pretty excited about its potential. It allows massively scalable business processes to be built using a pipeline concept where tasks can be executed in parrallel. I'm still getting up to speed with the capabilities of the product but its certainly very powerful from what I have seen so far. It's quite a different concept from many of the other SOA products I have worked with and its clear that Rogue Wave have put a lot of thought into their approach.

The main reason I am working with Hydra is to add support to FireStorm/DAO so that developers can generate DAO services that can be accessed by Hydra processes.

There is a nice flash presentation that gives a concise overview of Rogue Wave Hydra.