Right Java tools for J2EE, Web Service, Grid and more
|Home | Products | Documents | Downloads | Purchase | Support | Company | Partners | Contact |

SuperArch

Table of Contents

 

Overview

SuperArch is a framework for hosting SuperComponents, which provide various functionalities. SuperArch is a gateway providing connectivity to J2EE servers and Web Service servers for SuperComponents.

SuperArch itself is a client of J2EE servers and Web Servers.  SuperArch provides a rich GUI environment with un-matchable features and convenience to client computing. 

SuperArch is written entirely in the Java programming language using Swing GUI. It is operating system neutral. Most of SuperComponents are neutral to J2EE vendor and Web Service vendor.

Component based architecture

SuperArch provides a component based architecture for client side applications to access J2EE and Web Service.  These applications are SuperComponents that are Java applications. SuperComponents can be installed/uninstalled onto/from SuperArch. An application can be assembled by installing off-the-shelf SuperComponents on SuperArch. For example, Acelet provides a monitoring tool "Super", by installing the following SuperComponents on SuperArch:

Third party's SuperComponents are welcome.
 

Facilities

SuperArch, as a framework, provides many facilities. For example:

Envoy

SuperArch provides connectivity to J2EE server through Envoy, which is a SuperComponent itself. Envoy is a communication tool between SuperArch and a J2EE server. Envoy does not have any visible representation.

There is a specific Envoy for each J2EE server. Envoys hide the differences among different J2EE servers.

UniversalEnvoy (a subclass of Envoy) can connect virtually to any J2EE servers.  But you need to do some manual work, such as deploy dowry EJBs.
 

JNDI properties

This is an advanced topic. It is transparent for most of users.

Envoy uses JNDI properties to connect the J2EE server for naming lookup. It looks for properties files on Super home directory (default is AceletSuper) in the following order:

One of the files has been installed in Super home directory by the installer. 

These files are in standard JNDI properties format. All the properties must be valid.

Note: the machine and port part of provider will be replaced by parameters that inputted on Connect Panel when you logged into the system. But a valid java.naming.provider.url value is still needed for syntax purpose.

Note: If neither above properties can be found, Super will use empty properties to construct InitialContext.  If your system provides one in CLASSPATH when Super (client) is started, that one will be called indirectly. In that case, user manually inputted parameters will be ignored.

Environment variables

When Super (the client) starts, it calls a script file to set necessary environment variables. The script file is either of:

on Super Home directory (default is AceletSuper).

You may need to extend the CLASSPATH for Super (the client) sometimes. For example:

If you need to put other class or jar files on the CLASSPATH for Super (the client), you need to edit the script file.

There is also a backup file for the above script file, in case you want to back to the original file. The name extension of backup file is either:

Customize-able Panels

All panels inherited from the Table Panel are customize-able. You can drag and rearrange size and layout.  See Set preferred layout for details. 

Hibernation

When you exit Super and want to keep your places where Super was monitoring, hibernation is very useful feature. The hibernate feature saves a snapshot of all states of applicable modules on disk. When you restart Super, all the settings are restored to their original state. 

The hibernation here is different from hibernation of operating systems. The hibernation of Super saves data in ASCII or serialized data format, not saves the memory image. When Super restores settings, Super uses the data to reconstitute everything from scratch.  If, by any chance, there is memory leak or corruption (there is no known memory leak or corruption with Super), the bad condition will not be restored, so the restore is a fresh start.

The hibernation only saves and restores instances of applicable modules, not every window or panel. These hibernation-able panels are mainly for monitoring. The known hibernate-able panels are:

The hibernation feature is automatically activated when Super is terminated from

The hibernation feature will not be activated if Super is terminated in other ways. For example:

Get around the firewall

Super is an administration and monitor tool. It should run in a trusted network. If your data center is behind the firewall, if you do not have a direct database connection or direct application connection, you can use VPN (Virtual Private Network). Or you can run an instance of Super (the client) in your data center then use VNC (Virtual Network Computing) to manage and monitor your system. 

SuperComponent

SuperComponets are components or modules for Super.

There are two types of beans that can be installed on SuperArch: SuperComponent beans and Foreign beans. Note: these beans are regular Java beans, not Enterprise Java Beans.

SuperComponent beans are made for SuperArch, with GUI windows. Each SuperComponent is an application module. When they are installed, they will be started from one of SuperArch's menus. SuperComponents implement com.acelet.SuperBean interface.

Foreign beans may or may not built specifically for Super. There will be no visual presentation of them. Usually, foreign beans are EJB client side beans (stubs) or support beans for SuperComponents.
 

Properties of SuperComponents

Each SuperComponent comes with a properties file, which is under beanbox directory of Super Home (default is AceletSuper). For example: 

/usr/local/AceletSuper/beanbox/scheduler.properties
c:\AceletSuper\beanbox\scheduler.properties

Usually there are GUI panels for manage preference and property values. But there are also some values which need manually maintenance in rare cases. Those values do not need to maintain often, probably only once in life.

 

Security guideline for logins

Many SuperComponents require additional logins. For example database logins. SuperArch does not manage component's logins directly, but provides a guideline as below. All SuperComponents follow this guideline, unless it states differently.

When you input password on a login panel or a database parameter panel, it does not show literally. When you save it, it will be saved as plain text. We assume that your computers are located in trusted areas and protected by passwords. If you have security concern, you can leave user name and password empty when you save these parameters. When the direct database connection is needed, the system will use these database parameters to connect to database. If the parameters are not complete or not valid, the connection will fail. The login panel or database parameter panel will automatically pup up for you to key in user name and password.

Note 1: This guideline is for Super (client). For server side components, things are different. But the principle is the same: if password is not valid, the system will wait for a human touch.

Note 2: Datasources need login as well. But that is managed by J2EE server and protected by J2EE server. Super and SuperComponents just use datasources, the security is managed by your J2EE servers.

Output Information

SuperArch redirects all output information to a file. The output information would be printed on your regular STDERR and STDOUT.

The information is stored in a file. The file name is output. The extension is a timestamp which is the start time. For example: 

<super-home>/output.20050606204645 (Unix)
<super-home>\output.20050606204645 (Windows)

Each time Super starts, it will create a new output file. You can specify how many of these files be kept. The default value is 5. Older files will be deleted automatically.

Internationalization Support

SuperArch fully supports internationalization. All text on GUI components and messages can be in any national languages. Translating a plaint text resource file is the only thing needed to do for supporting another national language. The program does not need to recompile. All the GUI components will be resized to fit their text on the fly.

A new text file is all needed to support a new language. You need to do:

  1. Get the file superPhrase.properties and translate it to your language. Note: it is a properties file with key=value format. Do not change the key (left side of the equal sign). Only change the value (right side of the equal sign).

  2. Use native2Ascii to convert edited file to unicode.

  3. Name the file correctly. It must be either
    superPhrase_<language>_<country>.properties
    or
    superPhrase_<language>.properties

    where the <language> is two character denoting your language and <country> is two character denoting the variation.

  4. Put your file under <SUPER_HOME> (the installed directory, default is AceletSuper).

If the Operating System is not for the desired language, you can modify file

setEnvironment.bat
or
setEnvironment.sh
change
JAVA_OPTIONS=-Xms32m -Xmx200m
to
JAVA_OPTIONS=-Xms32m -Xmx200m -Duser.language=<your language> -Duser.country=<your country>

If you want to use English, just delete superPhrase*.properties from <SUPER_HOME> directory (the installed directory, default is AceletSuper).

The following is an example screenshot for Simplified Chinese:

User defined names

Many names will map to file names in the operating system, so do not use characters which may conflict with operators of the operating system. Please do not use the following characters:

<space>, '%', '&', '*', ':', ';', '\'', '"', '/', '\\', ',', '.', '<', '>'

Data input facilities

Some modules require data input as argument list for methods (functions, methods or operations). There are two way to assign these argument lists:

In the following scenarios you may want to pass arguments to the method from a program, not from keyboard:

Dynamic Argument class is designed for this purpose. You need to code your own class which implements Dynamic Argument. Each module requires specific Dynamic Arguments.

You need to put your implementation classes on your CLASSPATH when you start Super on client machine. See Environment variables for more information.

Simple data type

The following data types are considered as simple data types:

 

   © Copyright 1999-2008 Acelet Corporation. All rights reserved.