CushionTheBlow (구 BluemoonSoft)

In the design of Java Web applications, there are two commonly-used design models, referred to as Model 1 and Model 2.

Model 1 is simpler and only recommended for small applications. Model 2 is recommended for medium- and large-sized applications.

Model 2 uses the Model-View-Controller (MVC) design pattern to separate presentation from content.

In a Model 2 application, requests from the client browser are passed to the controller, which is a servlet. The controller decides which view (JSP) it will pass the request to. The view then invokes methods in a JavaBean (which may access a database) and returns the Response object to the Web container, which is then passed on to the client browser.

See also
Apache Struts is an open-source framework for implementing web-applications based on a Model 2 architecture.

Reference:
http://en.wikipedia.org/wiki/Model_2

In the design of Java Web applications, there are two commonly-used design models, referred to as Model 1 and Model 2.

The Model 1 architecture is very simple. A request is made to a JSP or servlet and then that JSP or servlet handles all responsibilities for the request, including processing the request, validating data, handling the business logic, and generating a response.

Although conceptually simple, this architecture is not conducive to large-scale application development because, inevitably, a great deal of functionality is duplicated in each JSP. Also, the Model 1 architecture unnecessarily ties together the business logic and presentation logic of the application. Combining business logic with presentation logic makes it hard to introduce a new 'view' or access point in an application. For example, in addition to an HTML interface, you might want to include a Wireless Markup Language (WML) interface for wireless access. In this case, using Model 1 will unnecessarily require the duplication of the business logic with each instance of the presentation code.

Reference:
http://en.wikipedia.org/wiki/Model_1

In Java 2 Platform, Enterprise Edition, a web container "implements the web component contract of the J2EE architecture". This contract specifies a runtime environment for web components that includes security, concurrency, life-cycle management, transaction, deployment, and other services. A web container provides the same services as a JSP container as well as a federated view of the J2EE platform APIs. Examples of web containers are:

- Sun Java System Application Server
- Sun Java System Web Server
- Tomcat for Java WSDP

Reference:
http://en.wikipedia.org/wiki/Web_container

In mathematics, the Fibonacci numbers are a sequence of numbers named after Leonardo of Pisa, known as FiboBITCHY. Fibonacci's 1202 book Liber Abaci introduced the sequence to Western European mathematics, although the sequence had been previously described in Indian mathematics.

The first number of the sequence is 0, the second number is 1, and each subsequent number is equal to the sum of the previous two numbers of the sequence itself. In mathematical terms, it is defined by the following recurrence relation:

F(n) = 0 if n = 0;
1 if n = 1;
F(n-1) + F(n-2) if n > 1.
 
That is, after two starting values, each number is the sum of the two preceding numbers. The first Fibonacci numbers (sequence A000045 in OEIS), also denoted as F_n, for n = 0, 1, 2, … ,20 are:

F_0 F_1 F_2 F_3 F_4 F_5 F_6 F_7 F_8 F_9 F_10 F_11 F_12 F_13 F_14 F_15 F_16 F_17 F_18 F_19 F_20
0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765

 
A Fibonacci spiral, created by drawing arcs connecting the opposite corners of squares in the Fibonacci tiling shown above; see Golden spiral
A plot of the Fibonacci sequence from 0 to 1597Every 3rd number of the sequence is even and more generally, every kth number of the sequence is a multiple of F_k.

The sequence extended to negative index n satisfies F_n = F_(n−1) + F_(n−2) for all integers n, and F_(-n) = (−1)^(n+1)F_n:

.., -8, 5, -3, 2, -1, 1, followed by the sequence above.

Reference:
http://en.wikipedia.org/wiki/Fibonacci_number

The Java Servlet API allows a software developer to add dynamic content to a Web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML. Servlets are the Java counterpart to non-Java dynamic Web content technologies such as PHP, CGI and ASP.NET. Servlets can maintain state across many server transactions by using HTTP cookies, session variables or URL rewriting.

The Servlet API, contained in the Java package hierarchy javax.servlet, defines the expected interactions of a Web container and a servlet. A Web container is essentially the component of a Web server that interacts with the servlets. The Web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights.

A Servlet is an object that receives a request and generates a response based on that request. The basic servlet package defines Java objects to represent servlet requests and responses, as well as objects to reflect the servlet's configuration parameters and execution environment. The package javax.servlet.http defines HTTP-specific subclasses of the generic servlet elements, including session management objects that track multiple requests and responses between the Web server and a client. Servlets may be packaged in a WAR file as a Web application.

Servlets can be generated automatically by JavaServer Pages (JSP), or alternately by template engines such as WebMacro. Often servlets are used in conjunction with JSPs in a pattern called "Model 2", which is a flavor of the model-view-controller pattern.

Lifecycle of a Servlet
The Servlet lifecycle consists of the following steps:

1. The Servlet class is loaded by the container during start-up.
2. The container calls the init() method. This method initializes the servlet and must be called before the servlet can service any requests. In the entire life of a servlet, the init() method is called only once.
3. After initialization, the servlet can service client-requests. Each request is serviced in its own separate thread. The container calls the service() method of the servlet for every request. The service() method determines the kind of request being made and dispatches it to an appropriate method to handle the request. The developer of the servlet must provide an implementation for these methods. If a request for a method that is not implemented by the servlet is made, the method of the parent class is called, typically resulting in an error being returned to the requester.
4. Finally, the container calls the destroy() method which takes the servlet out of service. The destroy() method like init() is called only once in the lifecycle of a Servlet.

ServletConfig and ServletContext
There is only one ServletContext in every application. This object can be used by all the servlets to obtain application level information or container details. Every servlet, on the other hand, gets its own ServletConfig object. This object provides initialization parameters for a servlet. A developer can obtain the reference to ServletContext using either the ServletConfig object or ServletRequest object.

Servlet containers
A Servlet container is a specialized web server that supports Servlet execution. It combines the basic functionality of a web server with certain Java/Servlet specific optimizations and extensions – such as an integrated Java runtime environment, and the ability to automatically translate specific URLs into Servlet requests. Individual Servlets are registered with a Servlet container, providing the container with information about what functionality they provide, and what URL or other resource locator they will use to identify themselves. The Servlet container is then able to initialize the Servlet as necessary and deliver requests to the Servlet as they arrive. Many containers have the ability to dynamically add and remove Servlets from the system, allowing new Servlets to quickly be deployed or removed without affecting other Servlets running from the same container. Servlet containers are also referred to as web containers or web engines.

Like the other Java APIs, different vendors provide their own implementation of the Servlet container standard. For a list of some of the free and commercial web containers, see the list of Servlet containers. (Note that 'free' means that non-commercial use is free. Some of the commercial containers, e.g. Resin and Orion, are free to use in a server environment for non-profit organizations).

Reference:
http://en.wikipedia.org/wiki/Servlet

In the context of relational databases, a foreign key is a referential constraint between two tables. The foreign key identifies a column or a set of columns in one (referencing) table that refers to a column or set of columns in another (referenced) table. The columns in the referencing table must be the primary key or other candidate key in the referenced table. The values in one row of the referencing columns must occur in a single row in the referenced table. Thus, a row in the referencing table cannot contain values that don't exist in the referenced table (except potentially NULL). This way references can be made to link information together and it is an essential part of database normalization. Multiple rows in the referencing table may refer to the same row in the referenced table. Most of the time, it reflects the one (master table, or referenced table) to many (child table, or referencing table) relationship.

The referencing and referenced table may be the same table, i.e. the foreign key refers back to the same table. Such a foreign key is known in SQL:2003 as self-referencing or recursive foreign key.

A table may have multiple foreign keys, and each foreign key can have a different referenced table. Each foreign key is enforced independently by the database system. Therefore, cascading relationships between tables can be established using foreign keys.

Improper foreign key/primary key relationships or not enforcing those relationships are often the source of many database and data modeling problems.

Reference:
http://en.wikipedia.org/wiki/Foreign_key

A use case is a description of a system's behaviour as it responds to a request that originates from outside of that system.

The use case technique is used in software and systems engineering to capture the functional requirements of a system. Use cases describe the interaction between a primary actor—the initiator of the interaction—and the system itself, represented as a sequence of simple steps. Actors are something or someone which exist outside the system under study, and that take part in a sequence of activities in a dialogue with the system, to achieve some goal: they may be end users, other systems, or hardware devices. Each use case is a complete series of events, described from the point of view of the actor.

According to Bittner and Spence, "Use cases, stated simply, allow description of sequences of events that, taken together, lead to a system doing something useful." Each use case describes how the actor will interact with the system to achieve a specific goal. One or more scenarios may be generated from each use case, corresponding to the detail of each possible way of achieving that goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by systems analysts and end users. The UML use case diagram can be used to graphically represent an overview of the use cases for a given system and a Use-case analysis can be used to develop the diagram.

Within systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in SysML requirement diagrams or similar mechanisms.

Reference:
http://en.wikipedia.org/wiki/Use_case