Grid Storage API

The behavior of a storage system as seen by a data grid user is de ned by the
data grid storage API, which defi nes a variety of operations on storage systems
and le instances. Our understanding of the functionality required in this API is
still evolving, but it certainly should include support for remote requests to read
and/or write named fi le instances and to determine fi le instance attributes such as
size. In addition, to support optimized implementation of replica management
services (discussed below) we require a third party transfer operation used to
transfer the entire contents of a fi le instance from one storage system to another.

While the basic storage system functions just listed are relatively simple, various
data grid considerations can increase the complexity of an implementation. For
example, storage system access functions must be integrated with the security
environment of each site to which remote access is required. Robust performance
within higher-level functions requires reservation capabilities within storage
systems and network interfaces. Applications should be able to provide storage
systems with hints concerning access patterns, network performance, and so forth
that the storage system can use to optimize its behavior. Similarly, storage systems
should be capable of characterizing and monitoring their own performance; this
information, when made available to storage system clients, allows them to
optimize their behavior. Finally, data movement functions must be able to detect and
report errors. While it may be possible to recover from some errors within the
storage system, other errors may need to reported back to the remote application
that initiated the movement.

Retargetable API generation

The generator has been designed to be retargetable to different host languages by
separating the implementation in a generic front-end, which produces an abstract
representation of an API, and a host language specific back-end. For each host
language, code templates need to be provided for generating automata, escaping,
and pretty-printing. For the Java and PHP back-ends the templates amount to
420 and 400 lines of code respectively.

To make the implementation of a new back-end as lightweight as possible, the
generator back-ends produces parse trees of the host API, which can be unparsed
to a source API without the need for a pretty printer for the host language. In this
way, only a syntax definition of the host language is required.

XML API and Application Support

DB2 introduced a new SQL column type in the database, the XML data type.
Applications can bind various language specific data types for input and output
of XML columns or parameters. These existing language specific data types
only allow the user to work with XML as character or binary types.

In order to use XML efficiently and seamlessly, new language specific XML
types are added to the existing client interfaces. These new language specific
XML types enable the database to be more efficient and enable the database
to supply a richer API for the applications. By making XML explicit in the
application, the database will avoid unnecessary and/or unwanted code
page conversions. XML documents have an internal encoding declaration
which makes all but the XML parser’s transcoding unnecessary. Avoiding
unnecessary code page conversions is often an important performance
benefit. Additionally, transcoding an XML document without carefully
adjusting the XML encoding declaration might make the XML document
invalid.

All the major database interfaces are supporting the XML type natively, i.e.
treating XML data as XML, not as a character type. Below, we will touch
on JDBC, ODBC, .NET, and embedded SQL.