By S.Baskar and V.V.S.Raveendra

After the advent of e-business, companies are classified into three different categories [1]. Brick & Mortar companies doing business in the traditional way, Dotcoms that are purely online companies and Hybrid ones. A hybrid company could have come into existence either way, i.e., a dotcom could extend its business into the traditional world or a brick & mortar could delve into e-business. From technology perspective when a brick & mortar company considers launching its e-business, it has problems of inertia. It has to leverage on its existing legacy systems. It can’t afford to develop all the applications afresh. It has to integrate legacy systems and new online systems to align with its e-business strategy. This is also known sometimes as web enabling of legacy systems or Enterprise Application Integration. It is not possible (also not desirable) to employ asynchronous integration for all business processes. For example, a customer wants to check his balance in his bank account at any given point of time. In such a scenario, synchronous integration becomes mandatory. Synchronous integration affects not only performance and security of applications but also schedule and cost of a project.

This paper discusses about our experiences in web enabling a legacy system that needed synchronous and asynchronous integration. Our experiences are detailed as best practices and lessons learnt, instead of following the conventional life cycle model [2]. Before moving on to technology aspects, a concise introduction to the business concepts of the application is given below.

The application primarily deals with various pensions’ products in insurance business. The products are related to personal and occupational pensions. They can be for individuals or groups. High level functionality can be divided into the following modules: Quotes, Servicing and Printing.

• ‘Quotes’ module handles the processes related to an individual customer obtaining a quote or an employer setting up a scheme.
• ‘Servicing’ deals with change of address or switching of funds etc.
• ‘Printing’ includes a range of functions varying from display of a quote in the browser as a PDF file to printing all individual quotes belonging to a scheme.

Figure 1 depicts the relationship between some of the terms used. A Company (which is an insurance company’s customer) can set up many schemes of a group pensions product. A scheme can have many groups, for example, Senior Managers, Managers, and Clerks. A group can have many members. A generic quote can be issued for a group and a specific quote can be issued for a group member. In the case of Individual Pensions product, each member is treated separately without any groups or schemes.

The project had a deadline that can not be changed because of government regulation. The dependencies were too many: the legacy application had to be reused as much as possible. The legacy applications were on three different platforms. They are on Tandem, S/390 and NAS2 (Netscape Application Server 2.0). At the same time the user interface had to be browser based so that various streams can access it, i.e. customers, business partners and customer call centre. The application should have security features to cater to the needs of all. Performance is critical, as it has to interface with customers and call centre. The application needed synchronous and asynchronous integration with applications residing on various platforms: Netscape Application Server 4.0 (the new application to reside on this), NAS2, Tandem and IBM S/390. All the requirements were not known a priori. They could only be defined progressively, making the risk higher.

The application is developed using HTML, Javascript, Java, Servlets, JDBC/ODBC, Java Server Pages (JSPs) and Enterprise Java Beans (EJBs). The web server is iPlanet web server 4.1, application server is Netscape Application Server 4.0 and the directory server is Netscape Directory Server 4.0. The database is UDB (Universal Data Base) Version 5.2. PVCS is used as a configuration management tool.

The high level architectural components are depicted in figure 2 from deployment perspective. The user interface is presented through a browser. The user request goes to the application server via the web server. Depending on the business function invoked by the user the request gets passed on to the UDB or Tandem or S/390 synchronously. (Example business functions are: setting up a scheme, adding a group or modifying the details of an existing group.) An API (developed in house) is used for synchronous communication. The software residing on web server and application server has minimal business logic. It does more of web enabling than dealing with the business logic.

The integration between NAS2 and NAS4 is because of the hyperlink from an old application hosted on NAS2 to the current application residing on NAS4. In that sense, it is front-end integration. On the other hand the integration between NAS4 and Tandem (or IBM mainframe) is back-end integration. ‘Quotes’ has synchronous integration, where as ‘Servicing’ and ‘Printing’ have both synchronous and asynchronous integration.

Figure 3 gives the design point of view of the multi-layered architecture. The screens are presented to the user as JSPs. JSPs communicate with functional servlets. A functional servlet controls a business function like setting up a scheme, or doing a quote. The functional servlets communicate with their corresponding functional EJBs. Analogous to functional servlets, functional EJBs implement a specific business function. For example, a functional servlet and a functional EJB together handle adding a member to a group. In the MVC (Model, View, and Controller) paradigm, a functional servlet is a controller and a functional EJB is a model. The EJBs used here are stateless session beans. These functional EJBs communicate synchronously with Tandem or S/390 server via a custom API.

Design Patterns

The primary goal of the project was web enabling on schedule within the available time. Therefore, making a pure object oriented design based on UML (Unified Modelling Language) was not part of the agenda. We have made use of design patterns wherever possible. Design patterns are recurring solutions to design problems you see over and over again [3]. The requirements for various versions of the products were defined progressively. Therefore the design patterns are immensely helpful in absorbing the uncertainties in the definition of requirements yet to come. This is the added benefit apart from the enhancement of maintainability for future. In the following we detail some of the patterns we have implemented.

In ‘Servicing’ module Bridge Pattern [3,4] came as a natural fit. Depending on whether a member belongs to a group pensions product or individual pensions product, the implementation of a particular transaction differs. The definition (or abstraction) and implementation of a service of group and individual pensions products can vary independently from each other.

Factory pattern [3,5] in our insurance application is used to handle various products with similar (but, not same) features. Based on the product chosen by the user, appropriate object is created in the beginning of a process itself.

While moving from one screen on the browser to another screen, servlets get the transaction ID from JSP. Based on the transaction ID, the servlet displays suitable JSP. The disadvantage with such an approach is, as more and more screens are added the servlet loses its maintainability. To handle JSP navigation, we have employed the technique suggested by Lasseigne [6]. The essence is to delegate the responsibility of finding ‘from’ and ‘to’ screens to a table in an RDBMS. For simplicity we have implemented the concept with a table in Java.

By making use of design patterns, we could not only design the application better, but also the risk was mitigated by incorporating the requirements as and when they were defined.

There are five different types of products with some variations within each type of product. The products deal with personal and occupational pensions. There are different versions for groups & individuals. Altogether there exist 14 categories. The products have more or less similar business processes, with minor differences. Having a distinct JSP for each product variation is a simple solution, but not the best as it results in 14 different programs. Explicitly coding for all products in a single JSP was found to be difficult to develop and maintain. Therefore a special approach is followed.

A super set of the fields in all the screens is made and a flag is used for each field to display or not. This super set is held in class A. Bean B contains the list of fields to be displayed for a given type of product. Class C contains the logic that takes the decision to display.

Validations are of two types. They are single field and cross field validations. Stateless session beans do both types of validations. Single field validations are done in a novel way. Connecting to the servlets and session beans for single field validations restricts response time. On the other hand coding the validations in Javascript would make the maintenance harder. To strike a balance, Javascript is generated automatically and dynamically. The technique is detailed in the following (See figure 4).

A JSP contains Javascript of two types. The ‘static Javascript’ is the Javascript coded in the normal way. The ‘dynamic Javascript’ is generated at runtime. This contains the attributes of fields that are to be validated. If the user enters incorrect input, the format, length, range and type checking is done by Javascript and error message is thrown as an ‘alert’. The dynamic generation of Javascript eliminates the need for hard coding of attributes in the code. The attributes are stored in a file on the server side. Based on those values the Javascript is generated dynamically. Maintainability is enhanced by way of replacing the ‘code change’ with merely a ‘file change’.

The single field validations are further carried on by single field validation EJBs to cater to user interfaces other than a browser and also to improve security. Cross-field validations are done by cross-field validation EJBs. Only after completely validating the data, it is passed on to Tandem. The validations done so far are not from business perspective. The exhaustive business rule checking is done on Tandem and the errors if any are passed on to the browser. It should be noted that the components on the application server are designed to web enable rather than replicate the business rules which are already existing in the legacy system residing on the Tandem.

To manage authentication across different servers, single sign on is implemented. The complexity arises from the requirement of multiple access routes to the pensions’ application. A user could have logged into the business partners applications and entered into pensions’ application, through a hyperlink. In such scenarios the destination server (pensions application) queries the origin server (business partners application) for UserID and Password. The origin server returns the UserID and Password to the destination server. The destination server does a pseudo login to the pensions’ application. The communication of UserID and Password is through asymmetric encryption.

Main events are identified and logged through the custom API. Event logging classes are separated from the classes implementing business functions.

The errors found in input from single field and cross-field validation classes are displayed to the user. Whenever there is an error in processing (i.e. due to an exception being caught or failure due to lack of connection to other servers etc.), it is logged through the custom API. Error logging classes are also separated from the classes providing business functionality.

Standards are strictly followed. Important ones are:

1. A servlet is not allowed to invoke another servlet, i.e. servlet chaining is not used for simplicity. In addition, we did not have processes that necessitated servlet chaining.
2. Whenever a call has to be made to a servlet from a JSP, first the request is forwarded to a security servlet. Security servlet authenticates and authorises the user and forwards the HTTP request to appropriate functional servlet. Security servlet is a front servlet and does not play the role of event delegation [7].
3. Stateful session beans are not used. Because state could not be passivated across application server and Tandem. Another reason is that scaling with stateful session beans could become an issue. It was considered as a technology risk.
4. Functional EJBs communicate with relevant components of Tandem server. A functional EJB should not invoke another functional EJB.
5. Data from one program to another is passed on via a bean.

There are more than 100 Java Server Pages, about 35 servlets, 30 Stateless Session Beans and nearly 140 Beans. Total number of lines of code is about 150,000.

While testing the code the screens posed an interesting problem. While displaying a JSP, the Javascript code is also shown in the browser. Our investigation confirmed that the problem is with Netscape Communicator (versions after 3.0). The JSPs worked well with Internet Explorer. To alleviate the problem various options were attempted. The Cascaded Style Sheets ‘include’ statements and Javascript ‘include’ statements were removed to know if they were causing the problem. After more investigation, the cause of the problem was found to be the incomplete/incorrect implementation of caching technique by Netscape. Due to lack of time, a quick win solution was implemented. By setting ‘Disk Cache’ and ‘Memory Cache’ to zero the problem was solved. This has negative affect on performance, as the benefit of caching is not utilised. For other solutions to the same problem see References 8 and 9.

Some of the entry points (hyperlinks) are from different applications (Host Applications) hosted on a different website. The pensions’ application requires data, which are in the browser frame of the host application. The access of the host application frame from the pensions’ application frame using Javascript worked well with Netscape Communicator, but with Internet Explorer (Version 4 and above) this has resulted in cross frame reference exception. There is no straightforward solution that can be implemented at client side; hence design is changed to accommodate this functionality in the server side.

To improve the availability of the server, two Java server processes were created within a single application server. This has introduced the problem of session data not being synchronised between the processes. As a result of this, some of the user requests within a single logical dialog window lose the session information and result in error. A tactical solution was implemented by having separate servers and single Java server process in each server. The client requests are made sticky; i.e. all the requests within a session from the client will go to a single server.

For web enabling and application integration, first important step is to evaluate the need for synchronous and asynchronous integration vis-à-vis business imperatives. Synchronous integration is more difficult and expensive to achieve than asynchronous integration.

The applications to be integrated can be on homogeneous and non-homogeneous platforms. Planning early for application integration related aspect is more helpful.

Usage of design patterns improves the development and maintainability of code. In addition, the changes in requirements can be absorbed in coding with lesser effort.

A typical e-business project requires more testing effort than a normal in-house project. Testing for various versions of browsers and integration between different systems requires more time. It is important to allocate sufficient time for testing in any e-business project [10].

The next step is to enhance as a product, so that various business partners can present the user interface to their customers as though it is their own. This is possible as the user interface is browser based. The functionality can remain the same but the ‘look and feel’ needs to be based on the standards of the partners. For example, some companies use blue as their colour and some others use orange as their colour. We need to incorporate these features into our application.

The authors work for Tata Consultancy Services. They can be reached at baskar_sundararajan@yahoo.co.in and varanasi_vsr@yahoo.com.

1. S.Viswanathan, Dotcoms versus Notcoms: The Impact of Internet Commerce on Traditional Firms, Extended Abstract, Stern School of Business, USA.
2. Ed Roman, J2EE project management, Critical measures when beginning a J2EE project, at URL http://www2.theserverside.com/resources/ProjectManagement.jsp
3. J.W.Cooper, 1998, The Design Patterns Java companion, at URL http://www.patterndepot.com/put/8/JavaPatterns.htm
4. A.Shalloway and J.R.Trott, 2001, Design Patterns explained: A new perspective on Object Oriented Design, at URL http://www.netobjectives.com/dpexplained/dpe_toc.htm
5. G.S.Raj, The factory method design pattern, at URL http://gsraj.tripod.com/design/creational/factory/factory.html
6. T.Lasseigne, Nov 2000, Dynamic Servlet to JSP page navigation, Java Report, at URL http://www.javareport.com/html/from_pages/oldarticles.asp?ArticleID=1615
7. J.Hunter and W.Crawford, 1998, Java Servlet Programming, O’Reilly & Associates, Inc., California, USA.
8. Problem with Netscape Communicator, at URL http://developer.netscape.com/support/faqs/champions/javascript.html#2-9
9. Problems caching .js source files, at URL http://forum.java.sun.com/read/16802606/q_6Ak4sGNpYQAAc8w#LR
10. V.V.S.Raveendra, January 2001, E-business application development, First Monday, at URL http://firstmonday.org/issues/issue6_1/raveendra/index.html

April 2001