a. Example of a typical VT-i client implementation

 

Implemented as a light weight (57k) Java based internet application, VT-i is a generic client that provides the flexibility to accommodate all possible business scenarios. UI layouts are inferred only by structures and data definitions contained within the transfer stream (no x, y info) minimizing the overall system design / development effort and providing for run-time interface reconfigurations. Based on a three level (List, field/control, parameter) hierarchical presentation algorithm not requiring x, y control placement information, features such as multiple panel caching, field level validation, context sensitive user assistance, and managed screen flow (accept / undo etc.) are all practically implemented in any Java enabled client OS environment.

 
 
2.0 Technology
 

Launched from a standard HTML page viewed in a Java 1.3 compliant web browser (Explorer 5.0, Netscape 7 etc.), the 57KB VT-i applet downloads to the PC client and executes requesting a parameter specified XML page from the host server. The VT-i client parses the static or dynamically generated tag based XML stream and generates a UI containing fields, tables, and parameters lists as represented by the XML specified data structures. The basic layout of the VT-i generated UI is as follows:

 

Header area title        Header field / control area    List title  Multi column   list area       Application area title  Application field / control panel area     Parameter title  Multi column  parameter table  Function keys 1 - 10, Enter (accept), Escape (undo)  Status bar (connection status, error / system messages)

 

An important feature is the ability of the client to automatically generate a practical and visually acceptable user interface layout without the specification of control x, y coordinates. The server need only generate a list of field attributes (labels, data type, length, permissions etc.) and indicate table, field set, and parameter relationships in the XML structure. This feature greatly simplifies the system design by negating the need for the UI to be defined in detail at system development time. In addition, at run-time the VT-i client provides all field level data type validation (i.e. locale based date / time / currency / number / masked user defined formatting etc.), screen level data management functionality (tab / do / undo / submit etc.), screen caching and overall application navigation functions. These features are supplemented by a number of utilities including a calendar, clock, and calculator. All return client to server data transfers are implemented via standard html FORM POST methodologies.

 
 
3.0 Features
 

In summary, VT-i is effectively a universal client 'Application Browser' with a rich set of features that may be applied generically to field, table and parameter data eliminating the need for an extensive client side proprietary development effort. Key functionality and features include:

 

Small 57KB Java applet resides on server therefore eliminating all client environment support responsibilities. 'Real' PC client application look-and-feel in comparison to web browser HTML / JavaScript based forms. Zero client development. Control layout determined by VT-i at run-time based on server specified information structures. Run-time configurable splash screen text, main window title / caption text, main window / minimized icons. Accommodates run-time UI field and control set changes determined by user permissions, business context etc. Overall application maintenance simplified by eliminating redesign and distribution of client components. Dynamically manages layout for all common client monitor types i.e. invokes panel scrolling at low resolutions. Full featured field level validation based on localized data types (i.e. Currency, Date, Time, Number etc.) Managed screen flow i.e. mandatory fields must be completed, updates sent / accepted etc. prior to next request. Control data type based user assistance utilities (currently: calendar, clock, calculator, currency convertor) Provides field level context based user assistance (120 character text associated with each control) Consistent user interface look-and-feel, option navigation, and field level validation across entire business application. Power user keyboard focused interface utilizing shift/ctrl/alt function keys. Full mouse support also provided. Easily implemented application prototyping using web server located static text based XML web pages. Simple well defined tag based interface stream (XML) providing for consistent and predictable client behavior. Three level (List, field / control, parameter) hierarchical presentation allows multiple UI panel and data caching Flexible server side technology options (i.e. WebSphere, Apache IIS, etc.) NB: anything that generates XML / HTML Modest developer skill set requirements i.e. similar or less than forms based database web application development. Framed Window and Browser modes (can be embedded in a HTML page and displayed within browser context) All return client to server data transfers are implemented via standard html FORM POST methodologies. Multithreaded, securely packaged. Developed with Java 2 JDK.

 
4.0 XML Structures
 

A key feature of the VT-i client is its ability to render and display hierarchical data views as represented by XML structures. This is achieved by allowing a set of input / display fields to be described for each record of a multi-column table, then for each field described, another multi-column table representing field level parameters. i.e.

 

	[Title][First name][Last name]	// list item 1 (3 field record)
	[Gender]	// field 1
	[Male]	// parameter 1 for field 1
	[Female]	// parameter 2 for field 1
	[Age]	// field 2
	[Phone]	// field 3
	[Credit Code]	// field 4
	[AVG][Average]	// parameter 1 for field 4 (two field table record)
	[BAV][Below Average]	// parameter 2 for field 4 (two field table record)
	[Date of Birth]	// field 5
	[Title][First name][Last name]	// list item 2 (3 field record)
	............	// another list record (i.e. above repeated or new field set)

 

If any attributes are not provided i.e. if no list tag is present in the stream then that area of the UI will not be populated resulting in a single panel of controls with associated parameters (if provided). NB: the *... and . characters present alongside some entry fields indicated the following: * = mandatory field, '...' = parameter list available from which an option must be selected, '.' = parameter list available from which an option may be selected or the field text edited.

b. VT-i example with no 'List' tags defined

 

If list record data is only provided (and no field and parameter attributes are supplied), the UI list area will occupy the entire width of the application frame i.e.:

c. VT-i example with no 'Application' tags defined

d. Example VT-i panel with 'List' but no 'Header' or 'Application' areas defined

 

Field (or control) attributes can be classed as 'Header' or 'Application' to specify in which panel zone of the UI they will be rendered. While 'Application' area field / control attributes must be redefined for each List record entry, Header (and Function key) information need only be specified once per each UI definition. If not required, 'Header' information may be omitted entirely i.e.

e. Example using only 'Application' area fields / controls defined

 

The ability to re-specify both the 'Application' and 'Header' field and control attributes for each 'List' entry permits the following two presentation scenarios: 1) Where the structure of field and control attributes remains constant for each 'List' record entry, menu, and table data detail may be scrolled as shown in the following two example UI panels:

f. VT-i using 'List' with constant 'Application' zone control set to implement a menu

g. VT-i using 'List' with constant 'Application' zone control set to display record detail

 

1) Where the structure of field and control attributes varies for each 'List' record entry, the result is a 'tabbed notebook' type panel selection mechanism. In this mode of use, VT-i effectively caches a number of UI forms and allows the user to navigate through a series of process or view options. The VT-i client will inform the server of panel selection changes and update request events allowing any of the hidden forms to be reloaded as required. The following screens demonstrate this mode of operation.

h. VT-i using 'List' with varying 'Application' area control set to implement tabbed type panel navigation

i. VT-i using 'List' with varying 'Application' area control set to implement tabbed type panel navigation

 

In the following two examples, although the 'List' area appears to represent a column of like table data (bulletin board memos), different field / control set structures are implemented to present varying data types (html and record information).

j. VT-i using 'List' with varying 'Application' area control sets to present differing data types (text / html)

k. VT-i using 'List' with varying 'Application' area control sets to present differing data types (record information)

l. VT-i application view demonstrating Calendar control

m. VT-i application view demonstrating Time Selection control

 

Using the basic three level XML structure (List, Field / Control, Parameters), most common business application presentation requirements should be accommodated. As the example screen scenarios show, even complex multiform views are easily generated based entirely on predefined XLM schema / DTD information.

 
 
5.0 VT-i Server Implementation
 

Current test applications have been implemented as Apache modules built utilizing the VT-i Server Library to manage low level client and server XML message interaction. The library provides a number of 'C' language APIs for use in a client initiated event based message 'call back' environment. The rich set of functions included allow for the definition of panels and controls (including tables and parameter lists), the assignment of events to keys and buttons and the management of user prompts, confirmation requests, messages, warnings and alerts with the absolute minimum of programming effort. All client / server interaction is based on published HTTP Server / MIME standards allowing an VT-i application to co-exist with other web portal activity on a server. In addition, HTTP type URL protocols allow for the specification of file path information which in the VT-i context may be extracted for use to determine database location. For example, a one application / many database versions (i.e. for different customers) type scenario can be easily managed utilizing the HTTP path directive. For example, the VT-i client URL:         http://www.ComputerBureauCo.com/data/JoesPharmacy/ChemistApp.vti specifies: server identity as ComputerBureauCo.com, location of database file set as /data/JoesPharamcy/..., and the name of the application call-back method (as defined in ChemistApp.c) registered and linked to the VT-i Apache Module (VTiServer.dll) located in the Apache/modules directory. Application level user authority can be either managed using VT-i server library routines (preferred) or alternatively by OS / database level security management tools / utilities. A key component of the both the VT-i client and server modules addresses issues relating security. All data transferred between the client and server is encrypted although the current default implementation (non random character substitution) should be considered fairly lightweight (to fully optimize system performance). The VT-i server library exposes encrypt / decrypt methods (and corresponding client classes) allowing more advanced security policies to be implemented as determined by application requirements. Another feature of VT-i client / server interaction as implemented by the Library is the virtual elimination of server application data persistence requirements by providing a means of transferring / storing all local data (i.e. key field, status information etc.) to the VT-i client for return use during subsequent server calls. This process reduces code complexity, improves server memory utilization (hence performance) and eliminates the requirement for absolute continuity of server operation (the HTTP server component [Apache] could be closed down / restarted without disruption to the remote user). A number of additional APIs are provided that wrap SQL Database type interfaces to simplify the creation of query statements from transferred client field information and the subsequent redirection of returned query results to VT-i defined client panel controls, tables and lists. This tight coupling between data sources and the VT-i Server Library dramatically reduces any application development effort required. Currently the library implements the 'MySQL' database system, an industrial strength Linux / Windows SQL based product in wide use.

 

Key features of the Apache VT-i Server Library module currently include: based on client initiated event message 'call-back' type environment (invoked per user instance / transaction). rich set of 'C' language APIs to define panel controls and assign events to keys and buttons. includes set of VT-i optimized Database SQL routines to optimize transfer of client / database / client transfers. implemented to reduce / eliminate data persistence requirements in Server processes. all client / server data transfers encrypted by default or user defined encryption processes. extensive provision for client user prompts, confirmation requests, messages, warnings and alerts. event based procedural code easily generated with high level application development tools (i.e.VTIG).

The development environment comprises the following objects: a core linkable 'C' library (VTiServer.lib), a 'C' language header file (VtiServer.h), a configuration source file (where new applications are registered), an example application source file (CustApp.c) and a makefile required to build the complete Apache Module (VTiServer.dll for WIndows / VTiServer.o for Linux).

 
 
6.0 VT-i and Enterprise Application Integration (EAI)
 

As stated, one of the key VT-i design aims was to provide a generic client that would present to the user an interface perceived to be as 'interactive' as a dedicated PC application but be implemented using standard HTML form based server technologies. While the VT-i XML may be generated using JSP and servlet objects implemented within traditional J2EE design models, it is also possible to initiate the XML using down stream processes.

   

Using standard EAI techniques, VT-i UI definitions could be created and stored using the same tools and processes used to manage XML based EIS messages thus eliminating all business function at the Web Server level. In the case of a WebSphere, MQSeries based environment, it is envisaged that creation, management, and population of VT-i XML messages would be facilitated by associated tools such as MQSI, Workflow Management, Extension packages (Finance), etc. Aspects such as XML message definition, session persistence, role management, error roll back would be managed using standard MQSeries processes and facilities i.e. message dictionaries, warehousing, brokers, security tools, message transformation and redirection. Advanced tools such as the MQSI Control Center utility would permit data flows between the VT-i based UI (via the WebSphere node) and other data sources (legacy systems, relational data bases, third part processes etc.) to be managed visually. The concept described above (although currently not implemented) would provide a fast track means of achieving a manageable VT-i business solution within an environment best suited to creating, maintaining and processing XML based information. It would also alleviate the need for the high degree of skill still required (even when using high level J2EE class libraries i.e. JADE) to develop and implement  complex applications in a web server environment.

 
 
7.0 Target Market
 

The VT-i concept was originally envisaged as a means for medium or large business organizations (or ASP's servicing this market) to quickly move from terminal based legacy systems to web based interfaces using EAI architecture concepts. Such businesses would not normally see a browser forms based web solution providing the functionality required but could not justify the expense required to rewrite business logic into a fully interactive PC client. The philosophy behind the VT-i concept is to offer a simplified development route (providing a real client side application rather than static forms) to this business sector. Many such organizations have already developed extensive web sites providing product information / specifications but have yet to move to provide useful functionality (ordering, invoicing, market intelligence etc.) to their remote sales and technical work force.

 
 
8.0 Revenue Potential
 

Considering it's near zero client development concept it should be attractive to businesses currently spending large amounts of money in this area. If utilized by an ASP, the rapid development aspect alone should provide a tangible competitive cost advantage. Its acceptance as an industry standard would significantly enhance the revenue potential.

 
 
9.0 Future Development
 

Possible initiatives include: A server Class Library to simplify the creation of a VT-i XML stream. This would involve associating control groupings (i.e. Customer Address), label, subheading information, parameter list data file, data length, editing defaults etc., together with normal database field attributes. Utilizing standard SQL requests, this additional VT-i field attribute information is wrapped in appropriate tags and presented together with the application data in the generated stream. Inclusion of a PDML (panel definition mark-up language) type facility to provide for UI schemes (i.e. calendar type field arrays) that may not be easily accommodated using the VT-i native layout manager.

 
10.0 Additional Information
 

Example of a VT-i prototype application UI currently located at http://www.codewrite.co.nz/vti For further information / comments, please e-mail Wayne Parker, wjparker@xtra.co.nz or call +64 3-379 0000