Apache Struts is an open-source web application framework for developing Java EE web applications.

It uses and extends the Java Servlet API to encourage developers to adopt a modelview-controller (MVC) architecture. It was originally created by Craig McClanahan and donated to the Apache Foundation in May, 2000. Formerly located under the Apache Jakarta Project and known as Jakarta Struts, it became a top level Apache project in 2005. Struts is categorized as a request-based web application framework.[1] Struts also supports internationalization by web forms, and includes a template mechanism called "Tiles" that (for instance) allows the presentation layer to be composed from independent header, footer, and content components. In a standard Java EE web application, the client will typically submit information to the server via a web form. The information is then either handed over to a Java Servlet that processes it, interacts with a database and produces an HTML-formatted response, or it is given to a JavaServer Pages (JSP) document that intermingles HTML and Java code to achieve the same result. Both approaches are often considered inadequate for large projects because they mix application logic with presentation and make maintenance difficult. The goal of Struts is to separate the model (application logic that interacts with a database) from the view (HTML pages presented to the client) and the controller (instance that passes information between view and model). Struts provides the controller (a servlet known as ActionServlet) and facilitates the writing of templates for the view or presentation layer (typically in JSP, but XML/XSLT and Velocity are also supported). The web application programmer is responsible for writing the model code, and for creating a central configuration file strutsconfig.xml that binds together model, view and controller. Requests from the client are sent to the controller in the form of "Actions" defined in the configuration file; if the controller receives such a request it calls the corresponding Action class that interacts with the application-specific model code. The model code returns an "ActionForward", a string telling the controller what output page to send to the client. Information is passed between model and view in the form of special JavaBeans. A powerful custom tag library allows it to read and write the content of these beans from the presentation layer without the need for any embedded Java code.

The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react. The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes. A viewport typically has a one to one correspondence with a display surface and knows how to render to it. The controller receives user input and initiates a response by making calls on model objects. A controller accepts input from the user and instructs the model and viewport to perform actions based on that input. An MVC application may be a collection of model/view/controller triads, each responsible for a different UI element. The Swing GUI system, for example, models almost all interface components as individual MVC systems. MVC is often seen in web applications where the view is the HTML or XHTML generated by the app. The controller receives GET or POST input and decides what to do with it, handing over to domain objects (i.e. the model) that contain the business rules and know how to carry out specific tasks such as processing a new subscription, and which hand control to (X)HTML-generating components such as templating engines, XML pipelines, Ajax callbacks, etc. The model is not necessarily merely a database; the 'model' in MVC is both the data and the business/domain logic needed to manipulate the data in the application. Many applications use a persistent storage mechanism such as a database to store data. MVC does not specifically

mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects; however, in very simple apps that have little domain logic there is no real distinction to be made. Active Record is an accepted design pattern that merges domain logic and data access code - a model which knows how to persist itself. Simple Version implementing Java Servlets and JavaServer Pages from Java EE: Model The model is a collection of Java classes that form a software application intended to store, and optionally separate, data. A single front end class that can communicate with any user interface (for example: a console, a graphical user interface, or a web application). View The view is represented by a JavaServer Page, with data being transported to the page in the HttpServletRequest or HttpSession. Controller The Controller servlet communicates with the front end of the model and loads the HttpServletRequest or HttpSession with appropriate data, before forwarding the HttpServletRequest and Response to the JSP using a RequestDispatcher. The Servlet is a Java class, and it communicates and interacts with the model, but does not need to generate HTML or XHTML output; the JSPs do not have to communicate with the model because the Servlet provides them with the informationthey can concentrate on creating output. Unlike the other frameworks, Java EE defines a pattern for model objects. Model The model is commonly represented by entity beans, although the model can be created by a servlet using a business object framework such as Spring. View The view in a Java EE application may be represented by a JavaServer Page, which may be currently implemented using a web framework, such as Adobe Flex, Struts 2, or JavaServer Faces (JSF). Alternatively, the code to generate the view may be part of a servlet. Controller The controller in a Java EE application may be represented by a servlet, which may be currently implemented using JavaSIn a standard Java EE web application, the client will typically submit information to the server via a web form. The information is then either handed over to a Java Servlet that processes it, interacts with a database and produces an HTML-formatted response, or it is given to a JavaServer Pages (JSP) document that intermingles HTML and Java code to achieve the same result. Both approaches are often considered inadequate for large projects because they mix application logic with presentation and make maintenance difficult. The goal of Struts is to separate the model (application logic that interacts with a database) from the view (HTML pages presented to the client) and the controller (instance that passes information between view and model). Struts provides the controller (a servlet known as ActionServlet) and facilitates the writing of templates for the view or presentation layer (typically in JSP,erver Faces (JSF).

Requests from the client are sent to the controller in the form of "Actions" defined in the configuration file; if the controller receives such a request it calls the corresponding Action class that interacts with the application-specific model code. The model code returns an "ActionForward", a string telling the controller what output page to send to the client. Information is passed between model and view in the form of special JavaBeans. A powerful custom tag library allows it to read and write the content of these beans from the presentation layer without the need for any embedded Java code. Struts is categorized as a request-based web application framework Modelviewcontroller (MVC) is a software architecture,[1] currently considered an architectural pattern used in software engineering. The pattern isolates "domain logic" (the application logic for

the user) from the user interface (input and presentation), permitting independent development, testing and maintenance of each (separation of concerns).

All the similar queries are clustered first.All the similar concepts are clustered along with the query. The concept then realised by the user gains weightage and hence would be displayed at the bigening. remember first the query clustering takes place and then the concept clustering takes place.