The End of the DBMS(as we know it)

Vijayshankar Raman

Garret Swart

IBM Almaden

Disclaimer: We don’t mean anything that we say! Don’t hold it against IBM, or our manager, or our families

The End of the DBMS

• Encapsulation is good for programmers; Bad for execution– Currently encapsulation ties software to hardware at design time

• Today, where the code runs determines how it is written– Browser => Javascript– Web App => J2EE or .NET– DBMS => Stored procedure or SQL

• We propose:– Service Oriented Execution Model for all code

• Single programming environment/language – Orchestration Optimizer

• Transparently moves code across hardware components

• The SOEM replaces all other computer languages• The OO replaces the DBMS as we know it

Today, code is tied to a particular programming environment

Browser WorkflowEngine

App ServerWebServer

DBMS

VirtualStorageServer

Disk

HTML & Javascript httpd.conf BPEL4WS Java/C#

SQL & Stored Proc

• Each component has its own language and environment

• Logical to Physical mapping of software to hardware should take place AT EXECUTION TIME, unhindered by encapsulation

Service Oriented Execution Model

• Everything is a represented as a service:– Each record in a table (getters for attributes)– Each language object– Each storage device

• Software == Service Orchestration – A table is a service that represents a set of services– A relational operator is a service, that composes a set

of services– A query is a composition of relational operators– A service is a workflow using queries and other

service invocations

Orchestration Optimization

• Logical Physical mapping: Subsumes old fashioned– query optimization, – service scheduling– compiler level optimization

• Will execute model on appropriate hardware– Disregarding encapsulation – Accounting for security and performance

• E.g.– Data reduction can run in storage– Data aggregation could run in client– Rendering could run on app server– Change from service invocation to function call to inline method