XAM API early draft specifications available

You have probably heard about XAM (eXtensible Access Method) before. It is a new type of storage API for applications to deal with Fixed Content. It was originally contributed to the SNIA last year and has made significant progress since then. Now the SNIA has published an early draft of the standard so that application vendors can get started on planning their use.

The XAM Architecture Specification version 0.6 is the meat of the standard. It describes the concepts and details the expected behavior of storage system that complies with the standard. Understanding this architecture is key to understanding how to work with a fixed content storage device that conforms to the standard.

The XAM API Specification version 0.6 is the initial C API that application vendors would actually code to. A Java API is also in progress and will likely be taken the to Java Community Process at some point. The XAM SDK TWG is off and running with this version of the specification and creating code inside of SNIA to implement the specification. The software will eventually be available under the BSD license once SNIA blesses the final version. If you want access to the SDK before then, the best way is to join the SNIA and participate in the work group.

Posted on: Jun 14, 2007

Posted by: mac

Category: General

Tags: none

Permanent link to this entry

Comments:

Can you explain the difference between the proposed Java version if this XAM spec and the already existing JSR 170 and update JSR 283? There seems to be considerable overlap. Could the new XAM Java spec be a subset of JSR 283?

Posted by Nick on June 17, 2007 at 06:42 PM MDT #

Nick, The JSR standards are great for Content Repositories such as Apace Jackrabbit (http://jackrabbit.apache.org/) in fact these can use (layer on top of) the proposed XAM API to manage content on the fixed content storage. My understanding is that the content repositories are not necessarily fixed content however, and do not implement any regulatory compliance policies.

Posted by Mark on June 17, 2007 at 07:29 PM MDT #

Thanks Mac for the quick response. Agree about difference in emphasis between CR and Information Lifecycle Management systems. If I understand the mechanism for specifying the lifecycle in XAM is to use "well defined" properties, this seems like a specific application of the general JSR 170 functionality of being able to associate attributes with data. Following on from that, would the proposed Java version of the XAM spec be just assigning policy meanings to certain attributes and maybe defining which JSR 170 methods wouldn't be available (throw an exception) if the repository was really an XAM - type system? What I would like would be to leverage a common way for applications to populate and browse/navigate data no matter what style of repository is backing it, and there seems to be significant overlap between CM and ILM systems regarding this functionality.

Posted by Nick on June 17, 2007 at 10:09 PM MDT #

XAM is not about ILM per se, although fixed content does have a life cycle, and a XAM storage system can be used as the last tier of a hierarchy to archive data that likely won't change. However, ILM is about classifying data and achieving each class of data's requirements of performance, availability and security as they change over the life of each piece of data. As part of an ILM system, XAM can be used for specific types (or classifications) of data - those that have associated, application defined meta-data, are essentially write-once/read-many and need to be retained, by law, for a specific period of time. Obviously, not all data has these requirements. As regards to JSR 170's association of attributes, these would be mapped to application specific meta-data in XAM for each object that the JSR repository stored. I don't see this as "overlap", but as the ability to support those attributes by XAM. The well defined attributes, on the other hand, are those which the XAM storage system understands and for which an application cannot modify the semantics. These include retention policies for how long to keep the file and so forth.

Posted by Mark on June 17, 2007 at 10:34 PM MDT #

Post a Comment:
Comments are closed for this entry.

This blog copyright 2009 by mac