From Ingres Community Wiki

Contents 1 Project Profile 2 Tools API Overview 3 Project Goals 4 Basic Tools Functionality

Project Profile

Developers	Roger Whitcomb
	Bodo Bergmann
	Durwin Wright
	Yunlong Zhao
Development Status	Design
Intended Audience	Developers, 3rd Party System Integrators
License	TBD
Operating System(s)	32-bit MS Windows (NT/2000/XP/Vista), Solaris, HP-UX, HP-Itanium, Linux, VMS
Programming Language(s)	C, C++, Java
Topic(s)	Ingres
Registered	03-feb-2010
Related Projects	Ingres Director
	Orchestram Management Suite

Tools API Overview

• The Ingres Tools API which is a foundation for developing Ingres management tools (also 3rd party integration). This will be a C/C++ interface and a Java (JNI-based) interface so tools can be written in any language of choice. There is also a secure, remote piece of this architecture that provides seamless access to Ingres administration from a remote computer. Also there is a discovery piece to the architecture for automatically detecting Ingres installations.

• The Ingres Director is a set of basic administration tools written in Java using the Apache "Pivot" framework [1] that can be shipped with all new versions of Ingres (starting sometime after the GA release of Ingres version 10.0) and which provides a single-entry point for administration of Ingres on all platforms. The Tools architecture could potentially be back-ported to all the GA Ingres 9.x releases to provide a single point of administration for all current Ingres versions.

• A presentation titled Ingres 10.0 New Admin Tools: Getting There From Here is available for download by clicking here. You can also watch the recording of the first presentation here: https://ingres.webex.com/ingres/lsr.php?AT=pb&SP=MC&rID=10493472&rKey=c948b16dd7c05f5e and the second presentation here: https://ingres.webex.com/ingres/lsr.php?AT=pb&SP=MC&rID=10507612&rKey=f9e6783802abeb20

• Note that these presentations anticipated the Tools shipping along with Ingres 10.0. However, we can now see that the Tools won't be shipping by the Ingres 10.0 GA date, but some time after that. Watch here for further news about the schedule.

• The current Tools API specification will be available shortly along with the "Javadoc" documentation (web-based).

Project Goals

• The first release of the Tools API will allow discovery of Ingres installations on a local or remote machine.

• Components targeted for the first release:
  • Discovery (Local and Remote)
  • Remote Command Server
  • Jar and shared libraries that comprise the Tools API

• Future releases of the Tools API will be capable of supporting all the basic administration functions for Ingres Director.

Basic Tools Functionality

The basic functions of this toolset will all be provided through the Tools API (point 1).

• Provide the "Director" capability as "plugins" or modules to Orchestram. This will plug the hole in Orchestram, which currently has a huge range of functionality, but lacks capability to do basic administration of Ingres itself.

• Enhance and support the "Orchestram" product. There are things I would like to reorganize, but I'm sure there are things that Premium will discover that either don't work or are awkward or missing that will need to be addressed. In this category are the increased Probe support (which benefits Nagios as well).

• Long-term strategy is to provide all the functionality now present in the VDBA suite of tools, but in the same mold as Ingres "Director", so that it will work on all platforms. Once this happens the VDBA suite can be deprecated and eventually eliminated and all tools development can proceed along these lines. Also, at some point, most, if not all, of the ABF-based tools (such as CBF, ISQL, NETUTIL, IPM, etc.) can be deprecated as their functionality is provided in a more modern GUI tool.

• As a sideline, and this is (one area) where I can use a lot of help, is integration with 3rd party tools. phpMyAdmin is a very capable tool and I think we could benefit (as an open-source player) by integrating with them. There are other places where I think we could easily fit into with the capabilities provided by the API and the experience gained from the above efforts.