Spring Framework

The Spring framework [Spring] is a multi-purpose framework based on the Java platform.

Although the important part for this work is the Spring Web framework, it can also be used independently of the Web application context. Integration facilities for different technolo-gies for several domains, such as persistence or transaction management, are provided. A modular architecture facilitates extensibility and reuse. The following modules are com-prised:

• Web framework

• Beans (factory, naming services, events, …)

• Support of common middleware technologies like CORBA, SOAP or Web services

• Direct Access Objects (DAO, database abstraction layer)

• Object Relational Mappings (ORM, integration layer for object relational map-pings, e.g. JDO, Hibernate, iBatis)

• Transaction management

• Aspect Oriented Programming (AOP, support for aspect oriented programming conform with AOP alliance and AspectJ)

The Spring Web framework is based on the Model/View/Controller (MVC) pattern [Reen-skaug79]: the model encapsulates the core application data and functionality, the view pre-sents data from the model to the user and the controller receives requests from the user, modifies the model and updates the view. For Web application development a slightly modified version of the pattern named MVC 2, MVC Version 2 or MVC Model 2 [Sun02]

is used resembling the strict HTTP request/response protocol. The view is updated only on each user request and there is no mechanism so that the model can trigger an update in the view actively, for instance by using the Observer pattern [Gamma95]. An example for the MVC 2 control flow is given at the end of this section. As already mentioned in the last section, by using the MVC pattern, the Spring Web framework allows for a high degree of decoupling between the model, view and controller parts.

The Tomcat Web container is configured for using the Spring Web framework by the fol-lowing code lines in the configuration file web.xml of a Web application.

<web-app>

Model Driven Software Engineering for Web Applications

<servlet>

<servlet-name>dispatcher</servlet-name>

<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>

<load-on-startup>1</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>dispatcher</servlet-name>

<url-pattern>*.uwe</url-pattern>

</servlet-mapping>

</web-app>

The meaning of the entries in the configuration file is that for each request with a URL which ends with .uwe the request is dispatched to an instance of the DispatcherServlet from the Spring framework as illustrated in Figure 73. When the user of a Web application enters a URL in the Web browser then a HTTP request is sent to the Web server, i.e. the Tomcat Web container. This request is decoded and a corresponding HttpServletRequest object request is instantiated which can be used to query the decoded parts of the HTTP request, such as for example the parameters of the request. Additionally, a HttpServletRe-sponse object reHttpServletRe-sponse is instantiated that has to be used for returning the code of a Web page that should be displayed to the user. See [J2EE] for details about the request and re-sponse classes. If the Web server encounters a URL with the ending .uwe then the request is dispatched to the corresponding DispatcherServlet from the Spring framework by calling the doService method. After handling the request within the Spring Web framework (see below) the resulting Web page is displayed to the user.

Figure 73. Dispatching of a Web request to the DispatcherServlet

159

In the following, the roles of the model, view and controller parts within the generic plat-form are presented. Additionally, the employed abstraction technique for the communica-tion between the parts is discussed, which allows to decouple the parts (including the trans-formations) for the corresponding concerns from each other. While the generic platform is flexible with respect to the concrete technology for the model and the view parts, the con-troller part is predefined as presented in the next section.

Model: Minimal requirements are imposed on the target technology for transforming the content model to a platform specific implementation. It is not required that any specific superclasses or superinterfaces are extended or implemented, just any kind of Java objects can be used for the model, i.e. Plain Old Java Objects (POJO) [Spring]. The access to the model from the view or the controller parts should only rely on calling the get- and set- methods corresponding to the properties in the content model. These requirements are ful-filled by most technologies and therefore the model technology is exchangeable to a high degree. In the worst case appropriate proxy classes would have to be generated. Those principles also apply if a database should be used for the persistence of the content objects, i.e. a mapping would have to be defined between POJOs and the database. The easiest way to achieve this is to use the database mapping of Enterprise Java Beans (EJB) [J2EE] or any other database mapping technology.

The Tomcat Web container allows the passing of named variables of arbitrary type be-tween the controller and the view. The main controller from the runtime environment (pre-sented in the next section) provides the content object (i.e. the model) of the current Web page (i.e. the view) to be displayed in a variable with the name self. As stated above, a con-tent object can be of arbitrary type, it only has to provide get- and set- methods for access-ing its properties. The most convenient way for implementaccess-ing the access to content objects from the view is to use the unified expression language, as for example available for Java Server Pages, see [J2EE]. For example, the expression self.projects within the Web page for the project manager is resolved to the list of projects by calling the getProjects method on the project manager content object. For more detailed examples see 5.6 and 6.2.4.1.

View: The Spring Web framework provides a mechanism for decoupling the concrete view technology, i.e. the target technology for transforming the presentation model to a platform specific implementation, from the controller part (the model part does not depend from the view technology anyway). This allows for example the use of the following view tech-nologies:

o Java Server Pages (JSP) o Tiles (based on Struts)

Model Driven Software Engineering for Web Applications

o Velocity and Freemarker (template languages) o XML + XSLT

o Document views (e.g. PDF or excel) o Jasper reports (report engine)

o Portlets

o JavaServer Faces

Different view technologies can even be combined. Additionally, the Spring framework allows the integration in other Web frameworks such as Struts or JavaServer faces. The following code lines in the configuration file for the dispatcher servlet demonstrate how the framework is configured to use Java Server Pages (JSP) and the Java Standard Tag Li-brary (JSTL) view technology. Within the controller part a concrete view is referenced only by a name. This view name is resolved to a Web page by the Spring framework, using the configuration information. For example, the concrete view name ProjectManager would be resolved to the JSP page /WEB-INF/jsp/ProjectManager.jsp.

<bean id="viewResolver"

class="org.springframework.web.servlet.view.InternalResourceViewResolver">

<property name="viewClass">

<value>org.springframework.web.servlet.view.JstlView</value>

</property>

<property name="prefix"><value>/WEB-INF/jsp/</value></property>

<property name="suffix"><value>.jsp</value></property>

</bean>

The other way round, URLs embedded in Web pages are used for the communication be-tween the view and the controller. The URL must have the suffix .uwe preceded by the name of a node from the navigation model for navigation purposes, such as for example ProjectManager.uwe.

Controller: A controller in the Spring Web framework is a Java class that implements the interface Controller. An outline to the general control flow for handling a Web request within the Spring framework, including the model, view and controller parts, is illustrated by the sequence diagram depicted in Figure 74. As explained above and illustrated in Figure 73, a Web request is handled within the doService method of the dispatcher servlet from the Spring framework. This request is then further delegated to a controller

imple-161

mentation by calling the method handleRequest. Here, the class MainController presented in the next section serves to illustrate the basic control flow within a controller. The method handleRequest has to return an object of type ModelAndView, which is a utility class used to return both the model and the view instances in a single return value. Note that the term model as used here refers to the data required for the presentation of a single Web page, i.e. a single content object. The model is implemented by a map, which contains exactly one entry self that holds a reference to the current content object. In the example the content object rootObject, which represents the entry point of the application as ex-plained in the next section is put in the map. Then a ModelAndView object is constructed with the name of the view to be displayed, in the example the view ProjectManager, and a reference to the model map. After the method call has returned, the dispatcher servlet calls its method render to render the resulting Web page. Within this method the call is further delegated to the concrete view implementation which receives a reference to the model map. The view implementation, in the example a JstlView for rendering Java Server Pages, retrieves the content object to be displayed from the model map and renders the Web page.

Model Driven Software Engineering for Web Applications

Figure 74. Handling of a Web request within the Spring Web framework