Browse Prior Art Database

A Generic Metadata Driven Database Component Support Framework

IP.com Disclosure Number: IPCOM000198746D
Publication Date: 2010-Aug-13
Document File: 6 page(s) / 151K

Publishing Venue

The IP.com Prior Art Database

Abstract

In this article, we are going to address the issues faced by database components in a product family thru a generic metadata driven database support framework which allows each component to declare and describe its supported databases in metadata xml consistently across components and products in a family. Hence database designs can be supported by the framework consistently for each component and shared by all consumers.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 30% of the total text.

Page 1 of 6

A Generic Metadata Driven Database Component Support Framework

Disclosed is a generic metadata driven database support framework providing a capability for each component to declare and describe respective supported databases using extensible markup language (XML) based metadata consistently across components and products in a family. Database designs can be supported by the disclosed framework consistently for each component and shared by consumers.

An enterprise using a services oriented architecture (SOA) solution typically offers families of stacked or related products represented as (

p

                          ). Each product in the stack consists a number of related components represented as (c). Many of the components are required to support a number of databases represented as (d).

For example, an IBM® Business Process Management offering consists of 4

products (

=4) in the

stack, namely, WebSphere® Enterprise Service Buses (WESB), WebSphere Process Server (WPS), WebSphere Business Fabric (WBF) and WebSphere Business Monitor (WBM). Each of the components further consists of a number of components that require database support, for example, within WPS database support is needed for 9 components (in this case, c=9). A typical component will have to support a variety of database types, versions,

p

                                          latforms and drivers as shown in Figure 1. In the example using WPS, the number of database implementations supported by each component is approximately 16 (using an average, d=16).

Generally, a different team owns each product and component. Each team typically designs the component database in a team-unique manner resulting in repeating the same database design

p

 rocess many times represented as Σ(p,c,d). The repetition common to this development style causes huge productivity losses and inconsistent database supports across components and

products.

p

1

[This page contains 1 picture or other non-text object]

Page 2 of 6

Figure 1

Another inconsistency issue may rise from within a single component database design. Generally there are two consumers of a database design in the form of a database administrator (DBA) and a product administrator. The DBA uses the design to generate database scripts and create or configure the database accordingly. The product administrator ideally uses the same database design to configure the runtime database resources. However, the two administrators are not always operating with the same set of assumptions or requirements. Differences occur because shared information such as a database name and authentication is not captured in a single consistent database design. A clerical error or miscommunication between the administrators may result in serious database access problems, which are hard to debug.

The disclosed framework is designed to address the previous two issues using a generic metadata driven database support framework, which allows each component to declare and describe respective supported databases using metadat...