Q&A

How does your design handle Scalability?
The following design aspects would help make the architecture scalable:

Web Server Cluster
The proposed solution makes use of the two web-servers. These servers will be clustered and would host the web-application. A load balancer would be used to distribute traffic to these servers. This will ensure best utilization of their capacity and also make sure no server is overloaded when no of users spikes up.

Stateless EJB
EJBs are the core of the proposed architecture. Stateless EJBs are container managed components and allow a limited number of instances to serve many clients thus making the application more scalable. The application server would ramp up/down the no. of instances as required.

Hardware Vertical and Horizontal Scaling
As the new architecture is J2EE based which would also support horizontal scaling. If, in future, FBN decides to add another Application Server, that can be clustered with the existing server.

DB Connection Pooling
JDBC database connections are both expensive to initially create and then maintain over time. As an application of this scale where users connect and disconnect frequently with applications, the application requests for data access can surge to considerable volume. Connection pooling would help reduce the overhead of creating new connections and would have a positive impact on scalability and performance.

How does your design handle performance?
Connection Pool
Connection pooling can improve the response time of any application that requires connections, especially Web-based applications. DAO Flight Search would undeoubtedly be the most frequently function of the system. In order to make it fast, DAOs are proposed. DAOs would give us the liberty of Query Optimization which can greatly enhance performance. This is in contrast to CMP Entity Beans where queries are generated by the Container. The other option that was considered was using BMP Entity Beans with DAOs, however, for searches we have avoided entity bean altogether and called Search DAOs from Stateless Session Beans.

Entity Beans
The new architecture proposes a mix of Entity Beans and DAOs. DAOs will be used for Searches whereas EntityBeans will be used for Itinerary and Profile Management. The benefit of Entity Beans can be leveraged in this case as it will not only make the development easier but also lifecycle/transaction management by the container would be more efficient.

Caching
Using ServiceLocators with Caching strategy would help minimize resource lookups. Frequently Used Data will be cached for the FatClient.

Local Interfaces
All EJBs are colocated and will use Local Interfaces. This will reduce the network overhead.

How does your design handle security?
For all internet communication, HTTPS will be used. Apart from that a DMZ would be created around the servers hosting the application. Also, travel agents nodes will be inside the network firewall.

How does your design handle Availability?
There is only one application server and two web servers. The availability is reduced as the app server is a single point of failure. However, the cluster of webservers would help keep at least one of the servers alive so the application would be up and running even if one of the webservers goes down.

How does your design handle Extensibility?
Extensibility is achieved by Low coupling, interfaces and encapsulation. The new application follows industry standard design patterns and strategies, makes use of components and employs interfaces for all external systems. This would ensure that the impact on the application would be minimal when it comes to enhancing/adapting it to changes.

How does your design handle Maintainability?
Low coupling, modularity, documentation

How does your design support session/state handling?
For the web application, session would be kept as HTTPSession, maintained in the webserver. Desktop Client would maintain its own state and would access stateless EJB Services. Desktop Client would also benefit from local cache of frequently used data which would help achieve its performance targets. The other alternatives of session state being using Stateful Session Beans and Database are not recommended. The majority of users are projected to be using the Web Application, so leveraging the cluster of two WebServers justifies the choice.

How does your design handle persistence?
The new application will make use of CMP Entity Beans. All Entity Beans will expose local interfaces and there relationships will be managed by Container (CMR EJB 2.1). Entity Beans would follow the Composite Entity Pattern. The new application will also use DAOs for searches and integration with FFM.

How does your client tier talk to business tier?
Both Web and Desktop Applications make use of services exposed by EJBs. The Business Delegate pattern is applied to ensure low-coupling between client and business tier. The business delegate in turn uses a Service Locator for looking up EJBs. The communication protocol is RMI/IIOP.

How does your design handle transactions?
EJBs are the core of the new application. The architecture proposes use of Container Managed (declarative) Transacations. This not only keeps the code clean and maintainable but also ensures that ACID requirements are satisfied without the developer coding for it. This is one of the biggest advantage of using EJBs.

How does your design handle authentication and authorization?
There are two kinds of users of the application - Travel Agents using the Desktop Client and Customers who use the web interface. The Desktop application would be a J2EE Application Client, and the J2EE Client container would authenticate the travel agents. Web Users will be authenticated by the container using a FORM login mechanism. The J2EE platform does not standardize a mechanism to add users dynamically to applications. So there is an obvious trade-off. Container Managed Security is easier to implement and maintain but would require a container specific code to access the user directory of the server. As this will only be a small piece of code and can be developed in a pluggable way so that when the need arises, can be replaced without much impact to the application, the architecture proposes the use of Container Managed Security.