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

or a web application).a model which knows how to persist itself. The Servlet is a Java class. Controller The controller in a Java EE application may be represented by a servlet. Alternatively. Struts 2. before forwarding the HttpServletRequest and Response to the JSP using a RequestDispatcher. such as Adobe Flex. The pattern isolates "domain logic" (the application logic for . which may be currently implemented using a web framework. although the model can be created by a servlet using a business object framework such as Spring. if the controller receives such a request it calls the corresponding Action class that interacts with the application-specific model code. the client will typically submit information to the server via a web form. View The view is represented by a JavaServer Page. and optionally separate. Java EE defines a pattern for model objects. 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. the JSPs do not have to communicate with the model because the Servlet provides them with the information—they can concentrate on creating output. the code to generate the view may be part of a servlet. a string telling the controller what output page to send to the client. The information is then either handed over to a Java Servlet that processes it.[1] currently considered an architectural pattern used in software engineering. 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). Unlike the other frameworks. Model The model is commonly represented by entity beans. 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. Controller The Controller servlet communicates with the front end of the model and loads the HttpServletRequest or HttpSession with appropriate data. Models are not data access objects. Requests from the client are sent to the controller in the form of "Actions" defined in the configuration file. Struts is categorized as a request-based web application framework Model–view–controller (MVC) is a software architecture. however. data. Active Record is an accepted design pattern that merges domain logic and data access code . or it is given to a JavaServer Pages (JSP) document that intermingles HTML and Java code to achieve the same result. in very simple apps that have little domain logic there is no real distinction to be made. Both approaches are often considered inadequate for large projects because they mix application logic with presentation and make maintenance difficult. View The view in a Java EE application may be represented by a JavaServer Page. The model code returns an "ActionForward".erver Faces (JSF). Information is passed between model and view in the form of special JavaBeans. A single front end class that can communicate with any user interface (for example: a console. Struts provides the controller (a servlet known as ActionServlet) and facilitates the writing of templates for the view or presentation layer (typically in JSP.mention the data access layer because it is understood to be underneath or encapsulated by the model. but does not need to generate HTML or XHTML output. interacts with a database and produces an HTML-formatted response. a graphical user interface. and it communicates and interacts with the model. or JavaServer Faces (JSF). which may be currently implemented using JavaSIn a standard Java EE web application. with data being transported to the page in the HttpServletRequest or HttpSession.

remember first the query clustering takes place and then the concept clustering takes place. . testing and maintenance of each (separation of concerns).the user) from the user interface (input and presentation). All the similar queries are clustered first. permitting independent development. The concept then realised by the user gains weightage and hence would be displayed at the bigening.All the similar concepts are clustered along with the query.