N-Layer Architectures

N-layer architectures allow us to organize a Web application in an arbitrary number of layers

(see Figure 4-4). They typically consist of three layers, the data layer, providing access to the application data, the business layer, hosting the business logic of the application in an application server, and finally the presentation layer, which renders the result of the request in the desired output format. Additionally, security mechanisms like firewalls, or caching mechanisms like proxies, can be integrated into the request-response flow upon demand.

2-layer and n-layer architectures differ mainly in how they embed services within the

application server component. Services like customization or workflow are held in the application server’s context, so that they are available to all Web applications. Wu and Zhao (2003) describe services and their interconnections with respect to workflow, security and business logic. Similarly, (Horvat et al. 2003) describe horizontal and vertical services, a terminology introduced with CORBA, in a portal architecture. Xiang and Madey (2004) describe a multi-layer service architecture using semantic Web services to support the development of Web applications.

Client Firewall Proxy Web-Server Application-Server Collaboration Data access Business Logic Workflow Personalization Connectors etc. Database-Server B2B Backend Legacy- Application Enterprise Information System Presentation layer Business layer Data layer

Figure 4-4 Ann-layer architecture for Web applications (according to Anastopoulos and Romberg 2001,

p. 42).

Services are embedded in the application server with a defined interface, and the same interface can be used to manage these services. The WebSphere application server with its WebSphere Business Components is a good example of these functionalities. As a further advantage, Web applications profit from the distribution and load balancing mechanisms of the application server. What’s more, so-called connectors can be used to integrate external systems, e.g., business partner systems, or to integrate legacy applications and enterprise information systems.

Many commercial application servers have been optimized for the processing of database contents, while the support of multimedia contents and hypertext structures has been neglected. One example of a possible integration of video data into an application server is available at (http://www.ibm.com/software/data/informix/blades/video/). The WebRatio modeling tool (see section 3.9.2) can map hypertext aspects onto J2EE and .NET (Ceri et al. 2003). This means that expansions have been implemented on top of existing implementations, such as J2EE. We will have a closer look at some of these expansions and concepts in the following subsections.

JSP-Model-2

Sun Microsystems’ JSP-Model-2 (Java Server Pages) architecture (http://java.sun.com/deve- loper/technicalArticles/javaserverpages/servlets jsp/) implements the MVC pattern

4.5 Layered Architectures 75 Web-Server Client Servlet-Container Servlet (Controller) JSP (View) JavaBean (Model) 4 2 3 Browser 1 5

Database-Server _{Information System}Enterprise

Figure 4-5 The JSP-Model-2 architecture.

for Web applications, thus laying the foundation for the integration of navigation aspects, internationalization, and multi-platform delivery in Web applications (see Figure 4-5).

The JSP-Model-2 architecture is deployed on a Web server, i.e., view, controller, and parts of the model functionalities of this pattern are available over a Web server extension – a servlet

container. The controller, i.e., the flow and control logic of the Web application, is implemented

in the form of servlets (see also section 6.6.1), which are software components running in a servlet container. The controller is responsible for providing access to the application logic (model) and selecting the graphical presentation (view). JavaBeans, i.e., software components representing the application’s data, are used to implement the model. The model itself normally accesses backend systems, such as a database or legacy application. The graphical presentation is realized by Java Server Pages (JSP) (see also section 6.6.1).

Struts

The JSP-Model-2 architecture is enhanced by the Struts open-source project of the Apache Software Foundation (http://struts.apache.org/). Struts offers useful additions for Web applications, such as error handling and internationalization. In addition, Struts uses an XML configuration file which allows the control of the processing flow within the MVC pattern to facilitate the processing of client requests.

Figure 4-6 shows how the Struts framework processes a user request: Initially, each user request (1) is received by the central ActionServlet. This servlet reads the request’s URI to find the controller (Action) the request is to be forwarded to (2), i.e., the application logic that should be executed for this request. The controller is responsible for selecting or creating a model in the form of a JavaBean, which can be represented in a view (3). Based on the selected model, and perhaps other information (user information, user agent, etc.), the ActionServlet can now select a view to represent the contents (4). Finally, the selected view generates the output, which is sent to the user (5). In contrast to the original JSP-Model-2, Struts allows to configure the view and

Web-Server Client Browser Servlet-Container ActionServlet (Controller)

JSP (View) JavaBean_(Model) 2 3 struts- config.xml Action (Sub- Control) 4 5 1 5

Figure 4-6 JSP-Model-2 implementation in Struts.

model allocation in the (struts-config.xml) file. This means that the content can be presented more flexibly, either for reasons of adaptation, or for multi-platform deliveries.

Similar to the JSP-Model-2, Struts lets you implement various output formats computed by configured JSP pages. In its standard installation, the framework offers no way to use other visualization technologies, e.g., XSLT (see section 6.5.5). However, there are various products that enhance Struts, trying to close this gap. For example, StrutsCX supports XSLT to generate different output formats (http://it.cappuccinonet.com/strutscx/index.php).

OOHDM-Java2

The OOHDM-Java2 approach specified in (Jacyntho et al. 2002) describes how the OOHDM navigation model is mapped onto the J2EE platform (see section 3.9.1). Its implementation is based on the MVC pattern. Figure 4-7 shows how OOHDM-Java2 components are mapped to the MVC pattern. In contrast to JSP-Model-2 and Struts, this approach introduces an explicit navigation component. The WebRatio tool (see section 3.9.2) supports the modeling and coding of the different components.

Model Controller HTTP Request Parser 1 Dispatcher 2 Selection of User Interface JSP (layout) Navigation Node 5 Client Extended View Business object Business object Business object 3 4

4.5 Layered Architectures 77 In this figure, the execution sequence is indicated by the numbered edges: (1) An HTTP request is issued to the HTTP Request Parser, which forwards a message to the Dispatcher (2). Similar to Struts, this parser runs the allocated application objects (3). Subsequently, the selected application object or other information (e.g., user agent) is used to identify the user interface (4). Next, the user interface is enriched by navigation aspects (5). And finally, the result is put in an appropriate layout and transmitted to the client.

Proxies

Proxies were originally used to save bandwidth, which is the reason why early proxies were referred to as caching proxies (Bongio et al. 2003), p. 353. But proxies are capable of assuming a number of other functionalities as well:

• Link proxy: Link proxies exist in at least two types. First, systems like Persistent URLs

(PURLs, see Weibel et al. 1999) use proxy-like components. More specifically, a proxy is used as an intermediate server to forward client requests for URLs to the (actual) server. If the name or location of the requested resource changes, then its address (URL) only has to be changed internally, and the client doesn’t have to know this. Such a change requires a mapping table between the requested URL and the “real” URL. This mapping table is maintained by the proxy. Second, proxies are used to adapt and format links and contents to users (e.g., Webcosm Hill et al. 1996). One of the ideas behind this concept is to dynamically insert links matching a user’s interests. This means that the HTML pages are analyzed in the proxy and modified to match the user profile. The user will be informed about the fact that the transmitted resource was changed at the bottom of the document. • History proxy: Many Web applications try to adapt their functionalities to users. However,

this attempt is normally accompanied by the problem that HTTP is a stateless protocol, i.e., no information whatsoever about the history of a user navigation is available across several Web sites. For example, if a user plans a vacation trip and books a flight, a hotel, and a rental car on the Internet, then the airline ticket vendor does not typically know that the user also booked a hotel and a rental car. If the airline company knew this information, then both the hotel and the rental car could be canceled if the user cancels the flight. A similar problem arises in the field of direct marketing (see section 8.3). The more details about a user’s interests are known, the more consumer-oriented an advertising effort can be. Proxies can be used to manage a user’s history. More specifically, the proxy assigns a unique ID for a user and stores this ID using cookie technology. Now, if the user visits the Web site of another company also connected to the same proxy, then this user information can be retrieved, enabling a unique user identification. This approach records and evaluates a user’s behavior within such an information aggregate, i.e., all Web sites sharing the same proxy. The Boomerang server of DoubleClick (http://www.doubleclick.com) uses this concept for direct marketing. Of course, the use of such technologies is a critical point with regard to the privacy of users.

Integration Architectures

External or internal systems, e.g., existing applications, existing databases and interfaces to external business partners, can be integrated into Web applications on three levels: the

presentation level, the application logic level, and the content level. Integration architectures address integration aspects on the content level and the application logic level and are commonly summarized under the term Enterprise Application Integration (EAI) architectures. This category also includes architectures which integrate existing applications as a whole, i.e. content as well as application logic is integrated. Strictly speaking, EAI focuses on the integration of legacy systems. Alternatives to EAI are Web services (see also sections 5.5.3 and 6.6.2), which support the integration of services, i.e., application logics and contents. On the presentation level, a set of different systems is typically integrated by using portal architectures.

EAI has emerged from the field of business-to-business integration, requiring existing systems to be closely coupled, from purchasing over production planning to billing. This integration can be implemented in any of the following ways:

• Point to point: The applications exchange the content to be integrated via external

communication mechanisms, e.g., file transfer or batch transactions.

• Data delivery: A system supports access to internal data directly, e.g., over a database

access.

• Data integration: Several applications use the same data storage, e.g., via a jointly used

database.

• Delivery of functionalities: A legacy system allows to access functionalities, e.g., over an

API.

• Reconstruction of functionalities: Access to functionalities is transparent to the client, i.e.,

a functionality can, but does not have to, be implemented directly in the legacy system. • Porting: Legacy systems are migrated onto Web platforms, replacing the original system.

Figure 4-8 shows an architecture used to integrate legacy systems which uses wrappers to integrate legacy systems. This integration approach uses specific middleware, which usually consists of application servers combined with XML technologies. One example of this approach is the J2EE-Connector architecture, which specifies the integration of legacy systems into a J2EE environment (Sun Microsystems 2003b)!

Adapter Wrapper System 1 Bus (Middleware) Workflow Business Logic Adapter Wrapper System n

Figure 4-8 Example of an EAI architecture.

The major drawback of most current integration approaches is that the application logic and data in legacy systems can be accessed only in their entirety. This has a negative impact on the adaptability and reusability of both the data and the application logic. Another problem is due to the different development paradigms used by legacy systems and Web applications. For

4.6 Data-aspect Architectures 79