The datatoolsshared.jar provides shared classes and interfaces for portlets and Web services in the console as well as stand-alone Java applications that are used to manage the console installation.

External Dependencies

The datatoolsshared.jar has the following dependencies which are provided and installed with the console:
IBM Java Runtime Environment 5.0 or higher

It also depends on the following jars:
Spring 2.0: list the jar file names here as well as the corresponding minimal property files
Commons Logging 1.1: list the jar file names here as well as the corresponding minimal property files
Commons Configuration 1.4: list the jar file names here as well as the corresponding minimal property files
Derby 10.2: list the jar file names here as well as the corresponding minimal property files
Servlet 2.4: list the jar file names here as well as the corresponding minimal property files
JavaMail 1.1: list the jar file names here as well as the corresponding minimal property files
Properties files: datatoolsconsole.properties

Introduction

The datatoolsshared.jar provides shared classes and interfaces for portlets and Web services in the console as well as stand-alone Java applications that are used to manage the console installation. Portlet developers who want to develop their own console modules are not required to use any of the functions provided by the shared jar. However to ensure a consistent user experience and enable easy integration into the console installer package, portlet developers are strongly encouraged to use this API. Not all public classes of the API should be used independently. For example, some classes in the messenger package implement the back-end service for the common JavaScript console messenger widget. Portlet developers should primarily use the JavaScript widget to interact with the console messenger. The documentation will indicate if a class should not be used independently.

data tools console shared api architecture

The API provides the following packages:

cache Provides classes to use the cache service provided by the console.
connection Provides classes to manage and obtain connections to IBM and non-IBM data servers.
logging Provides classes to intercept all uncaught middle tier Java exceptions and to post logs to the console logging Web service.
mail Provides classes to send e-mail through an SMTP server.
messenger Provides classes that implement the back-end service for the console messenger.
net Provides classes for the installer to get the port and IP address information.
persistence Provides classes to access and manage the configuration database.
security Provides classes for password and data encryption as well as JavaScript encoding and decoding functions.
util Provides classes to manage system and user preferences, to get string representation of a property list, to manage universally unique identifiers (UUIDs), to obtain version and product level information, as well as to provide encoding functions for XML.

 

The documentation for each class or interface contains usage examples.

Terminology

AOP: Aspect-Oriented Programming

Cache Service: A composite cache providing cache chunks for different components to use.

CSV: Comma-Separated Value

DAO: Data Access Object

DDL: Data Definition Language

Derby: A Java based, open source database management system

I18N: Internationalization

JCS: Java Caching System

JDBC: Java DataBase Connectivity

POJO: Pure Object/Java Object

REST-Style: Representation State Transfer-Style

SMTP: Simple Mail Transfer Protocol

Spring: A light-weighted J2EE application framework

UUID: Universally Unique IDentifier

WSDL: Web Service Description Language

Frequently Asked Questions

Question: How can I request or contribute a new shared class or interface?

Answer: The shared API is owned by the infrastructure team. Send a note to DSAC-Scrum-Feng with your request. After a team review and approval from the architect, the class or interface will be added.


Question: How are changes to the shared API managed?

Answer: All changes to the shared API will be incremental following a version (1.0.0.0, 2.0.0.0, and so forth) to avoid causing regression. New or overloaded classes or interfaces can be added in a fix, modification, or release as well.


Question: How are code changes to the shared API communicated?

Answer: If a code change to a shared class becomes necessary after a release is shipped, a notification will be sent to all developers to review and test the code change to avoid regression. Ensure that you are on the DSAC-Developers mailing list.


Question: Do I have to use the shared API to store configuration data?

Answer: It is highly recommended that you only persist data from a portlet or Java application through the shared API to facilitate install upgrades and reconfiguration. For instance, if you write to your own properties file, create your own Derby or Cloudscape database. The installer will not preserve that data.

/html>