Data as a Service

Editor's Note: While software as a service has been bandied about for the last decade, I've been watching two fascinating trends beginning to come together - the NoSQL movement, which is increasingly exploring "non-traditional" databases, including XML databases, and the notion of Database as a service (DaaS), in which database access is managed via RESTful services mediated by either XML or JSON. The XML community in particular should be paying attention to DaaS, as I suspect that DaaS will likely end up playing an increasingly dominant role with XML technologies.

SaaS has rapidly evolved from an online application source to providing application building blocks such as

• Platform as-a-Service (PaaS)
• Infrastructure-as-a-Service (IaaS) and
• Database-as-a-Service (DaaS)

DaaS is the latest entrant into the "as a Service" realm and typically provides tools for defining logical data structures, data services like APIs and web service interfaces, customizable user interfaces, and data storage, backup, recovery and export policies. To ensure successful DaaS implementations, developers and database professionals need to address traditional challenges associated with data design and performance tuning. They will also need to address new challenges introduced by the lack of physical access for backup, recovery and integration.

What Is DaaS?DaaS provides traditional database features, typically data definition, storage and retrieval, on a subscription basis over the web. To subscribers DaaS appears as a black box supporting logical data operations, and logical data stores where customers can only see their organization's data. Physical access is seen as a security risk and thus it is not available. As with SaaS, DaaS vendors build and manage data centers incorporating best practices in security, back-up, recovery and customer support. Data services typically are provided as SOAP or REST APIs allowing users to define data structures, perform CRUD operations, manage entitlements and query the database using a subset of standard SQL.

Real-World Examples: Force.com and Amazon SimpleDBTwo real-world examples of DaaS are Salesforce.com's Force.com, which provides data services in its toolkit for building applications, and Amazon's SimpleDB, which provides an API for creating data stores which can be used for applications or pure data storage.

Force.comForce.com supports the Model-View-Controller paradigm for application development where Model refers to the data model.

• Database schema: Developers can configure pick list values for fields in standard CRM objects (tables), or create custom objects and fields via the Salesforce.com Setup menu. Data elements can also be defined programmatically through the Metadata API, which is used by the Force.com IDE, an add-on for Eclipse. Lookup fields and parent-child relationships allow foreign key relationships between tables.
• CRUD operations: Data entry, updates and deletes can be performed using Force.com pages that are automatically generated for each table, or through the Force.com Web Services API. Apex, Force.com's programming language, provides the ability to develop object oriented code to perform data operations.
• Database queries: Querying data is done through SOQL, Force.com's subset of SQL. SOQL provides read-only access via the Web Services API or Apex, Force.com's development language.
• Stored procedures: Custom business rules can be implemented as Triggers, the equivalent of database stored procedures written in Apex.
• Pro: Force.com database development and functionality parallels traditional database development.
• Con: Force.com database design requires careful design and coding.

Amazon SimpleDBAmazon.com's SimpleDB service appears to be geared to developing applications quickly with minimal effort on database design and definition:

• Database schema: SimpleDB stores data in "domains," the equivalent of a spreadsheet tab. Once a domain is created attributes (fields) are created when records are added to the domain. Each record requires a unique ID string for each item (record) and attributes are added as name-value pairs such as ("First Name", "Tara"). Items are limited to 256 name-value pairs, and domains are limited to 1 billion attributes.
• CRUD operations: SimpleDB uses the Put to insert and update items, Get to retrieve an item by unique number, and Delete to delete records.
• Database queries: SimpleDB supports a subset of SQL for read-only access to data. SimpleDB does not support queries across domains, so SQL joins are not available. The Developer Guide suggests storing related data in a single domain as a workaround.
• Stored procedures: SimpleDB currently does not support stored procedures.
• Pro: SimpleDB allows rapid development of web based applications requiring data services.
• Con: SimpleDB does not support joins, foreign keys and stored procedures. Porting complex applications to SimpleDB may not be feasible.

Read the Rest of the Article