This article was originaly posted to the Royal Jelly blog: http://weblogs.java.net/blog/macsun/
The eXtensible Access Method (XAM) is new kind of storage interface for storage devices that can handle a special type of data, called “Fixed Content“. Version 1.0 is soon to be released, but there is a working draft available of the Architecture Specification, the C Language Binding and the Java Language Binding. It is this last document that this post covers. A good introduction to XAM is the beginning chapters of the Architecture specification, and that document covers the normative behavior required for implementations of the interface.
The primary Java Object that applications deal with to store and retrieve data is called an Xset. It is the object that is the container for both the data as well as the associated metadata. XSet metadata goes beyond the typical filesystem metadata, and adds fields for retention and other data management policies. Applications can also add their own metadata as well. This is a key requirement in the fixed content storage market. Any of the metadata in the XSet can be queried for later, in order to find the XSet.
But before we dig into the XSet, let’s talk about the other primary objects of the XAM Interface. First is the notion of a system that will contain the XSets. We call this storage system an XSystem in the abstract. The XSystem object is also the factory for XSet objects (via create and open methods). Now any given host may have access to any number of XSystem storage devices, so we need a way to create XSystem objects for each system we need to access. We do this through an object called the XAMLibrary. The XAM Library manages all the connections to the storage devices and acts as a factory for XSystem objects. It does this through the connect() method:
public XSystem connect(String XRI)
The XRI (XSystem Resource Identifier) string is a “handle” that is used to load the correct Vendor Interface Module (VIM) for the device and locate it, perhaps on the network. It has the following syntax:
"snia-xam://" [vimname] xsystemname [params]
The XSystem object that is returned from the connect() operation can now be used to talk to the storage device. The first thing we will need to do is to authenticate with the device, to prove that we are who we say we are. This is done through the authenticate() method:
public byte authenticate(byte buffer)
See the Architecture Specification for a more detailed description of the steps required to authenticate to an XSystem.
So we have the three primary objects of the interface: XAMLibrary, XSystem and XSet. All of these objects have properties which are accessed in the same way. These properties can be of several different types and can be created at runtime. Thus we need a way to do this in a type safe manner. The key to this capability is something called an XIterator:
public interface XIterator extends Iterator
public void close() throws AuthenticationExpiredException, XAMException;
Many of the basic operations on the fields these primary objects contain are in common, so the XAM interface defines a superclass for the primary objects called FieldContainer:
public interface FieldContainer
XIterator openFieldIterator(String prefix)
throws AuthenticationExpiredException, InvalidFieldNameException,
The XIterator returned from openFieldIterator() can contain all properties, or just a subset (those having a name starting with “prefix”). The FieldContainer Java interface also contains methods for: field interrogation; property creation, accessors, and mutators; field operations, and XStream operations. An XStream is an object that can contain the actual content associated with an XSet. XStreams have operations to read and write the content using various means both synchronously and asynchronously. The type of data an XStream holds can be any valid Mime type.
This post covers most of the basic objects that are part of the XAM interfaces. Future posts will delve into specific use cases.
Update: original Sun Blog post: 6/16/08