Introduction
In this article we describe the author's experience with the unconventional development of Internet applications. They were developed for a Suisse bank as a joint cooperation between the author located in Belgrade, Yugoslavia, and a Suisse software development company. The software was developed in a distributed fashion without any physical access to the production site.
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.
System Architecture
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.
All servers in the production environment run Sun Microsystems Solaris UNIX operating system. The web server is NES (Netscape Enterprise Server) with the addition of JRun engine for running Java servlets. The database server is Oracle. The CORBA application server is IONA OrbixWeb. CORBA clients use an internally developed API (Application Programming Interface) and wrapper Java classes developed on top of OrbixWeb.
The challenge in this project was to develop software in a distributed fashion without any physical presence at the production site, while still adhering to the very strict bank's security rules.
First, per the bank's development protocol, software developers do not have direct physical access to the production system. Instead, the developed software is handed over to the production system staff for final testing and installation on the production system.
Second, for security reasons, the already developed software cannot be taken out of the bank's premises for installation on a remote development system. It means that copies of the database and the applications running on the CORBA server were not available at the development site. Instead, stubs had to be developed to emulate the behavior of CORBA and database servers.
The entire software described in this article was developed on a single Windows NT Workstation. The CORBA server was one that comes with the JDK (Java Development Kit). The database was Microsoft Access. The web server was Apache with the JServ engine for running Java servlets. Software was developed using Oracle JDeveloper IDE (Integrated Development Environment). Obviously, the development and the production environments were very different, which was one of the development challenges.
The only contact between the development and the production sites was over the phone and via e-mail, thus software was developed solely in a telecommuting fashion. Once the database and CORBA stubs were set-up on the development site, and a basic skeleton of the application was set-up on the production site, it was easy to gradually build the application on the development site and test it on the production site. Software was shipped via e-mail in the form of compiled JAR (Java Archive) files and static text, HTML (Hyper-Text Markup Language), and graphic files.
Throughout the rest of this article, we will describe some of the tricks of trade used to overcome the development challenges.
CORBA Implementation
CORBA standard was, at least in theory, developed to standardize invocation of remote applications in networks. However, in practice, this is far from reality. In theory, the development of code which invokes remote, already developed applications, involves the following steps:
1. Use the remote application's IDL (Interface Definition Language) specification, and an IDL compiler to generate API stub code for invoking remote applications in the desired programming language (Java, C, C, C++).
2. Develop code for initiating the ORB (Object Request Broker) within the calling application under development.
3. Develop code for invoking remote applications from within the calling application under development.
However, in practice, there are a number of problems:
* CORBA applications developed in different programming languages may have problems talking to each other even when the development tools and the underlying libraries are produced by the same vendor.
* Java API specification is developed to standardize API and IDL stubs of all Java applications, thus maximize code portability. However, vendors of CORBA development tools like IONA did not adhere to this standard, so software developed using JDK and it's IDL compiler and CORBA name server cannot run using IONA's CORBA name server.
* Even different CORBA development tools of the same vendor, like IONA's OrbixWeb and Orbix 2000, are not mutually compatible, and require different application code.
Fortunately, the differences and incompatibilities in the application code apply mostly to a relatively small portion of the ORB initiation code. For that reason, it was possible to develop code using JDK CORBA environment and port it to the OrbixWeb production environment as follows:
1. Use the JDK IDL compiler to compile IDL specification and generate Java stubs for the development environment.
2. Develop and test the application using the ORB initiation code appropriate for the JDK environment.
3. Use the OrbixWeb IDL compiler to compile IDL specification and generate Java stubs for the OrbixWeb production environment.
4. Replace the ORB initiation code with the code needed for the OrbixWeb production environment.
Once this porting procedure is established, delivery of code modification is very efficient with a little help of code building scripts.
The other problem with the development of CORBA code was unavailability of the original CORBA application server. This problem was solved by developing a simple stub application server that emulates responses of the real application server. The stub server loads test data from a text file and upon request passes it to the CORBA client, i.e., to the requesting servlet in this case.
Database Implementation
Portability of JDBC (Java Database Connection) code is significantly better than CORBA related code. As long as database operations are restricted to standard SQL (Structured Query Language) and free of triggers and stored procedures, developed Java code runs on virtually any database. Porting to a different database type performed by simply specifying a different database source and driver in a database configuration textual file such as:
JDBCDriver = sun.jdbc.odbc.JdbcOdbcDriver
JDBCConnectionURL = jdbc:odbc:DbSource
The above two lines define database source named DbSource defined in the Windows ODBC (Open Database Connection) manager and the Sun Microsystems' JDBC-ODBC bridge database driver. By modifying the two lines in the database configuration file, one can switch from, e.g., Microsoft Access database at the development site to Oracle database at the production site. As a matter of fact, this approach is so convenient that the author used it in many other Java projects that involved databases. Microsoft Access allows quick prototyping and modification. Once the database design is finalized, the database can be ported to Oracle using an Oracle database porting tool. In addition, this approach allows the use of a laptop computer for demonstration of work in progress at a customer's site.
This approach was used in the project described in this article to quickly create the database stub that emulates behavior of the database at the production site. Since the application used a small subset of tables and fields in the actual database, replication of their structure at the development site was quick and easy.
When it comes to database Internet applications, another trick worth mentioning is the use of database connection pools. A typical servlet-based Internet application that uses a database involves three steps when a servlet is invoked: connecting to the database, accessing data, and disconnecting from the database. Connecting to the database is a time-consuming operation. For that reason, pools of pre-established database connections are maintained. Each servlet maintains a connection pool which consists of a configurable number of pre-established database connections. Instead of waiting for the connection to be established, a database request takes an already established connection from the pool, uses it, and later returns it back to the pool for further reuse. The use of connection pools significantly improves the application's performance. Oracle's JDeveloper IDE comes with a library that implements a connection pool manager. However, the author uses one of many connection pool implementations available for download from the Internet.
SOURCE:
http://www.technologyevaluation.com/research/articles/the-art-of-distributed-development-of-multi-lingual-three-tier-internet-applications-16870/
In this article we describe the author's experience with the unconventional development of Internet applications. They were developed for a Suisse bank as a joint cooperation between the author located in Belgrade, Yugoslavia, and a Suisse software development company. The software was developed in a distributed fashion without any physical access to the production site.
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.
System Architecture
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.
All servers in the production environment run Sun Microsystems Solaris UNIX operating system. The web server is NES (Netscape Enterprise Server) with the addition of JRun engine for running Java servlets. The database server is Oracle. The CORBA application server is IONA OrbixWeb. CORBA clients use an internally developed API (Application Programming Interface) and wrapper Java classes developed on top of OrbixWeb.
The challenge in this project was to develop software in a distributed fashion without any physical presence at the production site, while still adhering to the very strict bank's security rules.
First, per the bank's development protocol, software developers do not have direct physical access to the production system. Instead, the developed software is handed over to the production system staff for final testing and installation on the production system.
Second, for security reasons, the already developed software cannot be taken out of the bank's premises for installation on a remote development system. It means that copies of the database and the applications running on the CORBA server were not available at the development site. Instead, stubs had to be developed to emulate the behavior of CORBA and database servers.
The entire software described in this article was developed on a single Windows NT Workstation. The CORBA server was one that comes with the JDK (Java Development Kit). The database was Microsoft Access. The web server was Apache with the JServ engine for running Java servlets. Software was developed using Oracle JDeveloper IDE (Integrated Development Environment). Obviously, the development and the production environments were very different, which was one of the development challenges.
The only contact between the development and the production sites was over the phone and via e-mail, thus software was developed solely in a telecommuting fashion. Once the database and CORBA stubs were set-up on the development site, and a basic skeleton of the application was set-up on the production site, it was easy to gradually build the application on the development site and test it on the production site. Software was shipped via e-mail in the form of compiled JAR (Java Archive) files and static text, HTML (Hyper-Text Markup Language), and graphic files.
Throughout the rest of this article, we will describe some of the tricks of trade used to overcome the development challenges.
CORBA Implementation
CORBA standard was, at least in theory, developed to standardize invocation of remote applications in networks. However, in practice, this is far from reality. In theory, the development of code which invokes remote, already developed applications, involves the following steps:
1. Use the remote application's IDL (Interface Definition Language) specification, and an IDL compiler to generate API stub code for invoking remote applications in the desired programming language (Java, C, C, C++).
2. Develop code for initiating the ORB (Object Request Broker) within the calling application under development.
3. Develop code for invoking remote applications from within the calling application under development.
However, in practice, there are a number of problems:
* CORBA applications developed in different programming languages may have problems talking to each other even when the development tools and the underlying libraries are produced by the same vendor.
* Java API specification is developed to standardize API and IDL stubs of all Java applications, thus maximize code portability. However, vendors of CORBA development tools like IONA did not adhere to this standard, so software developed using JDK and it's IDL compiler and CORBA name server cannot run using IONA's CORBA name server.
* Even different CORBA development tools of the same vendor, like IONA's OrbixWeb and Orbix 2000, are not mutually compatible, and require different application code.
Fortunately, the differences and incompatibilities in the application code apply mostly to a relatively small portion of the ORB initiation code. For that reason, it was possible to develop code using JDK CORBA environment and port it to the OrbixWeb production environment as follows:
1. Use the JDK IDL compiler to compile IDL specification and generate Java stubs for the development environment.
2. Develop and test the application using the ORB initiation code appropriate for the JDK environment.
3. Use the OrbixWeb IDL compiler to compile IDL specification and generate Java stubs for the OrbixWeb production environment.
4. Replace the ORB initiation code with the code needed for the OrbixWeb production environment.
Once this porting procedure is established, delivery of code modification is very efficient with a little help of code building scripts.
The other problem with the development of CORBA code was unavailability of the original CORBA application server. This problem was solved by developing a simple stub application server that emulates responses of the real application server. The stub server loads test data from a text file and upon request passes it to the CORBA client, i.e., to the requesting servlet in this case.
Database Implementation
Portability of JDBC (Java Database Connection) code is significantly better than CORBA related code. As long as database operations are restricted to standard SQL (Structured Query Language) and free of triggers and stored procedures, developed Java code runs on virtually any database. Porting to a different database type performed by simply specifying a different database source and driver in a database configuration textual file such as:
JDBCDriver = sun.jdbc.odbc.JdbcOdbcDriver
JDBCConnectionURL = jdbc:odbc:DbSource
The above two lines define database source named DbSource defined in the Windows ODBC (Open Database Connection) manager and the Sun Microsystems' JDBC-ODBC bridge database driver. By modifying the two lines in the database configuration file, one can switch from, e.g., Microsoft Access database at the development site to Oracle database at the production site. As a matter of fact, this approach is so convenient that the author used it in many other Java projects that involved databases. Microsoft Access allows quick prototyping and modification. Once the database design is finalized, the database can be ported to Oracle using an Oracle database porting tool. In addition, this approach allows the use of a laptop computer for demonstration of work in progress at a customer's site.
This approach was used in the project described in this article to quickly create the database stub that emulates behavior of the database at the production site. Since the application used a small subset of tables and fields in the actual database, replication of their structure at the development site was quick and easy.
When it comes to database Internet applications, another trick worth mentioning is the use of database connection pools. A typical servlet-based Internet application that uses a database involves three steps when a servlet is invoked: connecting to the database, accessing data, and disconnecting from the database. Connecting to the database is a time-consuming operation. For that reason, pools of pre-established database connections are maintained. Each servlet maintains a connection pool which consists of a configurable number of pre-established database connections. Instead of waiting for the connection to be established, a database request takes an already established connection from the pool, uses it, and later returns it back to the pool for further reuse. The use of connection pools significantly improves the application's performance. Oracle's JDeveloper IDE comes with a library that implements a connection pool manager. However, the author uses one of many connection pool implementations available for download from the Internet.
SOURCE:
http://www.technologyevaluation.com/research/articles/the-art-of-distributed-development-of-multi-lingual-three-tier-internet-applications-16870/
No comments:
Post a Comment