Repository: Configuration data

Workbench includes a metadata-based repository that lets you create inventories of physical and application details. Beyond a simple catalog of configuration items, the Workbench configuration data repository also lets you define relationships between items. Relationships are used to describe package dependencies (between packages and related deployments), application infrastructure components (such as app server to databases), and the physical environment (like hosts). These capabilities make Workbench a ready CMDB solution for those adopting ITIL best practices.

The diagram shown above depicts the main components of the configuration data repository. The metadata store is a persistent datasource of model schema and instance data. A transform engine lets you define templates that bind to views of instance data in the datasource to generate output in various formats. The query service lets you lookup data in the repository to access information about configuration items or their relationships.

Workbench provides a base configuration data model that contains concepts you would expect (such as Resource, Assembly, Node, Package, Deployment, Service, Setting) and relationship constraints that let you control how items can be related. Workbench also provides tools that allow you to extend the basic model so you can introduce your own data types and contraints, and populate the repository with your own information.

You can use Workbench to maintain all kinds of configuration data. This section shows off some examples.

Node Inventory

Nodes are an example of one of the basic data types that is built into the Workbench UI. This view is accessible via the Node Manager which lets you list and lookup host machines.

The basic Node data type provides a number of generic attribtutes (like operating system and hostname). Of course, you can define your own attributes that let you record other kinds of host information.

Configuration Settings

Settings are a basic data type that lets you define individual configuration details. Often settings are used to describe application configuration (such as ports, timeouts, file paths, etc).

It's often useful to create your own setting data types that represent your specific kinds of configuration data.

If you need a "settings database", Workbench provides an easy solution.

Relationships

A key feature in the Workbench configuration data repository, is the ability to define relationships between configuration objects. For example, you might want to group a set of configuration settings based on the application component they describe.

Relationships can also be used to define configuration beyond settings to include packages dependencies, and even relationships to other services. The graphic below shows those kinds of relationships:

Workbench provides a graphical interface into viewing and editing these relationships as depicted by the following screenshot:

Business Services

Building on the idea of relationships, you can also define how your integrated software system is connected to comprise a business service. Typically, a business service is composed of several interacting software components.

The graphic below describes two example business services, a retail store and an online brokerage service. Each business service is based on a similar set of resources - apache, jboss and mysql - each of which has its own configuration.

Workbench exposes these relationships graphically, allowing you to visualize how your business services are arranged. It also gives you convenient roll up views on where the service's components are deployed (to show what hosts they are deployed) and what sofware package objects they currently use (to show what versions they're using).

Maintaining a map of your business service is crucial to understanding impacts due to failures, change outages and migrations. Having a view into your integrated software system will

• help you understand upstream and downstream impacts,
• have visibility into where your application components are deployed,
• let you correlate dependencies between application components

Workbench provides several repository interfaces to add, maintain and access configuration data. This section describes the Workbench data interfaces supporting data input and output.

Input

Form-based GUI	Workbench includes both a graphical type and object editor. With the type editor, you can create your own data types, relationship constraints, and attribute defaults. The object editor lets you create and modify instances of your data types and link objects together to define relationships.w
XML	XML specifications can be used used to define new data types or populate the repository with your information.
Scripted	You probably maintain data in various places and formats. You can use Workbench scripting interfaces to read existing data and register new objects in the configration database.

Output