Due to the very strict bank's security rules, previously developed applications used by the newly developed applications were not available for installation on the remote development site. For that reason, simple stubs were developed to emulate the behavior of previously developed but unavailable, CORBA (Common Object Request Broker Architecture) and database applications.
In addition, the application had to support multiple spoken languages, thus the developed software had to be internally independent of any particular spoken language. In this article we describe a number of useful tips and tricks of trade that may be helpful to developers facing similar situations. We will describe the three-tier system architecture, the development of CORBA and database portions of the applications, and present tips on multi-lingual application development.
Figure 1 depicts the three-tier system architecture typical for Internet applications. Users use web browsers to access various online banking applications via the Internet. Applications are executed by a web server. An example of such an application is the quotation of currency exchange rates. The user selects desired currencies and a branch of bank on a query input form and submits the query. The web server accepts the query, processes it, and returns the response back to the user's browser. Depending on the particular application, the web server may consult with a CORBA application server and/or a database server. The response is returned in the user's language of choice (German, French, Italian, or English).
Figure 1. System architecture
Per the bank's internal software development standard, all Internet applications, executed by the web server, are written using Java programming language and Java servlets. Although people from the Microsoft camp will most certainly disagree, this is a de facto standard for writing serious Internet applications.
Software described in this article had to support four languages, i.e., the user had to be able to submit queries and receive responses in the selected preferred language. Figure 2 depicts a general appearance of the user interface displayed in the user's web browser.
Figure 2. General appearance of the user interface
The user interface consists of two HTML frames. The upper frame is a static HTML page, written in the user's language of choice. It contains the language selection menu on the left side, and the query input form on the right side. The query form contains a hidden form parameter language that defines the form's language. For example, language=4 corresponds to English language. This parameter is submitted together with other query parameters so that the servlet knows it has to respond in English language.
The lower frame contains response to user's queries. Responses are dynamically generated by Java servlets.
Figure 3 shows the organization of Internet directories which contain different file types and files which correspond to different languages. A good initial organization of directories allows easy maintenance at a later time.
Figure 3. Organization of the Internet directories
The root directory contains static HTML files common to all languages such as the HTML frameset file which holds the two frames shown in Figure 2. The figures directory contains graphic files common to all languages. The applets directory contains Java applet classes and JAR files that contain applets.
The servlets directory is not a physical directory. It is a virtual directory mounted onto the web server's directory system so a servlet is invoked as it is in a real directory such as http://www.aaa.ch/servlets/rates?p=a. The rates is a servlet's external name followed by zero or more query parameters, depending on the query and the method used to invoke the servlet (POST or GET).
The four remaining directories, de, fr, it, and en contain static HTML and graphic files which correspond to German, French, Italian, and English languages respectively. Names and functions of files they contain are same except that their contents are written in different languages.
In order to make software internally independent of any particular language, all language-dependent strings are referenced using their internal language-independent symbolic names. To achieve this, we used one instance of java.util.Properties class for each language known to the application. The Properties class contains a set of name-value pairs of strings. A method getProperty(String name) and the string's symbolic name are used to retreive striing in a specific language.
An instance of the Properties class may be loaded from a plain text property file which contains lines that have a form name=value. In order to improve readability of property files, we used a convention that property names have a form function.name. For example, properties
title.RPT_TITLE=Currency Exchange Rates
label.COUNTRY=Country
code.0119=Yugoslavia
error.DB_ERROR=Database error
define a report title, a label, a country name internally referenced using country's ISO (International Standards Organization) currency code, and an error message. Property files for other languages have the right-hand side of the equality sign translated to the corresponding language. During the initialization, an application loads one property file (vocabulary) for each language it supports, and creates an array of instances of Properties that correspond to supported languages. Language-specific strings are retrieved using the internal string name and the language code received from an HTML query form. The following code may be used to translate internal language-independent string names to language-specific strings:
0 comments:
Post a Comment