A Comparison of Web Visualization Frameworks for eBusiness ...€¦ · development frameworks, one can overcome many challenges of web application development. This research is dedicated

Technische Universität Hamburg-Harburg. Arbeitsbereich Softwaresysteme

Technische Universität München. Arbeitsbereich Software Engineering betrieblicher Informationssysteme

O2 Germany GmbH &Co. OHG

Master Thesis

A Comparison of Web Visualization Frameworks for eBusiness Applications Using the Example of an Online Shop

Supervisors: Prof. Dr. Joahim W. Schmidt

Prof. Dr. Florian Matthes

Research Assistants: Rainer Müller

Thomas Büchner

O2 Germany GmbH & Co. OHG Supervisor:

Dipl.-Eng. Drasko Kokic

submitted by: Maria Ginsburg Mat.-Nr.:20519

Hamburg, 02.12.2003

2

ABSTRACT Developing a maintainable and extensible web application requires a significant amount of design and planning before beginning the implementation itself. Nevertheless, by leveraging development frameworks, one can overcome many challenges of web application development. This research is dedicated to the investigation of the reasons of framework appearance, the current situation in this area and the further trends of their development. Moreover, the current situation sees a lot of unstructured and mostly marketing information about the available solutions, therefore it is the aim of the paper to analyse and classify the vast amount of framework in order to see which opportunities currently are available for a developer. The important issue of the research is to answer the question how one can choose an appropriate framework for a particular application. During the investigation, six frameworks of different types were analysed and tested with the same use case. The test use case, the O2 Germany Online Shop prototype, was chosen as one allowing identifying the critical issues in development an application with a framework. The prototyping implementation helps to accentuate the number of criteria which are important to support a framework choosing process. These criteria are used to compare the six frameworks and create a scheme for the framework selection for a certain project.

3

TABLE OF CONTENT 1. Motivation and Setting the Problem....................................................................................... 5

1.1. E-Business Growing Importance: New challenges for IT .............................................. 5 1.2. Web Application Frameworks: Meeting the Challenges ................................................ 7 1.3. Problem of Choosing a Framework ................................................................................ 8

2. Web Application Frameworks – an Overview..................................................................... 10 2.1. Dynamic Technology for the Web ................................................................................ 10 2.2. Design Patterns and Frameworks.................................................................................. 12 2.3. Web Application Frameworks ...................................................................................... 18

2.3.1. MVC Oriented Approach ....................................................................................... 18 2.3.2. XML Publishing Approach..................................................................................... 25 2.3.3. Template Engine Approach .................................................................................... 29 2.3.4. Event Model Approach........................................................................................... 30 2.3.5. Component Approach............................................................................................. 33

2.4. Advantages and Drawbacks of Open Source ................................................................ 36 3. Prototype of Online Shop Application ................................................................................. 38

3.1. Online Shop Use-Cases................................................................................................. 38 3.1.1. Display of the products .......................................................................................... 38 3.1.2. Homezone Check ................................................................................................... 38 3.1.3. Shopping Cart ........................................................................................................ 39 3.1.4. Ordering Process ................................................................................................... 40

3.3. Online Shop Object Model............................................................................................ 41 3.4. Justification of the Choice of the Online Shop as a Sample Application ..................... 42

4. Implementation of Online Shop Use-Cases with the Chosen Frameworks ......................... 43 4.1. Online Shop Prototype Implementation Using Apache Cocoon................................... 43

4.1.1. Prototype Architecture ........................................................................................... 43 4.1.2. Shop module ........................................................................................................... 45 4.1.3. Ordering Process Module ...................................................................................... 49 4.1.4. Homezone Check Module....................................................................................... 54 4.1.5. Error Handling....................................................................................................... 54

4.2. Online Shop prototype implementation using Apache Struts ....................................... 55 4.2.1. Navigation Scheme ................................................................................................. 55 4.2.2. Controller ............................................................................................................... 56 4.2.3. Struts Configuration File ....................................................................................... 56 4.2.4. Forms Handling ..................................................................................................... 59 4.2.5. Form Data Validation ............................................................................................ 61 4.2.5. View ........................................................................................................................ 64

4.3. Prototyping Implementation of Online Shop with Velocity ......................................... 65 4.3.1. Access Beans and Their Properties........................................................................ 65 4.3.2. Manipulation of the Presentation Logic................................................................. 66 4.3.3. Creating Input Forms............................................................................................. 67 4.3.4. Resource Bundle..................................................................................................... 67 4.3.5. Import of the Local Files ........................................................................................ 67

4.4. Prototyping Implementation of Online Shop with JPublish.......................................... 68 4.4.1. Template ................................................................................................................. 68 4.4.2. Content ................................................................................................................... 68 4.4.3. Page........................................................................................................................ 68 4.4.4. Actions .................................................................................................................... 69 4.4.5. Configuration file ................................................................................................... 70 4.4.6. Form Handling ....................................................................................................... 70

4

4.4.8. Application Architecture ........................................................................................ 72 4.5. Experience of the Application Development with JavaServer Faces ........................... 74

5. Framework Comparison....................................................................................................... 75 5.1. Apache Cocoon ............................................................................................................. 77

5.1.1. User Interface Issues .............................................................................................. 77 5.1.2. Flow Control Issues ............................................................................................... 78 5.1.3. Server-Side Issues .................................................................................................. 79 5.1.4. Other Issues............................................................................................................ 80 5.1.5. Conclusion.............................................................................................................. 82

5.2. Apache Struts ................................................................................................................ 83 5.2.1. Use Interface Issues ............................................................................................... 83 5.2.2. Flow Control Issues ............................................................................................... 84 5.2.3. Server-Side Issues .................................................................................................. 85 5.2.3. Other Issues............................................................................................................ 85 5.2.4. Conclusion.............................................................................................................. 87

5.3. InfoAsset Broker ........................................................................................................... 88 5.3.1. User Interface Issues .............................................................................................. 88 5.3.2. Flow Control Issues ............................................................................................... 89 5.3.3. Server-Side Issues .................................................................................................. 89 5.3.4. Other Issues............................................................................................................ 90 5.3.5. Conclusion.............................................................................................................. 92

5.4. Velocity ......................................................................................................................... 92 5.4.1. User Interface Issues .............................................................................................. 92 5.4.2. Server-Side Issues .................................................................................................. 93 5.4.3. Other Issues............................................................................................................ 93 5.4.4. Conclusion.............................................................................................................. 95

5.5. JPublish ......................................................................................................................... 95 5.5.1. User Interface Issues .............................................................................................. 95 5.5.2. Control Flow Issues ............................................................................................... 96 5.5.3. Server-Side Issues .................................................................................................. 97 5.5.4. Other Issues............................................................................................................ 98 5.5.5. Conclusion............................................................................................................ 100

5.6. JavaServer Faces ......................................................................................................... 100 5.6.1. User Interface Issues ............................................................................................ 100 5.6.2. Flow Control Issues ............................................................................................. 102 5.6.3. Server-Side Issues ................................................................................................ 103 5.6.5. Conclusion............................................................................................................ 104

5.7. Conclusion................................................................................................................... 105 6. Conclusion.......................................................................................................................... 110

6.1. Work Overview........................................................................................................... 110 6.2. Further work................................................................................................................ 111

REFERENCES....................................................................................................................... 112

5

1. Motivation and Setting the Problem

1.1. E-Business Growing Importance: New challenges for IT E-Business is taking the major place in the world’s economy. Forrester Research estimated the value of e-commerce in USA and Europe in 2003 by US$3 trillion [Violino, 2003]. More entrants are attracted by e-marketplace as it becomes more lucrative. The introduction of the new information technologies changes the commercial activities for gathering information, shopping, trading, banking, accounting, auditing, financing, negotiating, collaborating, marketing, supplying, manufacturing, distributing, servicing and retailing. All companies will face the challenges brought about by the technology development. The main driver to employ e-Business is the opportunity to take advantage of the Internet to improve process efficiency, reduce product cost and improve information delivery. Using Internet in business has highly recognized benefits [West, 1997]:

− Reach the global market at low cost − Deliver product marketing, sales, services and distribution via one medium − Deliver accurate and actual business information − Build closer partnership with suppliers and customers − Provide interactive medium for business partners

In sprite of the number of e-Business benefits, many companies hesitate in its implementation due to the associated concerns. The main barriers are [KPGM, 1999]:

− Security fears − Low skill level in organization − Difficulties of implementation and maintenance − Concern over the number of customers who are using Internet − Cost implication of electronic trading

With the development of web technologies, these barriers are shrinking. Since 1991, the usage of Internet has profoundly changed. According to a cross-industry survey done by InformationWeek and BusinessWeek [Business Week, 1999], e-Business is practically ubiquitous. A full 81% of respondents said their companies have web sites; 76% are engaged in e-Commerce – buying and selling electronically. With such large-scale growth taking place in e-Business, the successful companies will be those who consistently do the best job satisfying Internet customers and suppliers. [IBM, 2002] Companies involved in e-Business employ two main characteristics of Internet: interactivity and connectivity. Companies may serve their customers in 24 hours x 7 days. They can have real-time dialog with their users. O2 Germany successfully utilizes these benefits of Internet by employing seller-centric (see Fig. 1.1-1) type of e-market. For the company the web market place is one of the main channels for business transactions. It handles the main selling processes online, from order processing to account payable, allowing real-time transactions between customers and salespersons. They offer web-based online supports, including managing customer’s own contract, online ordering and order correction. By doing so, they maintain their leadership in the value chain, achieve operational efficiency, reduce transaction costs and improve customer satisfaction.

6

Fig. 1.1-1. Seller-centric type of e-market [Anderson, 2000] Since more transactions are conducted in Internet, O2 Germany faced the challenge to keep the customers. As the company invested a lot into the attraction of customers to the website and do the first transaction, the next step is to enhance the customer’s loyalty through their satisfactory purchasing experience. Grievous experience showed the emergence of dotcoms or companies claiming their entry into e-business, describing bright scenarios of future paybacks to the investors. However, ignorance of the customers’ demand and lack of necessary preparation for the customer service coupled with limited numbers of customers eliminated them from the market. Archer and Gabauer [Archer, 2002] emphasize that building and maintaining customer relationships are the key to success in e-commerce, which depends on maintaining effective customer service. Customer Relationship Management (CRM) shifts the marketing perspective from “making sales of products” to “gaining and retaining clients” [Chen, 2001]. The key elements of this approach are:

− Dominating a specific market segment by developing highly appropriate products and services

− Building a deep relationship with customers in order to develop appropriate products and services

− Responding flexibly to market needs by continual monitoring, analysis and feedback − Developing relationships with suppliers and vendors in order to maintain an edge in

the market [KPGM, 1999] Success of the company’s e-Business depends on the critical synergy between business and information technology and the complex approach to the challenges that are places by e-Business integration:

- Time to market. The architects, analyst and developers today are being pressed extremely hard to produce critical e-Business solutions before some competitors do. At the same time they must realize that short-term thinking today could result in solutions that lock organization’s hand in future.

- Quality. E-Business raises the bar for high-quality software. Software is designed now for vast number of anonymous users. And the consequences of poor design are not just painful, but could be fatal for the company’s image.

Buyer

Buyer

Buyer

Seller-centric web-site Seller

7

- Cost saving. E-Business can not afford excessive costs for underlying non-value-added processes. There is need to reuse not just a code, but also the business knowledge that is reflected in the code.

- Adaptability. Software must be readily maintainable in timely response to business changes.

- Scalability. Success in the global marketplace presents its own challenges of vast numbers of users and transaction volumes.

- Consistency. Information is accessible from many viewpoints. Increased visibility magnifies the need to keep information consistent and present it in a consistent manner.

- Integration. Back-end systems must be made to integrate with the new web applications. Pressure increases to realize previous IT investments.[Allen, 2000]

1.2. Web Application Frameworks: Meeting the Challenges Application frameworks are a holistic set of guidelines and specifications that provide platforms, tools, and programming environments for addressing the design, integration, performance, security, and reliability of distributed and multi-tiered applications. [Samtani, 2002] An application framework may include the presentation services, server-side processing, session management, business logic framework, application data caching, application logic, persistence, transactions, security, and logging services for applications. In the past, programmers would have to spend many hours programming low-level features for new applications. Web application framework takes care of the common application functionality such as dispatching requests, invoking model methods, and selecting and assembling views. With the simpler functions taken care of by a pre-planned architecture, programmers can make small changes to customize the interface and concentrate on data manipulation. Framework classes and interfaces are structural, providing elements of a building, forming the application's underpinnings. Application developers extend, use, or implement framework classes and interfaces to perform application-specific functions. For example, a framework may offer an abstract class that a developer may extend to execute business logic in response to application events. A Web application framework makes Web-tier technologies easier to use, helping application developers to concentrate on business logic. The J2EE BluePrints [Java BluePrints, 2003] recommended best practice is to choose an existing, proven Web application framework for web application rather than designing and building a custom framework layer. A Web application framework can provide the following benefits to the application:

− Decouples presentation and logic into separate components. Frameworks encourage separating presentation and logic because the separation is designed into the extension interfaces.

− Separates developer roles. Application frameworks generally provide different interfaces for different developers. This separation allows both types of developers to work more independently and facilitates further maintenance.

− Provides a central point of control. Most frameworks provide a rich, customizable set of application-wide features, such as templating, localization, access control, and logging.

− Can be purchased instead of built. Time not spent developing structural code is available for developing business logic.

8

− Provides a rich set of features. Adopting a framework can leverage the expertise of a group of Web-tier MVC design experts. The framework may include useful features that you do not have the experience to formulate or the time to develop.

− Encourages the development and use of components. Over time, developers and organizations can accumulate and share a toolbox of preferred components.

− Provides stability. Frameworks are usually created and actively maintained by large organizations or groups, and are used and tested in a large installed base. Accordingly, framework code tends to be more stable than custom code.

− Has community support. Popular frameworks attract communities of enthusiastic users who report bugs, provide consulting and training services, publish tutorials, and produce useful add-ons. Open frameworks are particularly strong in this regard.

− May reduce training costs and time. Developers already trained and experienced in using a framework get up to speed more quickly and are more productive.

− May simplify internationalization. Most frameworks support a flexible internationalization strategy.

− May support input validation. Many frameworks have consistent ways to specify input validation. Validation is commonly available on the client side, on the server side, or both.

− May be compatible with tools. Good tools can improve productivity and reliability. Some frameworks are integrated with rapid application development tool sets.

All these issues can help the designers and developers to meet the requirement placed by e-Business application development. Indeed, these benefits come at a cost. One should think about the frameworks drawbacks:

- Less control. The application developer decreases his own control over the application when he use the someone’s design instead of his own

- Cost. Some frameworks must be purchased. - Not error prone. Other people’s code in the application means other people’s bug in it.

Still, many developers think that using framework increases implementation quality and improves the design.

1.3. Problem of Choosing a Framework A high recognition of necessity of web application frameworks resulted in large amount of framework developed on three – five years. These are released as proprietor and open source variants. Marketing people promote the advantages of using their solutions, the active communities around conduct a lot of discussions which framework is better. That creates an informational chaos around a developer and provides no clear information about the benefits or drawbacks of a certain product. Also, there are no clear guidelines how to choose a framework that will really help the development of a particular application. First of all, it is important to weight the benefits of using a framework at all. Wrongly chosen framework can make the development process quite painful. Another problem is to realize, that in process of choosing a solution for an application the most important question to ask is: How well does this framework fit for building my application? That means that there is no framework that is appropriate for every type of projects. Thus, the key challenges associated with building or selecting an application framework are whether the framework is compatible with the chosen architecture and whether the right set of services are provided at the appropriate level of abstraction. For framework authors, choosing the right level of abstraction is a difficult decision. On one hand, there is a desire to simplify

9

and reduce the development efforts of the application programmer. Counteracting the simplification is the fear of unduly constraining or limiting the application programmer. And that is a fundamental but often overlooked challenge: architecting the framework so that it is powerful and flexible while providing tangible saving of time and money. Still, application developer’s community lacks the methodology of choosing a particular framework for a particular application type. Which kind of question should be asked and which kind of criteria should be applied in the process of framework evaluation and choosing is not yet known. On another hand, should this procedure be done every time a developer needs a framework? This procedure would be highly simplified, if there would be the shared experience of the people who worked with different technologies and can compare them. The current research is aimed to the creation of a methodology of web application framework comparison and to the evaluation a set of the currently available frameworks. The paper covers the area of Open Source web application technologies, as rapidly growing and constantly attracting more attention one. It addresses the following questions:

- how the web technology came to the framework development and what is the benefit of this evolution

- which frameworks are available for web application development - how the vast amount of frameworks can be ordered and categorized in order to see the

trends of the technology - what are the important criteria of framework comparison - how to find out which framework fits a particular application

By answering these questions, the most favourable by now frameworks are compared and the trends of their development as main trends of the development of framework technology are investigated. Four of the chosen framework will be tested on the development of the same prototype application, so that the merits of each framework will be on focus. By examining a technology on a live use-case, it is possible to analyse its benefits and drawbacks and to understand what the critical issues of the framework-based application development are.

10

2. Web Application Frameworks – an Overview Previously, at the beginning of the web technologies era, web sites contained a static content base and a couple of cgi-scripts. Nowadays, web-applications are expected to provide more interactivity and functionality. The number of web application technologies and approaches is constantly growing and the direction of this development is hardly predictable. The problem arises from this is that of how to choose a promising working platform for web-development that will meet all contemporary requirements in a given web application. To tackle this question, it is necessary that one is well conversant with the actual state of development in this area. This section presents the evolution of the web applications development approaches. It gives the structured view on the currently existing frameworks. Since most of the discussed platforms are OpenSource, this section also discusses advantages and drawbacks of using OpenSource technologies.

2.1. Dynamic Technology for the Web HTML used to be the main language for the producing of web pages. The problem arises with increased necessity to deliver dynamic content to users. HTML is static in nature and has limited support for dynamic content. DHTML (Dynamic HTML) and JavaScript have helped to enhance the functionality of a standard web page, but this is not enough to deliver the kind of dynamic data that is required. This is one of the reasons for the move to the server side processing approach to deliver dynamic content. Java is the main language behind this transition along with Perl and PHP as server side languages. The great advantage of Java is that it works both on the server side and on the client side and is platform independent. It is suitable for the development of scalable, reliable business applications; it has syntaxes, understandable for the programmers who used to program in C/C++, means for localization, for DB access and for work with XML documents and very good corporate support. Java introduces a number of key technologies for web applications, as well as for desktop applications, through the Java 2 Enterprise Edition (J2EE) platform (see Fig. 2.1-1). J2EE platform eases the development of applications on the server side, allowing scalability, modularity and portability. This is helpful to build interfaces with different legacy systems and relational databases. Two of these technologies are Enterprise Java Beans (EJB) and Java Servlets. EJB component model simplifies the development of middleware applications by providing automatic support for services such as transactions, security, database connectivity, and more [Java BluePrints, 2003]. A servlet is a Java object capable of responding to network requests. In general, servlets can be accessed via all request-response based protocols. In J2EE settings most servlets are invoked through the HTTP protocol. The work of the servlet typically consists of:

− Extract input data from the request - typically data posted from a HTML form − Given the input, it executes business logic, typically by delegating the work to

dedicated EJBs − Based on the result from the EJBs, the servlet generates HTML based output

presenting the result to the end user

11

Fig. 2.1-1 J2EE platform architecture [J2EE Tutorial, 2003]

Servlets can be used to build presentation-oriented services for clients. They can be useful to return embedded HTML to the client when requested. This approach can lead to the growing complexity of the servlets, and hence to the growing complexity of editing the page appearance for designers, who normally are not responsible for business logic. Copying the data from static file will not be an appropriate solution, since the delivery of dynamic data, which depends on the request from the client. What can help to avoid this problem is the combination of the Servlet technology with Java Server Pages (JSP). As the developers of JSP writes on their web page: “Together, JSP technology and servlets provide an attractive alternative to other types of dynamic Web scripting/programming that offers platform independence, enhanced performance, separation of logic from display, ease of administration, extensibility into the enterprise and most importantly, ease of use. ”Java Server Pages (JSP) is a technology that lets mixing regular, static HTML with dynamically-generated HTML. Most of CGI-programs variations, including servlets, make generate the entire page via the code, even though most of it is always the same. JSP allows creating the two parts separately”. Here's an example: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD><TITLE>Welcome to Online Shop</TITLE></HEAD> <BODY> <H1>Welcome to Online Shop</H1> <SMALL>Welcome,  <% out.println(Utils.getUserNameFromCookie(request)); %> To access your account settings, click <A HREF="Account-Settings.html">here.</A></SMALL> <P> Regular HTML for all the rest of the online shop's Web page. </BODY></HTML> The shortfall of this approach is that embedding scriptlets in JSP’s means mixing business logic and presentation logic. An alternative to the use of scriptlets is the use of tag libraries that link to server side code that provides data access and other services, and make these

12

features available to the JSP author in a simple to use HTML/XML-like syntax. The specifications of JSPs and Servlet API included almost from the beginning the possibility for a programmer to create their own tags, custom descriptors. Custom tags have many features that make them attractive to use from any JSP. Custom tags can

− be customized via attributes passed from the calling page, either statically or at runtime;

− have access to all the objects available to JSP pages including request, response, in and out;

− modify the response generated by the calling page; − communicate with each other; you can create and initialize a JavaBeans component,

create a variable that refers to that bean in one tag, and then use the bean in another tag;

− be nested within one another, allowing for complex interactions within a JSP page; and

− encapsulate both simple and complex behaviours in an easy to use syntax and greatly simplify the readability of JSP pages.

The idea with tag became very popular, so that tag libraries were built. One of the most interesting implementation of these is Jakarta Taglibs. JSP has its standard library – JSTL, which contains tags for condition loops, formatting, work with XML, databases etc. Java Beans provide a simple java object with get and set methods for particular parameters. This gives a solution for storing business data that can then be used by the JSP’s to generate a dynamic response to the client. These are the basic technologies for building web applications. They are themselves enough to build an application, but a better way to do it is to look at various design strategies and work out the best approaches. The next section looks at design patterns and specially frameworks.

2.2. Design Patterns and Frameworks The appropriate technologies assembled in a wrongly in the design of an application can lead to a system that is too difficult to update and maintain it. Mature engineering disciplines have handbooks that describe successful solutions to known problems. For instance, automobile designers do not design cars using the laws of physics. Instead, they reuse standard designs with successful track records. Similarly, design patterns in software development process and the design of software are the abstract solutions to design problems that have been tried or tested. In "Understanding and Using Patterns in Software Development" [Riele, 1996], Dirk Riehle and Heinz Zullighoven give a definition of the term "pattern" which is very broadly applicable: “A pattern is the abstraction from a concrete form which keeps recurring in specific non-arbitrary contexts”. But a pattern is more than just a solution to a recurring problem. The problem occurs within a certain context, and in the presence of numerous competing concerns. The proposed solution involves some kind of structure that balances these concerns, or "forces", in the manner most appropriate for the given context. Using the pattern form, the description of the solution tries to capture the essential insight which it embodies, so that others may learn from it, and make use of it in similar situations [Appleton, 2000]. Richard Gabriel, author of “Patterns of Software: Tales From the Software Community“ [Gabriel, 1996] explains pattern definition as following:

13

− Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.

− As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves.

− As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.

− The pattern is, in short, at the same time a thing, which happens in the world, and the rule which tells us how to create that thing, and when we must create it. It is both a process and a thing; both a description of a thing which is alive, and a description of the process which will generate that thing.

A pattern involves a general description of a recurring solution to a recurring problem replete with various goals and constraints. But a pattern does more than just identify a solution; it also explains why the solution is needed. J2EE patterns are an extension of the patterns concept in relation to the J2EE platform.

Design patterns provide an ideal way to enhance the quality of an implementation but on their own they are difficult to use, because of their high level of abstraction. The use of a collection of patterns in a particular way is required. A collection of patterns forms a vocabulary for understanding and communicating ideas. This is what Alexander calls a pattern language [Alexander, 1977]. If a pattern is a recurring solution to a problem in a context given by some forces, then a pattern language is a collection of such solutions that, at every level of scale, work together to resolve a complex problem into an orderly solution according to a pre-defined goal. In the Patterns Definitions section of the Patterns Home Page [Pattern Definition, 2003], Cope defines a pattern language as follows: “A pattern language defines a collection of patterns and the rules to combine them into an architectural style. Pattern languages describe software frameworks or families of related systems.” Coplien gives a slightly different definition in “Software Design Patterns: Common Questions and Answers” [Coplien, 1998]: “A pattern language is a structured collection of patterns that build on each other to transform needs and constraints into an architecture.” Coplien then says that: “Good pattern languages guide the designer toward useful architectures and away from architectures whose literary analogies are gibberish or unartful writing. Good architectures are durable, functional, and aesthetically pleasing, and a good combination of patterns can balance the forces on a system to strive towards these three goals. A good pattern language gives designers freedom to express themselves and to tailor the solution to the particular needs of the context where the patterns are applied.” Pattern language allows visualizing exactly how the patterns fit together to form a particular framework and hence ensures the higher quality of the produces framework. Software frameworks are closely related with design patterns. A framework is a set of cooperating classes that make up a reusable design for a specific class of software. A framework provides architectural guidance by partitioning the design into abstract classes and defining their responsibilities and collaborations. A developer customizes a framework to a particular application by subclassing and composing instances of framework classes. [Appleton, 2000] A framework differs from a programming library in providing an inverted flow of control between itself and its clients. When using a framework, one usually just implements a few

14

callback functions or a few classes, and then invokes a single method or procedure. At this point, the framework does the rest of the work, invoking any necessary client callbacks or methods at the appropriate time and place.

Frameworks employ design patterns both in the design and the documentation. Normally a framework implements a set of design patterns that are targeted towards a particular purpose or domain. Despite the fact that these two concepts are tightly coupled, it is important to recognize the difference: a framework is executable software, whereas design patterns represent knowledge and experience about software design. Frameworks are the physical realization of one or more software pattern solutions; patterns are the instructions for how to implement those solutions.

The major differences between design patterns and frameworks are as following [Gamma, 1994]:

1. Design patterns are more abstract than frameworks. Frameworks can be embodied in code, but only examples of patterns can be embodied in code. Strength of frameworks is that they can be written down in programming languages and not only studied but executed and reused directly. In contrast, design patterns have to be implemented each time they are used. Design patterns also explain the intent, trade-offs, and consequences of a design.

2. Design patterns are smaller architectural elements than frameworks. A typical framework contains several design patterns but the reverse is never true.

3. Design patterns are less specialized than frameworks. Frameworks always have a particular application domain. In contrast, design patterns can be used in nearly any kind of application. While more specialized design patterns are certainly possible, even these would not dictate application architecture.

A framework should provide the following features: − They have to provide hooks so that developers can extend certain parts of the

framework to give extra functionality. − They have to be simple to use and easy to go with. Often with complex frameworks

this is not always possible but the developers in the project should strive to make sure that there is a trade-off between the two.

− They have to be flexible to the needs of the developer and must provide for a number of different solutions in order to make them useful.

− They have to be modular so that certain modules in the framework can be added or removed as required. Each of the modules also has to be loosely coupled with each other but highly cohesive.

− They must increase the productivity of the developers on the project and enhance the quality of a specific implementation.

J2EE Frameworks are, like J2EE Patterns, extensions of the framework concept in relation to the J2EE platform. An example of this is the Model View Controller (MVC) pattern and frameworks that is common amongst Java applications on the desktop but less common amongst enterprise applications. Before discussing MVC Pattern, the problem of separation of concerns should be mentioned.

15

With the rate at which businesses change along their models and strategies, it is necessary to keep a web site up-to-date. Web developers agree on the idea that in order to create maintainable application, it is important to reach the precise task division between the development process participants. Some authors try to explain it with the fact that web designers do not like code in layouts or can spoil it when inserting in their code. Actually, the problem is not in the web designers. When presentation and code are separate, the project becomes easy to be handled. The presentation part is assigned to web designer role and the business logic – to the web developer role:

− The Web Designer – the person who is responsible for the aesthetic look and feel of the page and the graphic design elements of the web site.

− The Web Developer – the person who is involved with the semantics and the data behind the website. They may possibly be involved in developing a middleware to interface with a backend database which is used to store the data that the website is used to present.

Mixing these roles can result in difficulties to maintain the application, since interdependencies between the components cause strong wave effects whenever a change is made anywhere. High coupling makes classes difficult or impossible to reuse because they depend on so many other classes. Adding new data views often requires re-implementing or cutting and pasting business logic code, which then requires maintenance in multiple places. Data access code suffers from the same problem, being cut and pasted among business logic methods. [Java BluePrints, 2003] Model View Controller pattern separates the data model from the actual view of the application (see Fig. 2.2-1.). Originally it was implemented in SmallTalk-80, than it became a standard for java application development.

Fig. 2.2-1. MVC pattern. Component Interaction [Java BluePrints, 2003]

MVC defines three specific parts that application should be split up into [Java BluePrints, 2003]:

16

− Model - The model represents enterprise data and the business rules that govern access to and updates of this data. Often the model serves as a software approximation to a real-world process, so simple real-world modelling techniques apply when defining the model.

− View -The view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented. It is the view's responsibility to maintain consistency in its presentation when the model changes. This can be achieved by using a push model, where the view registers itself with the model for change notifications, or a pull model, where the view is responsible for calling the model when it needs to retrieve the most current data.

− Controller - The controller translates interactions with the view into actions to be performed by the model. In a stand-alone GUI client, user interactions could be button clicks or menu selections, whereas in a Web application, they appear as GET and POST HTTP requests. The actions performed by the model include activating business processes or changing the state of the model. Based on the user interactions and the outcome of the model actions, the controller responds by selecting an appropriate view.

In order to use this pattern in web application development, the actual technologies should be addressed. The framework that used MVC concept and employed the technologies discussed above (JSP, Java Servlets and Java Beans) has been named Model 1 [Java BluePrints, 2003]. Model 1 uses MVC components for web applications as following:

− The model is a Java Bean used to maintain all the data that resides in the model. This is a class that contains get and set methods to access and store the data. This may also be used to access the database in order to obtain this data.

− The view is the graphical user interface (GUI) that is presented to the user in the form of a JSP. The user may interact with the JSP by submitting a form or performing some sort of action which is then submitted as a HTTP request to a particular JSP.

− The controller in the case of Model 1 is also the JSP which handles the request from the client and generates a response in the form of a JSP. It retrieves the data it needs from the Java Bean which it then uses to embed in the response page as shown in Figure 2.2-2.

Fig. 2.2-2. MVC Model 1 Architecture [Shin, 2003]

17

In Model 1 (see Fig. 22-2.), a Web browser directly accesses JSP pages. The JSP pages access Web-tier JavaBeans that represent the application model, and the next view to display (JSP page, servlet, HTML page, and so on) is determined either by the hyperlinks selected in the source document or by the supplied request parameters. A Model 1 application control is decentralized, because the currently displayed page determines the next page to display. In addition, each JSP page or servlet processes its own inputs (parameters from GET or POST). Apart from the decentralization, the problem in this model is in the way how the data is obtained and manipulated by the controller from the Java Bean model. The offered idea to use JSP as a controller means that a lot of work and functionality needs to be put in it in the form of scriptlets. As it was said, these are blocks of Java code embedded within JSP, so that business logic is encoded along with presentation one. That means the problem of separation of concerns is not solved. Web designers still need to have knowledge about the actual code in the web page in order to present data to user. And the task of simplifying the maintainability is not fulfilled. Necessity to change web page presentation will lead to the change of the system. The Model 1 architecture suits better for small, static applications. It provides simple structure for applications that have simple, fixed page flow, have little need for centralized security control or logging, and change little over time. The improvement for Model 1 leads to Model 2 that improves Model 1 in a number of ways, with the most significant improvement being the use of a controller to handle requests from the client.

Fig. 2.2-3. MVC Model 2 Architecture [Shin, 2003]

When a request arrives, the controller initializes a Java Bean that will be used for the request (see Fig. 2.2-3.). The controller centralizes the logic for dispatching requests to the next view based on the request URL, input parameters, and application state. The Java Bean can then be used to store data from the HTTP request or it can be used to retrieve data. The JSP is responsible for generating the view whilst the servlet alleviates a lot of the work that the JSP has to do for the request. Model 2 is a good approach to take because it makes maintenance

18

of the application much easier and improves the separation of the business logic and the presentation logic. The benefits of Model 2 are more evident as the size of the application grows. The Model 2 controller servlet provides a single point of control for security and logging, and often encapsulates incoming data into a form usable by the back-end MVC model. For these reasons, the Model 2 architecture is recommended for most interactive applications. [Java BluePrints, 2003]. Despite all these advantages, in this case nothing prevents a developer from embedding application logic into the JSP. It is known, that many developers actually fall into the trap, often to perform a quick fix. This results again in an application hard to understand and maintain. A significant alternative to the Model 2 is Model 2X. It uses the eXtensible Mark-up Language (XML) instead of Java Server Pages as the view. By using XSL stylesheets along with an XSL transformer (XSLT) XML data is transformed into a different content type such as HTML or even PDF via the use of formatting objects (FO). This has brought rise to a number of XML publishing frameworks which favour this approach over the Model 2 approach. Indeed this is a cleaner approach since all processing logic is specified in the XSL stylesheet to render the view to the client. A side effect of this is that it is complicated to build and modify these XSL stylesheets and there is a stipulation that the data passed around the system must be in an XML format to start with. [Merkay, 2002]

2.3. Web Application Frameworks A web application framework can be defined as a framework for developing web applications in a maintainable, consistent manner making sure that above all the presentation logic of the page is separated from the business logic. The number of frameworks that have appeared in last three - five years is tremendous. They differ not only in favour of using JSP or XML approaches. They are based on different concepts and generally can be classified in the following groups [Holloway, 2003]:

− MVC Orientated Approach − XML Publishing Approach − Template Engine Approach − Event Model Approach − Component Orientated Approach

This section describes these approaches and example implementations of the approaches are investigated.

2.3.1. MVC Oriented Approach The MVC Oriented approach is a direct utilization of the Model 2 framework. Like Model 2 it has the following components:

− Controller – the controller is generally responsible for initializing web applications and handling requests from the user before delegating the requests to particular sub-components (sometimes called Actions or Commands) in order to generate a response. In order to map the requests to sub components we need to use some sort of mapping mechanism.

19

− Model – the model is responsible for storing data, this is generally represented as a Java Bean or similar data structure containing get and set methods. We can then call these from the controller according to the parameters passed from the user request.

− Template Views – some sort of templating mechanism is required and this generally involves taking some existing mechanism such as Java Server Pages JSP.

− Mappings – a number of mappings are required in order to provide links between the URI’s that a user will be able to access from the web browser via the web interface and the sub-components that will handle the requests from the user.

There are a number of the frameworks employing this principle. Among them are Maverick, WebWork, Apache Struts. The following section describes Apache Struts, a relatively mature and established MVC framework, which provides a number of interesting features and perspectives. Apache Struts Struts is initiative of the Jakarta Project sponsored by the Apache Software Foundation. It was created by Craig McClanahan in May 2000 and its code was donated to the Apache Foundation for the development community. Like all other Apache Group’s projects, Strut framework is OpenSource and it is distributed under the Apache software licence. Struts framework provides well-elaborated design that allows a developer to focus the attention on developing the business logic, instead of thinking on the peripheral functionality like program flow, validation and request dispatching. Fig. 2.3-1. shows the program flow within Struts framework:

Fig. 2.3.1-1. Apache Struts. Program Flow [Kochmer, 2003]

Below, the components are described in the order they are used in control flow.

20

web.xml. The first step is to configure deployment descriptor. This is the configuration file which is checked by the Servlet container on start-up. When the container has determined that Struts servlet exists it will map all appropriate file requests to it. It is common to map any request for a file that ends with .do to be processed by the default Struts Action Servlets: <servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping> The request can look like following: http://www.eShop-struts.de/eShop/start.do Request. The next step is sending the request from the client for a page or submitting a form in browser. Controller. This is the central processor in Struts. In Struts the controller is implemented as a Servlet. It determines which action is required and sends the information to be processed by subcomponent Actions. It can also send request straight to a JSP page to be displayed. The controller plays the role of a centralized point through which the flow of logic is controlled. It allows performing security and filtering logic. Controller subcomponents, referred to as "Action classes", coordinate activities in the application. This may mean taking data from the user and updating a database through a Model component, or it may mean evaluating an error condition with a back-end system and directing the user through special error processing flow. Controller components accept data from the users, decide which Model components need to be updated, and then decide which View component needs to be called to display the results. One of the major contributions of the subcomponents is that they allow the developer to remove much of the error handling logic from the JSP pages in their application. This can significantly simplify the logic in the pages and make them easier to develop and maintain. Struts-config.xml. This configuration file stores mapping of actions. The controller checks this file to determine which modules to call upon an action requests. It is read on the start-up and stored in the memory as mapping database in order to speed up the performance. Model. It is an object to store the results of the user response for the duration of the process. Often the model object takes the data from the submitted form and stores the results in a Java Bean. Here the pre-processing of the received data can be performed. It is clear that model object is project specific. It is a “model” of the business logic or data behind a Struts application. For example, in a Struts application that manages customer information, it may be appropriate to have a "Customer" Model component that provides program access to information about customers. It is also common for Model components to provide interfaces to databases or back-end systems. Model components are generally standard Java classes. There is no specifically required format for a Model component, so it may be possible to reuse Java code written for other projects. View. View components are the parts of an application that present information to users and accept input. In Struts applications, it corresponds to Web pages. View components are used to display the information provided by Model components. Usually, there is one View components for each Web page in a Struts application. View components are generally built using JavaServer Page (JSP). Struts provides a large number of "JSP Custom Tags" which provide the possibility to perform Struts presentation logic using XML-like syntax and simplify the development of View components.

21

Struts Tag Libraries. Tag libraries hide project logic behind simple-to-use Tag statement. These Tags are used only within the view components in JSP’s. They can be combined or even substituted with standard JSP tag libraries. Property file. The property file is a way to store messages that an object or page can use. Struts Tag libraries can also access it for titles or other string data. Mostly it is used for localization purposes. There can be several property files for different languages. Business Objects. Business Objects handles the business logic of the application. Since the logical flow in Struts is spread among several steps, business objects can be addressed from any of the steps. [Kochmer, 2003] The Struts developers point to the following strengths of the framework [McCay, 2003]:

− Struts makes it possible for JSP pages to externalize flow control. Rather than specify physical links to various JSP pages within the JSP file, the JSP file contains a Struts-defined logical URI. The Struts URI defines a logical page request mapped to actions that may return different physical JSP pages depending on the context of the HTTP request.

− Struts simplifies the development of the actual JSP file content by limiting it to user interface generation only. Java that would otherwise appear inside the JSP files appears in separate servlet action classes that the JSP page invokes at runtime.

− Struts helps to separate the development roles into user interface designer (HTML or tag library user) and JSP action-handler developer. For example, one person can write JSP page using only HTML or suitable tag libraries, while another person works independently to create the page action handling classes in Java.

− Struts externalizes JSP actions that would otherwise appear inside all the JSP pages of a project into a single configuration file. This simplifies debugging and supports reuse.

− Struts consolidates String resources that would otherwise appear inside all the JSP pages of your project (for example, form labels) into a single file. This greatly simplifies the task of localizing JSP applications.

Version Struts 1.0 lacks the “dynamic properties”, or the ability to use meta-data to drive the creation of forms and the associated Action Forms, and makes the client-side form/ JavaScript interaction difficult. These drawbacks were addressed in Struts 1.1. But still, building large and complicated forms is quite a difficult task in this version.

InfoAsset Broker For the research purpose, one of the frameworks to be compared is a proprietor one, created by InfoAsset AG. InfoAsset Broker is a framework that provides a broad functionality for web-based portal software development. Its strength lies in the clearly defined architecture that covers all three layer of the web application: presentation, business logic and persistency layers. Since this research paper covers mostly the web-visualization frameworks, it is fair to talk about the presentation logic functionality of Broker. Architecture On the presentation layer, Broker provides a structure close to MVC-Oriented framework approach.

22

HTTP request is received by the Web-server. The request contains the name of the requested document. The web-server consults the configuration file handler.txt, which maps the requested path to the handler to be invoked. The request is transferred to the corresponding handler with the session object. Handlers can be compared with the Actions in Struts. They handle the request by extracting necessary parameters and perform business logic calling the Service objects for required content. A Handler returns a Station, workflow control element that defines which step should be done next. A Station can transfer the control to another handler by passing it parameters, call a template to present for a user or finish the workflow without visual effect for the user. The example of Broker components interaction is depicted on the Fig. 2.3.1-2. In this case a station of VisibleStation type is considered. Configuration files Broker has two main configuration files:

− Property.txt. This file configures web-server. It contains host-specific setting, user-agent customization, logging, content manager configuration etc. It is placed under workspace/project/project_name.

− Handler.txt. This file maps the requested path onto the corresponding handler. It supports the following syntax: path = Java handler class. For example,

blacklist/allSuspiciousAssets=de.infoasset.broker.weblogHandler.blacklist.AllSuspiciousAssetsHandler One can use wild-card matching for path definition. error/*=de.infoasset.broker.weblogHandler.ErrorHandler This mapping means that all requested started with “error/” will be handled by ErrorHandler. Handlers Handlers are the Java classes that extends the base class de.infoasset.broker.weblogHandler.IntrospectiveHandler. They perform three steps of every request handling:

1. The initialization of a handler. In this step, all stations and their substitutions are defined. The following snippet is the initialization of de.infoasset.broker.weblogHandler.blacklist.DeleteQueryHandler.java :

public void init(Session session, final OutputStream output, final String documentId) {

stations[TEMPLATE_KIND] = new Line() { public void setParameters(SetParameters parameters) { } public String forwardTo() { return "blacklist/queries"; } }

2. The necessary parameters are extracted from the request. Here, the parameters are retrieved, but not processed. public void getParameters(GetParameters parameters,String documentId) {

queryId = parameters.getString("queryId", false, ""); }

23

3. On this step the processing of the parameters is performed by implementation of the method doBusinessLogic. In order to fetch the required information, handler calls Service classes, which creates assets and retrieves information from there or populates them with the corresponding request parameters. Depending on the processing result, Method doBusinessLogic returns a Station instance which defines the following step in the workflow. The following snippet is the implementation of doBusinessLogic method in DeleteQueryHandler.

public Station doBusinessLogic(Session session) throws Exception { if (!session.isEditor()) throw new

AssetProtectedException(session.getMessage("weblog_access_denied")); session.getServices().getBlacklistQueries().removeBlacklistQuery (queryId);

return stations[TEMPLATE_KIND]; } Every handler has the following attributes: - for every request-parameter a corresponding variable - an array of stations

Fig. 2.3.1-2. InfoAsset Broker. Interaction diagram

24

Stations A station is a workflow control component, which takes the control after each handler execution. Depending on which type of stations it is, it forwards to another handler, fills in a template and shows it to a user or terminates a workflow without visualization. The type of the station that takes the control is defined by the preceding handler. There are three types of stations available:

− VisibleStation. It substitutes placeholders in a template and visualizes them to a user. − Line. Forwards to another handler. If any parameters are to be sent to the next handler,

this station sets the parameters by implementing the method setParameters(SetParameters parameters).

− InvisibleStation. This station neither visualizes a template nor forwards to another handler. It can perform some action, for example, send an email or do some debug output.

Every type of stations can perform some additional actions. It can send an email or form a template through TemplateAction (see Fig 2.3.1-2.). It would be possible to compare stations with Struts’ ActionForwards, since they both maps the Handler/Action outcome to the next step of request processing or of the next view. But on the other hand side, ActionForwards lack the functionality that stations bear. In Struts, the data are pulled in the template what is outsourced to JSP tags or Velocity template language, whereas Broker uses push strategy, by filling in a template by Fillers. Another difference is that, if ActionForward transfers the control to the next action, it is the decision of the previous action how the parameters are sent, whereas Line Stations are responsible for it. Having this intermediate component in-between pure controller and pure view components, makes it possible to enclose a designer from the business logic completely. Templates Templates are html files that contain html-code and so called placeholders. The placeholders are substituted with the necessary content on the station processing step. The substitution is defined in the putAllSubstitutions method. In the following example, the station of the invisible type invoked after EMailEntryHandler being processed substitutes the corresponding placeholders in emailEntry/entryBody template (see Fig. 2.3.1-3).

class EmailEntryHandler public void putAllSubstitutions(Template template) { template.put("body", new PrintSubstitution() { public void print(Session session, PrintStream p) { p.print(bodyString); } }); template.put("attatchments", new ListTemplate() { //method implementation }

emailEntry/entryBody $body$ <br><br> $[attatchments a$ $[a.isImage$ <img src="/$a.directoryPath$/$a.localFilename$">$]a.isImage[$ <a href="/$a.directoryPath$/$a.localFilename$">$a.localFilename$</a> $a.isImage]$ $attatchments]$

Fig. 2.3.1 -3. InfoAssetBroker. Placeholder substitution

25

Placeholders’ definition complies with the certain, quite simple and intuitive, syntax rules. - Variables are enclosed with $$ signs. For example, $body$ - If a variable is an array or an object, its elements can be accessed with

$array_name.array_element_name$ placeholder. For example, $a.directoryPath$. - It is possible to use the condition by

$[variableName $ Conditional Content $] variableName[$ Alternative Content $ variableName]$ expression

- It is possible organize loop the iteration over a list by the following syntax: $[documents d$ Sample Row 1 with variables d.xxx d.yyyy Sample Row 1 with variables d.xxx d.yyyy $]documents[$ Output if empty list $documents]$ expression

The Broker component structure that provides web-visualization functionality is depicted on Fig. 2.3.1-4.

Fig. 2.3.1-4. InfoAsset Broker. Component structure On the presentation level, Broker gives the clear advantages in the separation of business and presentation logic by introduction of the Push-MVC Model 2.

2.3.2. XML Publishing Approach

The bases for these types of frameworks are Model 2X approach rather than the traditional Model 2. A number of basic components can be outlined:

− XML Document. This is a basic structured hierarchical document that contains the

data for a particular entity or set of entities. − XSL Document. This is an XML stylesheet, it contains formatting instructions to

apply to a particular XML document − XSL Transformer. This is the software that it responsible for taking the XML

document and applying the rules specified in the XSL document to it. The resulting

Web- server

handler.txt

Handler session Station Visible/Line/Invisible

Business Objects

HTTP responce

template populated with content

parameters

HTTP request

26

document is then output of a transformer. It may be anything from a web page to a PDF document. (see Fig 2.3.2-1)

Fig. 2.3.2-1. Components of a framework that implements XML Publishing Approach [Holloway, 2003]

Examples of this approach include Rezin and Cocoon. Cocoon has a very wide commercial presence and it the subject of discussion within web developers’ community; therefore it is interesting to look at it. Apache Cocoon Cocoon is a framework that allows the dynamic publishing of XML content using XSLT transformations. It claims to provide strong separation of concerns by employing XML to describe content and XSLT as means to transform that content into multiple formats. Cocoon sees three concerns which should be separated:

− Content, basically the information which is displayed on a web page, possibly stored in a collection of XML documents.

− Style, the look & feel of a website, often implemented using XSLT transformations towards XHTML and/or other delivery formats such as PDF, Excel, or Wireless Mark-Up.

− Logic, which is used to generate or alter the Content being presented to the user. All the areas can work together provided the contracts between each do not change (see Fig. 2.3.2-2.). This allows developers to work productively on the creation of the web application while minimizing the resources spent.

Fig. 2.3.2-2. Apache Cocoon. Work areas [Cocoon userdocs, 2003]

Cocoon is based on the main principle of pipeline architecture. A pipeline consists of some input data, followed by a number of processing steps. Every processing step takes as an input the output of the previous step. At the end of the pipeline the final output is produced. Cocoon has several pipeline components which can be grouped depending on the role in the pipeline:

− Pipeline inputs - generators and readers − Processing steps - transformers and actions − Pipeline outputs - serializers

27

− Conditional processing - matchers and selectors A Cocoon pipeline generally consists of at least a generator and a serializer, but may consist of any number of processing steps. Data is passed through a Cocoon pipeline as a SAX event.

Fig. 2.3.2-3. Apache Cocoon. Pipeline flow [Cocoon userdocs, 2003]

Generators are responsible for reading a data source (for example, a file) and passing that data into the pipeline as a series of SAX events. Once XML document pushed into the pipeline, a number of different transformers can be applied to it. Transformers are the main processing steps in a Cocoon pipeline. They accept SAX events as input, perform some useful processing, and then pass the results further to the pipeline as SAX events. A way to view a transformer is as a component that modifies a stream of SAX events as it passes through it. The most widely used transformer is the XSLT Transformer. It gives its input into an XSLT processor that performs an XSLT transformation. The results of the transform are then given back into the pipeline as SAX events. [Cocoon userdocs, 2003] The endpoint of any pipeline is a Serializer. A serializer renders a stream of SAX events taken either directly from a generator or from the previous processing steps of transformation to the format which is necessary for the response. Serializer can produce XML document, HTML, plain text, PDF- and other formats.

Fig. 2.3.2-4. Apache Cocoon. Pipeline components [Cocoon userdocs, 2003]

28

These three components are the core of any pipeline. Other components to be mentioned: Readers are special case of input generators; they are not XML-aware components. Their task is to access an external resource and copy it directly to the response. Normally they are used for work with static data, such as images or CSS stylesheets. Actions are a means to plug additional dynamic features into a pipeline and are often specific for particular applications. However, there are some generic actions available, for example, to access database, perform form validation, sending mail, and so on. It is possible to perform conditional processing using matches and selectors. Matchers are the two conditional components that are equivalent to simple if statements. If some condition is true, then a particular pipeline or a section of a pipeline is evaluated. if condition then evaluate pipeline A Selector is also a conditional component, which works when several options are available. They are typically used for conditions within a pipeline, whereas matches are used to test which pipeline should be entered. if condition then evaluate section A else evaluate section B To configure the request-response cycle a Sitemap is used. It fulfils two functions:

− It contains the declarations of the components that are used in pipelines − It contains the definition of pipelines that use the declared components

Normally the structure of the sitemap looks as following: <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0"> <map:components> 

<map:generators/> <map:readers/> <map:transformers/> <map:actions/> <map:serializers/> <map:actions/> <map:matchers/> <map:selectors/>

</map:components> <map:pipelines>

 </map:pipelines> </map:sitemap> The next snippet shows the pipeline which starts when requested URL matches the pattern “content/*.html”, and transforms XML document with the name of the requested html file my means of content.xsl stylesheet into HTML document <map:pipe> <map:match pattern="content/*.html"> <map:generate src="content/{1}.xml"/> <map:transform src="transforms/content.xsl"/> <map:serialize type="html"/> </map:match> </map:pipe>

29

The strengths of the framework include: − Clean separation of the business logic and the presentation logic. The XML portion

represents the business logic and data which the web developer deals with whilst the XSL contains the presentation logic which the web designer deals with.

− Pipeline architecture seems to provide very clear design to the application. The strengths and drawbacks of Cocoon will be discussed in the next chapters, but already from the short introduction to this framework, one can notice its high complexity and possible problems with performance.

2.3.3. Template Engine Approach The template engine approach employs an intermediate template which is compiled by a template engine into an output format such as HTML web-page or SQL. The core components that are used in this approach:

− Template Page. An intermediate template which contains static information and references to the dynamic data in a data model

− Output Page. The resulting page produced by the template engine in processing of the template

− Data Model. The model where data are stored. It is referred from the template by means of special tags

− Template Engine. Template engine replaces the tags in the template page by the referred data from the data model using the tags (see Fig. 2.3.3-1)

Fig. 2.3.3-1. Components of a framework that implements Template Engine Approach [Holloway, 2003]

For web page a template page will contain a mixture of static html and embedded tags. An example of a template page is shown: <html>

<head></head> <body>

<h1>Welcome <%customer.name%></h1> </body>

</html> As soon as template engine encounters such a tag in a template, it refers to model data to substitute the tag with the corresponding data. So that output page will look like this: <html>

<head></head> <body>

<h1>Welcome Maria </h1> </body>

</html> There are a number of template engine frameworks: Webmacro, Freemarker, Velocity. Apache Velocity

30

Velocity is very simple in its architecture, as it is meant to be nothing more than a template engine. The idea is to do one thing only and do it well. ] Velocity provides a simple template syntax and a clear separation of content and data. It uses Velocity Template Language (VTL) to display dynamic content within text. [Velocity User’s Guide, 2003 This language operates with references in order to access dynamic data (e.g. $userName) and statements in order “to do something” (#set): #set( $a = "Velocity" ) There are three types of references in the VTL: variables, properties and methods. In the previous example $a is a variable. Properties are actually references to the dynamic data sources. For example, there is an object Employee, which have property name and has the corresponding get method. It can be referenced from a template by VTL property: $Employee.name or by VTL methods: $Employee.getName().VTL Properties can be used as a shorthand notation for VTL Methods, so these two examples have the same effect. The difference of the methods from the properties is that methods can have parameters: $page.setTitle( "My Home Page" ) Directives are easy-to-use script elements that can be used to manipulate the output of Java code. For example, #set directive is used for setting the value of a reference. A value can be assigned to either a variable reference or a property reference, and this occurs in brackets, as demonstrated: #set( $primate = "monkey" ) #set( $customer.Behavior = $primate ) Another script element, #include, allows the template designer to import a local file, which is then inserted into the location where the #include directive is defined. The useful feature of Velocity is the “Velocimacros”. Velocimacros can be thought of as snippets of re-usable data that can contain any code that will be used several times in the template. They can contain a repeated part of the template or a sequence of methods. The clear advantage of Velocity is its simplicity. Indeed, it is not a development framework, but it can work as a substitution for JSP pages for other tools.

2.3.4. Event Model Approach The event model involves the delivery of the events to specific listeners that are registered to receive those events. An event is an action that occurs at a specific time on the client or on the server. This event is normally coupled to a specific action or another event if we have chained a series of events together. An example of this is when a user submits an html form containing their registration details; the event invokes the saveRegistration action which saves all the user details to the database.

31

A listener is something that listens for a specific event; it generally wants to know whether something has changed and in the case where it has changed we perform an action, this is called handling an event. This approach is taken from client-server application architecture, but in this case a browser is a client and the server is a web application that runs on servlet engine or standalone server. When the client issues an HTTP request to server, it is translated into an event and delivered to the registered listeners. A user can send a HTTP request through the use of various buttons or through the set of HTML form components. Among the frameworks that support this approach there are Barracuda, WingS, JPublish. JPublish JPublish specifies its components according to the roles in the web application development team. Each role corresponds to the particular element in JPublish [JPublish Tutorial, 2003]:

Element Role Templates Designers Content Authors Actions Programmers Pages Integrators Static Resources No Role

That means that designers work on the template design, authors write the content, programmers code the logic, and integrators put all these pieces together. It is claimed that there is no intersection between all these roles and this separation eases the development of the application.

Templates are the layout of the web site that defines its appearance. JPublish template system allows having a single template for the whole site. Changes in it will cause changes in the appearance of the all page of the site. JPublish gives the possibility to define a default template which is applied to the pages where no template specified. JPublish determines the appropriate template at request time by the request path. If HTML content is requested, the templates/basic.html will be applied, in case of WML content, templates/basic.wml is called.

Content in JPublish can be pulled from various sources including file system, databases or even other web sites. It can be done through repositories:

− FileSystemRepository. Default repository which retrieves content from the local file system

− ExtendedFileSystemRepository. Extension of the FileSystemRepository which allows actions to be associated with content

− DBRepository. Repository which pulls content from a database − WebRepository. Repository which pulls content from web sites

When content is loaded from a Repository it will be passed through the site’s ViewRenderer. The default ViewRenderer in JPublish is the Velocity engine from Apache Jakarta. Other renderers can be used if specified in configuration file. The access to a repository is possible by its name, since all repositories are automatically exposed to the view. For example, to refer to the requested page from the template:

32

$fs_repository.get($page.Path)

This line of Velocity will first look for an object called fs_repository which has already been made available to the Velocity engine. Once a reference to fs_repository is located, the get() method is called passing $page.Path as the value. $page.Path resolves to the current request path. If the requested page is http://www.mysite.com/contact.html then $page.Path would equal /contact.html [JPublish Tutorial, 2003]

Actions implement business logic. They can employ a variety of languages including Java, BeanShell, JavaScript, Jython and any other languages supported by Apache’s Bean Scripting Framework. Actions can be associated with certain element of application like page, template, request, or can be executed on start-up, shutdown, pre- and post-processing of the HTTP request. Other actions available:

− Global Action. Global actions are executed on every request unless overwritten by a pre-evaluation action.

− Path Action. Path actions are executed when the specified path is matched. − Parameter Action. Parameter actions are executed when an action name is sent via a

specific HTTP parameter.

Pages provide meta-data about particular requested page paths. When a request is received for repository content the JPublish servlet will first attempt to find a page object for that request path. By default if no page object is found then JPublish will return a 404 error (page not found). A page can contain a variety of meta-data. Page designer can add there any property which will be accessible by page.getProperty(name) or page.getProperty(name, locale) methods. If a template different from the default one should be applied to the page, it is defined also in the page description. Another important element is the action definition. Page actions are the actions which are executed every time the page is requested.

<page-action name="MyAction"/> JPublish offers also several features that help in customizing JPublish. These include:

− Custom Error Handlers. JPublish supports assigning custom error handler classes to request paths. When an error occurs JPublish will execute all custom error handlers which are attached to the request path. Error handlers are mapped to paths in the jpublish.xml configuration file:

<error-handler-map path="/*"> <error-handler class="com.mycompany.MyErrorHandler"/> </error-handler-map>

− Customizable Character Encoding. Assigning different character encoding for a give path in internationalized sites.

− Extensible Content Repository. Possibility to create custom content repositories and expose those repositories on pages.

− Extensible Page Loader. Extensible page loader for loading page configurations. As a strength of JPublish the following can be named: It features flexible programmatic actions which can be written in Java or any Bean Scripting Framework-supported scripting language (such as Python or JavaScript), Velocity templates for layout, a repository abstraction layer, optional Velocity-parsed content, search engine friendly URLs. It provides clear separation of concerns by precise definition of the roles and bundled elements of the architecture.

33

2.3.5. Component Approach Development of the server components and the programs that use these components is the logical result from the necessity of rapid web application development. It is the same way as for the “traditional” applications. Each component is responsible for the forming its interface element and for its service during the interaction with a user. It can be, for example, a form, a frame around this form, a field in the form or a button. The main thing is that it is responsible for a certain part of web application interface. A component is a “black box”, which instance stores the information about its state and is able to react on events accordingly to its state. That means that the combination of JSP’s, servlets, Java Beans that were designed for the certain project, will be substituted with a clearly defined tree of standard (transferable from project to project) components. Web page now acquired a new meaning: with use of the components it can be defined as a form, similar to the “forms” in the systems for visual development such as JBuilder. All components are able to support the uniform look and feel, event handling, MVC, embedded localization. A developer does not need to know their code; it is enough to use their public methods. One of the newest and the most promising component frameworks is JavaServer Faces led by Sun Microsystems as JSR 127 under the Java Community Process (JCP). It seems, this technology will be positioned in the market as the mainstream technology for web application development. Therefore it is interesting to take a closer look to this framework. JavaServer Faces Under JavaServer Faces the development of a web application involves the assembly of UI components, connecting them to business logic components and server-side event handlers. JSF API consists of:

− A set of classes to represent standardized UI components, manage state, perform event handling and input validation

− Custom tag libraries for accessing the UI components from within a JSP This separation of UI components from the business logic provides clear separation of concerns, where the following roles are defined:

− UI Component Developer. Responsible for the development of the UI components − Application Developer. Responsible for the connection of the components to the

event handlers, for creating model object, page navigation, error handling. − Web Page Authors. Responsible for the presentation of UI components on the

presentation layer. To understand JSF it is important to understand its request processing lifecycle, defined in JSF specification (see Fig. 2.3.5-1) [JSR- 127, 2003]:

34

Fig.2.3.5-1. JavaServer Faces. Request processing lifecycle [JSR- 127, 2003]

Reconstruct Component Tree. This phase is initiated when a page request is submitted to the server (i.e. a user clicks a submit button on a web page). During this phase the server creates a hierarchical tree of UI components which represent the elements constituting the page. The JSF engine parses this component tree and wires all the declared event handlers and validators to the specific components. All this information is finally persisted in a FacesContext. A faces context is a snapshot, an object tree representation of the incoming page. This information is utilized in the following phases until the response is rendered. Apply Request Values. In this phase the JSF engine applies the values from the request object (parameters) to the respective components in the component tree (available from the current FacesContext) created in the previous phase. These values are stored locally in the UI components. In the event that conversion errors occur during storage of these values, they are queued up in the FacesContext, so they can be displayed when the content is finally rendered. If any event handlers were associated with specific components, they are notified of the relevant events. Perform Validations. After the request values have been applied, the JSF page enters the validation phase, wherein all the registered validators are applied to relevant UI components. The locally stored values of these components are run through the associated validators and validation errors, if any, are queued in the Faces Context. If validation errors occur in this phase, the JSF engine skips the next two phases and the page enters the Render Response phase. The page is reconstructed from the component tree and displayed along with the validation errors and any errors or messages queued up in the FacesContext from the Apply Request Values phase. If no validation errors are detected, the page enters the Synchronize Model phase and any events generated at this point are broadcast to the interested event handlers. Synchronize Model. In this phase any model objects associated with UI components are synchronized to the UI component's local value. If any conversion error occurs at this point, (e.g. a String value is mapped to an Integer property in a model object and cannot be parsed into an integer), the errors are queued in the FacesContext and the page enters the Render Response. The page is recreated from the component tree and rendered to the user displaying

35

the conversion errors which occurred in this phase. Also any events generated at this point are broadcast to the interested event handlers. Invoke Application Logic. After the model has been successfully synchronized, the page enters this phase. In this phase the JSF engine handles all application level events, such as linking to another page, performing updates to back end services, database updates, etc. When processing an application level event, a default ActionListener determines the outcome of the Action and passes the outcome to the NavigationHandler. The NavigationHandler then looks up the response to be generated from the navigation rule defined in the application configuration file, based on the outcome of the application logic, i.e. success or failure. The component tree for the next page to be generated is constructed and the page enters the final stage. Render Response. In this phase the JSF engine renders the UI components in the component tree persisted in the FacesContext. If any errors or messages have been queued up from previous phases, they are rendered along with the page. This component tree is persisted so subsequent requests to this page can access it and it is readily available to the Reconstruct Component Tree phase. The architecture of JSF consists of six layers:

− UI Component Model − Rendering Model − Event Model − Validation Framework − Page Navigation Framework − Internationalization Framework

UI Component Model. It defines the functionality of the components and consists of Java Beans representing various modes of input, selection and grouping capabilities. All components implement the abstract class that defines the state information and associated behaviour. UI component model is extensible and one can create new components by extending or aggregating existing components. Rendering Model. The rendering model defines the presentation aspects of a UI component. The same UI component can be rendered in different ways by different renderers. Event Model. It defines Listener and Event classes that a web application can use to handle events generated by UI components. An Event object identifies the component that generated the event and stores information about the event. To be notified of an event, an application must provide an implementation of the Listener class and register it on the component that generates the event. Validation Framework. The validation framework provides a mechanism by which “Validators” can be registered with UI components. Page Navigation Framework. The page navigation framework provides an easy declarative mechanism to specify the sequence of pages to be loaded without requiring any special code in the application. The navigation can be completely defined in the application resource file. Internationalization Framework. This framework provides an easy mechanism for localizing static data, dynamic data, and messages in applications.

36

JavaServer Faces is a very new framework, available only in Early Access 4 by now. The developers claim that it is a better framework, since it accumulates the best experiences of others. In theory, it looks like JSF eases Web-base application development by the following:

− It allows creating user interfaces from a set of standard, reusable server-side components

− Provides a set of JSP tags to access those components − Transparently saves state information and repopulates forms when they redisplay − Provides a framework for implementing custom components − Encapsulates event handling and component rendering so you can use standard JSF

components or custom components to support markup languages other than HTML − IDEs for JSF are being developed by tool vendors

2.4. Advantages and Drawbacks of Open Source Since most of the frameworks that will be mentioned are available as Open Source, it is reasonable to discuss this phenomenon and its advantages and drawbacks for businesses and developers. A program product is said to be available “open source”, when it is delivered with the source code that is allowed to modify. Under some licences it is required that all the modifications should be provided back to the product developers. This is in opposite to the proprietary software which does not provide source code. There are already a number of companies that deployed and use Open Source software, and a number of companies that start to think about this possibility. And the question “to use or not to use” is not a philosophical one, but mostly financial and business question. It is not enough to see an example of the competitor, since some projects will make benefits from using open source, others can fail. The decision have to be taken is the trade-off between the risks and the rewards. The following can be named as the advantages of Open Source:

- Openness. When a developer has the code it is easy for him to solve problems. Than means that he does not depend on the fixed vendor.

- Potential Stability. It is a “potential” advantage, since even unstable product has the potential to become stable. As it was said, under some licence all the changes should be sent back. That means that the community of developers, by changing some bugs, after some time brings the product to the stable state. This assumption can fail, if no one is interested in the product

- Adaptability. Open Source software means Open Standards, thus it is easy to adapt software to work closely with other Open Source software and even closed protocols and proprietary applications. This solves vendor lock-in situations which ties one’s hands to one vendor.

- Innovation. Innovation is driven by competition that is kept alive by Open Source.

- Cost. Although Open Source doesn't necessarily mean that it is free. Most Open Source software is freely available and doesn't cost any additional licenses per user/year. This allows cutting down in price and spending more time to create more secure and adapted solutions.

Thinking about using Open Source products one should also take into account the risks it bears:

37

- Restricted choice. Almost in every area of software there is a wide choice for different commercial packages. It is hardly true for open source options.

- Difficult to use. Open Source packages in most cases are made by professionals for professionals. Many functions will involve creation of configuration files, scripts, recompiling the source code.

- Higher cost of operation. Open source products need much higher degree of technical expertise to operate and maintain.

- Higher cost of technical support. Open source costs more to support because the software is typically self-supporting.

- No warranty. If one uses open source he is not supported by any third company.

Open Source risks and advantages are the issues that should be taken in the discussion of the choice of a proper web development framework.

38

3. Prototype of Online Shop Application During the research, different web application frameworks are compared by using in implementation of the same sample application, so that the application features become irrelevant for the comparison, but the merits of each framework become on focus. Such example should demonstrate the common features expected from a CRM web application in order to analyse the applicability of the frameworks for this kind of applications. Online Shop was chosen as a sample application and its core use-cases were implemented. In this section the use-cases of Shop application, its navigation scheme and object model are described.

3.1. Online Shop Use-Cases

3.1.1. Display of the products

Use Case Name and Purpose Display of the products is the categorized presentation of the currently available products.

Following Use Cases / Forks Any displayed product can be put in shopping cart

Scenarios / Activity 1. (initial) 1.1) Presentation of the top products in start page 1.2) Presentation of the products of the certain manufacturer, when his name is chosen

from the shop sidebar menu

Backend-Calls Retrieval of all available products with product details and properties (for example “top product”)

Additional Requirements In the prototyping implementations responses from backend are emulated in XML data structure in file system repository.

3.1.2. Homezone Check

Use Case Name and Purpose “Home Zone Check” allows the user to check/verify the availability of the Genion Feature at the home address.

Post-conditions Any addresses entered here are temporarily preserved for the following usage (e.g. Order Process or future Homezone Check).

Follow-up Use Cases / Forks Initiate order for the chosen product.

Scenarios / Activity 1. (initial) user enters street, building number, zip, town

39

2. System retrieves home zone status from backend Possible status: available, not available, side-street check required, (error)

3. If Homezone Check was called at after ordering a product, link to shopping cart is provided

Additional Requirements - In the prototyping implementation the backend call is skipped. As soon as entry data are

validated, the positive result is presented - Homezone Check must be able to run as

- a standalone feature (Homezone Check from shop menu) - first step of the Order Process

Errors - a mandatory fields is not filled out:

redisplay current form and indicate the missing fields - filled in data does not correspond to the validating rules:

redisplay current form and indicate the wrong data

3.1.3. Shopping Cart

Use Case Name and Purpose Shopping cart allows the user to view and modify his/her order

Pre-conditions - The user clicked on the button „Bestellen“ on the page „Handydetail“ of the chosen

mobile phone or a tariff, i.e. the shopping cart is not empty. - In case the accompanying tariff is either O2 Genion Power SMS or O2 Select Power

SMS, the user has to fill in the Home Zone form, which should be validated. - In case of O2 Starter Power SMS the user gets immediate access to shopping cart after

ordering an item - In case user filled already the shopping cart, Home zone already checked or is not needed,

he can access the cart from any place of the online shop by clicking the icon in left upper corner

Follow-up Use Cases / Forks - Order process, the user fills in the forms with necessary information and submits the order

Scenarios / Activity 1. The user views the price details of the chosen mobile set (image, article name,

number, price) 2. The user can modify the quantity of the order 3. The user can delete the complete order 4. The user can proceed to the order use case

Additional Requirements

For the prototyping implementation in Cocoon the shopping cart must contain only one product (accordingly to O2 Supply requirements) Backend responses are emulated in XML data structure in file system repository

40

Backend-Calls - detail data on the product

Errors - The shopping cart can not contain more then one mobile phone order. Next order can be

done only after the shopping cart will be empty (for Cocoon prototype, according to O2 Supply requirements).

3.1.4. Ordering Process

Use Case Name and Purpose “Ordering process”, process that leads the user through the steps of ordering an item

Pre-conditions - The user placed an order into the shopping cart and wants to proceed to submit the order

Scenarios / Activity The ordering process consists of the following steps:

− Personal Details

− Individual tariff options

− Bank connection/ Delivery and billing address

− Last Check/Order Confirmation

The order of steps is fixed for all order processes but may be changed easily. It is also possible that some steps do not appear e.g. the tariff options page is not needed for prepaid mobiles.

The personal details page requests all needed user data, such as name and address, date of birth, a passport identification and nationality.

The individual tariff form in the second step offers available and selectable options the user has for the selected contract.

The next page of the ordering process is intended for the entry of the bank connection and, if required, an alternative billing address as well as delivery address. By default the user’s home address is entered in these fields.

1. The user fills in the form with personal details.

1.1. The form is validated.

2. The user fills in the form with tariff options.


3. The user fills in the form with bank, delivery and billing data.


4. The user views the summary of his/her order data. The user has the opportunity to change the data entered by clicking on a change button (Last Check form)

4.1. The order is saved

41

4.2. User feedback is displayed. (Order Confirmation)

Additional Requirements - In order to proceed with the following step the user has to correct the errors in the current

form - If the form on any step is filled in correctly the user has the possibility to come back to it

from other steps.

Errors Forms fields are validated against the predefined rules. If one ore more entries in form fields are erroneous, the user is redirected to the same page with corresponding error message. The user can not proceed with further steps until he/she corrects the current one

3.2. Online Shop Navigation Scheme Navigation scheme of Online Shop prototype was designed close to the original application and in the way it allows to integrate the previously described use-cases.

Fig. 3.2-1 Online Shop prototype Navigation Scheme.

Every page has a menu bar with the direct access to the start page, products, categorized by manufacturers, and Homezone Check tool. By clicking on any product listed in Start Page and Products by Producer pages, a user is prompted to the page with the detailed information about the chosen product. The user can place the current product into the shopping cart by clicking the button Bestellen. In Shopping Cart page it is possible to view and modify the order and start the ordering process. Order Process contains four forms (see 3.1.4), which should be filled in. Homezone Check can be a step in Order Process, if it is not done before order, or can be used as a separate tool. This scheme is a core navigation, which is slightly modified in different implementations. The modifications were done either in order to experiment with the frameworks or because of the limitations of a framework.

3.3. Online Shop Object Model The following Object Model is used in order to handle the data reside on backend (see Fig. 3.3-1)

42

As in the case of Navigation scheme, this Object Model is slightly different for different implementations.

Fig 3.3-1. Online Shop Object Model

SessionManager is an entry points for all data that need to be stored in the session. OrderProcess is an object that serves the process of ordering a product. Shopping Cart stores the information about order. Topic is an object that is necessary for connecting menu bar with the content part of the page. The name of the manufacturer of the current product should be highlighted.

3.4. Justification of the Choice of the Online Shop as a Sample Application Online shop is the application that was already implemented in different variations and different technologies. It is well known by most of the web application developers. Another realization of Online Shop is not new by itself. But this application was chosen as a sample application because of the following reasons:

1. Implementation of Online Shop allows examining how the frameworks support the most important tasks of web applications development, and CRM web applications in particular: - User navigation. How easy it is to implement designed navigation scheme. - Categorized data publishing. A framework should be able to manage the data coming

from different sources and be flexible to allow the information to be delivered in the way it is defined by application designers.

- Form handling. All CRM application use forms for getting the user data, therefore it is important to know how a framework handles reading these data, populating the forms, mapping them to object model.

- Form validation. If a framework provides help in form validation, it greatly reduces the programmers’ load, since it is a very diligent and not creative task.

- Separation of concerns. Separation of tasks of programmers and ones of designers and layout programmers in one of the core features of the new frameworks.

2. As it was already mentioned, online shops are already implemented in various technologies, e.g. OpenShop, InterShop. That gives the basis to talk about the possibilities provided by the frameworks in comparison with other technologies.

3. Online Shop is a prototype for NECOS application required by O2 Supply Germany.

43

4. Implementation of Online Shop Use-Cases with the Chosen Frameworks In the previous chapter the use cases of Online Shop were described. In order to carry on the evaluation of the frameworks, the prototyping implementation of this application was done using four frameworks from the four categories, discussed in chapter 2. This chapter contains the description of each of the four implementations. The following frameworks with different approaches were chosen:

- XML Publishing approach – Cocoon - MVC Oriented approach – Struts - Event-Based approach – JPublish - Template-based approach – Velocity

For the Component-Based approach, JavaServer Faces were chosen. The implementation of the Online Shop using this framework was not successful for a number of reasons, which are discussed in section 4.5.

4.1. Online Shop Prototype Implementation Using Apache Cocoon

4.1.1. Prototype Architecture As it was described in section 2.3.2 , in Cocoon any request is handled by the cocoon-servlet which consults the sitemap.xmap for a pipeline to delegate the request to. A pipeline is a kind of request handler that is activated if the request-URL matches a given pattern.

In order to prevent the sitemap.xmap becoming too large and for performance reasons, it was decided to divide the application in three modules:

- Shop. It is responsible for product presentation in the Online Shop. It includes start page, the presentation of the available products by manufacturers, detailed presentation of a product.

- Homezonecheck. The module checks the availability of the Genion feature, home zone, in the given address.

- Orderprocess. The module supports the process of the product order, by providing a number of forms for collecting the user’s personal data. The shopping cart is included in the order process as its first step.

The navigation scheme designed in section 3.2 for Cocoon prototype will look as depicted on Fig. 4.1.1-1.

Menu bar is available for each page in each module. Trough it, a user can access the start page, homezonecheck page and product categories. The navigation on the application content is interconnected with menu bar in the way that a category is highlighted when a user views a product from the particular category.

44

Fig. 4.1.1-1. Online Shop Navigation scheme in Cocoon

Processing scheme Each module has its own sitemap.xmap definition which is responsible for a sub-URL only In Cocoon terminology, the construction of the sitemap tree is called sitemap mounting.

shop/start

homezonecheck/

orderprocess/

/eShop/shop/src/webapp /sitemap.xmap

/eShop/orderprocess/src/ webapp/sitemap.xmap

/eShop/homezonecheck/src/ webapp/sitemap.xmap

http://myserver/eShop/shop/Start /eShop/src/webapp/sitemap.xmap

Fig. 4.1.1-2. Sitemap mounting for Online Shop prototype in Cocoon

The main sitemap handles the mounting and processing of common elements. One of the most important pipelines is handled in the main sitemap: navigation. This piplene processes the configuration of the menu, defines which menu title should be highlighted. The result of this piple is aggregated with the content part of the page.

In order to follow the MVC paradigm following (simplified) processing schema is applied (see Fig. 4.1.1-3). The request is received by Cocoon servlet and transfered to the pipeline that matches it. The pipeline give the control flow to an action that updates the model and defines the next view. A pipeline can give the control to another pipeline inside itself, so that the data processing become recursive.

orderprocess

homezonecheckshop

45

Action request

View

Pipeline

forward

Internal forward to other pipeline

response

Cocoon Servlet

Fig. 4.1.1-3. MVC paradigm in Cocoon

The Action component acts as a controller that performs business logic and prepopulates model objects for the view component. The view components task is to render pages which will be sent back as response.

A pipeline consists mainly of action components, generators, transformers and serializers. Generators produce SAX events which will be delivered to the next component inside the pipeline. A couple of transformer components can use the SAX event to generate other SAX events. Finally SAX events are serialized to a final, transferable form.

4.1.2. Shop module Pipeline flow The sitemap of this module contains three external pipelines and one internal. The external pipelines are used to handle URL- requests:

- http://myserver/eShop/shop/StartPage. Start page of the application.

- http://myserver/eShop/shop?producer= . List of the products of the chosen manufacturer. Request parameter identifies the chosen manufacturer.

- http://myserver/eShop/shop/handy?name= type= . Chosen Product details page. Parameter name identifies the name of the product. Parameter type identifies which category should be highlighted in the menu bar.

The internal pipeline is used to aggregate the dynamic and navigational parts of the page. It is illustrated on the following example.

The sitemap fragments on Fig. 4.1.2-1 are taken from the main-sitemap and the shop-sitemap. These fragments show the process of the pipeline mounting and the communication between pipelines in one sitemap on the example of the start page. Supposed, a user entered URL http://myserver/eShop/shop/StartPage into the browser. First processing step is the delegation of the relative request URL shop/startPage from the Cocoon servlet to the main-sitemap. The main-sitemap prompts the request to the shop module. The remaining request URL (StartPage) will be matched in sub-sitemap on line 20. Next processing step is to perform StartShop-action in line 21. Within that action, a parameter page used in line 22 is created. The parameter value accessed through the expression {page} will be „shop/StartPage“ for this example.

Model

46

The generator in line 22 causes a forward to another pipeline. The internal pipeline in line 10 matches the request and continues the processing. Outcome of the aggregator starting in line 11 is an XML document with root element page and children navigation (from part in line 12) and content (from part in line 13). The wildcards in line 10 is resolved to {1} =“shop“ and {2}=“StartPage“. Pipeline “navigation” uses the given parameter (here: „shop“) to decide which item to highlight. Pipeline “dynamic” gets „StartPage“ that is used as base-name for a XSP-filename. Finally, the intermediary XML doc is transformed in line 15. As one can see parameter {2} is again used to generate an appropriate filename. In this case it is required that XSP and XSL base-name are equal.

1: <map:pipeline internal-only="true"> 2 : <map:match pattern="dynamic/*"> 3: <map:generate type="serverpages" src="documents/{1}.xsp"/> 4: <map:serialize type="xml"/> 5: </map:match> 6: <map:match pattern="static/**"> 7: <map:generate src="documents/{1}.xml"/> 8: <map:serialize type="xml"/> 9: </map:match> 10: <map:match pattern="page/*/**"> 11: <map:aggregate element="page"> 12: <map:part src="cocoon://navigation/{1}"/> 13: <map:part src="cocoon:/dynamic/{2}"/> 14: </map:aggregate> 15: <map:transform src="stylesheets/{2}.xsl"/> 16: <map:serialize type="xml"/> 17: </map:match> 18: <map:pipeline> 19: <map:pipeline> 20: <map:match pattern="StartPage"> 21: <map:act type="StartShop"> 22: <map:generate src="cocoon:/page/{page}"/> 23: <map:serialize type="html"/> 24: </map:act> 25: </map:match> 26: </map:pipeline>

1: <map:match pattern="*/**"> 2: <map:mount check-reload="yes" src="{1}/" uri-prefix="{1}"/> 3: </map:match>

eShop/src/webapp/sitemap.xmap eShop/shop/srcwebapp/sitemap.xmap

Fig. 4.1.2-1. Control flow in sitemap mounting

47

Actions Cocoon supports two different kinds of action classes: actions driven by a HTML link request and actions driven by form submit. Shop module uses only simple actions extended from com.o2.portal.actions.AbstractBaseAction. The Fig. 4.1.2-2 depicts the processing steps for this kind of Actions.

Model:m

act(..):Map perform(): Map

AbstractBaseAction: action

<<create>>

Request/Session

setAttribute(m)

Fig. 4.1.2-2. Interaction diagram for processing an HTML link request case

In the shop module three actions for each external pipeline are used. StartShopAction. It performs only when pipeline matches the request http://myserver/eShop/shop/StartPage. Implements only method perform(). It requests the start page configuration data from Configurator class and stores the data in the SeManager class, which is responsible for managing the session. It returns “shop/Startpage” as a next view. HandyViewAction. It performs only when pipeline matches the request http://myserver/eShop/shop. Implements only method perform(). It reads the request parameter producer and requests the list of the available products of this producer name from Configurator class and stores the data a in the SeManager class. As a next view, it returns “{producer_name}/handy”, where producer_name is the parameter used for the menu highlighting in navigation pipeline. HandyAction. It performs only when pipeline matches the request http://myserver/eShop/shop/handy. Implements only method perform(). It reads the request parameter name and requests the detailed data about this product from Configurator class and stores the data a in the SeManager class. As a next view, it returns “{whatfor}/handy”, where whatfor is the parameter used for the menu highlighting in navigation pipeline. Since this module uses only AbstractBaseAction, the overall request processing scheme looks similar for each of three pipelines (see Fig. 4.1.2-3)

48

Fig. 4.1.2-3. Processing flow for the requests driven by HTTP links

HTTP request is transferred to the shop-sub-sitemap form the main sitemap. If request matches one of the external pipelines, the corresponding action is performed. It reads necessary data from the repository (it this case it is file system repository) and populates model object. The next view, that the action returns, contains two parts – one is for navigation part of the page, which renders menu bar, and the second one is for choosing the corresponding xsp- page, which reads data from the session and writes them in XML structure. At the end of the pipeline, these two parts are aggregated, transformed by application of the stylesheet and serialized into HTML form. View. Views are developed as Cocoon XSP pages. In addition a stylesheet library from OIO (Orientation in Objects - beanhelp.xsl1) is used that offers a <jsp:useBean> replacement for easier access of model beans out page, request and session scope. For activation of beanhelp:

− In file .../eShop/src/webapp/WEB-INF/cocoon.xconf <target-language name="java"> element is required:  <builtin-logicsheet> <parameter name="prefix" value="help"/> <parameter name="uri" value="http://www.oio.de/help"/> <parameter name="href" value="context://stylesheets/beanhelp.xsl"/> </builtin-logicsheet>

− beanhelp.xsl is to be placed in eShop/src/webapp/stylesheets

1 http://www.oio.com/public, search for beanhelp.zip

49

Here is the example of using this tag: <?xml version="1.0" encoding="ISO-8859-1"?> <xsp:page language="java" xmlns:xsp="http://apache.org/xsp" xmlns:help="http://www.oio.de/help"> <xsp:structure> <xsp:include>com.o2.shop.model.ShopAdvantage</xsp:include> </xsp:structure> <content name="StartPage"> <help:useBean id="shopAdvantage" scope="request" class="com.o2.shop.model.ShopAdvantage"/> <heading><O2-LOGO/> online shop</heading> <shopAdvantage> <heading> <xsp:expr>shopAdvantage.getHeading()</xsp:expr> </heading> </shopAdvantage> </content> </xsp:page> <useBean> needs to be placed after the first non-xsp namespace-URI element. The reason is that this way it is ensured that code generation that actually occurs when help:useBean gets evaluated takes place inside the generate() method of xsp’s java file.

The shop module uses following XSP’s for view layer: - StartPage.xsp - Handy.xsp - HandyView.xsp

4.1.3. Ordering Process Module As a first step, the order process includes a shopping cart. Here, a user can view his order. If he wants to make the order with the chosen product, he can proceed with filling in the four steps of forms (details see section 4.1.1). Pipeline flow For this module three pipelines are used. Two of them are external, they matches the following requests:

- http://myserver/eShop/orderprocess/cart. Shopping cart - http://myserver/eShop/orderprocess/. A set of forms for order process

Shopping cart uses the same pipeline structure as shop module, whereas order process employs XMLForm framework introduced in Cocoon. For the activation of the XMLForm it is necessary to provide the following changes in configuration files:

50

− .../eShop/src/webapp/WEB-INF/cocoon.xconf must contain within <input-modules> element the declaration of XMLForm: <component-instance class = "org.apache.cocoon.components.modules.input.XMLFormInput" logger="core.modules.input" name="xmlform"/>

− .../eShop/src/webapp/sitemap.xmap must declare XMLForm transformer within

<map:transformers> element:  <map:transformer name="xmlform" logger="xmlform.sitemap.transformer" src="org.apache.cocoon.transformation.XMLFormTransformer"/>

For the order process, the pipeline which processes XMLForm is presented by the next snippet: 1: <map:pipeline internal-only="true"> 2: <map:match pattern="xform/**"> 3: <map:generate type="serverpages" src="documents/{1}.xsp"/> 4: <map:transform type="xmlform"/> 5: <map:serialize type="xml"/> 6: </map:match> 7: <map:match pattern="static/**"> 8: <map:generate src="documents/{1}.xml"/> 9: <map:serialize type="xml"/> 10: </map:match> 11: <map:match pattern="page/*/**"> 12: <map:aggregate element="page"> 13: <map:part src="cocoon://navigation/{1}"/> 14: <map:part src="cocoon:/xform/{2}"/> 15: </map:aggregate> 16: <map:transform src="stylesheets/{2}.xsl"/> 17: <map:serialize type="xml"/> 18: </map:match> 19: </map:pipeline> 20: <map:pipeline> 21: <map:match pattern="*"> 22: <map:act type="OrderProcess"> 23: <map:parameter name="messagePageURL" value="message"/> 24: <map:parameter name="xmlform-id" value="order.process"/> 25: <map:parameter name="xmlform-model" value="com.o2.portal.model.OrderProcessModel"/> 26: <map:parameter name="xmlform-scope" value="session"/> 27: <map:parameter name="xmlform-validator-schema-ns" value="http://www.ascc.net/xml/schematron"/> 28: <map:parameter name="xmlform-validator-schema" value="orderprocess-rules.xml"/> 29: <map:generate src="cocoon:/page/{view}"/> 30: <map:serialize type="html"/> 31: </map:act> 32: </map:match> 33: </map:pipeline>

51

The additional transformation step done in line 4. During the transformation, object model is accessed and additional xf-elements will be inserted into the xsp document. The action here has to be a subclass of com.o2.portal.actions.AbstractXFormPortalAction. The additional parameters on lines 23-28 define:

− xmlform-id which form object identified by this id should be populated

− xmlform-model class name of Java Bean used as model

− xmlform-scope the scope of form object (request or session)

For validation of the form data, two additional parameters have to be provided:

− xmlform-validator-schema-ns value=“http://www.ascc.net/xml/schematron“ Fixed value

− xmlform-validator-schema value=“rules.xml“ XML rules filename

Actions For XMLForms processing, it is required that actions extends com.o2.portal.action.AbstractXMLFormPortalAction. These action are driven by form submit. The processing steps in case of the XMLForm action are depicted in the Fig. 4.1.3-1.

ConcreteXMLFormAction

act():Map

Form:f <<find/create>>

Model:m <<find/create>>

setValue(path, v)

setXXX(v)

perform()

Fig. 4.1.3-1. Interaction diagram for processing an form submit request case

The model, in case of ConcreteXMLFormActions is always populated by method Form.setValue(path, object). The path is later on in the view used to access model data with the means of XMLForms.

Fig. 4.1.3-2 shows form processing activity in greater detail.

52

<<abstract>> AbstractXMLFormAction

ShopAction

Form

<<interface>> FormListener

<<uses>>

<<implements>>

Violation

0..n

act(..) MyModel

<<extends>>

<<uses>>

<<uses>>

Fig. 4.1.3-2. XMLForm processing

The process model employs the following actions: - ShopingCartAction. This action is called when

http://myserver/eShop/orderprocess/cart matches the shopping cart pipeline. It set the ordered product in session manager and forbids adding more than one product in the cart. It extends the BaseAction and returns orderprocess/ShoppingCart as the next view

- OrderProcessAction. This action is called when http://myserver/eShop/orderprocess/ matches the order process pipeline. It reads the command which was sent with request. This can be: cancel form, submit form, go to the next form, go to the previous form. If form is submitted, it applies to validation logic to validate the data and if data are valid saves them in the model object. In case user wants to jump to another form, it applies to page navigation logic to check, if action is allowed. Depending on the command, it returns the next view.

In general, for all XMLForm actions, the request processing is depicted on Fig. 4.1.3-3:

Fig.4.1.3-3. Processing flow for the requests driven by HTTP links

53

View In the case of XMLForms, Cocoon XSP pages are referred to the XMLForm elements by the tags from xmlform taglib: <xsp:page language="java" xmlns:xsp="http://apache.org/xsp" xmlns:xf="http://apache.org/cocoon/xmlform/1.0"> <content> 

<xf:form id="move-wizard.form" view="cocoon-view-ShowContactInput" method="POST"> 

<xf:textbox ref="/customerData/emailAddress" name="EmailAddress"> <xf:caption>Email</xf:caption> <xf:violations class="error"/> </xf:textbox> ...  <xf:submit id="ShowContactInput"> <xf:caption>Abschicken</xf:caption> </xf:submit> </xf:form> </content> </xsp:page> Every form must be identified by attribute “id”. This id is used by XMLForm framework in order to find corresponding form object to be populated with requested data. Form Validation

On processing of AbstractXFormPortalAction.act(..) the data is getting validated against the rules defined in rules.xml. Violations are stored in a List accessible through − Form.getViolations(). It is used mainly in actions − <xf:violations>. On xmlform-transformation converted in a sequence of

<xf:violation>msg</xf:violation> elements. <xf:violations> element is context sensitive in a sense that it matters what parent xf-element is validated against the rules.

In rules.xml file, validation is controlled by „phases“. Phases identify which rules are to be applied for validation in particular form view. Views correspond to phases and in turn phases control rules.

54

<schema ns=http://xml.apache.cocoon/xmlform xmlns="http://www.ascc.net/xml/schematron"> <title>Schema for the XML Form example</title> <phase id="userIdentity"> <p>For user identity information.</p> <active pattern="user"/> </phase> <phase id="deployment"> <p>For deployment info page.</p> <active pattern="dep" /> </phase> <phase id="confirm"> <p>For final total validation and tracking some tricky problems.</p> <active pattern="user" /> <active pattern="dep" /> <active pattern="sys" /> </phase> <pattern name="User Info Validation Pattern" id="user"> <rule context="/firstName"> <assert test="string-length(.) > 3">First name <anametag/> <wrapper>should</wrapper> be at least 4 characters.</assert> <assert test="string-length(.) < 20">First name should be less than 20 characters.</assert> </rule> <rule context="/lastName"> <assert test="string-length(.) > 3">Last name should be at least 4 characters.</assert> <assert test="string-length(.) < 20">Last name should be less than 20 characters.</assert> </rule> <rule context="/email"> <assert test="contains( string(.),'@')">Email format is invalid.</assert> </rule> <rule context="/age"> <assert test="number() > 0 and number(.) < 200">Age should be a reasonably big positive number.</assert> </rule> </pattern> <pattern name="Deployment Information Validation Pattern" id="dep"> <rule context="/number"> <assert test="number() > 0">The number of deployments must be non-negative ( hopefully positive :-> ) .</assert> </rule> <rule context="/">

<assert test="not(string(publish) = 'true') or (starts-with(liveUrl, 'http://') and contains( string(liveUrl),'.') ) "> The URL of the published site is invalid.</assert>

</rule> </pattern> <pattern name="System Information Validation Pattern" id="sys"> <rule context="/system/@ram"> <assert test="number() > 0">The RAM value should be a positive number, denoting the memory in MB (e.g. 128, 512, etc.).</assert> </rule> </pattern> </schema>

view from xf:form element

Fig. 4.1.3-6. Validation rules declaration

4.1.4. Homezone Check Module This module consists of only one form and is done using XMLForm framework. Its implementation is similar with the implementation of Ordering Process module.

4.1.5. Error Handling With the current architecture there are three ways for processing exceptions and error conditions 1) The ConcreteAction catches all possible exceptions and requests an appropriate XSP

view page for rendering. Navigation highlighting enabled

a) Business exceptions should be handled that way

55

2) Exceptions are handled through the means of <map:handleErrors> within a pipeline. Navigation highlighting enabled a) Unexpected Exceptions (RuntimeExceptions, RemoteExceptions,...)

3) Exceptions are handled outside pipelines in map:handleErrors. Navigation highlighting disabled, fallback to Start-Topic

a) Session expired, Authorization b) Exceptions thrown outside the scope of actions (SAXException, exceptions in XSP)

4.2. Online Shop prototype implementation using Apache Struts

4.2.1. Navigation Scheme Page flow is defined as depicted on the Fig. 4.2.1-1:

Fig.4.2.1-1. Online Shop Navigation scheme in Cocoon

The application should be deployed in Tomcat. A user can reach the application by typing http://localhost:{port_number}/eshop-struts. Web.xml configuration file contains instructions to make index.html a welcome page. <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> The index page redirects to start page of Online Shop, which presents a teaser and a number of top mobile phones. By clicking on the picture of a phone, a user is directed to the page with the detailed information on the chosen phone.

If the user decides to order the phone, he can click on button Bestellen. The phone will be added to the shopping cart of the user, which can be seen in left upper corner of the page, where a symbol of the shopping cart is depicted. There one can see the number of items in the cart and the total cost of the order. By adding an item into the basket, user stays on the same page.

The user can go to the shopping cart page by clicking the shopping cart depiction in the left upper corner. There one can see all chosen items with detailed information. It is possible to change the quantity of the ordered item. The user should enter the number and press Update. The number of items is changed and the total price is re-calculated. In order to delete an item, one can enter 0 into update field and press Update.

56

4.2.2. Controller In Struts, the Controller is implemented by the ActionServlet class. It should be declared in the deployment descriptor: <servlet> <servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> </servlet> Request URI should be mapped to this servlet. It is done by the declaration in the deployment descriptor, that all URI which match pattern *.do are to be taken by Struts servlet: <servlet-mapping> <servlet-name>action</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping> In this case request URI will have the following form: http://myserver/mycontext/action_Name.do In Fig. 4.2.1-1 URIs for each page of the Online Shop prototype are depicted. In fact, the processing of the incoming requests occurs in the RequestProcessor to which ActionServlet delegates all the input requests. The RequestProcessor examines the request URI for an action identifier, creates a request handler instance using the information in the ActionMapping configuration object, and calls the requesthandler.execute() method. The execute() method of the request handler is responsible for interacting with the application model. Depending on the outcome, the request handler returns an ActionForward configuration object. The Fig. 4.2.2-1 illustrates the interaction within Struts framework:

Fig. 4.2.2-1. Struts component interaction

4.2.3. Struts Configuration File Action Mapping. Mapping between the servlet path in the request URI and an appropriate request handler is specified in struts-config.xml file. The following declaration is used for creating ActionMapping configuration object, which is the runtime representation of the <action> element:

HttpServlet <<front controller>> org.apache.struts.action.ActionServlet

ForwardConfig org.apache.struts.action.ActionForward

<<dispatcher>> org.apache.struts.action.RequestProcessor

Serializable <<view helper>> org.apache.struts.action.ActionForm

<<request handler>> org.apache.struts.action.Action

ActionConfig org.apache.struts.action.ActionMapping

57

<action-mappings type="org.apache.struts.action.ActionMapping"> <action path="/navigateAction"

type="com.o2.portal.common.navigateAction"> <forward name="product" path="/product.jsp"/> <forward name="startAction" path="/startAction.do"/> </action> <action name="CheckoutForm" path="/checkout" scope="request" type="com.o2.portal.common.CheckoutAction" validate="false"> <forward name="warenkorb" path="/warenkorb.jsp"/> </action> <action path="/startAction" scope="session" type="com.o2.portal.common.startAction"> <forward name="index" path="/start.jsp"/> </action> .. </action-mapping> The attributes in this declaration are: path The context relative path in the HTTP request that is used for identifying this action mapping. type Class name that will be used for creating an instance of the request handler for handling this request. name The logical name of a Java Bean, also called a form-bean that will be used to hold form data. The form-bean will be saved in the specified scope using this name. scope Request or session scope for saving the form-bean. ActionForward. These objects have a unique identifier to enable their lookup based on meaningful names like “success”, “warenkorb” etc. ActionForwards have the forwarding URL path and are used by request handlers to identify the next view. These objects are created from the <forward> elements in struts configuration file. Global <forward> elements are used for declaring the destinations common within the application. Online Shop prototype has two global forwards, for the forwarding a user to the start page and the error forward for handling errors occurred. <global-forwards type="org.apache.struts.action.ActionForward"> <forward name="start" path="/startAction.do"/> <forward name="error" path="/error.jsp"/> </global-forwards> Actions. A subclass of Action is also called request handler. It is created specific for every request. The base Action class provides common functions for accessing framework-related resources and methods for saving errors detected by the execute(…) method of its subclass. The execute(…) method of a request handler should contain control flow for dealing with request parameters and the associated ActionForm, it should encapsulate model interaction semantics, and it should provide the next view based on the outcome of model operations.

58

The Online Shop prototype uses the following Actions:

Action Name Model Forward Description

startAction NavigateAction SeManager

product

The Action is invoked by clicking on a category on the main menu. If start page is requested, redirects to start page. If category of a certain producer is requested, populates the HandyByProducer attribute in SeManager and forwards to Handy category page

StartAction SeManager index The Action is invoked on the first call of start page. It initializes the session and populates teaser and tops of SeManger with the data from Configurator

ProductAction SeManager productDetail The Action is invoked when a user requests product detail page. Populates the product attribute in SeManger and forwards to product Details page with chosen product

AddToCartAction SeManager productDetail The Action is invoked when a user clicks on the button bestellen on product detail page. It Updates ShoppingCart attribute in SeManger and forwards to the same page.

CheckoutAction SeManager warenkorb The Action is invoked when a user clicks on shopping cart link or button update in shopping cart item. It forwards to shopping cart page. If update is requested, update the number of items in the shopping cart.

editRegistration SeManager register The Action is invoked when a user clicks bestellen button on shopping cart action. Populate the user attribute in SeManager from RegistrationForm, forwards to user details form page

warenkorb

homezone

saveRegistration SeManager

register

The Action is invoked when a user submits form with user details. It saves the data from form into the model and forwards to shopping cart, if action is cancelled; homezone, if submitted data are validated; back to user detail form, if data are not validated

59

In Struts-Studio notation, the action mapping scheme for the prototype is depicted on Fig. 4.2.3-1

Fig. 4.2.3-1. Action mapping scheme in Struts Studio presentation

4.2.4. Forms Handling In the code example from struts configuration file, the path attribute maps to the action attribute of the HTML <form> element. <action name="CheckoutForm" path="/checkout" scope="request" type="com.o2.portal.common.CheckoutAction" validate="false"> <forward name="warenkorb" path="/warenkorb.jsp"/> </action>

60

Attribute name declaratively specifies a Java Bean with properties to hold the parameters from the HTTP request. These Java Beans extend ActionForm class. The instances of ActionForm classes are stored in the specified scope. The ActionForm sub-classes are declared in the struts-config.xml file by using <form-beans> tag: <form-beans type="org.apache.struts.action.ActionFormBean"> <form-bean name="registrationForm" type="com.o2.portal.registration.RegistrationForm"/> <form-bean name="CheckoutForm" type="com.o2.portal.common.CheckoutForm"/> </form-beans> Dynamic URL generation for action attribute using the custom FormTag <html:form action="/saveRegistration?type=siemens"> will create an HTML <form> tag with the action attribute containing the following URL: <form action="/contextPath/saveRegistration.do?type=siemens"/> The FormTag calls the org.apache.struts.util.RequestUtils.createActionForm method, which will search for an ActionFormBean configuration object with a name that matches the name specified on the corresponding <action> element. A new instance of the ActionForm is created using the type attribute of the <form-bean> element; a new instance is created when the ActionForm instance is not found in the specified scope, otherwise the FormTag calls the ActionForm.reset method on the existing form-bean to clear it in preparation for the form data from the next request. The scope is specified by the scope attribute in the <action> element; the new ActionForm instance or the existing reinitialized instance is saved in the specified scope using the name attribute. The ActionForm-derived objects are used for storing the parameters from a request object. An ActionForm subclass is a Java Bean with get and set methods for properties corresponding to parameters in the HttpServletRequest object. If an ActionForm object is created by the FormTag, then in the request subsequent to form rendering by the FormTag, the RequestProcessor will access the form from the specified scope; the form to be retrieved is identified by the related action mapping. The RequestProcessor will then reset the form properties, populate the form with request time parameters, and then call the validate method on the form object to perform server-side validation of user input. The validate method is called only when the validate property in the ActionMapping object is set to true; this is the default behaviour. The result of validation could be an ActionErrors object, explained in the section “Error Handling,” which is used by org.apache.struts.taglib.html.ErrorsTag to display the validation errors to the user. The ActionForm can also be used for storing intermediate model state, which is subsequently referenced by a view (a JSP) for presenting to the user. The ActionForm objects are found in the specified scope using the name attribute specified in the <action> element; when a form-bean is found by the RequestProcessor, it is passed to the request handler’s execute() method. By default, all forms are saved in the session scope. The existence of form objects in the session beyond their usefulness could result in wasted memory, so that the request handlers must track the life cycle of form objects stored in the session. Prototype implementation of Online Shop contains two ActionForms:

- com.o2.portal.common.CheckoutForm. It is used for the shopping cart for changing the quantity of ordered products.

61

- com.o2.portal.registration.RegistrationForm. This ActionForm is used for handling two forms in order process, User Details Form and Homezonecheck Form. It is possible, if in the declaration of the action mapping the input JSP-page is specified.

<action input="/register.jsp" name="registrationForm" path="/saveRegistration" scope="session"

type="com.o2.portal.registration.SaveRegistrationAction" validate="true">

<forward name="warenkorb" path="/warenkorb.jsp"/> <forward name="homezone" path="/homezone.jsp"/> </action> <action input="/homezone.jsp" name="registrationForm" path="/saveHomezone" scope="session" type="com.o2.portal.registration.SaveHomezoneAction"

validate="true"> <forward name="warenkorb" path="/warenkorb.jsp"/> <forward name="last" path="/lastcheck.jsp"/> </action>

4.2.5. Form Data Validation As it was already mentioned, Struts provides the facility for the input data validation. There are two ways of the validation available. First one is the Struts embedded facility and the second one is the Validator framework, which is used as a plug-in. Both validation possibilities are implemented in Online Shop prototype for the investigation reasons. In both case the Registration form is validated. To employ the embedded Struts validation feature, RegistrationForm class which extends ActionForm, overrides the following method: validate(ActionMapping mapping, HttpServletRequest request); RegistrationForm validate method is performed for the two forms, User Details form and Homezonecheck form. The following snippet shows the validate method in RegistrationForm: public ActionErrors validate(ActionMapping mapping, HttpServletRequest request) { ActionErrors errors = new ActionErrors(); if (action.equals("homezone")){ //initialization of the parameters if ((street == null) || (street.length() < 1)) { errors.add("userAddress.street", new ActionError("error.street.required"));} if ((street != null) &&(street.length() > 30)) { errors.add("userAddress.street", new ActionError("error.street.too.long"));} if ((email != null) && (email.length() > 0)) { int atSign = email.indexOf("@"); if ((atSign < 1) || (atSign >= (email.length() – 1))) { errors.add("email", new ActionError("error.email.format", email)); } ... }

62

else{ if ((hstreet == null) || (hstreet.length() < 1)) { errors.add("homezoneAddress.street",new ActionError("error.street.required")); } if ((hstreet != null)&&(hstreet.length() > 30)){ errors.add("homezoneAddress.street", new ActionError("error.street.too.long"));} ... } After the bean properties have been populated and before the action class’s perform() method starts, the controller servlet calls the validate method. The following scenarios for the validation process are possible:

- The necessary validation is performed and no errors are found. In this case, ActionErrors instance of zero-length or null is returned. The perform() method of the appropriate Action class is called.

- The necessary validation is performed and an error or errors are found. In this case, ActionErrors instance that contains ActionError classes with the error message keys is returned. Error message key is used to display the error reason. ActionErrors array is stored as a request attribute which is accessible by <html:errors> tag. Then controller servlet forwards the control back to the input form, which is identified in the input property in the current ActionMapping.

The second way to validate forms in Struts is to use Validator Framework. This framework was developed for Struts and first introduced in Struts 1.1. The goal of the Validator development was to reduce the redundancy and routine of the previous validation method. Validator framework is very functional and reduces the programmer workload. It is easy to use, when it is already installed and set up. To configure the Validator, the following steps are done:

1. In struts-config.xml, ValidatorPlugin is declared: <plug-in className="org.apache.struts.validator.ValidatorPlugIn"> <set-property property="pathnames" value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/> </plug-in> 2. Set up the configuration file validator-rules.xml. The following snippet shows the

definition of the two of the validators for Online Shop: <form-validation> <global> <validator name="required" classname="org.apache.struts.validator.FieldChecks" method="validateRequired" methodParams="java.lang.Object, org.apache.commons.validator.ValidatorAction, org.apache.commons.validator.Field, org.apache.struts.action.ActionErrors, javax.servlet.http.HttpServletRequest" msg="errors.required"> <validator name="minlength" classname="org.apache.struts.validator.FieldChecks" method="validateMinLength" methodParams="java.lang.Object,

63

org.apache.commons.validator.ValidatorAction, org.apache.commons.validator.Field, org.apache.struts.action.ActionErrors, javax.servlet.http.HttpServletRequest" depends="required" msg="errors.minlength"> ... The attributes of validator element provide the information of the class and the method to be invoked. For example, in the minlength validator, the method validateMinLength() of the class org.apache.struts.validator.FieldChecks will be called. Attribute depends shows the dependency between validators. When minlengh validator will be invoked, the required validator will be called first. Msg attribute defines a key from a resource bundle to generate an error message. The example of the message in the ApplicationResource.property file for maxlength validator: errors.minlength={0} can not be less than {1} characters. The corresponding keys to be inserted in {0}, {1} are given in validation.xml configuration file. In the validation-rules.xml file for Online Shop, the validator element contains javascript element that defines the JavaScript function to be executed on the client side. 3. Configuration file validation.xml. This configuration files is used to connect

validators defined in validation-rules.xml file with ActionForms. <formset> <form name="registerForm"> <field property="register.user.firstName" depends="required,mask"> <arg0 key="First Name"/> <var> <var-name>mask</var-name> <var-value>^[a-zA-Z]*$</var-value> </var> </field> <field property="register.user.lastName" depends="required,mask"> <arg0 key="Last Name" resource="false"/> <var> <var-name>mask</var-name> <var-value>^[a-zA-Z]*$</var-value> </var> </field> </form> </formset> Attribute name of the form element corresponds to the name of the ActionForm defined in the Struts configuration file. Attribute property of the field element defines the input field to be validated using the XPath syntax. Attribute key of the arg0 element defines the property to be inserted into the message key in resource bundle. For example, validator required is bundled with errors.required={0} is required key in ApplicationRecource.property file. If validation of the field register.user.firstName is failed, First Name is required message will be shown.

64

4. RegistrationForm extends org.apache.struts.validator.ValidatorForm Once these for steps are done and the Validator framework is configured, it is ease to maintain the validation further. If any validation rules or logic should be changed, no application source should be modified.

4.2.5. View The look and feel of Online Shop prototype implemented in Struts is constructed based on the standard capabilities of JSP and Struts custom tag libraries:

- struts-bean - struts-html - struts-logic

Struts Bean Tag Library contains tags for accessing beans and their properties and also for the definition of new beans. As example, one can see start.jsp. <%@ taglib uri="/struts-bean" prefix="bean" %> ... <html:html locale="true"> <head> <title><bean:message key="index.title"/></title> <html:base/> </head> <bean:define id="sessionManager" name="sessionManager" scope="session"/> <bean:define id="teaser" name="sessionManager" property="teaser"/>  <a name="mobileImageLink" href="productAction.do? name=<bean:write name="teaser" property="name"/> &type=<bean:write name="teaser" property="type"/>"> <logic:iterate id="picture" name="teaser" property="pictures"> <logic:match name="picture" property="key" value="small"> <img src="images/<bean:write name="picture" property="value"/>" alt="" border="0" height="130" width="93" name="mobileImage"/> </logic:match> </logic:iterate> The bean tags used here are:

- message. Render an internationalized message string. - define. Define a scripting variable based on the value(s) of the specified bean property. - write. Render the value of the specified bean property to the current JSP Writer.

Struts Logic Tag Library contains tags for the presentation logic manipulation. In the same example <logic:iterate id="picture" name="teaser" property="pictures"> <logic:match name="picture" property="key" value="small"> <img src="images/<bean:write name="picture" property="value"/>" alt="" border="0" height="130" width="93" name="mobileImage"/> </logic:match> </logic:iterate> the following tags are used:

- iterate. Repeat the nested body content of this tag over a specified collection.

65

- match. Evaluate the nested body content of this tag if the specified value is an appropriate substring of the requested variable.

The Logic Tag Library contains also empty, equal, graterThan, notMatch etc. tags. Struts HTML Tag library is used to create Struts input forms. The example can be seen in register.jsp: <html:errors/> <html:form action="/saveRegistration.do"> <html:hidden property="action" value="homezone"/> <!—HTML code --> <html:select property="user.title" size="1">

<html:options collection="titleArrayKey" property="value" labelProperty="label"/>

</html:select> <!—HTML code --> <html:text property="user.firstName" size="15" maxlength="25"/> <html:text property="user.lastName" size="17" maxlength="25"/> ...

<html:submit property="action"> Submit </html:submit> </html:form> The following tags are used here:

- errors. Conditionally display a set of accumulated error messages. - form. Define an input form. - hidden. Render a hidden field. - select. Render a select element. - text. Render a text input field. - submit. Render a submit button.

Other tags can be found in the HTML Tag Library, such as, checkbox, radio, button, image etc.

4.3. Prototyping Implementation of Online Shop with Velocity As it was said in the section 2.3.3, Velocity is focused on the data presentation. That means that it can not be used for the complete application development. Therefore for the Velocity prototype, the business logic developed using Struts framework was used. For the view layer, the functionality done previously in JSP was implemented in Velocity. As Struts Tag Libraries, Velocity is used to solve the main problems on the view layer:

- Access beans and their properties, access the resource bundle - Manipulation of the presentation logic - Creating the input forms - Import of the local files

4.3.1. Access Beans and Their Properties To access data contained in corresponding Java Beans, the VTL references of the property type were used. The properties of a Java Beans can be referenced by XPath-like statement. As an example, one can use start.vm file.

66

#set ($teaser=$sessionManager.teaser) <!—HTML code --> <a name="mobileImageLink"

href="productAction.do?name=${teaser.name}&type=${teaser.type}"> <img src="images/${teaser.pictures.get("small")}" alt="" border="0"

height="130" width="93" name="mobileImage"/> <td nowrap=""><div class="otTeaserHead"><span/> $teaser.tariffs.get("Genion Power SMS") </div></td> … Model object of Online Shop defines class sessionManager which has Handy class as a property that is presented as a teaser on the start page. In this case, access to the Handy properties for inserting them into the HTML template is required. It could be done, for example, with the following statement: $ sessionManager.teaser.name To make the statement shorter the directive #set was used. It assigns the instance of class Handy returned by sessionManager.getTeaser() to the variable teaser. Afterwards, it is possible to access its properties via this variable. It is important to mention, that Handy properties name and type are of the simple type, whereas pictures and tariffs are indexed. For example, teaser.getPictures() method returns Map instance. To access its element method get(..) is used. ${teaser.pictures.get("small")

4.3.2. Manipulation of the Presentation Logic In order to organize loops and use condition, the VTL #foreach and #if directives were used. As an example one can see navigation.vm file. #if($topic.type==$current)

<a href="navigateAction.do?type=${topic.type}&link=${topic.link}" class="navsub_hi">$topic.text</a>

#else <a href="navigateAction.do?type=${topic.type}&link=${topic.link}"

class="navsub">$topic.text</a> #end #foreach($subtopic in $topic.subTopics) <tr class="nav_sub2"> <td><img src="images/blank.gif" width="16" height="17"/></td> <td width="12" valign="top"> <img width="6" height="11" vspace="1" src="images/i.link.sub.gif"> </td> <td width="144"> <img src="images/blank.gif" width="1" height="1"/><br/> <a href="navigateAction.do?type=${subtopic.type}&link=${subtopic.link}" class="navsub_hi">$subtopic.text</a> ... #end

67

If-condition is used here in order to decide whether to highlight the menu topic being rendered or not. If this topic is current, meaning that a user is currently viewing the content of the topic, it should be highlighted. Foreach-loop is applied to the set of subtopics for each topic for rendering.

4.3.3. Creating Input Forms Input forms are created in the Velocity template by using HTML syntax. The connection of the forms with the corresponding bean property is done by VTL in the way described before. As an example, one can view the register.vm file. <form name="register" action="saveRegistration.do"> <input type="hidden" name="action" value="homezone" /> <td width="120">Title</td> <select name="user.title" value="$!{user.title}" size="1"> <option value="">$msg.get("selectOne")</option> <option value="mr">$msg.get("mr")</option> <option value="mrs">$msg.get("mrs")</option> <option value="ms">$msg.get("miss")</option> <option value="dr">$msg.get("dr")</option> </select> <td width="120">Name</td> <input type="text" name="user.firstName" value="$!user.firstName"

size="15" maxlength="25"/> <input type="text" name="user.lastName" value="$!user.lastName" size="17"

maxlength="25"/> ... <td>

<input type="submit" name="Submit" value="$msg.get("submit")"> </td> </form>

4.3.4. Resource Bundle For the localization purposes or for the managing the static text, Struts uses so called Resource bundle, file that stores the certain texts mapped to the message keys. In order to reach these messages through VTL, $msg.get(key) is used.

4.3.5. Import of the Local Files Every page of the Online Shop consists of three parts. The upper part contains the static image and the title, the left part - navigation menu and the right part - content. These three parts are done in the separate files and are assembled with the help of the VLT directives #import and #parse. <table border="0" cellspacing="0" cellpadding="0" align="center"

width="780"> <tr> <td><img src="images/header-o2-logo-bild,property=OnlineBild.gif"/>

</td> <td><img src="images/blank.gif" width="1" height="1"/></td> <td>#include("header.html")</td> <td><img src="images/blank.gif" width="1" height="1"/></td> </tr>

68

<tr valign="top"> <td class="myo2on_nav_sub">#parse("navigation.vm")

<img src="images/blank.gif" width="194" height="10"/> </td> <td><img src="images/blank.gif" width="1" height="1"/></td> ... It is important to notice, that static html-file is attached with the directive #import. The part that contains the dynamic data and is done as velocity template is attached with the directive #parce.

4.4. Prototyping Implementation of Online Shop with JPublish As it was said in the section 2.3.4, JPublish is an event-based framework, which separates the role of application developers by separating the elements of the application. Every page of the Online Shop prototype is supported by at least three elements: template, content, meta-data (so called pages).

4.4.1. Template Online Shop prototype employs only one template which is used for every page in the application. By default, the template should be stored in the template folder. Basic.html template aggregates three parts of a page: header.html, menu.html and the current content page. Since JPublish uses Velocity as a View Renderer, the template assembles these three parts by means of VTL: <tr> ... <td>#parse("repository:fs_repository://header/header.html")</td> </tr> <tr valign="top"> <td class="myo2on_nav_sub">

#parse("repository:fs_repository://navigation/menu.html") <img src="images/blank.gif" width="194" height="10"/></td> <td>  $fs_repository.get($page.Path)  fs_repository is the reference to the File System Repository, which will be discussed later.

4.4.2. Content Here, content files are html files that have references to the dynamic data. They contain html code for the data layout and VLT references to the Java Beans’ properties.

4.4.3. Page Page is an XML file that defines the meta-data for the content presentation. The default FileSystemPageManager obtains Page object by locating XML configuration file with the same name as content file in local system. The page configuration can describe a number of meta-properties. They are accessible by page.getProperty(name) or page.getProperty(name, locale) methods. For the Online Shop prototype, mostly title

69

property is used. Page definition can specify the template to be used and, what is more important, the page actions that are invoked every time the page is requested. The following snippet is the definition of handy page: <?xml version="1.0" encoding="UTF-8"?> <page> <property name="title">++++JPublish Eshop Handy Detail++++</property> <page-action name="ShowHandyDetails"/> </page>

4.4.4. Actions Actions provide the application business logic. They can be done in various scripting languages. For the Online Shop, the programming language is Java. JPublish provides the possibility to bundle actions to the application components or events. As one can see, path and page actions are mostly used, what led to the simple, but less flexible application structure.

Action Type Bundle Description LoadStartPage path path=”/*” Load the product and

navigation configurations and save it in the session

NavigationAction page handylist.html Getting the list of available products for the requested producer, defines which menu topic should be highlighted

ShowHandyDetails page handy.html Getting the chosen product details from the configuration file

AddToCart page shoppingCart.html Save the chosen product into as the session property. If requested, change the quantity of the ordered product.

UserDetailsAction page userDetails.html Save data from the submitted form into Java Bean

HomezonecheckAction page fake_for_forms.html Fetch the data for homezone address from the submitted form

BeforeHomezoneAction page homezonecheck.html Set user information into the context

LastAction page last.html Save the order and delete the shopping cart data

This actions’ structure is quite redundant, since action mostly connected to the page. Some pages are requested from the different places in the application and, depending on it, different actions should be performed. In this case, some actions need to check where they are called from.

70

4.4.5. Configuration file JPublish is a modular framework. Some of the modules were already mentioned: VelocityViewRenderer, FileSystemRepository, FileSystemPageManager. In order to tell the JPublish framework that these modules will be used, it is necessary to declare them in the configuration file jpublish.xml, which reside in the folder WEB-INF/: <jpublish> <page-manager classname="org.jpublish.page.xml.XMLPageManager"/> <view-renderer classname="org.jpublish.view.velocity.VelocityViewRenderer"> <velocity-properties>WEB-INF/velocity.properties</velocity-properties> </view-renderer> <repository name="fs_repository" classname="org.jpublish.repository.filesystem.FileSystemRepository"> <root>content</root> </repository> <repository name="xml_repository" classname="org.jpublish.repository.filesystem.FileSystemRepository"> <root>xml</root> <write-allowed>true</write-allowed> </repository> ... Every action that will be used in the application is also to be declared in the jpublish.xml configuration file: <define-action name="LoadStartPage" classname="com.o2.portal.actions.LoadStartPage"/> <define-action name="ShowHandyDetails" classname="com.o2.portal.actions.ShowHandyDetails"/> <define-action name="AddToCart" classname="com.o2.portal.actions.AddToCart"/> When an action is bundled to an element or an event, it is referenced by the name declared here. For page action it is used in <page-action> element. Path action is declared in jpublish.xml. <path-action name="LoadStartPage" path="/*"/>

4.4.6. Form Handling In order to process forms, JPublish uses FormProc library that provides API for handling and validating forms. In order to employ this module the following steps are done:

1. FormProc library is declared in JPublish configuration file: <module classname="org.jpublish.module.formproc.FormProcModule"> <config>WEB-INF/formproc.xml</config> </module> 2. This declaration defines the location of FormProc’s own configuration file

formproc.xml. This file specifies the validators to be used by mapping the validator types to their implementation classes:

<validator-map type="expression"

classname="org.formproc.validation.REValidator"/>

71

<validator-map type="rule" classname="org.formproc.validation.RuleValidator"/> <validator-map type="group" classname="org.formproc.validation.ValidatorGroup"/> Formproc.xml file contains also the mapping of every form that is used in the application to their declaration files: <form name="update-cart" file="update-cart-form.xml" monitor="true"/> <form name="user-details" file="user-details-form.xml" monitor="true"/> <form name="homezonecheck" file="homezonecheck-form.xml" monitor="true"/>

3. Every form is declared in its own XML document. Te following snippet is the declaration of update-cart form used in the shopping cart: <form> <name>update-cart</name> <element name="quantity"> <validator type="expression"> <pattern>[1-9][0-9]*</pattern> <error lang="en">Quantity must be 1 or greater</error> </validator> <message lang="en">Required</message> </element> <element name="titleId"/> </form> Here, each form input field is defined by element <element>, where attribute name corresponds to the field name in HTML form. Child element validator defines the rules for the field validation and the message to be shown if the validation fails.

4. A form should be initialized before being presented. FormProc action formproc.initForm is used for this purpose. Normally, this action is bundled to the page which will present the form. Update-cart form is initialized in shoppingCart.xml file:

<page-action name="formproc.initForm"> <form>update-cart</form> <target scope="session">UpdateForm</target> </page-action> initForm action initializes the FormProc Form object and sets the target object to the value of session.getAttribute("UpdateForm"). After the form being submitted, it should be processed by formproc.processForm page action.

<page-action name="formproc.processForm">

<redirect-fail>shoppingCart</redirect-fail> <redirect-pass>shoppingCart</redirect-pass> </page-action> In the HTML form presentation the element <input type="hidden" name="formproc.formname" value="update-cart"> is required. Using this parameter processForm action finds the definition of the current form and applies the validation

72

rules for the corresponding form fields. If validation fails, it uses <redirect-fail> element to define the page to presented, otherwise the user is prompted to the page defined in the element <redirect-pass>. 5. The actual presentation is done by means of HTML and Velocity Template Language. As it was mentioned already, the required element of every form is <input type="hidden" name="formproc.formname" value="{form_name}">, where form_name should correspond to the name declared in formproc.xml configuration file.

4.4.8. Application Architecture The final architecture on the Online Shop prototype is depicted in the following figures (Fig. 4.4.7-1. – 4.4.7-3):

Fig 4.4.7-1. Online Shop product presentation module

index.html

index.xml

handy.html

handy.xml ShowHandyDetails()

handylist.html

handylist.xml NavigationAction()

LoadStartPage()

/handy.html?name= &type=

/handy.html?name= &type=

/handylist.html? type=

ShoppingCart.html?name= & type=

73

Fig. 4.4.7-2. Online Shop Shopping Cart module

Fig. 4.4.7-3. Online Shop Order Process module

UserDetails.html

fake.html

UserDetails.xml UserDetailsAction() formproc.InitForm() form update-details target user

homezonecheck-form.xml

redirect-fail

fromproc.xml

fake_for_forms.xml HomezoneAction() formproc.processForm()

redirect-pass

form submit

validation rules

UserDetails.html

homezonecheck.html

homezonecheck.xml BeforeHomezonecheckAction() formproc.InitForm() form homezonecheck target user

update-details-form.xml

ShoppingCart.html

fake.html

ShoppingCart.xml AddToCart() formproc.InitForm() form update-cart target UpdateForm

update-cart-form.xml

redirect-fail

ShoppingCart.html?name= & type=

fromproc.xml

fake.xml formproc.processForm()

redirect-pass

form submit

validation rules

UserDetails.html

74

4.5. Experience of the Application Development with JavaServer Faces In the implementation phase of the research, there was an attempt to implement the described use cases of the Online Shop using the JavaServer Faces. Currently [august, 2003] JSF is available in Early Access 4 version. Because of the version instability and the number of bugs, the Online Shop prototype in JSF is not done accordingly to the specification and does not work properly. The following drawbacks refer only to EA 4 and most probably will be eliminated in the coming release.

- the work of navigation handlers is sensitive to whether HTML code in the JSP’s is well-formed. They worked perfectly with the simple design, with more complicated design they failed.

- the navigation between the pages which require Actions to be performed, needs to be done by using a form, even though they are not covered in the application design

- the variety of the available components is not large. They still do not cover all the necessity of a web application design. Creating of the own components is complicated and far not intuitive.

- another big problem was the lack of the unique identificators for the input fields. It is impossible to iterate over the element of the panel_data component

JSF package contains two example applications implemented in JSF. They have simple structure and not complicated design, but one can get the idea about the basic concepts of JSF. Still, it is early to judge this product at least before its first release.

75

5. Framework Comparison Previous chapters give the overview of the existing web application frameworks and provide more precise view to the more outstanding ones. These frameworks were used for the test implementation of the same application. Now, in order to compare the frameworks, the comparison criteria are to be identified that can be critical for the one who makes the choice. The prototyping of a well-known eBusiness application, Online Shop, allowed identification of these issues. In spite of its relative simplicity, the Online Shop case covers the most critical issues open for consideration in web development. These issues include separation of concerns, navigation handling, session handling, form processing. This chapter analyses each of the studied frameworks in terms of the aforementioned features and as a result, the evaluation table is presented with the evaluation grades for every criteria of each framework. User Interface issues

1. Separation of the presentation and programming logic. Chapter 2 has already discussed the importance of the separation of concerns. It was said, that it is critical not only for the clear definition of the designer’s and the programmer’s tasks, but also for the further application maintenance. The clearer application tasks and application elements supported by different roles are separated, the easier it is to find and modify a given piece of the application

2. Taglibs or template language. For the presentation logic, the studies framework use either Taglibs or a template language. What is important is to see how the framework inserts the dynamic data into the static one. A developer can be interested in the range of functionalities provided, ease-to-use, availability of framework taglibs or a template language.

3. Support of the multiple client types/ output formats. It is becoming the standard requirement that a web application supports not only a user, who sits in front of his computer, but also a user with access devices such as mobile phone or a PDA.

4. I18n. In web application development two types of the internationalization are needed. One type is the internationalization of the dynamic data, the business data from EJB or a database. This information is renewed per request. There are Java libraries that provide different features for the i18n. More interesting is to compare approaches to the second type of localization – i18n for static texts.

Flow control issues These criteria are analyzed for every framework, but the evaluation grades are not given, since a framework either supports this feature or not.

1. Event handing. Event handling features in many approaches in web application development as an easy and natural way of the reaction of users’ actions. This issue addresses the question how a framework defines an “event” and which mechanism handles it.

2. MVC/Model 2. The implementation of MVC Model 2 is a guarantee for the separation of concerns. This issue discusses whether a framework supports the MVC concept and if so, how it is done.

3. Workflow. This issue addresses the problem to define an application flow on a meta-level. That means the possibility to specify a certain application aspect for the certain application state. This can prevent a user to submit a form twice, enter or leave the predefined action sequence in the middle.

76

Server-side issues

1. Form mapping and validation. This issue addresses the question how the data submitted by a user can be retrieved, manually for an HTTP request or it is available in some structure, and how these data can be validated

2. Error handling. As soon as the validation of a form fails, the problem of how to handle errors occurs. A developer may want to redisplay the same form with already entered data, display the error messages and so on. How flexible is the error handling in a framework is the point of this issue.

3. Component model. Many frameworks differ in their definition of the components. How a framework approaches the component concept and to which extent these components are reusable is discussed under this issue

Performance

A framework performance is measured by the throughput and the processing time. Throughput is a number of requests handled by a time unit. Processing time shows the average time spent for 1 request. The performance characteristics for every framework are measured by Apache JMeter, an Open Source product that allows simulating load on web application and measure performance. The simulation conditions are the same in every case:

- the workstation that runs Apache Tomcat 4.1.24 has the following configuration: − processor Pentium (R) 4 2.40 GHz − 512 MB RAM

- ten users - forty loops - five HTTP pages requested by a user - request are coming under Gaussian distribution with the deviation of 100 ms

In order to test the scalability, the load is increased by factor 2 and the performance change is observed.

Tools integration

Under this issue two types of tools can be discussed. Page tools are those for page designers. If they need to integrate taglibs into the page, the tool should recognize and support the tag library. Java IDEs are the tools for developers. The question is whether there are an IDE that supports framework specific features.

Others

1. Production presence. The number and the kind of the projects developed in a

particular framework gives the impression about its stability and the possibility for being applied

2. Learning curve. Very powerful framework can appear to be too difficult to be understood for the beginners. In other cases, a framework shows lack of documentation and supporting information.

3. Maintenance. Calculating the cost of an application, one should take into account not only the costs of design and development, but also the maintenance costs. The modifications may be required both of business logic layer and presentation layer. If

77

the final architecture of the application is well designed and structured, the further maintenance may require not much effort. Whether the use of a framework leads to the good design of an application is evaluated by this criterion.

Integration ease is the extremely important feature when one decides about choosing a development framework. It is not taken for the comparison just because all the frameworks being evaluated do not have particular mechanisms for integration with back-end system. This functionality is left for the developer decision and can be implemented using the available Java libraries.

5.1. Apache Cocoon This section analyses the previously described criteria for Apache Cocoon framework

5.1.1. User Interface Issues

Separation of Presentation from Programming Logic The concept of Separation of Concerns (SoC) is the base concept of Cocoon. This framework defines four aspects of the web application development: logic, content and style and a management to ensure the collaboration of the first three aspects [Cocoon userdocs, 2003]. The components responsible for the logic are those which control the pipeline flow: generators and actions. Content is stored in a collection of XML documents. Style is defined using XSL stylesheets, whereas Management is provided by the sitemap configuration file. In theory, this separation is quite clear, whereas in practice, one can see some overlapping in concerns.

- XSP technology that supports the dynamic content generation implies the introduction of procedural code into the static mark-up. That actually means that logic and content aspects are mixed. It does not introduce any difficulties for application developers, in cases where at the design phase the functionalities done by actions and XSP’s are clearly separated. The right solution would be to perform the business logic in action and to use Java code in XSP’s only for the dynamic data retrieval.

- Separation of concerns by using XML structure and style defined in XSL stylesheets does not prevent developers from using style directives inside content XML files. As an example, consider the following snippet that describes XMLForm: (this kind of solution is not recommended by Cocoon, but it does not prevent it)

<row>

<cell> <field-group caption="Vorname" caption-position="top">

<field type="text" ref="/customer/firstName" size="19"/> </field-group>

</cell> <cell> <field-group caption="Name" caption-position="top">

<field type="text" ref="/customer/name" size="19"/> </field-group>

</cell> </row> The conclusion here is that Cocoon provides the possibility to build an application with clear Separation of Concerns. In order to employ this possibility the proper and careful architectural design is a prerequisite.

78

Taglibs In Cocoon, the idea of Taglibs coming from JSP is applied to XSP. Taglibs here are the logicsheets that define a set of custom tags to be used within XSP to insert a block of code. XSP built-in taglibs provide the core functionality for XSP: embedding procedural logic in an XSP page, connection of a program expression as a Text node, dynamically building an element or an element attribute and others. There are a number of external Taglibs offered by various Cocoon developers that support working with SQL, LDAP, SMTP server. Still, XSP Tag libraries are not as rich as JSP’s one. Online Shop prototype uses BeanHelper taglib from oio.de to simplify access to Java Beans.

Support for Multiple Client Types

Cocoon is a dynamic multi-channel web publishing framework [Cocoon userdocs, 2003]. It supports various types of data sources and output formats. By using different serializers in the pipelines it is possible to transform XML data, that contain necessary content, into XML, HTML/XHTML, WML, PDF, Postscript, MS Excel, flash, plain text and other formats. Every format will need its own stylesheet for layout formatting and the corresponding serializers that are mostly prefabricated.

Internationalization

Cocoon provides a transformer for web application internationalization purpose, I18n Transformer. It should be declared in the corresponding section of the sitemap configuration file. XML file that contains data to be translated uses the special tags in i18n namespace to mark-up the text which should be substituted with a message from a corresponding dictionary. The transformer supports the following features:

- text translation - attribute translation - parameter substitution in the text being translated - data, number and currency formatting

The internationalization infrastructure for Cocoon application is quite flexible and powerful. It allows defining several message catalogues for different application elements, it does not make the sitemap heavier and does not have too much influence on the performance, since the catalogues can be cashed at the start-up.

Event Handling Cocoon does not support event handling concept. The term event is applicable only inside a pipeline for SAX events generated by the generators. But starting from Cocoon 2.0, the pipeline processing goes away from the event-driven request-time DTD interpretation and now relies on the processing chain, when all compliable elements are precompiled.

5.1.2. Flow Control Issues

MVC/Model 2 In the first Cocoon version, one can hardly see the implementation of the MVC frameworks. There was no clear separation of Model, View and Controller layers in a way that something processes an HTTP request ("Controller") and updates some kind of server state somewhere ("Model"), and then forwards control to something else which takes data out of the model and

79

creates an HTTP Response to send back to the client ("View"). That made the development of web applications that focus on the interaction with users, for example via sequence of forms difficult. Starting from Cocoon 2.0 the developers introduced the elements of MVC pattern and the first step was the integration of the XMLForm. As the Cocoon developer announced [Cocoon Wiki, 2003], “XMLForms combines the best from Jakarta Struts, XForms and Schematron”. Here, Action (controller component) creates the Form object (model component) if necessary and populates it with data based on the request parameters. Transformer (view component) takes a form descriptor document as input and fills it with data and error messages from a Form object that is referred to in the document.

Workflow Sitemap configuration file is responsible for the control flow for each request- response cycle. It connects the pipeline components in the necessary order and defines the parameters to be transferred from one component to another. But it is not possible to see the state of the system and its corresponding aspect from the pipeline definition. The view to be presented to a user is defined by actions. It is known that Cocoon developers are currently working on the advanced control flow allowing description of a web application as a state finite machine. But by now, since this information is not available, it can be said that the framework does not support this feature.

5.1.3. Server-Side Issues

Form Mapping and Validation

In the implementation of the Online Shop prototype, XMLForm framework for Cocoon was used. The experience showed the advantages of this framework: its lightweight mark-up and clear separation between form definition and its layout. XMLForms uses a simple principle for the content production. A form template is filled with the values from the data model and an instantiated form is transformed using stylesheets (default XMLForm or a custom one) to the target format. Form fields reference the data model by XPath, so that the data model can be of an arbitrary complexity. It was easy to set up XMLForms. It required a single definition file, data model and XPath to connect them. Problems arise when a field formats, different from String, such as date or float, is required or booleans, like check boxes and radio buttons, are to be handled. In these cases XMLForms shows limitations reflect lack of formatting functions in XPath. After the submission of a form, XMLForm parses the request parameters and sets their value into the data model using XPath. It filters the parameters that are not part of the data model. The data input is validated using the Schematron that allows inter-field controls, again using the XPath. The validation rules are defined in the separate configuration file that simplifies the maintenance of forms. In validation, XMLForm shows its use simplicity, but gives again strong limitations in parsing the dates or locale-dependent data. XMLForms had a lot of success because it filled the big gap in Cocoon for the forms handling. But the more complex a case is, the more limitations this framework shows. These limitations were taken into account in the new form handling framework, Woody, that is being developed now.

Error Handling

80

In Cocoon, the validation Transformer fills on the form descriptor with the data that refers to a field and messages, if validation fails. The errors are stored in Violations object which is accessible in FormAction through getForm().getViolations(). On the screen rendering, the message tags are substituted with a corresponding message, or for the internationalization purpose the message can be fetched from the dictionary defined for the current locale.

Component Models/ Reuse It is out of question, that Cocoon is highly modular. It is distributed with many prefabricated components: the list of the all available generators, transformers and serializers is very big. Since these components either produce or consume SAX events, they can be chained together to organize a SAX processing pipeline. The task of creating a pipeline to process a certain request adds up to plugging in the necessary components. Web developers are not limited to the available component set. It is possible to create an own application- specific component by extending the existing component or by implementing the appropriate component interface. These components can be re-used in the next applications.

5.1.4. Other Issues

Performance/Scalability The results of the simulation showed quite poor performance of Cocoon: URL Count

Loops Average Proc.Time

Min Proc. Time

Max Proc. Time

Error % Rate

HTTP request

400 12613 111 38275 0.00% 45.9/min

Fig. 5.1.11-1. shows the performance dynamic over time. Cocoon developers stated that starting from the version 1.1, the framework increased its cashing capability, and hence increased the performance even with default cashing. The pipeline processing complexity counterbalances these efforts. Still, it is possible and even required to tune the cashing explicitly in order to increase the performance Cocoon shows good scalability. Under the load increased twice, it decreases throughput by factor 2.003, showing the same overall performance within statistical error.

81

Fig. 5.1.11-1. Apache Cocoon application performance test results

Tools Integration

It is quite difficult to choose a development tool for Cocoon, since it combines a number of different technologies: XSL, XML, XSP and Java. No IDE was found created specifically for Cocoon projects. XML/ XSL. On the implementation of the Online Shop prototype, UltraEdit- 32 Professional Text/HEX Editor was used. It is not the best choice, since its only advantage is proper highlighting the mark-up. The better choice would be XML Spy from Altova that provides a great support both in XML editing and validation (also against the defined Schema/DTD) and XSL editing and transformation. Particularly for XSL developers, Visual XSL Studio from Xtensible Technologies, Inc. is a good support. It specifically addresses the problem of building the presentation layer for XML based data. It provides a WYSIWYG drag-and-drop editor for visually laying-out the presentation of the data for XML documents. XML Spy and Visual XSL Studio are proprietor tools; the trial versions are available online. IDE Tools. Most of the Cocoon programmers use the well-known IDE, such as Eclipse or IntelliJ. These tools are quite powerful in support of Java programming. The problem arises when it goes about creation and debugging XSP pages. The main complain of the programmers that develop their project in Cocoon, is the lack of XSP precompiling and debugging possibilities. As soon as an error occurs in XSP, it is very difficult to localize it.

82

Production Presence Cocoon is being developed for already 5 years. By now its production presence looks quite good. For Cocoon 1.0, there are about 30 web-sites known by the framework developers, whereas for Cocoon 2.0, there are 21 listed. For the production presence analysis, only the last ones were chosen. From 21 web sites, 95 % are commercial portals. About 70 % out of them are information/ news portals (mostly based on the advertising and community business models), 30% are those with focus on the business – customer interaction (based on the merchant or manufacturer business models). It is important to note that with Cocoon 2.x the number of business applications developed with this framework has grown up. Further growth is expected, since Cocoon develops to the direction of MVC approach, elaborating on the form handling (JForm, Woody) and workflow control. These numbers cover only web sites listed on Cocoon’s home page. The analysis of the mail forums of the Cocoon community allows one to suggest that overall distribution (information/interaction focus) keeps its tendency for all announced or discussed Cocoon projects.

Learning Curve The price for clear concern separation and the way it is done is a high complexity of Cocoon. Stylesheets are complex in nature; therefore the learning curve is more likely to be steep for the designers who previously used to deal only with HTML. Also, XSP technology is almost invention of Cocoon, that’s why most of web developers hardly have experience of working with it. On the other hand side, Cocoon is supplied with some documentation, tutorials, and examples. But these do not cover all Cocoon functionality. Therefore it was often the case when the view of the source code was done, in order to understand a feature of Cocoon. There are a number of mail forums with around 1000 active users, who can help to overcome Cocoon difficulties.

Maintenance As it was previously said, Cocoon offers the infrastructure for a very clear separation of concerns. It is the matter of the right application design to use this Cocoon architecture in a way that preserves this clearness and precision of the task separation. The development of Cocoon application also requires the precise architectural specification, including XSP tag dictionaries, DTDs/ Schemas. If these requirements are fulfilled, the final structure of an application developed in Cocoon allows reducing further maintenance efforts.

5.1.5. Conclusion Cocoon supports highly structured web application development. If an application is well designed, the efforts of maintenance and management costs are low by allowing separating on different context different requirements, skills and capacities. It supports multiple data sources and various data output formats. It has a sophisticated and tuneable caching. Being highly functional, Cocoon reaches high complexity with the growth of the application size. Creation of a stylesheet for a sophisticated page design supporting complex content can become a nightmare for a designer. With the navigational structure going from a simple line

83

model to a more complicated network model, the pipeline definition may become more conundrum-like and may loos its clarity. Cocoon being powerful publishing framework is highly suitable for content rich portals with data based in XML. In this area it simplifies processing, delivery and publishing of the vast amount of data. For business dynamic application this framework looks too redundant. The things that can be done faster and more efficient with MVC or even-based frameworks will result in unjustified work overload with Cocoon. The beauty of Cocoon is its underlying simple and genius idea of XML pipeline processing. It allows not only separate presentation from content, but also provides semantic to the content.

5.2. Apache Struts

5.2.1. Use Interface Issues

Separating Presentation from Programming Logic

Struts achieves SoC by implementing MVC model, where Controller code is a Java class, Java Beans are used for Model and JSP’s implement the View. Taglibs serve as bridge – when the Model is updated by the Controller, JSP’s use tags to pull the data out of the underlying bean layer and embed it into the View. This approach seems to be a clear separation of programmer and designer tasks; however the experience of work with Struts shows some drawbacks, which concern mostly use of JSP technology.

- JSP’s by default allow embedding a Java code into a markup. There is no mechanism to forbid doing it. Indeed, it can be avoided in the phase of development by using the taglibs. But there is always the possibility that on the maintenance phase, in order to modify some elements fast, the code will be inserted into the view that can gradually lead to the mixing up of presentation and programming code.

- On the other hand, tags are still the representation of the server-side programming logic in markup expressions. Moreover, tags are far away from simplifying the tasks of designers, having a quite complicated syntax. Therefore, in fact, taglibs still pollute the SoC and do not make development process less complicated.

Taglibs

As it was already said, taglibs are the integral part of Struts. By now Struts offers four libraries: for Bean interactions, HTML elements, for logical constructions and for Template support. Struts developers increasingly apply to Jakarta Taglibs Project, which has 20 more additional libraries. Tag libraries make the bridge between presentation and programming logic and eliminating Java code inside the mark-up, hence facilitating the separation of concerns. Still, use of a tag is not intuitive for a designer and requires the knowledge of underlying model object. In practice, a designer creates an HTML template and it is a programmer who inserts the corresponding tags inside. Since high importance is placed on the taglibs in the framework, it is logical to assume that this concept will be cultivated and elaborated.

Support for Multiple Client Types Multiple output formats can be supported only by different sets of JSP pages. Therefore the range of supported formats is not very long, from HTML to XML, and the problem of template synchronization is not solved.

84

Internationalization

For internationalization, Struts uses standard Java libraries: - Locale is a representation of the particular choice of the country - PropertyResourceBundle is a standard implementation of ResourceBundle that

allows the definition of resources by “name=value” expression. - MessageResources is the class that allows treating a set of resource bundles like a

database, where a required message is fetched depending on the current locale. For example, for resource bundle MyApplication, one need to create MyApplication.properties file and as many MyApplication_xx.properties files as the number of supported languages. Such an approach is easy to be maintained, because only one copy of a template is to be managed. But on the other side, it seems to be not an efficient way, since the text that is static in nature has to be placed in the template dynamically. That leads to the question about the performance under the high load.


Event Handling Being the direct implementation of the MVC design pattern, Struts does not support the concept of event handling.

MVC/Model 2 Struts bases its architecture on the MVC pattern, clearly defining the Control, Model and View components. But the framework does not force a developer to follow this principle. Nothing forbids calling a JSP (view) without going to an Action (controller), so that concrete implementation of MVC is left up to the developer of the application.

Workflow Recently, a Struts workflow extension has been created in order to control the sequence in which the actions performed. It allows defining the workflow in struts-config file, by specifying previous, target and next state for every system state. An action to be invoked should bring the system to the state specified by the next state of the previous action or its previous state should match it. If no workflow violations are encountered the workflow state information is updated, after that action code can be executed. If a workflow is violated, it is cleaned up and removed from the current session and the action code is not executed. Instead, control is forwarded to a global forward definition workflowViolation_workflowLabel with workflowLabel specifying the name of the workflow that was violated. This extension forces MVC approach to a developer and allows declarative definition of the navigation flow.

85


Form Mapping and Validation In this area Struts seems to be very strong. When a developer implements Actions, he can define ActionForm, as a standard Java Bean. While set method of the bean should always take String value, get method can return object of any class. That makes possible to convert data. If ActionForm is defined, Struts controller will automatically map the values from the HTTP request into the bean. This occurs before the Action class is invoked, therefore at the point where the developer is handling an action the Java Bean attributes are already available. Validation in Struts can be handled in two ways. First one is overriding the validate method in Action class. In this case validation is in fact a set of if then else statements, what gives a high work load to the developer and hardly can be reused for other projects. The second and more modular way is to use Validator Framework. It is a quite powerful framework allowing defining the validation rules in the file separate from the main logic and these rules are not tightly coupled with the application, so that they can be used in further projects. These rules can define both server- side and client-side validation. By supporting the regular expressions, validation rules promote declarative approach. This framework was used for the Online Shop prototype. The experience shows that this framework requires many efforts to set up, but once it starts to work it simplifies the further validation dramatically.

Error Handling The <form> element that corresponds to the <form-bean> element in Struts application has <field> sub-element. Each sub-element can specify that it must pass one or more validators. If validator fails, it passes back a key to message template in the application resources together with replacement parameters. Struts uses these parameters and keys to produce an error message. This approach is very flexible for internationalization purpose. It also gives the possibility to create uniform messages, which can be specified by parameter substitution.

Component Models/ Reuse Struts has a very generic approach to component concept, applicable for any reusable piece of code. They are Model components, View components, Controller components. But these terms are quite fuzzy to distinctly define what a component in Struts is.

5.2.3. Other Issues

Performance/Scalability Comparing with Cocoon, the performance of the Online Shop implemented with Struts increased twice. URL Count


Min Proc. Time

Max Proc. Time

Error % Rate

HTTP request

400 4790 130 13380 0.00% 1.8/sec

86

Fig. 5.2.11-1. shows the performance dynamic over time. The performance results are still not acceptable for production. The code is required further optimization. Concerning the scalability, the Struts showed decrease of throughput in 2.56 times by load increase in 2 times. That means decrease in performance for 28%.

Fig.5.2.11-1. Apache Struts. Performance test results

Tools Integration The popularity of the Struts framework one can be evaluated by observing the number of available development tools. There are large a number of free Struts plug-ins for the most popular IDE’s for Java programming such as Eclipse, IntelliJ, Borland Java and proprietor IDE’s that were created especially for Struts projects. From the plug-ins, Easy Struts and Improve’s Plug-in were tested. Both plug-ins put the emphasis on the visual editing of the Struts configuration file, wizard creation of Actions, ActionForms and JSP. There is a number of IDE’s that was developed especially for Struts projects. One of them is Exadel Struts Studio. It is a visual building tool that employs “drag-and-connect” approach for creating a site-map. Struts Studio includes macro-palette for the tag libraries. It is nice tool for those who just started to work with Struts. But it slows down the product development process for those who did understand the main concepts of Struts. It is much easier to modify site-map manually than in Struts Studio. Moreover, besides some technical instability, this tool does not provide supporting functionality of Eclipse or IntelliJ in writing Java code. Other IDE’s to be mentioned are M7 Professional and Object Assembler 3.0 Enterprise Edition form ObjectVenture. They offer the same functionality for Struts components support. All these tools are proprietary and costs from $300 to $1000 per licence.

87

The experience of Online Shop prototype development shows that using IntelliJ or Eclipse is quite enough to work on Struts project. Visualization makes development process nicer, but not more efficient.

Production Presence

The production presence of Struts is known to be large. To analyse the structure of it the 28 web-sites powered by Struts were observed [Struts Project Pages, 2003]. 97% of them are commercial web sites. The distribution by business models: advertising - 30%, brokerage - 25%, merchant -20%, manufacturer – 9%, other web sites use several models. Around 54% of the web sites place the focus on the customer – system interaction (that in fact is the strength of Struts) rather then content delivery. The evidence of Struts stability is that the number of large businesses uses this framework (not necessarily on a customer facing website): Ford Motor Company, Lands’ End Inc, IBM Corporation, Citigroup, Universal Underwriters Group.

Learning Curve Struts uses standard technologies for its components, therefore developers who already know Java and JSP will not have difficulties to start with Struts. Moreover, Struts has very good documentation, specifications and is supplied with a set of tutorials. Online Shop prototype was developed for half of the time needed for the Cocoon prototype.

Maintenance

As it was said, Struts offers the infrastructure that separates the tasks for different development roles very clearly. If this infrastructure was used properly for the certain project, maintenance cost can be negligible - XML configuration files make it easy to customize actions. To add functionality, one simply needs to create an Action, a Form, and the JSP -- the framework takes care of the rest. Maintenance cost can become high if one tries to use the framework “off-the-shelf” without any efforts to adopting it. Indeed, there are ramp-up costs, but they are highly dependent on the team’s previous experience.

5.2.4. Conclusion Implementation of the Online Shop prototype showed that Struts is very helpful for dynamic business applications. It implements MVC model that allows concentrating on business logic, simplifies maintenance and make the final product adaptable and flexible. It is very standard-oriented; it facilitates i18n, easy form handling and validation. It was relatively easy to implement necessary navigational structure by simply mapping request URI to the corresponding action. In Cocoon network page flow increases the complexity of the sitemap and, in the case of mounting several sitemaps, some page transitions are not possible. On the other hand side, it is a lightweight framework. It does not force to use all the elements it provides. That makes it applicable for the web sites of different complexity. Struts exhibits a number of drawbacks, but most of them are related with use of JSP (see section 5.2.1). The Struts developers tried to overcome the JSP’s drawbacks by allowing using other presentation technologies instead. Also, they try to employ achievements of Cocoon of processing XML data in a new framework stxx that is in fact Struts plus XML/XSL transformation.

88

Last three months of the Cocoon and Struts development clearly shows the tendency of both to employ the best solutions from each other. Previously, one can see rugged discussions of the Cocoon and Struts fans which framework is better. It was obvious that these frameworks can divide a big share of application area. Cocoon could be specifically for information portals, whereas Struts specifically for dynamic business applications. Now, the situation changed. The developers seem to decide to adapt the achievements of each other. Fast pace of this adaptation allows talking about the certain point in time of Cocoon and Struts merge in a new very powerful and functional framework.

5.3. InfoAsset Broker



Broker provides the clear separation of programmer and designer roles by employing “MVC -Push” model. The difference of this model from MVC-implementation provided by Struts is as follows: after Controller component updates Model, View component (a Template in case of Broker) does not request Model by itself for the corresponding data, but the Controller populates the Template. It is done by Stations, visible or invisible one, when TemplateAction’s putAllSubstitution() method is called. In this method, the placeholders that are used in the Template to be populated are substituted with the values from Model. Hereby, a page designer needs just define the name of the placeholders and its position in the page, but he does not need to take care about from where and how this data comes from.

Taglibs/ Template Language

Broker employs its own template language. It has very simple and intuitive syntax that defines the rules for placing placeholders, organizing conditions and list iteration. It is used for the declaration of the variables for Controller and definition of the place to insert the data in the template; therefore it does not require lots of effort for a page designer to use it. Support for Multiple Client Types / Multiple Output Formats In order to support different client types in Broker, one should maintain multiple template sets for each type. A User Agent class has its id, which is also used as a name of the template folder. It is important that it is not required to duplicate the full set if the templates for different client types. For example, for Internet Explorer and Opera browsers the presentation differs only in a subset of templates. In this case, only this subset should be separated for Opera browser, the rest will be used from the same source. This approach raises the problem of synchronization of the template version. Once the changes of the presentation are required, the editing of several templates should be done. This problem is being avoided by the Broker developers by means of Dreamweaver. This tool provides the possibility to use “main” template for all template pages that bears the common design features. As long as the changes concern only these features, only “main” template should be changed.

89

Internationalization Internationalization of static data in Broker uses the same approach as for the support of the multiple user agents, i.e. the maintenance of the multiple template sets for each language. In this case such approach provides efficiency, since only the dynamic portions of the template need to be localized every time template is used. But the difficulties to maintain still remains, because the multiple copies of the presentation layout must be kept in synchronization with each other. For localization of the dynamic messages, Broker uses approach similar to Struts. It has a dictionary message.txt which contains the mapping for the message key for different locale and corresponding message text.


Event Handling Broker uses event handling concept on the Store layer. On the Presentation layer this concept is not defined. A term “event” can be viewed as a kind of “gesture” of a user, that means any action on a client that results in a subsequent HTTP Request. With this approach, the event is treated as a String that map to individual classes, Handlers, which are instantiated and cashed. This approach is used by many frameworks, e.g. Struts. It provides good scalability under load.

MVC/Model 2 Broker implements MVC design patters by specifying the Controller, Model and View functionality for different components. The Controller part is given to:

- Web-Server that handles the requests from the client and defines which Handler to invoke by consulting with configuration file handler.txt

- Handlers that extract required request parameters from the request, perform business logic, if needed, modify the state of Model and choose the next processing step

- Stations that instantiate and populate templates with values from Model and give a required template to the web-server or perform side-effect actions

Model is handled by Business Objects. View is represented by Templates. It was mentioned already, that Broker MVC pattern implementation differs from the one used in Struts by providing “push”- functionality for data retrieval on the view layer.

Workflow Workflow control is not explicitly implemented in Broker. The state of the system and its corresponding aspect is defined in Handlers in run-time.


Form Mapping and Validation Broker does not provide a mechanism for processing ad validating forms. The data submitted in a form are extracted in Handler’s getParameters() method manually and processed in

90

doBusiness() method. Validation can be done also here using functionalities offers by Java libraries.

Component Models/ Reuse Broker uses the term “component” in a generic sense that can be used to describe any reusable piece of code. One can talk about handler or station component. Because the term is used so loosely, it is difficult to find a distinct concept of a "Component Model" within Broker.

5.3.4. Other Issues

Performance/Scalability Since Online Shop was not implemented by means of Broker, the performance test for the framework does not correspond to the default conditions and its results are not taken for the comparison evaluation. The development version of weblog 20six.de was tested on the testing PC with 10 and 20 users requesting 4 pages in 40 cycles. The results of the test exceed those received from the tests of other frameworks: URL Count


Min Proc. Time

Max Proc. Time

Error % Rate

HTTP request

400 1668 70 4947 0.00% 5.2/sec

Fig. 5.2.10-1. shows the performance dynamic over time. Such results allow the web site to go to production. Scalability test showed no performance drop under the load increase by factor 2.

Tools Integration Development of a Broker-based application can be supported with common page tools and IDEs. Since Broker templates are basically HTML markup, Macromedia Dreamweaver is highly useful for their development. It allows visual page editing, support layouting and does not prevent introduction of Broker placeholders. Java developers can use the traditional IDEs, such as IntelliJ or Java Builder. Broker developers recommend using Eclipse, since Broker plug-in for Eclipse is available. This plug-in is built for the code introspection, providing the possibility to analyse the component hierarchy and control possible project errors.

91

Fig. 5.3.10-1. InfoAsset Broker. Performance test results

Production Presence

Most of the business applications done by Broker are rich content, with focus on user – system interaction and document organization and store. www.20six.de is an example of web-site powered by Broker.

Learning Curve Broker goes further than just providing the infrastructure for web presentation. Its architecture covers three layers of the web application and supports very complex business solutions. Therefore, some preliminary studies are required to start working with this framework. On the other hand, Broker is based on the clear and logical concepts that make ramp-up period for the experienced web application developers quite short. The lack of documentation and tutorials is the drawback of Broker. But since this framework is still in the development, this drawback can be viewed as temporal.

Maintenance The clear separation of concerns makes applications made in Broker easily maintainable on the presentation level. One can encounter difficulties to change Business Object structure, but changing the page design or page flow is supposed not to bring many problems to a developer.

92

5.3.5. Conclusion InfoAsset Broker places its focus on the development of the Knowledge management solutions. [infoAsset AG, 2003] It offers interactive Knowledge-maps, Document- and Skills- Management functionality, automated document classification. Its presentation layer is specialized for the needs of these functionalities. Therefore it can not be seen as a competitor of Cocoon or Struts, but rather there could be the possibilities to combine their advantages.

5.4. Velocity Velocity has a very simple architecture, since it meant to be nothing more than a template engine. Its concept does not go to the area of “development frameworks” and often serves as a View component for others, such as Struts and JPublish. For Online Shop prototype for Velocity, Control and Model components are done with Struts, whereas instead of JSP’s Velocity was used. Therefore it does not allow comparison of Velocity with other frameworks by some of the issues offered previously. This analysis stresses the view features of the framework that provides the possibility to correlate Velocity with JSP technology.


Separating Presentation from Programming Logic Velocity uses its own template language for performing the presentation logic and dynamic data insertion. Unlike JSPs, Velocity templates do not allow using Java code inside and in fact it is not needed, since VLT provides wide spectrum of functionalities. One could argue whether such approach is a better support of Separation of Concerns concept. On the one hand, the absence of pure Java inside HTML mark-up is already a step towards clearer SoC. It is a sign of “good design” for JSP developer as well. Custom Taglibs for JSPs are getting more popular in JSP world and provide all the functionality of JSP without a single line of code. In Online Shop prototype for Struts, taglibs were used (snippet for navigation.jsp): <logic:match name="topic" property="type" value="<%= string1%>"> <html:link page="/navigateAction.do" name="topic" property="mapping"

styleClass="navsub_hi"> <jsp:getProperty name="topic" property="text"/> </html:link> </logic:match> <logic:notMatch name="topic" property="type" value="<%=string1%>"> <html:link page="/navigateAction.do" name="topic" property="mapping"

styleClass="navsub"> <jsp:getProperty name="topic" property="text"/> </html:link> </logic:notMatch> Velocity Template Language (VTL) uses the same concept of pulling dynamic data from data sources and performing presentation logic. In fact, both taglibs and VTL expressions are the trial to avoid Java code by substituting it with own syntax. That means that programmers’ and designers’ tasks are still mixed in both cases.

Taglibs/ Template Language Velocity Template Language is very simple and elegant. For comparison, the previous snippet from navigation.jsp in VTL looks as follows:

93

#if($subtopic.type==$current) <a href="navigateAction.do?type=${subtopic.type}&link=${subtopic.link}"

class="navsub_hi">$subtopic.text</a> #else <a href="navigateAction.do?type=${subtopic.type}&link=${subtopic.link}"

class="navsub">$subtopic.text</a> #end The complexity of tag libraries looks very heavy in contrast to VTL. JSP give not only higher opportunity for typing mistakes, but also quite complicated syntax. A page designer needs to read specifications on every tag from a tag library and consult a programmer in order to use it properly. For example, in order to construct a link with several parameters with <html:link> tag, one should add a property with get method that returns a map of the required parameters to a corresponding Java Bean.

Page Generation Velocity differs from JSP in the approach of page generation. JSP uses process of edit/transform/compile/load/run that uses javac to compile the Servlet into a .class file which is loaded by the Servlet Engine. In opposite, Velocity simplifies this process to edit/parse/run approach. It loads templates, parses them one time and stores their Abstract Syntax Tree (AST) representation in memory. When a template changes, the existing cashed template is replaced with newly parsed version. Such approach provides benefits in performance and allows using configurable templates loaders for retrieving templates from different sources. It is reported that the performance of Velocity is comparable or even slightly better that JSP

Support of Multiple Client Type and Internationalization Velocity does not offer any mechanism for multiple client types and internationalization support. In these cases it depends on the underlying “development” framework.


Data Sources Velocity can take as an input any type of text. It can be Java, SQL, HTML, XML, plain text, internationalized text, etc. The parser is very robust in terms of only parsing out what it cares about and ignoring the rest. The advantage of such approach is that it provides a single template system for all kinds of data sources.

5.4.3. Other Issues

Performance/Scalability Being a lightweight template framework, Velocity shows increase of performance. Online Shop for Velocity was based on Struts, just the JSPs were substituted with Velocity templates. Therefore, this increase can be related to the advantages of Velocity

94

URL Count Loops

Average Proc.Time

Min Proc. Time

Max Proc. Time

Error % Rate

HTTP request

400 3788 280 11626 0.00% 2.28/sec

Fig.5.4.6-1 shows the performance dynamic over time.

Fig. 5.4.6-1. Velocity. Performance result test

The loss of performance of 2.31 times under the increase of load in 2 times, one can relate to the Struts.

Tools Integration Simple syntax of VTL allows easy editing of Velocity Templates in any Text Editor. In spite of it, Velocity developers offer a variety of plug-ins for different IDEs and Editors to make development with Velocity more convenient. The plug-ins, worth to be mentioned, are Velocity Template Editors for IntelliJ, Eclipse and UltraEdit. Basically they do not make work with Velocity faster, but easier for beginners.

Production presence There are 14 web-sites powered by Velocity listed on the Velocity home page. All of them are commercial sites. Around 35% of them are based on the Brokerage business model, 40% - on Community business model, others are – Merchandizing, Manufacturer, Infomediary. Most of them require communication with a user through forms, where Velocity offers a great help as a View component. Velocity is used not only for web sites, but also in conjunction with general applications, such as GentleWare Poseidon for UML. It uses Velocity template tool for Java code generation

95

from UML diagrams. Another application powered by this framework is Venus Application Publisher that helps in packaging, signing and publishing Java Network Launching Protocol software.

Learning Curve Velocity has a learning curve of about 3 to 5 hours. Mostly the beginners can be productive within one day. The documentation and tutorials that Velocity supplied with is not voluminous but it is enough to understand the main principles of Velocity.

Maintenance The maintenance of Velocity templates does not require much effort. Changing the presentation of the view adds up to the changes in HTML or another page language. If business logic has been corrected, the corresponding adjustments of the Template variables are the less difficult thing.

5.4.4. Conclusion Comparing to JSPs, Velocity does not offer clearer separation of the view aspect of an application from the model and control aspects. But it provides simple and easy to learn template language. Having less then ten directives, it provides the same functionality as JSPs does. Velocity’s advantage becomes clearer when it comes to access to application data from templates. It handles access to objects and their methods like in scripting languages such as JavaScript and therefore it feels familiar to template designers. As a benefit of Velocity one can name a simple development cycle. Errors in templates are easy to be localized and debugged. It is important to note, that Velocity is supported with a very active and supportive community of users and developers.

5.5. JPublish



JPublish pursues the goal of separation of not only the programmer’s and designer’s roles. It also defines the roles of authors, who deliver the content, and integrators who put all components together. Every role holder is responsible for certain JPublish components: templates, content, actions or pages. In this case it is stated that no tasks are intersected. In practice, that is not completely correct. JPublish uses Velocity for template processing. As it was said in the section 5.4, VTL does not provide complete separation of the design and the programming logic. It just makes the assimilation of these roles less troublesome. After the closer look on the templates and the content components, one can notice that they are basically of the same concept. A template is the layout of a page, and a content element contains the layout for the certain element of the page. Both of them contain HTML code and Velocity Template Language. Template uses them to define the general look of the page, whereas the content element uses them to access the data from underlying model and define

96

the look of a small piece of information. Of cause, it is possible to divide content in very small pieces and create a hierarchy of templates, so that there will be no HTML code in content element. With such approach the problems of maintenance and performance are inevitable. The idea to define an integrator as a separate role looks very interesting, but not forcible. Page element defines meta-data of a page, such as page title, and a set of actions that need to be attached to it. Certainly, these tasks are those of a designer and a programmer, who defines the required control flow. Finally, instead of the reasonable separation of different roles, JPublish offers quite redundant component architecture difficult for maintenance.

Taglibs/ Template Language In its template and content elements, JPublish uses Velocity Template Language, which was discussed in section 5.4.

Support for Multiple Client Types One can support this feature in JPublish by maintaining multiple page sets. The necessity to build not only the additional set of the templates, but also additional set of content and page elements, makes this process even more difficult.

Internationalization JPublish’s support for web sites internationalization does not look very impressive. Integrator can define the properties to be localized for every page configuration by defining the corresponding locale: <page> <property name="title">Welcome</property> <property name="title" locale="fr">Bonjour</property> <property name="title" locale="de">Wilkommen</property> <property name="title" locale="de_AT">Gruss Got</property> </page> That means that when several pages need the same data to be localized, their localized versions have to be replicated in every page configuration file. JPublish’s support of alternative encoding is very useful. It is based on the request path and allows specifying encodings of the content, of the site template, of request parameters, and of the response sent back to the web-browser.

5.5.2. Control Flow Issues

Event Handling JPublish defines an event as a request from a client. The strength of the framework is that its actions are mapped to the events in various ways. They can be associated with a particular page or a template, can be executed when a particular path is matched or on start-up or

97

shutdown, on pre- and post-processing of the HTTP request. The list of the possibilities to map action to the request is quite impressive and provides certain flexibility to the developers. The experience with Online Shop showed that there are cases when the offered possibilities of action mapping are not enough. Order process contains the sequence of pages with forms. Every page is associated with the actions for current form initialization (FormProc module [FormProc, 2003]), previous form processing (FormProc module) and the custom action for business logic performance. If a user presses button “cancel” in order to come back to the previous form, the error will be thrown, since the processing of not initialized form occurs. In order to avoid this situation, the fake pages in between the pages with forms were used. (see Fig. 4.4.7-3) Such a design redundancy could be avoided, if JPublish would have opportunity to identify user action on the client and map an action handler to it.

MVC/Model 2 JPublish event handling model does not provide it with clear MVC control flow. One can see action components as Control and templates and content elements as a View, whereas definition of model is not covered by JPublish. Hence, the definition of MVC approach under this framework is quite vague, but is not impossible. A developer can design the architecture of the application in a way in fulfil the MVC specification.

Workflow

JPublish does not provide tools to manage the workflow explicitly.

5.5.3. Server-Side Issues Form Mapping and Validation JPublish uses FormProc module which uses FormProc library [FormProc, 2003] for form processing and validation. In order to use this module it should be declared in jpublish.xml file. Forms are specified in XML documents. FormProc has its own configuration file where all forms are defined. The specification of each form with fields and the corresponding validation methods declaration is stored in a separate XML file. FormProc uses formproc.initForm() method to create an object to handle data from the current form. Method formproc.processForm() validates the submitted data and populates this object. JPublish uses FormProc's powerful validation facilities that provide the following features:

- Validation using regular expressions, scripts, rules or Java classes - Validators defined in the main FormPoc configuration file can be reused through all

the forms - Additional Validators can be added at deploy-time - “Group” validators facilitate nested validators - Form fields can be grouped together and validated

98

Error Handling Error Handling offered by FormProc is very simple and does not require too much effort. After the form processing, an instance of org.formproc.validation.ValidationResult class which represents form validation results can be obtained through the Session object. Using its method isValid() one can check the validity of a form element. Method getErrorMessage() returns the message to be presented to a user in case the data are not valid. Following snippet shows the example of using Validation result object on the View level: #set ($formResults = $session.getAttribute("formproc.result")) ... #if ( $formResults ) #if ( $formResults.isElementValid($field) ) $message $form.getError($field) #else <font color="#ff0000">$message</font> #end

Component Models/ Reuse JPublish employs Component Model concept allowing creation of reusable components. The framework understands a component as a collection of actions and views which can be placed directly to the content. A component must implement the org.jpublish.JPublishComponent interface or extend org.jpublish.component.AbstractComponent abstract base class. Components which extend from the AbstractComponent base class need only implement the render() method and they can actually delegate responsibility of rendering to a component-specific view renderer. Components are declared in the JPublish configuration file as children of a component manager. <component-manager> <components> <component id="component_id" classname="com.mycompany.MyComponent"> <repository name="repository_id"/> </component> </components> </component-manager>

In case, the component extends from AbstractComponent, the content will be pulled from the specified repository. That allows a component to provide logic and a basic view but at the same time individual sites has the ability to customize component views as necessary.

5.5.11. Other Issues

Performance/Scalability JPublish showed the best results in performance test out of four frameworks. URL Count


Min Proc. Time

Max Proc. Time

Error % Rate

HTTP request

400 2860 220 7821 0.00% 3.0/sec

99

Fig. 5.5.11-1 shows the performance dynamic over time. JPublish also shows good scalability: 2.012 throughput decrease under load decrease in 2 times.

Tools Integration Basically, a JPublish application can be developed using the common IDEs and text editors. But it would be very useful to have a plug-in for any IDE to manage the amount of various elements of JPublish. It is very easy to be mixed up with the vast amount of configurations and meta-files.

Fig. 5.5.11-1. JPublish. Performance test results

Production Presence JPublish is a new and not very popular framework. Therefore it does not have a wide production presence. Only four web sites powered by this framework were found. Among them, one is the home site of JPublish and another one is the web page of the JPublish author. One web site made with JPublish is worth to be mentioned. www.masterfile.com is an Online Shop for digital licensed images. It has very clear, but quite complex structure and simple and elegant design, it is available in seven different languages for more than 30 different markets. The developer of this web site found JPublish very easy-to-use and maintainable framework. They write in their web site description: “The open architecture of JPublish allows us to easily create new modules or in-house plug-ins to act as glue between our legacy systems and web applications.” [JPublish, 2003]

100

Learning Curve JPublish is not difficult to learn. Depending on one’s experience with J2EE standard technology, one can start with it within two – three days. The problem is that the documentation and User’s Guide provided by the framework developers are not very comprehensive and JPublish community is not very big and active.

Maintenance JPublish is a component and modular framework. The architecture of the final product could be maintainable, if one can handle the huge and sometimes redundant amount of JPublish elements. But with the growing complexity of the application, the maintenance can become unaffordable.

5.5.5. Conclusion JPublish is a very interesting framework to investigate on. It depicts a number of useful features:

− Flexible action mapping − Support of several template engines (Velocity, FreeMarker, WebMacro) − Repository abstraction layer − Search-engine friendly URLs that look like static URLs − Modularity − Component-based architecture − Pluggable page manager − Utilities

Still, the separation of concerns offered by JPublish looks quite problematic. It is not easy to handle the large amount of configuration and meta-files that are the result of pursuing the goal to completely divide developers’ tasks. That is not a problem for small web-sites, but with the growth of the application complexity can become not manageable. Another issue is the stability of JPublish. Providing their product Open Source, framework’s developers rely on the community for reporting the bugs and correcting the code. Since JPublish is not very popular framework and for last half a year there was no new releases, it would be risky to use it for large commercial projects.

5.6. JavaServer Faces


Separating Presentation from Programming Logic JavaServer Faces (JSF) defines four perspectives for its technology:

- Page Authors. Web designers who create look and feel of the web site. Within JSF they use taglibs.

- Application developers. Programmers who are responsible for the model object, the event handlers, the validators and the page navigation.

- Component writers. Programmers who create the custom components directly from the component classes or by extending the standard components provided by JSF.

- Tools Vendors. Legal or private entity that provides tools for leveraging of JSF technology in order to simplify creation of user interfaces.

101

The primary roles for the development of an application are page author and application developers. Hence, the Separation of Concerns provided by JSF consists only in splitting up the presentation and programming logic. Here, there are a couple of remarks to be made:

− The JSF application designers create the page view in the JSP pages using JSF tag libraries, which shortcomings for pure SoC were discussed in the section 5.2 and 5.4. However, in JSF tags are used to include a component into the page. As soon as there will be tools that support visual creation of JSPs with UI components of JSF, the separation of behaviour and presentation will be finer-grained.

− Another issue that prevents clear SoC lies in the design solution of JSF UI components. With the definition of the form fields’ components, a designer should specify the corresponding validator for this field. In this case, he needs to know not only the validators available but also the nature of the field data. That is the area of the programmers’ concern.

− Some tags need to specify the scope of their use (session, application, request etc). That is out of the designer knowledge scope as well

Taglibs JSF provides two tag libraries. JSF-core library defines the tags for event handling, attribute configuration, parameter substitution, validation etc. These tags are independent of any rendering technology. HTML_basic tag library is used to represent the common HTML user interface components. It allows avoiding the hard-coding of UI components in HTML what leads to the complete reuse of the components. It is possible to define own tag libraries that renders custom components or renders the output in another format then HTML.

Support for Multiple Client Types Currently, there is no precise information, how JSF supports multiple client types. It is assumed, that it can be done by assigning the different renderers to the different type so that the components will look different for browsers, PDA or mobile phones. Indeed, it is not enough to create full-value version for another client type, since the page view and static data may need to be changed. Probably, there JSF team works on it, since JavaServer Faces is claimed to support this feature.

Internationalization For application internationalization, JSF uses Properties file which contains localized messages. It can be used both for dynamic and static data localization, since it is accessible by JSP tags and Java methods. Dynamic data are localized by use of the class ResourceBundle’ s method getBundle(). For the static data, one should declare JSTL fmt tag library. The tag <fmt:setBundle> registers the use of the Properties file on the page. Later on, the corresponding messages are retrieved by the key attribute of the UI components tags.

102


Event Handling

JSF is built around event handling approach which is perfectly used in conjunction with its UI component model. The term event is defines as an action on a component triggered by a user. An event can be of the two types. Value-changed event occurs when a user changes the value of a component, for example UIInput or UISelectOne components. Action event is fired when user activates a component of UICommand type. It can be either a hyperlink or a button. In any case, an Event object defines the component that generates an event and stores the information about the occurred event. In order to be notified of an event and process it in the necessary way, the implementation of the Listener class must be provided. The event listener should be registered with a component. When a user activates it, the event is encapsulated into HTTP request, along with other information, such as browser type and requested URL. After receiving the request, Faces servlet invokes the corresponding listener method to process it.

MVC/Model 2

JSF implements MVC pattern by associating the tasks of Model, View and Controller to its elements. View is implemented by author JSP pages, using JSF components that encapsulate HTML elements. Model is supported by Java Beans as the state holders of user-input and component data. Faces servlet along with event listeners define the control flow and update the Model state [Kurniawan, 2003]. Unlike in Model 2 implementation of MVC pattern, JSF uses more complex control flow between these elements. It is base on the reconstruction of the component tree from the HTTP request and further processing of this tree by applying component values, validation and model synchronization.

Workflow The JSF workflow is defined by the Navigation Model. Navigation rules are specified in the piece of XML code in the application configuration resource file. It maps three constituents of the navigational flow: the origin, the application state and the next view. The origin defines the page from which the navigation should be done. The next step is the page to be shown in case the application state equals the one specified. The state can be the outcome from the event listener or can be explicitly imposed from the JSP page. <navigation-rule> <from-tree-id>logon.jsp</from-tree-id> <navigation-case> <from-action-ref>LogonForm.logon</from-action-ref> <from-outcome>success</from-outcome> <to-tree-id>/storefront.jsp</to-tree-id> </navigation-case> <navigation-case> <from-action-ref>LogonForm.logon</from-action-ref> <from-outcome>failure</from-outcome> <to-tree-id>/logon.jsp</to-tree-id> </navigation-case> </navigation-rule>

103


Form Mapping and Validation There is no separate technology for processing forms. Any form of an application can be built with standard JSF UI components. AS for other components, the JSF life cycle of the request is applied: reconstitute request tree ->apply request value->validation->update model values ->invoke application-> render response. For the input validation JavaServer Faces technology provides a set of standard classes and associated tags that page authors and application developers can use to validate a component's data. The problem here is that page author is responsible for the field validation definition. JSF tutorial states: “The page author registers the validator on a component by nesting the validator's tag within the component's tag”. [Reynolds, 2003] Since the forms designer (model author) defines the fields that make up the form bean, he is the one he knows what the acceptable values for this field are. Taking into account the process of developing and maintaining an application, the question arises: how will the rules that govern a form’s fields be conveyed from the form designer to the page designer?

Error Handling A page designer can place the error message resulting from the input validation on the JSP using output_errors tag. <h:output_errors for="ccno" />

Attribute for matches the id of the component those data are validated. This mechanism provides flexibility for the designer to choose the massage location on the page.

Component Models/ Reuse JavaServer Faces strength is its UI component model that is based on the configurable, statefull components for application user interface, encouraging the component reuse, simple prototyping and easy maintenance. JSF component architecture includes:

- a set of UI component classes - a rendering model that defines the look of a component - an event and listener model that handle the event triggered from the component - a conversion model for plugging the data converters to components - a validation model that controls the pluggable validators

Even though the JSF developers claim their component to be rich, by the Early Access 4 the amount of standard components available is not impressive. That concern not only the UI components (menus or tree structures are suppose to be the basic ones), but also the Validators or Renderers. Hopefully, Sun Microsystems is not going to outsource their implementation to the tool vendors, since it will lead to the dependency on specific vendor even for such a small things.

Tools Integration Many big companies, such as IBM or BEA, announced the development of the IDEs that support the visual, “drug-and-drop”- like development of the JSF application. Probably the

104

first releases of such tools will appear after the first release of JSF. Before it happen, the development in JSF in very tedious work.

Other Criteria

Since only Early Access 4 of JSF is available, it is difficult or impossible to evaluate such features as production presence or learning curve. After the first release, the boom is expected of the JSF-powered web sites, probably not commercial ones, but still the one to see the capabilities of the framework. Learning curve is expected to be not very steep, since Sun provides already very comprehensive documentation, tutorial and guidance set. As soon the JSF-supporting IDE will be released, the learning to work with the framework may become easy and enjoyable.

5.6.5. Conclusion From the documentations and the description provided by Sun Microsystems, Java Server Faces seems to be a good server-side UI component framework. Still, it is impossible to evaluate it comprehensively in the available Early Access version. The implementation of the Online Shop using EA 4 failed because of the number of bugs and not elaborated issues of JSF. It is already stated, that JSF is a future standard of web application development and the community around is growing very fast. Nevertheless, the first release will show the validity of such a statement.

105

5.7. Conclusion The results of the conducted analysis are aggregated into the following table:

Weight for Online Shop

Cocoon Struts /JSP

Velocity JPublish JSF Broker

1 SoC 3 4 4 4.5 3.5 4 4.5 2 Taglibs/Template

language 2 3

XSP Taglibs

4 JSP/Struts Taglibs

5 VTL

5 VTL

4.5 JSF Taglibs

5 Placeholders

3 Support of multiple client type/ output format

3 4.5 4.5 - 4.5 4.5 4.5

4 Internationaliza- tion

1 5 4.5 - 2 4.5 4

5 Event handling - - - x x - 6 MVC Model 2 x x - x x x 7 Workflow - x - - x - 8 Form mapping,

validation 3 4 5 - 5 5 -

9 Error handling 1 4.5 5 - 5 5 - 10 Component

model/ reuse 2 4 3.5 - 2.5 5 4

11 Performance 3 2 4 4.5 5 n/a n/a 12 Scalability 3 5 3.5 4 5 n/a n/a 11 Tools integration 2 2 3 3 1 n/a 10 12 Production

presence 1 5 5 4 2 n/a n/a

13 Learning curve 1 3 4.5 5 4.5 3 4 14 Maintenance 3 5 5 5 2.5 5 5 15 License Apache Apache Apache Apache-

style Sun Microsystems

Info Asset AG, proprietary

Results for Online Shop

120.5 131 136 115 92 98

Agenda: The grades are given in 10 grades evaluation scheme (from 1 to 5 with 0.5 step): 5 – very good 4 – good 3 – acceptable 2 – bad 1 – not acceptable “-” – not applicable “n/a” – information is not available

106

Here, some remarks are to be provided. − Each issue for each framework is graded on the basis of the analysis given in the

previous sections and own experience. − Separation of concerns issue was evaluated from the point of view to which degree the

different concerns are divided and the different roles are not intersected. − Taglibs issue is evaluated from the point of view of their richness, availability and

easy-to-use. The frameworks that use template language have higher grades, since this approach is more intuitive, simple and at the same time preserves rich functionality.

− For support of multiple client type, every framework has the same grade, since in principle all of them offer the same mechanism, namely support of the additional set of templates/stylesheets. By now it seems to be the only approach found by the developers.

− Event handling, MVC Model 2 and workflow are evaluated from the point of view supported/ no supported, since these issues can be important or not depending on the project.

− Concerning form mapping, one should mention, that currently Cocoon is actively working on the new modules for its support. The already available Woody documentation allows saying that with its first release the Cocoon grade for this issue can be increased and probably will reach the Struts’ one.

− The comparative results of performance tests are shown on Fig. 5.7-1 and Fig. 5.7-2

Fig. 5.7-1. Comparative processing time Fig. 5.7-2. Comparative throughput − Production presence gives the grade only for the number of the projects powered by it,

but not for a quality of these projects. − In learning curve issue, the higher grade is given not only for the simplicity to learn,

but also for the availability of supporting documentation, tutorials and activity of the community around the framework.

One can see from the table that Velocity being only a template framework is not comparable with other development frameworks. Therefore the comparison is better to be conducted on the presentation level, for example with JSP. From the section 5.4.1, it can be concluded, that Velocity provides the advantages in separation of the presentation and the programming logic, simplifies the access to model object and it is easy-to-use. The implementation of Online Shop was faster and less error prone with Velocity than with JSP.

0

2000

4000

6000

8000

10000

12000

14000

Processing time [ms]

CocoonStruts/JSPVelocity/StrutsJpublish

0

20

40

60

80

100

120

140

160

180

200

Throughput [req/min]

107

In spite of that for every framework a grade is given, the author would avoid the question: which framework is the best one? More correct question would be: which framework is optimal for my project? The result table can be use to support the decision in case the decision-maker knows how to set preferences for the comparison issues. Every issue need to be weighted and indeed every project will have different weights in the rows. Currently, the table shows how the priorities are set for Online Shop prototype. Weight are given where 3 means “highly critical criterion”, 2 means “critical criterion”, 1 means “not critical criterion”. According to the calculations, the preference should be given to Struts with Velocity as a template framework (136 points). This table gives the methodology for web framework comparison by providing the critical issues to be investigated under every framework choice. On the other hand, the problem arises when one does not know which of them are of higher priority. Here, so called, soft evaluation which comprises not only of the facts given before, but also of the experience of working with these technologies, the opinion of their community and the developers and the personal perception can be helpful. This is accumulated on the profile diagrams that correlate the types and requirements to an application with the evaluated frameworks. Fig. 5.1.7-3 shows the framework profiles depending on the type of the web application. Axis X shows to which degree the application is focused either on the user-dependent or user-independent information. One can count news-, advertising- and information-portals as applications with high focus on user-independent information presentation, and weblogs, electronic shops that require user registration as applications with high focus on user-independent information presentation. On the right side of the axis, there are the applications that provide highly personalized views depending on the user profile, his activity and behaviour. Such applications are highly interactive, use many forms and provide information depending on the user state or his request. These kinds of application are mostly process-based. On the left side of the axis, the applications that can be supplied with the data from different sources, but their content is equally presented to all users. Such applications fit more to the data-based class of the web applications. JSF, due to its architecture that supports UI components and event handling, perfectly fits to the highly interactive applications development. Broker is placed in the same area, due to its elaboration on the Business Object Layer. Therefore it is very strong in supporting the process-based applications. Struts as a good implementation of the MVC model 2 pattern is optimal for processing users’ requests and responding to them. Still, when it goes about automatic fields update or dynamic view creation, it is better to use JSF or Broker. Cocoon is initially publishing framework. Its XML processing pipeline idea is aimed to the very clear separation primarily content and presentation. Hence, it is a good solution for informational portals, content management systems etc. Tracing the latest development in Cocoon, one can notice that their developers are intensively working to provide a high degree of “MVC” to it. The examples are the newly developed form support and the intention to incorporate flow control. On the other side, Struts is going to the direction of Cocoon. The Struts developers introduced the XML processing framework that calls Stxx. It substitutes JSP on the view layer with XML/XSL processor.

108

If previously one could think about the integration of Struts and Cocoon for own purposes, it is now not necessary anymore. It is possible to find the best solutions of Cocoon in Struts and vice versa.

Fig.5.7-3. Frameworks profiling diagram

On Fig.5.7-4 the profiling diagram uses the complexity of navigation and the complexity of design of the application, for which framework is chosen. Complexity of design does not mean the appearance of a page, but the number of different element which require dynamic data, frameworks etc. The complexity of navigation is defined by the navigational scheme to be used. In simple case it is a tree, in more complicated case it can be a net. Cocoon is suggested to be used for the average complexity of both design and navigation. With the growth of navigation complexity the sitemap complexity grows fast. Since Cocoon uses XSL stylesheets, it is quite difficult to use it for the design with many elements. In fact, it is due to the absence of the tools that would support the visual Cocoon stylesheets development. Struts, Broker, JPublish and JSF are applicable for the same complexity of design, since they employ the same approach of the templates. The difference is only in using taglibs or template languages. But JPublish because of its component redundancy can become a mess with growth of navigation complexity. JSF due to its ability to handle events and assign components to their even listeners is applicable for different navigation schemes, with dynamic page and field update. Broker is applied in the same area due to its concept of Stations.

User-dependent information presentation

User-independent informationpresentation

Suitability

Struts

Cocoon JSF

JPublish

Broker

109

Fig. 5.7-4. Profiling diagram for the evaluated frameworks in correlation with complexity of application

navigation and of application design

Fig. 5.7-4 shows the framework profiling diagram depending on the complexity of the implementation of the chosen logic.

Fig. 5.7-5. Profiling diagram for the evaluated frameworks in correlation with complexity of application

navigation and implementation complexity

Here, one can see, that the more a framework is applicable for complex solution the more complex is the project implementation. JSF is the only exception, but under the condition that its final release will correspond the anticipations. Here, the question of the development team qualification should be raised. In order to be productive with Broker, the experienced Java programmers and template designers are required. Struts need high proficiency in J2EE standard technologies. Cocoon requires knowledge of XML/XSL technologies. If the knowledge corresponding to the chosen framework is missing, the project leader should take into account the learning curve of a framework, educational and ramp-up cost.

110

6. Conclusion

6.1. Work Overview Developing web applications has long been a problem due to the inability of HTML to cope with dynamic data delivery. A number of web frameworks have been developed recently that provide a way to overcome the difficulties of matching the requirement of e-Business. The literature research on the present solutions in the field of web application frameworks allowed one to indicate the five major types:

- MVC-Oriented approach - XML Publishing approach - Event – Handling approach - Template Engine approach - Component approach

From each category one framework is chosen for the comparison purpose: Cocoon, Struts, Velocity, JPublish and JSF. For the research purpose one proprietor framework was taken into the examination - InfoAsset Broker. In order to find out which criteria are the critical ones when choosing a framework for a particular application and hoe these criteria can be evaluated in the chosen frameworks, the case study was done. As a use-case for testing, the O2 Germany Online Shop prototype was implemented. This case study was chosen, since its implementation allows examining how the most common application functionality can be done with the use of different frameworks:

- User navigation. How easy it is to implement designed navigation scheme. - Categorized data publishing. A framework should be able to manage the data

coming from different sources and be flexible to allow the information to be delivered in the way it is defined by application designers.

- Form handling. All CRM applications use forms for getting the user data, therefore it is important to know how a framework handles reading these data, populating the forms, mapping them to object model.

- Form validation. If a framework provides help in form validation, it greatly reduces the programmers’ load, since it is a very diligent and not creative task

While implementing the Online Shop case study with each framework, other important issues were identified and classified:

− User Interface issues Separation of concerns Taglibs or template language Support of the multiple client type Localization

− Flow control issues Event handing MVC/Model 2 Workflow

− Server-side issues Form mapping and validation Error handling Component model

− Scalability − Tools integration

111

− Production presence − Learning curve − Maintenance − Integration ease

Every framework was analysed by each of the given criteria. On the basis of the analysis the evaluation table was created. This table is a formal support of the choice of a proper framework for an application. In order to use it, one should weight the criteria according to the preferences of the project being developed. The weighting was done for Online Shop and the most appropriate frameworks were defined: Struts with Velocity as a Template engine. Additionally to the criteria table, the profiling diagrams were built based on these criteria, the author’s experience and the experience of the frameworks community (shared by different mailing lists). These profiles correlate the types of the web applications, their complexity and the optimal framework choice. The work done during the presented research gives the structural view to the currently available large amount of different approaches and implementations of web application frameworks. It investigates these approaches and proposes the possible way and criteria for choosing the one most appropriate for a certain application.

6.2. Further work Currently one can see two ways for the further topic development. The first problem, which is not covered by the paper, is the cost analysis of the different frameworks for different types of web applications. The task needs the access to the different applications in different industries and interviewing the developers and project managers. This analysis would give a good insight to the project management of such applications and provide more precise evaluation of every technology. The current research talks only about presentation frameworks that give the business logic implementation to a developer decision. It is known, there are business layer frameworks available. It is necessary to investigate in this area and find out how these frameworks can collaborate with the presentation framework presented in this paper.

112

REFERENCES [J2EE Tutorial, 2003] Eric Armstrong, Jennifer Ball, Debbie Carson, Ian Evans, Maydene Fisher, Dale Green, Kim Haase, Eric Jendrock. J2EE 1.4 Tutorial. http://java.sun.com/j2ee/1.4/docs/tutorial ,2003. [Riele, 1996] Riehle and H. Zullighoven. Understanding and Using Patterns in Software Development. Theory and Practice of Object Systems, 2(1):3--13, 1996. [Appleton, 2000] Appleton, Brad. Patterns and Software: Essential Concepts and Terminology http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html, 2000 [Gabriel, 1996] Gabriel, Richard P., Patterns of Software: Tales from the software community. Oxford: Oxford University Press, 1996. [Alexander, 1977] Christopher Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King and S. Angel. A Pattern Language. New York: Oxford University Press, 1977. [Pattern Definition, 2003] Pattern homepage. http://hillside.net/patterns/definition.htm, 2003. [Coplien, 1998] J. O. Coplien "Software Design Patterns: Common Questions and Answers", in: Rising L., (Ed.), The Patterns Handbook: Techniques, Strategies, and Applications, Cambridge University Press, New York, January 1998. [Gamma, 1994] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley. October 1994. [Java BluePrints, 2003] Java BluePrints. Guidelines, Patterns, and code for end-to-end Java applications. http://java.sun.com/blueprints/patterns , 2003. [Shin, 2003] Sang Shin. MVC Pattern and Frameworks. Sun Microsystems Inc., 2003 [Holloway, 2003] Janathan Holloway. Web Application Framework – An Overview. University of Wales Aberstwyth, 2003. [Kochmer, 2003] Casey Kochmer. The JSPBuzz Newsletter. JSP Specific. http://www.jspinsider.com , 2003. [Merkay, 2002] Julien Merkay, Gilbert Bouzeid. Boost Struts with XSLT and XML. http://www.javaworld.com, 2002. [McCay, 2003] Larry McCay, Erik Bergenholtz, Craig McClanahan. Trail Map. http://developer.bluestone.com , 2003. [Cocoon userdocs, 2003] Cocoon user documentation. Understanding Apache Cocoon. http://cocoon.apache.org/2.1/userdocs/concepts/index.htm , 2003. [Cocoon Wiki, 2003] Cocoon Wiki http://wiki.cocoondev.org , 2003

113

[Velocity User’s Guide, 2003] Apache Velocity User’s Guide. http://jakarta.apache.org/velocity/user-guide.html , 2003. [JPublish Tutorial, 2003] JPublish Tutorial. http://www.jpublish.org/tutorial.html, 2003. [JPublish, 2003] JPublish web site, http://www.jpublish.org/tutorial.html , 2003 [JSR- 127, 2003] Java Specification Request 127. JavaServer Faces. Sun Microsystems Inc., http://jcp.org/en/jsr , 2003 [Kurniawan, 2003] Budi Kurniavan. Introducing JavaServer Faces. O’Reily onJava.com. http://www.onjava.com/pub/a/onjava/2003/07/30/jsf_intro.html , 2003 [Struts Project Pages, 2003] Struts Project Pages. The Apache Software foundation. http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsProjectPages, 2003. [infoAsset AG, 2003] Home page of the company infoAsset AG. http://www.infoasset.de/contents/products/index.htm, 2003. [FormProc, 2003] FormProc. Web Form Processing and validation, http://www.formproc.org, 2003. [Reynolds, 2003] John Reynolds. Field Validation Thoughts. http://weblogs.java.net , 2003 [Violino, 2003] Violino, B. How will you integrate technology with business? Computerworld, Volume 37, Framingham, 2003 [West, 1997] West E.J.W., Using the Internet for business-Web oriented routs to market and existing IT infrastructures, computer Networks and ISDN Systems 29, 1997 [KPGM, 1999] KPMG Consulting, Electronic Commerce Research Report 1999 [Anderson, 2000] Anderson Consulting, B2B eMarkets partner workshop. May 31-June 1, 2000 [Business Week, 1999] Zellner, Wendy and Forest, Stefanie Anderson. Retailing: The Big Guys Go Online. Business Week, 1999 [IBM, 2002] IBM Global Services. Caring for customers on the Web: New challenges fro e-business customer service. IBM, 2002 [Archer, 2002] Archer, N. and J. Gebauer. B2B Applications to Support Business Transactions: Overview and Management Considerations, Business to Business Electronic Commerce: Challenges and Solutions. M. Warkentin. Hershey, Idea Group Publishing, 2002 [Chen, 2001] Chen S. Strategic Management of e-Business. John Wiley & Sons, Inc., 2001 [Allen, 2000] Paul Allen. Realizing e-Business Through Components. Addison-Wesley Publishing Company, 2000

114

[Chen, 2003] Ying Chen. Evolution of E-business Application. Helsinki University of technology, 2003. [Samtani, 2002] Samtani, G., Sadhwani, D. Web Services and Application Frameworks. Working Together. Web Services Architect, 2002 [Ridruejo, 2002] Ridruejo, Daniel Lopes. Apache Overview. v.0.9, 2002 [Husted, 2002] Husted, T., Dumoulin, C., Franciscus, G., Winterfeldt, D. Struts in Action. Manning, 2002 [Langham, 2002] Langham, M., Ziegeler. C. Cocoon:Building XML Applications. New Riders Publishing, 2002 [Brown, 2000] Alan W. Brown. Large-Scale Component-Based Development. Prentice Hall PTR, 2000 [Linthicum, 2000] David S. Linthicum. B2B Application Integration. E-Business - Enable Your Enterprise. Addison-Wesley, 2000 [Harmon, 2001] Harmon, P., Rosen, M., Guttman, M. Developing E-Business Systems and Architectures. A Manager’s Guide. Morgan Kaufmann Publishers, 2001 Mail Archive for Users and Developers of Cocoon, Struts and Velocity. http://www.mail-archive.com

Documents

A Comparison of Web Visualization Frameworks for eBusiness ...€¦ · development frameworks, one can overcome many challenges of web application development. This research is dedicated