Most data is "fixed content," or digital information that will be preserved in its original form without change. Examples include most images (think of a medical X-ray or a canceled check); archived transactions; stored e-mail, presentations and business documents; and contracts, medical records and legal papers. EMC Corp. estimates that 80% of all stored data is fixed and that it grows by 90% annually.
For many organizations, federal regulations control what, how much and how long content must be retained. But for regulatory compliance, electronic discovery and corporate governance purposes, companies must be able to guarantee the integrity or authenticity of certain data, ensuring that the data we view now is the same as it was originally and hasn't changed over time.
Today's data glut, coupled with legal requirements and functional needs to store information for long periods of time, creates problems. How do we handle information from a variety of sources in different formats? What happens when technology and hardware change, making older stored data harder and more time-consuming to retrieve? When a company merges into an organization with different IT equipment and procedures, what happens to its data? And if retrieving data involves several conversion steps, how do we know it's unchanged?
A new set of standards, the Overview Extensible Access Method, aims to bring order to this chaos. XAM acts as a layer of abstraction between different operating systems, fixed-content applications (such as e-mail, file or database archiving products), and the data-access management software. This allows users to retrieve data regardless of what application created it. XAM also simplifies the migration of data from one disk subsystem to another, obviating the need for specialized middleware.
How It Works
XAM defines three primary objects. XSet is the basic addressable unit of data. A unique identifier is attached to data along with user-defined metadata -- things like the file's creation date or size or what project the data is associated with. XAM stores metadata in separate fields and binds these to the original data, creating one data object. The user or system can specify which fields can be modified; that's critical because unmodifiable fields protect the audit trail and guarantee authenticity.
An XSystem is a logical container of XSets that can provide capabilities outside XAM's scope -- such as security, migration, virtualization and performance.
The XAM Library implements an API that dynamically links applications to storage hardware. An application can communicate with multiple XAM storage systems through so-called vendor implementation modules (VIM), which are similar to device drivers. These pieces of vendor-written code translate XAM requests into device-specific actions. Thus, vendors needn't change products to use XAM; instead they can write VIMs and let XAM handle everything else.
XAM uses a query language, XAM QL, modeled on the SQL's Select statement. XAM queries aren't as powerful as SQL's general-purpose queries because XAM storage systems are generally designed as data archives, not as relational databases.
XAM grew out of an EMC system called Centera, which began shipping in 2002 and focused on fixed-content data. IBM grew interested in 2004, and Hewlett-Packard, Hitachi and Sun Microsystems joined the effort in 2005, at which time XAM was proposed to the Storage Networking Industry Association (SNIA) as a formal interface. As XAM developed, it grew to encompass non-fixed-data content.
In October 2007, SNIA announced successful interoperability demonstrations with hardware and software from EMC, HP, Sun and Vignette. According to SNIA, this showed that XAM can decouple data applications from storage systems, freeing user organizations from being locked into a single supplier on either end.
Kay is a Computerworld contributing writer. Contact him at russkay@charter.net.
Next: Opinion: Develop a storage security game plan