1. 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

2. 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

3. Today, code is tied to a particular programming environment BrowserWorkflow Engine App ServerWeb Server DBMS Virtual Storage Server Disk HTML & Javascript httpd.confBPEL4WSJava/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

4. 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

5. 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