Skip to main content

eXtensible Access Method (XAM)

The XAM (eXtensible Access Method) Interface specification “defines a standard access method (API) between Consumers (application and management software) and Providers (storage systems) to manage fixed content reference information storage services. XAM includes metadata definitions to accompany data to achieve application interoperability, storage transparency, and automation for ILM-based practices, long term records retention, and information security. XAM will be expanded over time to include other data types as well as support additional implementations based on the XAM API to XAM conformant storage systems.”

The SNIA XAM standard access method is designed to benefit storage vendors, software developers and the end user community. It provides:

Interoperability : applications can work with any XAM conformant storage system, information can be migrated and shared.

Compliance : integrated record retention and disposition metadata.

ILM Practices : a framework for classification, policy, and implementation.

Migration : the ability to automate migration process to maintain long-term readability.

Discovery : application-independent structured discovery avoids application obsolescence.

XAM anticipates that objects will migrate from one storage medium to another during their lifetimes. For instance, 10-year-old medical images stored on tape are now being migrated to disk. Ten years from now, images in disk-based archives may wind up on a storage platform that hasn’t been invented yet.

XAM relies on a flat address space that isn’t tied to a specific storage device. XAM also assigns each object (for example, an e-mail message) a unique identifier that exists for the lifetime of the object. The identifier doesn’t change even if the object is moved from one storage system to another, making it findable and able to be traced to any XAM-enabled device.

XAM also has a language to express metadata about the object. This metadata will provide key information about each object that can be used to apply policies, such as a retention period, without the need for the app that created the information to access the object.

XAM has standardized the language for expressing metadata, and work is ongoing to create standard formats for different content types. For instance, likely metadata formats for e-mail will include sender, recipient, and subject. The creators of the standard had an eye on electronic discovery. XAM can search metadata, a key requirement for legal discovery and internal corporate investigations.

To meet the industry challenges, the storage industry requires a set of standard interfaces to enable more functional and sophisticated products. These interfaces need to allow multiple vendors to provide different classes of hardware and software products that store, retrieve, and manage reference information reliably and seamlessly.

XAM Approach

XAM provides an application programming interface (XAM-API) that allows XAM applications to store data in a fashion that does not depend on the specific storage system. XAM provides the following important functionality to applications and storage systems:

Reference information is associated with a globally unique name. By binding reference information to a unique name, an application can efficiently manage the reference information without concern for the data’s actual location. Location independence provides a mechanism for implementing Information Lifecycle Management (ILM) practices within a XAM-based storage system itself.

Metadata is raised to the same level of importance as the reference information itself. By bundling together data and metadata (contextual data about the information being stored), applications can more easily manage and share reference information, which facilitates ILM.

Storage systems are accessed via a standard, pluggable architecture. By standardizing the architecture, customers can add and remove storage products without impacting applications. The XAM architecture is a software framework that allows XAM-enabled applications to interface with XAM-compliant vendor devices in order to store and retrieve reference information in a vendorindependent and location-independent manner.

A standard XAM storage provider interface. XAM Storage System vendors can plug their systems into the XAM API by creating a provider for the Vendor Interface Module API (VIM API). XAM also provides a standardized set of management disciplines and semantics for fixed content, such as retention, expiration, etc.

XAM Architecture

The XAM architecture is a software framework that allows XAM-enabled applications to interface with XAM-compliant vendor devices. The goal of this architecture is to allow applications to take advantage of the XAM API (Application Programming Interface) to store and retrieve reference information in a vendor-independent and location-independent manner.

A primary requirement of the architecture is the ability to support access to multiple vendors’ XAM Storage Systems and multiple versions of the same vendor’s XAM Storage System. That is, different versions of the XAM specification must be able to access the same XAM Storage System, or, the same version of the XAM specification must be able to access different versions of a XAM Storage System. The architecture also allows multiple applications to access the same XAM Storage System.

The XAM architecture provides a mechanism for XAM Storage System vendors to create Vendor Interface Modules (VIMs) that act as bridges between the XAM standard APIs and the vendor’s XAM Storage Systems. How the VIMs connect to their respective devices (for example, TCP/IP, SCSI, or a file system) is transparent to the XAM standard API and the application. The connection is completely encapsulated by the VIM; the applications should be unaware of the VIM’s existence and functionality.

XAM Approach, Object Model

Three software modules (Toolkit, XAM, and VIM APIs) are defined within the XAM architecture. The XAM architecture uses these software modules to create a logical view of the XAM Storage System. This logical view defines a set of objects that are arranged hierarchically, providing a consistent abstraction that is independent of a variety of implementation approaches.

XAM has three primary objects: the XSet, the XSystem, and the XAM Library:

An XSet is the unit of data that an application can commit to persistent storage within XAM… An XSet is the addressable unit of storage in the XAM architecture from the application’s perspective. For an application to store data in an XSystem, the application must create an empty XSet, populate the XSet fields with its data, and then commit the XSet to persistent storage. If the commit is successful, the application is given a name for the XSet, called a XUID. The application can use the XUID to access the data it stored, exchange the XUID with another application so that it can retrieve the XSet, use it to create application-specific relationships between XUIDs, or use it for other purposes.

An XSystem is a logical container of one or more XSets. An XSystem may provide additional capabilities for data storage management, which may ultimately influence XSet data access and data management. These capabilities, such as resource, security, migration, virtualization, resiliency, and performance, are outside the scope of XAM. XAM accommodates these XSystem capabilities by providing an XSet abstraction that obligates the XSystem to the mutually agreed-to data storage management behavior and rules.

The XAM Library enables an application to discover and communicate with multiple XAM Storage Systems. The XAM Library allows applications to create and manage XAM Sessions, to connect to and manipulate XSystems. Besides these capabilities, the XAM Library also presents a number of fields (properties or XStreams), which are pertinent to the XAM Library, and describe its capabilities, configuration, and other characteristics… An XSystem may map to a single storage array supplied by a storage vendor, or maybe to a physical or logical partition of this array. It may also map to an aggregation of several arrays, or several partitions residing on the same or different arrays, supplied by the same or different vendors. The implementations of these arrays may include different types of storage hardware and media, e.g. Fibrechannel or SATA disk drives, or optical disks or tape drives.

Data can be attached to any of the primary objects. XAM defines the unit of data that can be attached to a primary object as a field, of which there are two kinds: properties and XStreams. Properties are used to contain simple kinds of data (strings, integers, etc.), and have a simple set/get style API. XStreams are used to contain larger and potentially more complex data (JPEGs, XML files, or binary data) and are accessed as a stream of data through a read/write style API. Regardless of the object to which the field is attached, the same XAM field-manipulation APIs are used; they are scoped to the appropriate object on which they operate (XAM Library, XSystem, or XSet).

XAM Query Language Grammar

The XAM Query Language (XAM QL, or XAMQuery) is modelled on the SQL select statement. Two parts to the statement allow the application writer to control the contents of the query. The first part (the select clause) specifies that the application is requesting a list of XUID values. Unlike SQL, the return value “.xset.xuid” is required, and shall be the only allowable value. The second part (the where clause) allows specification of a subset of XSets to be returned in the results. For XAM 1.0, the select clause shall be present and contain only the keyword “select .xset.xuid”. The second part of the query, the where clause, is optional and provides the greatest amount of application control.

XAM query should not be confused with the more general-purpose SQL relational databases. XAM query is not intended to provide the same performance guarantees seen in a mature relational database management system. XAM Storage Systems are generally designed to be archives of data, rather than relational databases. Example uses of query include locating the following types of records:
  • Archived medical data records for a patient.
  • A collection of telephone data records referencing some phone number.
  • A computer backup data set containing a named file.
Refinements of these basic searches can be extended using the XAM query relational operators to narrow the search.


Popular posts from this blog

Exploring Node.js Internals

I found a great article explaining Node JS internals, must read : Some other articles : Introduction to Node.js Being an official website, explains what Node.js is, as well as its package managers, and lists web frameworks built on top of it. “ JavaScript & Node.js ”,  The Node Beginner Book This book by  Manuel Kiessling  does a fantastic job of explaining Node.js, after warning that JavaScript in the browser is not the same as the one in Node.js, even though both are written in the same language. Beginning Node.js This beginner book goes beyond an explanation of the runtime. It teaches about packages and streams and creating a web server with the Express framework. LibUV This is the official documentation of the supporting C++ code of the Node.js runtime. V8 This is the official documentation of the JavaScript engine that makes it possible to write Node.js with JavaScript.

Hibernate Object Conversations

Session methods to use for object conversations Save() A new instance being attached to the session. An insert will be scheduled. Update() Call Update to make a transient object persistent again. It will force a SQL update on the transient object. This is because Hibernate does not know whether the object is dirty or not and to be safe by default schedules an update. This method will throw an exception, if the entity is already registered with the session. - NonUniqueObjectException is thrown. saveOrUpdate() Either a save or an update will be called based on whether the identifier exists or not. No identifier - save is called, else update is called. Or for a better understanding, if the object is transient, then a save is called, if the object is persistent, then an update is called. Reattaching an unmodified instance - If you know for sure that an object is not modified and you just want to make it persistent again - Session.lock(item, LockMode.No