# Presentation: 355063

## Object Store Overview	

- Pete RoseReed Murphy

## What is Content?

**Content is everywhere**
**Content is best described by example:**

***Presentations***

***Graphics***

***Database***

***eMail***

***XML***

***Video***

- <?xml version=“1.0”>
- <CHECK>
- 	<From>**Mark A. Hale**</From>
- 	<Number>**151**</Number>
- 	<Date>**June 13, 2001**</Date>
- 	<Payee>**Hyatt Regency**
**	****	**</Payee>
- 	<Amount>**$134.56**</Amount>
- 	<For>**Hotel Stay**</For>
- </CHECK>

**Notes:**
10,000’ view:  Content is everything and it is pervasive.  In a minute, we will show how you must consider many forms of supporting content.  For example, there is no such thing as an XML-only solution.  There will always be some other asset type.  This is why we focus so much on our core – it provides full content management for all asset types.

## 3 Drivers for Hitting the Content Wall 

- 3 Drivers for Hitting the Content Wall

**Phase 1**
**Experiment**

**Phase 2**
**Deploy**

**Phase 3**
**Business Critical**

**Number of**
**Contributors**

**Frequency of Changes**

**1-3**

**<10**

**Occasional**

**Regular**

**Daily or hourly**

**Number of **
**Assets**

**100’s**

**1,000’s**

**10,000’s – 10’s mil**

**10-10,000+**

_**Problems grow **__**geometrically**_
**Collisions and content dependencies**
**Code and asset mixed**
**Architectural interdependencies**
**Workflow**
**Templating**
**Parallel teams**
**...**

**Complexity**

**The Content Wall**

**1**

**2**

**3**

**Notes:**
Given all of the types of assets, why must we scale?  We provide an architecture for an enterprise on the other side of the Content Wall.

Simple formula to emphasize this point:

	500 XML documents
	20 Components Each
	------------------------
	10000 Managed assets 

10000 Assets will bring a relational-based system to a halt.

## Aggregating Content

**A wide variety of content is aggregated as it is readied for production **

**"*****Web content is collectively the ***_***text***_***, ***_***graphics***_***, ***_***audio***_***, ***_***video***_*** and***_*** applications***_*** that provides a compelling experience online*****”**
**	****	****	**

**1999**

**File System Content**

**Database Content**

**Application Code**

**Notes:**
Build Slide

An asset is an aggregation of many forms of content.  The following are important:

	- A Web page is a delivery mechanism for many forms of content: file system, application code, database, to name a few
	- All of these assets come from a user base with extremely variant skill sets
	- Finally, all of these assets must be aggregated and approved to be production ready 

Build:

We focus on Web pages because they are easy to visualize
The same problems hold true for FrameMaker documents and XML which are an aggregation of many asset types
Key differentiator:

We manage at a fundamental level all assets necessary to solve enterprise problems.  We are not simply document assemble, Web page assembly, XML creation tool.
Interwoven is about managing all of these complex relationships and maintaining integrity throughout the content infrastructure.  This leads into scalability and performance.

## All Storylines are Complex In the Enterprise Setting

**1.  ****	****Tremendously more complex**

**2.  ****	****Storage requirements have minimum of 33% overhead for binary content**

**3.****	****Difficult to automate content reduction**

**Notes:**
XML is greatly oversimplified in its examples.  Here is a common one:

Given an XML file, transform it using XSLT and produce an output that is device ready

Even this process is much more difficult:

There are many more documents
There is more than XML involved, what about graphics.  Moreover, these additional assets should not be transformed to XML.  Data storage requirements go up and data loss is a problem.
Finally, automatic translation is a fallacy.  Virtualization is mandatory for test and approval.

## TeamSite for Content Collaboration

**Production**
**Systems**

**Workareas**

**Staging Area**

**Editions**

**TeamSite**

**OpenDeploy/DataDeploy**

**Technical**
**Contributors**

**Business**
**Contributors**

**Notes:**
This slides covers material that should have been covered already in previous presentations:
Branching is the way to ready content for production
Workareas are needed for individuals to get their content prepared.  Our locking models support this.  Virtualization is key.
Staging is essential for approval and conflict resolution.
Editions are the decisive link to product and audit trail
Workflow, syndication, etc. surround this process
Metadata is key to keeping an inventory of content
We sit on the major application servers and databases
Finally, we are not a production system. We are a content infrastructure.

## Centrally Administered Infrastructure

**Syndication Server**
- Corporate server organized into news domains

**Intranet Site**
- Company intranet site organized by department

**Staging Server**
- Main site is tested against workgroup updates before going live

- ERS

- FSA

- APHIS

- FS

**Workgroup Branches**
- Reporters contribute articles in their domain.  Approval is done before content is published to site-wide staging.

***Today – A News Source***

**Departmental Branches**
- Employees contribute internal departmental data.  Managers approve content to go company live.

- Operations

- Public Affairs

- Programs

- Human Resources

**Staging Server**
- Internal pages are tested before manager approval

**Notes:**
The next two slides show typical installations for TeamSite.  Key points:
Enterprises do not mix internal and external content for obvious security reasons.  I am quick to point out that this is the first of many organizational or departmental reasons why businesses set up their systems the way they do.  We do not require federations like XXXX for scalability.  We match the enterprise.
We are able to handle many branches and sub-branches on a server.
Finally, I clearly distinguish that TeamSite is a Content Infrastructure system.  We push readied content out to production servers.

## Departmental Infrastructure

**Syndication Server**
- Corporate server organized into news domains

**Intranet Site**
- Company intranet site organized by department

- ERS

- FSA

- FS

- APHIS

**Workgroup Servers**
- Reporters contribute articles in their domain.  Approval is done before content is published to site-wide staging.

***Today – A News Source***

**Departmental Servers**
- Employees contribute internal departmental data.  Managers approve content to go company live.

- Operations

- Public Affairs

- Programs

- Human Resources

**Staging Server**
- Internal pages are tested before manager approval

## Content Infrastructure is About Asset Management

- Applications

- Platform

- How is this layer architected?

***Relational***

***Object-Oriented***

*We architect the infrastructure to integrate with your platform...*

**Notes:**
Continuing to go into depth.  I anecdotally point out that I enjoy Interwoven because we have such a well defined space between applications and platforms.

Next, we will be discussing the object-oriented technology that makes our system scalable.  We weighed the tradeoffs between relational and object-oriented technologies.  We used an object-store.  

I emphasize that we are not talking about the transactional system used to store data (e.g. a database).  This is a platform and we integrate with all platforms.  What we are talking about is the fastest and most scalable way to access metadata for content assets.

## Scalability: Relational or Object DB?

- Scalability: Relational or Object DB?

**0**

**1 mil**

***SQL***

**Server or Application**

**base**

**Average Query ****100 ms****	****         ****0.1 ms  1000x**
**Exponentially slower****	****         log or constant time**
***Documentum*****	****         *****Interwoven***
***Vignette*****	****	****         *****Veritas / NetApps***
***IntraNet Solutions******	******        ****** ******Oracle***

_**Object Store**_

_**Relational Store**_

**library problem**

**Notes:**
The competing technologies are summarized in this slide.

Emphasize the fact that we need to build to a full-functional content infrastructure.  That means all assets have versioning, locking, workflow, approval, etc.  These culminate at the top – the application layer.

At the bottom left, a relational store requires many tables to describe the metadata (versioning, locking, workflow, approval, etc) about content assets.  The access time to the metadata grows exponentially with the number of assets.

At the bottom right, an object store requires an object class to describe the metadata (versioning, locking, workflow, approval, etc) about content assets.  The access time varies constant, linear, or logarithmically (depending on complexity – e.g. is it for an edition, staging, workarea) for the assets.  Much lower growth pattern than a relational system thus resulting in great scalability.

Finally, we keep good company in our architecture choice.  It is the same as Veritas/NetApps and Oracle.  The fact of the matter is that many relational databases are actually SQL front-ends on object systems (like Oracle).  Don’t fall into the trap – XXXX may sit on Oracle which means they must do this slow relational map to get to Oracle’s high performance back-end.

## Let’s move on to assets...

**Notes:**
This slide puts Content Infrastructure into perspective before describing the object core in detail.  Content Infrastructure is about millions of assets and thousands of users.  That is scalability.

## High-Performance Object Backing Store

- ID
- Access
- Version

- ID
- Access
- Version

- ID
- Access
- Version

- ID
- Access
- Version

- Asset

- Asset

- User
- View (WA)

- User
- View (WA)

**Notes:**
Simply stated, we use objects that contain metadata descriptions.  
These objects have built-in referencability (recall that this is a major differentiator of content management over document management) and point to the assets stored in the file system.  
File assets are shown here but they could be databases, application code etc. as well.
Workareas are nothing but a new class of object that points to the objects that grant access for a user to view the asset in the context of a workarea

## Tangent – Relational Model

- Asset

- Asset

- Transaction Time:  O(100)ms

- Mappings, joins, selects are known to slow relational databases

- Map

- Select

- Join/Select

**Notes:**
A quick digression to the relational model.  To accomplish elements of content infrastructure would require:

A metadata table (of which a schema must be defined up front)
A view table to handle user views
Nested tables to handle collaboration

Note that the number of tables is much greater than shown here.  Remember the formula:

	500 XML documents
	20 Components Each
	------------------------
	10000 Managed assets 

10000 is the magic number for table rows.  This is the region where relational systems slow down significantly.  As we all do, we code default size limits into our systems.  They always come back to haunt you.

To sum it all up, a relational system would result in an average of a 100ms access time given the joins and selects.

## High Performance Backing Store

- Staging

- Editions

- Branches

- ID
- Access
- Version

- ID
- Access
- Version

- ID
- Access
- Version

- ID
- Access
- Version

- Asset

- Asset

- User
- View (WA)

- User
- View (WA)

- Staging

- Editions

- Branches

- Transaction Time:  O(1/10)ms

**Notes:**
Continuing with the TeamSite architecture.

Our access time for metadata is on the order of 1/10 ms. 

We replicate our object paradigm to staging, editions, branches.  Keep in mind the following:

Workflow, versions, locks, etc. are all part of this object structure.  They are just not shown to keep it simple.
Object links for staging, editions, and branches are multi-dimensional which is why they are not shown. A user needs access rights, asset objects, and many other objects to fill out a branch.  This is too complex to shown on a slide.

Stepping from here.  We have a 1/10 ms access time versus a 100 ms access time for relational systems.  This is a 1000x speedup.  Well, we don’t really have a 1000 times faster in production because we consume cycles with functionality – but without this speedup, we could not even imagine providing the software that we have.  See next slide.

## Summarizing Performance Benefits

- Object-Oriented
- Transaction times on the order of tenths of milliseconds

- Relational
- Transaction times on the order of hundreds of milliseconds

**System Functions**
- Workareas, Workflow, Templating, XML Componentization

- Object-Oriented
- Constant to Linear Growth in Access Time

- Relational
- Exponential Growth in Access Time

**Infrastructure**
- Full Branching, Staging, Virtualization

**Base Capability**
- Versioning, Locking, Authorization

- Object-Oriented
- Feature Support Enabled by Low Transaction Time

**Environment**
- Distributed Repositories, Federation

- Performance insufficient for live branching

- Syndication
- Federations, Editions

**Notes:**
Here you see the difference between the architectures summarized.  Case in point – XXXX must use federations because they are relational.  However, to get the full functional content infrastructure that we have, an object-store is a must!

Note, that we can use syndication to produce a federation.  Keep in mind that our customers only want to move content across these repositories when it is production ready.  No one wants another department to use a ‘draft’ copy because it has not been approved.  This is why we emphasize organizational architecture as shown above that scales appropriately.  

## Copyright 2003 Interwoven, Inc. All Rights Reserved

**This confidential publication is the property of Interwoven, Inc.**
**No part of this publication may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written consent of Interwoven, Inc.  Some or all of the information contained in this publication may be protected by patent numbers: US# 6,505,212, EP# 1053523, US# 6,480,944, US# 5,845,270 or other patents pending application for Interwoven, Inc.  Misappropriation of the information contained in this publication may be a violation of applicable laws.**** **
**Interwoven, TeamSite, MetaTagger, OpenDeploy, DataDeploy, MediaBin, MetaCode, MetaFinder, MetaSource, OpenTransform, SmartContext, StiNG, TeamCatalog, TeamCode TeamDoc, TeamPortal, TeamTurbo, TeamXML, TeamXpress, VisualAnnotate, the taglines, logo and service marks are trademarks of Interwoven, Inc., which may be registered in certain jurisdictions.  All other trademarks are owned by their respective owners.**** **
**All other trademarks are owned by their respective owners.**