that separate the information's presentation from its underlying location and logic.
Salvo Components
The core of Salvo is its server component, which runs on Microsoft Windows NT Server 3.51 or higher. Using a GUI, developers create
information rules
, which allow for a user to access data sources and manipulate their information. These rules let you create information objects for inclusion in applications.
Since Salvo's
development environment
uses HTML, all the information-object-programming tasks can be done via a Web browser. The resulting objects present information to users via an HTTP- (i.e., Web browser) or ODBC-compliant (i.e., stand-alone) container. Simware is working to provide hooks into Salvo for Common Object Request Broker Architecture (CORBA) and Component Object Model (COM) object technology. Cli
ent applications can be written in any tool that supports ODBC, such as PowerBuilder, Visual Basic, and Visual Basic for Applications (VBA).
Data sources that can be unified into an application developed with Salvo include 3270, 5250, VT100, and VT220 terminal-based applications, as well as ODBC data sources. Salvo 3.5 ships with drivers for Informix, Ingres, Microsoft SQL Server, Oracle, and Sybase ODBC sources. Drivers for other vendors' products can be acquired from the individual vendors.
For a relational database, the data source name and a connect string are specified in the Salvo interface. For a terminal-based application, for example, an IP address and a port number to your TN3270 server, an emulation type, a screen size, and a code page are specified. Code-page support provides multilanguage capabilities for mainframe applications. You need not have TCP/IP installed on your mainframe computer to take advantage of Salvo: It works with SNA-to-TCP/IP gateways, such as Microsoft's Systems Ne
twork Architecture (SNA) Server. All users of the finished application need a user ID and a password. Group access can also be defined.
Dealing with Data
After defining the "what" (the data source) and the "who" (the user), you construct the "how" (the rules). You define information rules that regulate access to data and generate information objects. Information rules come in three flavors: information generators, information builders, and context interpreters.
An
information generator
is required for each data source that the application accesses. It can be redefined as necessary in the editor, allowing the application to follow data sources as they migrate from one platform to another. Information generators can also operate independently of data sources to run an algorithm, read from a file, or return static text.
Information builders
handle processing instructions. They work on the information object tables created by information generators. Some examples of operat
ions that can be performed on a table include the following:
- join or union
- sort or filter data
- arithmetic calculations
- delete columns or tables
The
context interpreter
redirects a request to the appropriate information rule, based on the context of the particular request. The context might concern the user or user group that generated it, or the date and/or time of the request. Users see results that are tailored to include only the host or ODBC data defined by the developer.
The strength of the information object model lies in its modularity. Information rules can be individually developed and tested and then integrated into a complete application. Information rules are stored in an information object repository, where they can be used and reused.
For Web clients, Salvo's information objects are displayed via a default HTML template. Information rules can invoke a custom template or server-side script. These custom actions are specified or modif
ied when you create the object's corresponding information rule. Scripts currently must be written in Rexx; however, Simware is working on VBScript and JScript implementations.
Another of Salvo's strengths is that it gives developers lots of control over where their scripts live. For security, all scripts that return log-on data can be hidden from the client. If the goal is to move the computing burden to the client, scripts that generate complex GUI elements can reside inside the template that runs on the client.
Server-side scripts can be either written using an integrated editor or written on an external editor and then copied into Salvo. Sample code is provided to ease script creation. In a template, standard HTML features, such as check boxes, radio buttons, and text-input fields, can be used to generate output that the Salvo server directs to the appropriate information rule. Also, any scripting language supported by the client browser, such as JavaScript, JScript, and VBScript, can be used
by the template to analyze or modify content or to alter inputs or outputs. These instructions are transmitted via a CGI stream carried as a standard server request, just like a URL typed into a browser's location field.
For example, to convert a 3270 screen into HTML without calling an information rule -- the quick-and-dirty way to "scrape" a 3270 screen -- a CGI data stream is placed between HTML FORM tags that generate a server request for a connection, as shown in the listing
"Capturing a Screen"
. The inputs are hidden because there's no user interaction. The
ScriptName
input contains the name of the script that initiates the session -- in this case, one that comes preloaded in Salvo.
Templates use the
SalvoImport
tag to define how the tables in an information object are transformed into HTML, as shown below:
SalvoImport(tablenumber,rowspec,colspec)
The first nested value,
tablenumber
, is the number that specifies the pos
ition of the table in the information object (e.g., if the result set has only one table, then
tablenumber
equals 1). The second value,
rowspec
, is a specification of the position of the row(s) in the table. The number can be either a row number or a row definition. A
row definition
can be a range of rows or a combination of ranges of rows and row numbers (e.g., 2, 4-6, 8-10). The last value,
colspec
, is a specification of the position of the column(s) in the table. The number can be a column number or a column definition whose syntax is identical to
rowspec
's.
Legacy Support
Salvo helps eliminate the inflexibility of legacy applications, allowing developers to meet the constantly changing requirements of their users. If the goal is, for instance, to provide a remote user with only certain screens in a data-retrieval program, the old model required developers to modify the legacy application in COBOL (or whatever its native coding environment was). Sal
vo changes this model by using HTML, server-side scripting, and information rules. By taking advantage of Salvo's ability to make HTML pages out of terminal screens, a programmer can use the context-interpreter information rule to control access to specific pages (i.e., screens). Salvo also adds the ability to deliver data from ODBC data sources, which are integrated with the legacy application data, to the client.
Other tools for Web-centric host connectivity on the market today include OpenConnect's OpenVista, which allows developers to create custom Java applets. Of course, the applets require a Java Virtual Machine (VM) to execute.
Salvo 3.5 provides the framework for a new generation of Web-centric applications. With its ability to integrate data from divergent enterprise environments and to leverage current development tools and standards, the Salvo model could prove to be the legs that keep legacy systems moving into the twenty-first century.
Product Information
Simware, Inc.
Ottawa, Ontario, Canada
Phone: 613-727-1779
Fax: 613-727-3533
E-mail:
simware@simware.com
Internet:
http://www.simware.com
Using the Web with Legacy Databases
