Panther Applications in Croatia

Brief History
When the Prolifics application development toolset came to the Croatian market in 1990, independent software vendor company Pardus (then 4-MATE) chose it to develop a back office application for a large retailer. The character-mode JAM5 application was running on an Intel-based UNIX system, with 60+ concurrent users, the largest in the region at that time.

Based on the successful experience with the Prolifics toolset, Pardus developed another large integrated information system for retail banks. The platform was again character mode JAM5 on UNIX, with custom mechanisms for distributed database support. The system has since migrated to the recent version of Panther and is still in use today.

Pardus continued to use JAM and Panther for its own development, and started to distribute it to other Independent Software Venders (ISV) and end user organizations with their own IT staff. Programs for JAM and Panther training, consulting, project management, and end-user development team mentoring were created. This contributed to the rapid success of the tool in the Croatian market.

As a result, Panther is now used by the two largest banks in the country. One of them still uses the originally Pardus-developed software for its core data processing, supported by 70+ in-house Panther developers and a team of Pardus consultants. Other users, apart from ISV houses, include departments like the Croatian postal services, customs, health insurance, several ministries and Zagreb municipal administrations.

An Example: Forensic DNA Database
Pardus uses and encourages other fellow-developers to use Panther for a wide variety of applications. One interesting example is the Pardus-developed eQMS::DNA application, a DNA “fingerprint” database, now in use in Central Forensic Laboratories in two countries.

When the opportunity to develop such an application arrived, Pardus again chose Panther because of its excellent rapid prototyping abilities, flexibility of its scripting language and the versatility of its database transaction generator. Native XML import and export capabilities were an advantage.

The resulting eQMS::DNA application is a system primarily used for maintenance and efficient searching of database of human genotypes for forensic purposes (such as identification of biological traces like blood, hair, skin etc), but also has the capability to be used in fields such as livestock lineage tracking.

DNA fingerprinting relies on the fact that certain points in human (or other) genome (loci) change relatively quickly (display polymorphism) from generation to generation – fast enough to form a combination unique for an individual, but slowly enough to be stable within single individual's cells. The type of polymorphisms and number of loci used for constructing genotypes in eQMS::DNA is configurable, but typical installation will employ a standard set of 13 to 18 STR (short tandem repeat) loci.

The system maintains data on individual donors with optional end-user configurable personal and demographic data, multiple samples containing genetic material taken from the donor, and genotypes obtained from the samples, possibly using multiple techniques and identification kits. Both processed genotypes and optional additional data such as peak quality, confidence parameters and raw electroferograms can be kept. The system also keeps profiles of unidentified traces.

Manual entry of data to Panther screens, from plate gel electrophoresis is possible, but the typical data source results from automated capillary electrophoresis sequencers. Communication with systems such as Interpol DNA Gateway is also supported.

The searches can be performed interactively or in full automatic mode. All searches, including those using partial profiles and relaxed criteria are typically done in less than a second. The system also supports mixed-stain searches with provisions for common contaminant identification (such as genotypes of laboratory or other forensic personnel).

Interpol maintains a list of available DNA profiling systems (probably the most well known being FBI CODIS). eQMS::DNA is the only application from a commercial software developer.

Figure 1:Screen shot of eQMS::DNA profiling application

New Developments
Pardus has assisted many clients in modernizing their legacy character-mode JAM and Panther applications.

For example, a Complex Card Management application for a leading Croatian bank was recently ported from JAM5 character-mode to Panther5 GUI. Initial functionality was complete within a month, with an additional month spent adding capabilities made possible by the new version of the Panther tool.

Pardus mentored several of their customers as they transitioned from character-mode to GUI to the Web environment, and from 2-tier to multi-tier architecture. One example includes developing a Java wrapper to call mainframe-based Web services from within a 2-tier GUI and Web Panther application. Another customer, a public health institution, uses the similar Pardus-provided tool to provide their clients with controlled access to their LIMS software (also developed by Pardus) that contains data on analysis of food and water samples.

Despite the market focus shifting away from dedicated application development toolsets, Panther stays a viable product in the Croatian market, thanks to the high penetration and the level of experience and expertise available to its customers.

For more info see http://dna.pardus.hr/ and http://lims.pardus.hr/.

Dragi Raos is a co-founder of Pardus d.o.o a software development and IT consulting company from Zagreb, Croatia. Pardus is a distributor of Panther and JAM in Croatia. Dragi has three decades of experience in technical and scientific computing, design and development of complex financial applications and training and coaching of development teams, he has served as team leader or technical consultant with clients ranging from International Atomic Energy Agency to large regional banks to public health institutions. Dragi's technical expertise includes database management systems, middleware, CASE tools and a wide range of development environments, including 20 years of experience with Panther and all versions of JAM.

Converting your Legacy JAM Application into a Panther Web Application

Converting a legacy JAM/Panther 2-tier application into a Panther Web Application offers a significant advantage: a conversion allows reusing a significant portion of the existing code as most JPL and C functions continue to be fully functional.

Although straightforward, the conversion process is not trivial or automatic. The conversion process does present some challenges and involves making changes and additions to the existing code.

In this document, I start by quickly describing some key differences between a JAM/Panther 2-tier application running on a GUI environment and a Panther application running on the web. Then, I proceed to discuss aspects of the application that are reviewed during the process of converting a GUI application to the web.

Key differences between a GUI application and a Web application
In a GUI environment, when a JAM/Panther application is executed, it runs on a dedicated process that performs several tasks for the application: this one process makes the calls required to display the screens and widgets to the user, handles the screen event cycle and maintains the application state. In this same process, all the screens and JPL code are loaded and executed. This process, also, connects to the backend, which is typically a database that is accessed through the Panther DBi.

When an application is executed on the web, the architecture is quite different. For starters, instead of having one process perform virtually all the tasks required for the application to work, several processes (residing in different hosts) are involved in performing the tasks required for an application to run on the web.

On the web, the browser is the only program running on the client computer. It allows the user to interact with the web pages dynamically generated on the server. Once a given page is displayed to the user, there is no interaction with the server until the user performs an action that results in submitting a request to the server. More specifically, as the user interacts with a page in the browser, several events are generated and they can be divided into two groups: events that are handled locally by the browser alone (for example, when the user tabs between the fields in the page) and events that require server processing (for example, when the user clicks on a push button to perform a search in the database).

When an event in this second group occurs, the browser submits a request to the HTTP server. The request is then passed along to an available Panther Web Application process, which executes the appropriate Panther code and replies with a new rendition of the screen in the form of a new HTML page. This HTML code is then transmitted back to the browser and displayed to the user.

This is perhaps the root cause of most of the changes required for converting an application to the web: whereas in a GUI environment, a single process continually handles the screen event cycle, executes the appropriate Panther code and displays the application screens using the platform’s native API. On the web, these operations are split between the browser (which renders the HTML code it receives and maintains its own event cycle as the user interacts with it) and the Panther Web Application processes residing on the server (which receive requests from the clients, execute the appropriate Panther code, and reply with HTML code that is sent back to the browser).

The Panther Web Application processes that actually execute the Panther code are a pool of processes called Jservers. Each of these Jserver processes handles one request at a time, and generates a response. Being stateless processes, the Jservers retain no memory of previous transmissions: as soon as a Jserver process has produced the reply for a request, it again becomes available to process more requests, which may come from the same user session or, in most cases, from an altogether different user session. Using stateless processes is a common practice for web applications because they allow excellent scalability: a small number of stateless processes can handle requests coming from a large number of users.

Maintaining the Application state
So, if the Jservers are stateless processes: how is the application state maintained for each user session on the web? The short answer is: by caching data.

Panther Web automatically caches application state data, such as the values of hidden widgets, scroll state of widgets, and bundles.

Two modes of caching data are supported: embedding the cached data in the generated HTML code, or keeping the cached data on the server and embedding just a reference to the cached data in the generated HTML code.

Panther Web also provides functions to define and use context global variables from JPL code. Such variables are set by a specific user session and remain private to that user session.

Functions to store and retrieve data in HTTP cookies are also provided.

HTML Generation
As described previously, the application screens are dynamically rendered as HTML code to be presented on the browser. Panther automatically generates the HTML code for the screens and the widgets in them.

The HTML generated by Panther may need to be customized, mainly for 2 reasons: to fine-tune the visual appearance of the screen on the web and to integrate JavaScript code.

Using the Panther editor, the name of a pre-existing HTML document can be specified in the HTML-template property of a screen thereby providing the structure of the HTML generated for the screen. This allows you the flexibility to determine how the HTML for the screen is generated. The provided HTML template is tied to the Panther backend by embedding Panther-provided tags into it, thus specifying the exact location where the HTML code for the dynamic elements are to be included in the resulting HTML page.

Custom HTML properties can also be set for the individual widgets on a screen. These properties allow making additions or changes to the HTML attributes within the INPUT element that Panther generates for a widget.

These properties can also be used to hook in JavaScript functions and JavaScript libraries such as Dojo and jQuery.

To give you an example of the kind of things that can be done by customizing the HTML generation, see the screen shot of an application screen in the Panther editor.

By including the code shown below in the screen JPL, the attribute property of the Single Line Text widget called “i_odate” is modified before Panther generates the HTML for the screen:

When the screen is displayed in the browser, see how the widget is no longer displayed just as an input field, but as a Dojox calendar widget.

Navigation
GUI applications typically have menu bars that allow the user to navigate between screens. On the web, there is no natural replacement for menu bars and many alternatives are available for providing navigation controls on the web. During the conversion, it is necessary to select the one that better suits your needs.

Web Event Handling
You can provide JPL procedures with the names listed below, and those procedures get executed as events occur in a web application:
web_startup – This procedure is called when a Jserver process is started. The code to open the connection to the database is typically invoked from this JPL function and the database connection is maintained through the whole life of the Jserver process. This procedure can also be used to load public procedures and data used through the application, specify database error handlers, and define global variables.
web_enter – Each screen can have its own implementation of this procedure. It gets called after the screen entry event and before the web browser data is loaded into the Panther screen structure. This is only called once on each request submitted.
web_exit – Each screen can also have its own implementation of this procedure. This is invoked after all other events have been processed and immediately before Panther dynamically generates the HTML output for the request being processed.
web_shutdown – This procedure is invoked when the Jserver process is shutting down. This is where any required application clean up is typically invoked, including the code to close database connections.

Conclusion
Several approaches need to be evaluated when facing the prospect of making an existing Panther GUI application available on the Internet or an intranet.
This document has provided you with a glimpse of the differences between the two environments and has presented aspects of the application that need to be addressed during a conversion. Hopefully this information has piqued your interest about converting GUI applications to the web in general and the Panther Web product in particular.

Eduardo Ramos is a Project Manager at Prolifics. He has over 16 years of experience in the IT field, specializing in the development and migration of multi-tier applications using various technologies including Panther and the IBM WebSphere family of products.