Follow your heart (102)-----Indian's design document

I think they copied this part for every project , but anyway , i can learn something from it. 说实话,有些我还没看明白.除了打省略号的是从我这边的文档copy过去,略加变了几句外.

1 Design Overview
1.1 Architectural Goals and Constraints

The overall architecture goals of the system is to provide a highly available and scalable ********Application for users, to ********
.
The Travel****Application can be used by travellers -
*********************

A key Architectural goal is to leverage industry best practices for designing and developing a scalable, enterprise-wide J2EE application. To meet this goal, the design of the ****Application will be based on core J2EE patterns as well as the industry standard development guidelines for building the ****Application.

总的看,好像他们是用j2ee做项目


1.2 Guiding Principles

Guiding principles provide a foundation upon which to develop the target architecture for the screening tool, in part by setting the standards and measures that the tool must satisfy. These in turn drive design principles that can be used to validate the design and
ensure that it is aligned with **** overall Architecture, Design Principles and Standards.

1.2.1 Scalable

Scalability is the ability of the platform to scale both up and down to support varying numbers of users or transaction volumes. The application should be able to scale horizontally (by adding more servers) or vertically (by increasing hardware capacity or software efficiency).
1.2.2 Flexible

Flexibility is the ability of the application to adapt and evolve to accommodate new requirements without affecting the existing operations. This relies on a modular architecture, which isolates the complexity of integration, presentation, and business logic from each other in order to allow for the easy integration of new technologies and processes within the application.
1.2.3 Standards-Based

Portal services will comply with established industry standards. The standards-compliance will not only apply to application development but also to design, platform/infrastructure and other parts of the Travel Management application. Examples of standards include HTML, XML, J2EE, and JSP.
1.3 Design Patterns

Design patterns are elements of reusable object oriented software. A design pattern catalog is a repository of design patterns. Use of such patterns makes the design of an application transparent. These patterns have been used successfully by developers in their respective fields, and therefore, the pros and cons of the pattern (as well as implementation issues) are known beforehand. All design patterns are reusable and can be adapted to particular contexts.
Some of the design patterns which will be used in the design and development of the Travel Management Application are -
• Front Controller
• Session Façade
• Business Delegate
• Data Access Object
• Value Object

1.3.1 Front Controller

The Front Controller pattern helps to implement a centralized entry point that controls and manages user (screen) request handling. The controller manages the handling of the request, including invoking security services such as authentication and authorization, delegating business processing, managing the choice of an appropriate view, handling errors, and managing the selection of content creation strategies.
1.3.2 Session Facade

The Session Façade pattern (using a session bean as a façade) helps to encapsulate the complexity of interactions between the business objects participating in a workflow. It manages the business objects, and provides a uniform coarse-grained service access layer to clients, that expose only the required interfaces.
1.3.3 Business Delegate

The Business Delegate pattern helps to reduce coupling between presentation-tier clients and business services. The Business Delegate hides the underlying implementation details of the business service, such as lookup and access details of the EJB architecture. Technical Design Document Page 8 of 32

1.3.4 Data Access Object

The Data Access Object pattern helps to decouple the session EJB layer from the database thus increasing the portability of the application.
1.3.5 Value Object

The Value Object design pattern, also known as the Data Transfer Object, efficiently transfers remote, fine-grained data by sending a coarse-grained view of the data. This design pattern will be used for the communication between the middle tier and the back end.
1.4 Design Principles

Best practices and design principles will be applied in two main areas –
1) Presentation Services to individual desktops should be uncoupled -
a) Presentation services are delivered to a web browser rather than to custom client software. A range of modern browsers that support HTML, DHTML, and XML are required.
b) A common look and feel for Travel Management application.
c) Client side JavaScript should be used for validating user input and prevent round trips between the browser and the server
d) The Travel Management Application user interface will be designed in such a way that common user interface functionality will be implemented in a similar manner across the board. Examples of this include –
• A consistent way of capturing date inputs
• A uniform way of displaying informational and error messages to the users
• A uniform way of displaying required and optional fields in the screens.
2) Business Rules should be encoded within the application development framework-
a) Business rules will need to be separated from the presentation and database frameworks
b) Server applications are based on event-based systems. Complex server side event cascades will need to be supported.
c) Standard frameworks for encoding business rules and events will need to be used.
d) Adoption of a component based framework needs to be considered to promote reuse of information objects.

2. Topology Diagram
The diagram below provides an illustration of the System Architecture along with various system components that will be used in architecting the Travel Management application -

Fig 1: Topology Diagram

Interaction of software components along with its responsibilities is explained below -
Web Server – Web server is responsible for serving web pages, mostly HTML pages, via the HTTP protocol to clients. The Web server sends out web pages in response to requests from browsers. A page request is generated when a client clicks a link on a web page in the browser.
JBOSS Application Server – Application server hosts the Online Screening application and hosts the business logic and the business model classes of applications. It serves requests for dynamic HTTP web pages from Web servers.
MySQL Database – Travel database stores the User data, travel trip data in relational format.
HTTP - Hyper Text Transport Protocol is the communication protocol used to connect to servers on the World Wide Web. The primary function of HTTP is to establish a connection with a Web server and transmit HTML pages to the user's browser.
JDBC – Java Database Connectivity is an application program interface (API) specification for connecting programs written in Java to the data in popular databases. The application program interface lets you encode access request statements in structured query language (SQL) that are then passed to the program that manages the database. It returns the results through a similar interface.
XML - A programming language/specification developed by the W3C, for organizing and tagging elements of a document so that the document can be transmitted and interpreted between applications and organizations.

3. Application Architecture
Application architecture defines the various components and their interactions in context of a whole system. Application architecture is the critical software that bridges the architectural gap between the application server and the application’s business logic, thereby eliminating the complexities and excessive costs of constructing, deploying and managing distributed enterprise applications.
The Online Screening Tool will have a layered application architecture which provides some of the key features below –
STRUCTURE: Organizing applications along business-level boundaries and not technical boundaries SPEED & FLEXIBILITY: Making application changes through configuration and not programming CONTROL: Modifying, extending or overwriting any architectural element. REUSE: Achieving greater reusability and integration by loosely coupling application logic to infrastructure.
At a conceptual level, they represent distinct and cohesive aggregations of functionality. The Online Screening Tool design is based on a tiered approach. “A tier is a logical partition of the separation of concerns of the system. Each tier is assigned its unique responsibility in the system. We view each tier as logically separated from one another. Each tier is loosely coupled with the adjacent tier.” The Online Screening Tool architecture can be represented in the following layers illustrated by the diagram below:
3.1 Presentation and Content Layer

The Client Tier represents the point at which data is consumed by the system’s users which include online users as well as external systems.
3.1.1 Presentation Layer

A standard Internet Browser such as Internet Explorer is the primary client for the online Screening application. HTML pages are delivered to the client browser by the Travel Management application upon a user request. The Web Pages support Chinese and English as user languages.
3.1.2 Content Layer

The content layer as the name signifies is the front-end information layer that the end-user interacts with. Data-to-content conversion and Content-to-data conversion are the two primary responsibilities of this layer. Any application that is created will use the common framework components to implement the primary responsibilities using the technology that seem most appropriate for that application. Choice of technology for this layer would range from plain HTML to a Java-HTML combination to an application.
3.2 Business Objects Layer



The Business layer will implement the business rules for the application. It will host the business service components as well as business objects (BO). These Business Services include Enterprise Java Beans and the BO’s include the dependent JAVA classes that will provide service API’s to the business rules and operations required by the application. Business components are software units, and process business logic.
The business components will implement the following: