Model-Driven Development of Dynamic Web Applications

Extreme Markup Languages 2002

Montréal, Québec August 6-9, 2002

Model-Driven Development of Dynamic Web Applications Hideki Tai IBM Mari Abe IBM

Takashi Nerome IBM Masahiro Hori IBM

Abstract The World-Wide Web is increasingly used as a means for accessing on-line applications, although the Web was initially created to access documents. In contrast to data-intensive Web sites, dynamic Web applications are Web-based business applications that execute business logic for changing the business state captured by the system. Due to the central roles of business logic, it is important for the dynamic Web applications to be modeled focusing not only on the client-side presentation, but also on the server-side processing such as the execution of business logic and page-flow control. This paper proposes a Web Application Descriptor (WAD) for modeling dynamic Web applications, and presents a prototype of the Web Application Development Support Tooling (WAST), which is an environment for developing Web applications based on the WAD model. WAD specifies the navigational structure of Web applications, and prescribes the behavior of Web applications in terms of logical pages and actions used for directing the page flow. WAD allows modeling such page navigation flow at a description level independent of both the content view and the runtime application framework, so that it can be exploited for the conceptual design and execution of dynamic Web applications.

Rendered by www.RenderX.com

Model-Driven Development of Dynamic Web Applications Table of Contents 1 Introduction..................................................................................................................................... 1 2 Designing Dynamic Web Applications...........................................................................................2 2.1 WAD: Web Application Descriptor....................................................................................... 3 2.2 Example: A Simple Shopping Application............................................................................ 6 3 Development Environment............................................................................................................. 9 3.1 WAST Workbench............................................................................................................... 10 3.2 Conformance Checking........................................................................................................12 4 Related Work.................................................................................................................................13 Bibliography.....................................................................................................................................15 The Authors......................................................................................................................................17


Model-Driven Development of Dynamic Web Applications

Model-Driven Development of Dynamic Web Applications Hideki Tai, Takashi Nerome, Mari Abe, and Masahiro Hori

§ 1 Introduction The World-Wide Web is increasingly used as a means for accessing on-line applications, even though the Web was initially created to access documents. In contrast to data-intensive Web sites, Web applications implement business logic that changes business state information captured by the system. With particular emphasis on the aspect of business logic execution, such Web-based business applications are called dynamic Web applications in this paper. Due to the central role of business logic, it is important for the dynamic Web applications to be modeled focusing not only on the client-side presentation, but also on the server-side processing such as the execution of business logic and page flow control [Conallen 1999]. In pursuit of separating applications from presentation, a number of embedded scripting languages (e.g., JSP, ASP, and PHP) have been developed. Embedded scripting languages, which take a page-centric approach [Butler 2001], allow page authors to access application objects within HTML pages. Since those Web pages include script code or invocations of application code to be interpreted by an application server, they are often called server-side pages or server pages. Server pages process their own inputs (i.e., parameters from GET and POST), and the next page to display is determined by the current page being accessed. This architecture allows the clearer separation of presentation from application. However, such a Web application becomes difficult to maintain as the application grows and changes over time, because the page-flow control is distributed among individual pages. This disadvantage of the page-centric approach stems from the increased dependencies among the processing distributed in each server page. In order to reduce the complexity of interaction between the server pages, it was proposed to decouple the view components (i.e., server-side pages) from the server-side engine (e.g., Servlet), and place responsibility for page-flow control in a central controller. This design is known as the Front Controller pattern [Alur 2001], which centralizes control providing a central place to handle system services and business logic across multiple requests. As an architectural pattern, this design constitutes a Model-View-Controller (MVC) pattern for dynamic Web applications [Davis 2001], where the model encapsulates the application state, the view provides the presentation of the model, and the controller handles the incoming requests. A number of runtime frameworks based on the MVC are emerging as means for the development dynamic Web applications [Barracuda] [Struts] [Turbine]. In most large development projects for Web applications, programmers need to primarily work on the implementation of business logic, and presentation is left to Web page designers. This separation of the roles tends to make the deliverables technologically solid and well presented, but it requires the teams to collaborate and communicate together effectively. Despite the solid basis of the MVC pattern for the runtime behavior, the difficulty at design time is not necessarily resolved by the MVC pattern in itself. Therefore, it is important for the development of dynamic Web applications to be provided with tool support that facilitates consistent, effective creation of artifacts throughout the life cycle of the Web application, even for the modification or enhancement after the deployment of the application. The key issue in the current methodologies for the Web application development is that the application development is being conducted without any well-defined model of Web applications agreed upon by the various participants in the development process. The objective of this research is to develop technologies for model-driven Web application development, in which the development processes



page 1


proceed on the basis of a well-defined Web application model, so that consistency and integrity can be checked and maintained easily among various artifacts created by participants with different roles. In this paper, we present a model of dynamic Web applications called Web Application Descriptor (WAD) [Tai 2002], and Web Application Development Support Tooling (WAST). The WAST is an environment for the model-driven development, and developed on top of a Java-based open tool integration platform [Eclipse]. Note that although the WAD model and WAST workbench rely on the MVC architecture, they are independent of any particular implementation of runtime frameworks. The WAST workbench is realized as a tool framework that can be customized for different MVC-based runtime frameworks. In the next section, we briefly introduce the WAD model focusing on the navigation flow modeling, and give an example of a simple shopping application described with WAD. Section 3 explains the WAST workbench, which provides a visual editor for authoring the navigational structure of a Web application, as well as menu commands for code generation. Since the WAST workbench currently supports code generation for the Apache Struts [Struts] framework, examples of the generated artifacts are used as deliverables for the Struts framework. Finally, we compare our approach to the related work on Web application modeling.

§ 2 Designing Dynamic Web Applications JavaServer Pages technology [JSP] is becoming widely used for the development of dynamic Web applications. In the literature of JSP, the page-centric approach without any controller servlet is called a Model 1 architecture, while the elaborated design based on the MVC pattern is called a Model 2 architecture [Seshadri 1999]. The JSP Model 2 architecture decouples JSP pages and servlets, and places responsibility for page flow within the controller. Figure 1 illustrates the server-side MVC framework for the Model 2 architecture, and its runtime behavior is briefly described as follows. Each HTTP request is processed by a single controller servlet, which invokes the server-side actions by setting up new objects and/or calling methods. As a result of the action invocation, states of the server-side objects are updated, and the control is forwarded to a view represented as a JSP page, which in turn accesses server-side objects and generates a client view of the server-side model data.

Figure 1 MVC framework for dynamic Web applications

Although the MVC framework prescribes the architectural design of dynamic Web applications, the runtime module requires a variety of artifacts (such as JSP files, Java classes, configuration files written in XML), and the consistency among them needs to be carefully maintained. For example, when a page flow is dynamically determined as a result of a form action [Figure 2(a)], the page flow

page 2




may be controlled either by the form action [e.g., Java servlet code for "SearchProduct.do" in Figure 2(b)], or another action invoked following the form action. In such situations, it is not easy to change the destination even if the change is minor, such as changing the URI of the next page. In the WAST workbench, the tool user does not have to specify such URIs for page transitions explicitly, but the code generator automatically creates the URIs by referring to the page names given by the user.

Figure 2 Example of an input form and its HTML source

In addition, the parameter named "keyword" in Figure 2(b) will be accessed in the servlet code in the following manner. searchKeyword = request.getParameter("keyword");

A servlet programmer, who uses the form input data from the HTTP request, must be aware of and follow the naming convention of the parameter in the presentation page. Note here that the MVC runtime framework can neither maintain consistency nor detect mismatches between the parameter name for input and the index for the server-side access. Therefore, if the page author changes the parameter name from "keyword" to the upper case "KEYWORD" in the presentation page, the servlet programmer needs to make the corresponding change at the same time. The MVC runtime frameworks, however, does not support such design-time integrity checking. The goal of the WAST is to provide design-time supports for the development of dynamic Web applications, and the tool support includes the automatic creation of URIs consistent across the JSP pages and Java servlet code as well as the generation of action stub code typically used for conformance checking of form parameters. These features of the WAST workbench come from the model-driven approach, which relies on the specification of dynamic Web applications, namely, the WAD model.

2.1 WAD: Web Application Descriptor Web Application Descriptor (WAD) is a specification for describing the site structure or the navigation flow of dynamic Web applications, whose runtime framework follows the MVC architecture. A WAD allows describing the outlines of Web applications, and describes how pages are linked. In addition, WAD describes what and when the action is invoked, and how the action responds to an invocation. However, WAD includes neither the view of the content (i.e., page layout and image) nor the actual business logic (i.e., the Java implementation of action classes), which are open to the individual developer. The key components of the WAD specification are the navigation part and the action part. In the XML representation of WAD, the root element is "WAD", and consists of two primary elements: "NagivationPart" and "ActionPart". The specification of the WAD document structure is defined with the XML Schema [XML Schema-1 2001], and given in the WAD specification document [Tai



page 3


2002]. Figure 3 shows an overview of the WAD document structure using the notation of a class diagram of the Unified Modeling Language (UML) [Rumbaugh 1998]. Each rectangle in the figure corresponds to an XML element. The relations between an element and its content elements are indicated by the UML's notation for an aggregation or a whole-part relationship. For example, the rectangle for the "ActionGroup" element in Figure 3 is given with a diamond as the indication of the whole, since the "ActionGroup" has multiple "Action" elements as its children. Multiplicity of the association is shown as zero or one ('0..1'), zero or more ('*'), and one or more ('+'). When the multiplicity indicator is omitted, it means exactly one ('1'). In addition, constraints on the complex type definitions, such as "xsd:sequence" and "xsd:choice", are indicated by the brace ('{}') notation of UML.

Figure 3 Overview of the WAD document structure

The action part of WAD declares the interfaces of actions or business logic. The navigation part then allows specifying a complex navigation flow directed by the action invocation. The essential constituents of the navigation part are the nodes and ports (Figure 4). A node is provided with ports as points of connections with other nodes. A navigation flow arrives at an entry port and leaves from an exit port. While terminal nodes cannot be nested any more, a container node may comprise other nodes as its children. This containment relationship among WAD nodes makes the entire navigation structure a hierarchical directed graph of WAD nodes, and allows representing complex navigation flows in Web applications. There are three types of nodes in WAD: "LogicalPage", "ActionInvocation", and "Region". The first two are terminal nodes, and the region is a container node. A logical page is a virtual unit of presentation, and an action invocation indicates the invocation of an action or the execution of business logic. In the WAD document structure, the "NavigationPart" element has only one region element as the root region [see Figure 3 (a)]. Each region has one "Ports" element that has arbitrary number of "EntryPort" and "ExitPort" elements. In addition, the region element has a "RegionBody" element (Figure 5), which may have an arbitrary number of "Region", "LogicalPage", and "ActionInvocation" elements. Note that the "Region" element has a "RegionBody" and the "RegionBody" may have the "Region" as its immediate child element. Due to this recursive structure, the navigation part of WAD forms a hierarchical nesting by "Region" elements.

page 4




Figure 4 Illustration of ports and links

Figure 5 Illustration of hierarchical WAD region

The dynamic aspect of Web applications is prescribed by actions, which are defined in the action part of a WAD [Figure 3 (b)]. The primary role of an action is either accessing data on a server, or conditional branching for making decisions. An action represents business logic such as 'login', 'logout', 'setParams', and 'submit'. The proper invocation of actions in the navigation flow requires knowing which action in the action part is actually invoked, and indicating which exit port should be reached depending on the results of action execution. The association from "ActionInvocation" to a corresponding "Action" is indicated by the attributes of the "ActionMapping" element, which is an immediate child of the "ActionInvocation" element (see Figure 5). The association to an exit port is indicated by the attributes of the "PortMapping" element, which is an immediate child of the "ActionMapping" element. An example of the use of these elements is given in the next subsection.



page 5


Figure 6 WAD Ports as URI aliases

Ports in WAD can be regarded as aliases of URIs, which are identifiers of Web resources [URI 1998]. A resource that can be indicated by a URI includes not only entities (e.g., documents and images), but also actions or services on the Web. Figure 6 shows how the WAD nodes are connected via ports. In the graphic notation of WAD, a "LogicalPage", "ActionInvocation", and "Region" are respectively represented as a rectangle, triangle, and rounded rectangle. Note that every port that arrives at an entry port of the same terminal node (i.e., either "LogicalPage" or "ActionInvocation") can be regarded as an alias of the destination node URI. In Figure 6, for example, the exit ports indicated by "URI-act" are found in the action invocation node (e), the region (b), and the logical page (c). All of these exit ports are aliases of the entry port of the action invocation (f). In this way, the structure of the navigation flow in WAD is prescribed by the semantics of the URI connections. This assumption is reasonable for modeling dynamic Web applications, in which both action invocations and page references are uniformly indicated by URIs. In contrast, since previous works on modeling Web navigation treated the Web as a kind of hyper document [Atzeni 1997] [Fraternali 2000] [Isakowitz 1995] (often assuming relational databases as external data sources), they could only support the design of simple and static Web pages without any constructs for the actions to capture dynamic behavior.

2.2 Example: A Simple Shopping Application This subsection gives an example of a simple shopping application, in order to explain how the application can be described with the WAD model. The root region of the shopping application is illustrated in Figure 7. The root region is further decomposed into two sub-regions: Product Search Region and Cart Region. The product search region is the place where the shoppers try to find products from the store. The cart region provides simple shopping services for shoppers to add to and view the contents of a shopping cart. Since only the interfaces of the sub-regions and the links

page 6




among the regions are specified at this level, Figure 7 can be regarded as a template for this shopping application.

Figure 7 Root region in the shopping application

Figure 8 shows part of the XML representation of the portion of the shopping application corresponding to the root region. The "Region" element that is an immediate child of the "NavigationPart" element is the root region, which comprises two regions, the "ProductSearchRegion" and "CartRegion", as children of the "RegionBody" element. The root region has an entry port named "start" and holds a "Next" element (boldfaced in Figure 8). The attribute values of the "Next" element indicate that the entry port of the root region is connected to another entry port, which is named "start" and belongs to "ProductSearchRegion". This connection is depicted in the upper left of Figure 7.

... ... ... Figure 8 Navigation part of a WAD document for the shopping application

The cart region defines two entry ports and three exit ports. Figure 9 shows the navigation flow within the cart region. The two entry ports, "addToCart" and "viewCart", both reach the cart page after the action invocations. The "viewCart" entry port immediately calls the "GetCartData" action to obtain the current contents of the cart, while "addToCart" calls the "AddToCart" action before the invocation of "GetCartData". Therefore, the "viewCart" entry port is used as a shortcut for shoppers to examine the contents of the shopping cart without any addition to the cart.



page 7


Figure 9 Cart region in the shopping application

Figure 10 shows part of the "RegionBody" element of the cart region. The "RegionBody" element can have an arbitrary number of "Region", "LogicalPage", and "ActionInvocation" elements as nodes to be included in a region (Figure 5). The cart region here consists of three logical pages and two action invocations. Every "ActionInvocation" element needs to have an "ActionMapping" element, which further holds a "PortMapping" element (see Figure 5). The "ActionMapping" element holds a pair of "actionGroupName" and "actionName" attributes, and allows specifying a reference to an "Action" element included in the action part of the WAD. In addition, the "PortMapping" element holds a pair of "exitPortName" and "resultCode" attributes, and allow specifying a reference to an exit port to be connected to when the action invocation at hand returns the designated result code. Note that an exit port to be connected to as a result of action invocation must be one of the exit ports included in the "Ports" element of the same "ActionInvocation" element.

... ... ...

... Figure 10 "RegionBody" element of the cart region

For example, the "ActionMapping" element (boldfaced in Figure 10) indicates that an actual action is "AddToCart" action included in the "Cart" action group. In addition, the "PortMapping" element, which is a child of the action mapping, indicates that the action invocation needs to be connected to the exit port whose name is "OK" when the result code of the action invocation is "OK". Although setting these attribute values seem to be burdensome, the attributes can be set easily from the property sheet of the WAST workbench.

page 8




Figure 11 shows the "AddToCart" action of the "Cart" action group, which is referred to from the action mapping boldfaced in Figure 10. The "Action" element specifies an interface for the action by means of the "ActionParam" and "ActionResult" elements. In addition, the "ActionGroup" and "Action" elements allow associating the action with the name of a Java class to be executed as the action code. Although the association is made by using "Annotation" elements, the explanation of this annotation is beyond the scope of this article. See the WAD specification document for further details.

wast.application.action AddToCartAction ... Figure 11 Example of an action group for the cart region

§ 3 Development Environment The development process for dynamic Web applications is iterative and incremental. As shown in Figure 12, the WAST workbench provides five development scenarios distinguishing between the roles of page authors and Java programmers. In the figure, artifacts are indicated by a check mark if they are automatically generated. In addition, the artifacts that are generated automatically but which require further revisions are indicated by '(rev.)' along with the check mark.

Figure 12 Scenarios for the development of Web applications with WAST

The static preview scenario [Figure 12 (1)] is to create a mock-up application, in which all the logical pages are created as static HTML pages and solely with static page traversal. The test run [Figure 12 (2)] is a typical scenario during the iterative and incremental development, and can be started with automatically generated page stubs, action stubs, and a configuration file. The page stubs can then be incrementally replaced with page skeletons, whose layout and presentation are customized by a page author. In the same manner, the action stubs can also be incrementally replaced with action



page 9


skeletons, in which customized Java code is added by a Java programmer. Note that the test run scenario can be executed even with a mixture of the stubs and skeletons, both for the pages and the actions. In parallel with the test run scenario, page authors can conduct the view conformance checks [Figure 12 (3)] for testing customized page skeletons along with automatically generated action stubs and the configuration file. In this scenario, the page authors do not have to rely on any other artifacts that need to be customized by Java programmers. This assumption is crucial for allowing the page authors to proceed on their own work without regard to the progress of the Java programmers. The view conformance checking is explained later in this section with an example taken from the simple shopping application. In the same way, Java programmers can conduct the action conformance check [Figure 12 (4)] for testing customized action skeletons and the revised configuration file. The Java programmers can concentrate on their own work without regard to the progress of the page authors. Finally, the deployment scenario is to make the Web application available for field testing or actual use [Figure 12 (5)].

3.1 WAST Workbench In order to support the model-driven development based on the WAD specification, a development environment called the WAST workbench was developed on top of a Java-based open tool integration platform [Eclipse]. The high-level configuration of the WAST workbench is depicted in Figure 13. The WAST workbench consists of a WAD editor and tools for generating the artifacts necessary for a runtime environment.

Figure 13 Generation of artifacts by WAST

The WAST workbench is designed as a tool framework for development environments for dynamic Web applications, and can be customized for different runtime environments that follows the MVC architecture. Since the WAD is an application specification language independent of any particular runtime environment, the WAD editor itself can be common to every runtime framework. On the

page 10




other hand, in order to customize the workbench for different runtime frameworks, the generator modules (for views, actions, and configuration info) need to be tailored for the target runtimes. A screenshot of the WAST workbench is shown in Figure 14. The main part of the workbench is the WAD editor [Figure 14 (c)], which allows visual authoring of navigation flow within a WAD region. Upon the selection of a WAD node (e.g., a rectangle for a logical page or a triangle for an action invocation) in the editor, a corresponding item in the outline view [Figure 14 (d)] is highlighted. By clicking on an item in the outline view, the properties of the selected item are shown in the property view [Figure 14 (e)].

Figure 14 Screenshot of the WAST workbench

Once a WAD specification is created either completely or partially, the WAST workbench allows users to generate artifacts to be used for a runtime environment. The WAST menu in the workbench [Figure 14 (b)] provides commands for the generation of artifacts, and each command corresponds to a scenario given in Figure 13. Generated artifacts such as HTML/JSP pages and Java programs are listed in the navigation view of the workbench [Figure 14 (a)].



page 11


3.2 Conformance Checking This subsection explains the view conformance checking to be done by a page author in the course of the refinement of page skeletons [Figure 12 (3)]. The search page in the simple shopping application is taken as an example of a logical page to be customized. Figure 15 shows a portion of the Product Search Region, in particular the nodes and links directly related to the search page.

Figure 15 Product search region in the shopping application

On the basis of the WAD specification, the logical page for the search page can be generated as a page stub shown at the left side of Figure 16. The stub page displays the two exit ports: "viewCart" [Figure 16 (a)] and "listProducts" [Figure 16 (b)]. In the test run scenario, a stub for the search product action can also be available. When the "listProducts" button is clicked on the stub page, a stub for the search product action is invoked and a message dialog pops up as shown in Figure 16 (c). In this case, since the name of the form input parameter is consistent with the parameter access in the Java code, no error message is shown in the dialog. In addition, the dialog is provided with an "OK" button to proceed with the execution of the application, because the search product action has only one exit port with a result code "OK". If an action has two exit ports, a corresponding message dialog comes up with two buttons to direct the page flow directed for each result code.

page 12




Figure 16 Invocation of an action stub from a page stub

Figure 17 shows a customized search page that includes the two exit ports for "viewCart" and "listProducts" as in the page stub, but it is assumed here that the style of this page has been further refined by the page author. The input form here is essentially the same as the one shown in Figure 2 (a), and the source markup would look like as shown in Figure 2 (b). Now consider the hypothetical situation where a page author changed the name of the input form parameter in the course of the page customization from the lower case "keyword" to the upper case "KEYWORD". The small change creates an inconsistency between the input form in the related JSP page and the servlet code that accesses the parameter. If the page author runs the view checking on the shopping application [Figure 12 (3)], this inconsistency can be reported through a message dialog as shown in Figure 18. The dialog says that no valid action parameter is given and an expected parameter whose name is "keyword" is missing. This is because of the corresponding form parameter was submitted as an upper case name "KEYWORD". In this example it is impossible for the action stub to detect the exact error, but the report of the missing parameter helps the page author to understand that the JSP page is not consistent with the expected parameter of the action stub. Without this conformance checking support, it is quite difficult and time consuming for a page author to know what is wrong with the JSP file edited by the page author.

§ 4 Related Work The Unified Modeling Language (UML) [Rumbaugh 1998] notation is being extended with semantics and constraints that allow developers to model the business logic in Web applications. A UML extension [Conallen 1999], for example, allows representing the relationship between a form and a Web page by means of a submit association stereotype between the Form and Server Page stereotyped classes. However, since the UML extension provides no constructs for modeling actions or servlet controllers, it would not be straightforward to use this UML extension for modeling dynamic Web applications based on the MVC framework.



page 13


Figure 17 Example of customized page skeleton

HDM-lite is a hypermedia design model tailored to the development of Web applications, and used for specifying the structural, navigation, and presentation semantics for Web applications [Fraternali 2000]. The HDM-lite model integrates database and hypermedia modeling concepts with presentation abstractions for the Web context. The navigation semantics in HDM-lite are prescribed on the basis of the movement of the focus from one page to another, and are defined with presentation-related concepts such as accessing, filtering, and indexing. In contrast, the navigation semantics in the WAD model are prescribed on the basis of the semantics of the URI. This difference in the modeling perspectives stems from the intended scope of the Web applications. That is, HDM-lite assumes hypermedia-like data-intensive Web applications, and navigation in the presentation is the central issue. On the other hand, the WAD assumes dynamic Web applications with business transactions, and the navigation semantics need to capture the invocation of server-side actions as well as the page flow. HDM-lite also introduces the concept of region as a part of a screen to be scrolled independently. As in the WAD model, regions in HDM-lite may recursively contain other regions. However, the region in HDM-lite is essentially a unit of presentation, while the region in WAD is an arbitrary unit of a WAD document fragment for application reuse. This difference also came from the different emphasis of the modeling perspectives between the presentation centric approach in HDM-lite and the server-action centric approach in WAD. A development environment called Autoweb [Fraternali 2000] has been realized for data-intensive Web applications on the basis of HDM-lite. Although Autoweb allows code generation as well as mapping from relational database schema to presentation pages on the Web, Autoweb assumes the

page 14




Figure 18 Action stub dialog reporting missing parameter

CGI process as part of the runtime environment and cannot be exploited as currently exists for runtime frameworks based on the MVC architecture. Forms are an important part of the Web, and they continue to be the primary means for enabling interactive Web applications. XForms, which are the successor to HTML forms, provide a platform-independent markup language for online interaction between a form processor and a user agent [XForms 2002]. XForms separate the purpose of form filling (e.g., data collection) from the interactive presentation that allows the user to provide the required information by means of completing the form. WAD concentrates on the modeling of the action-based navigation flow, and is not concerned with how the form data is going to be filled in and how the interaction is presented. WAD concentrate on the results of such form filling as submitted data. A set of "ActionParam" elements included in the "ActionParamGroup" in WAD corresponds to such form data that will be processed by server actions. The action parameters are constrained by data-type restrictions, and it would be useful for WAD to use XML Schema data types [XML Schema-2 2001] for the type restriction in WAD.

Bibliography [Alur 2001] Alur, D., Crupi, J., and Malks, D.: Core J2EE Patterns: Best Practices and Design Strategies. Sun Microsystems Press Java Series, Prentice Hall PTR, Upper Saddle River, NJ (2001). [Atzeni 1997] Atzeni, P., Mecca, G., and Merialdo, P.: To weave the Web. Proceedings of the 23rd International Conference on Very Large Databases, pp. 206-215 Athens, Greece (1997). [Barracuda] Barracuda: MVC presentation framework for Web applications. Enhydra.org Project, http://barracuda.enhydra.org/ (2002).



page 15


[Butler 2001] Butler, M. H., Current Technologies for Device Independence. Technical Report HPL-2001-83, Hewlett-Packard Company (2001). [Conallen 1999] Conallen, J.: Modeling Web Application Architectures with UML. Communications of ACM, Vol. 42, No. 10, pp. 63-70 (1999). [Davis 2001] Davis, M.: Struts: an open-source MVC implementation. IBM developerWorks, http://www.ibm.com/developerworks/ibm/library/j-struts/ (2001). [Eclipse] Eclipse Platform. eclipse.org Consortium, http://www.eclipse.org/ (2002). [Fraternali 2000] Fraternali, P. and Paolini, P.: Model-driven development of Web applications: The Autoweb system. ACM Transactions on Information Systems, Vol. 28, No. 4, pp. 323-382 (2000). [Isakowitz 1995] Isakowitz, T., Stohr, E. A., and Balasubramanian, E.: RMM: A methodology for structured hypermedia design. Communications of ACM, Vol. 38, No. 8, pp. 34-44 (1995). [JSP] JavaServer Pages. Sun Microsystems, Inc., http://java.sun.com/products/jsp/ (2002). [Rumbaugh 1998] Rumbaugh, J., Jacobson, I., and Booch, G.: The Unified Modeling Language Reference Manual , Addison-Wesley Object Technology Series (1998). [Seshadri 1999] Seshadri, G.: Understanding JavaServer Page Model 2 architecture. JavaWorld.com, http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc_p.html (1999). [Struts] The Struts Web application framework. Apache Software Foundation, http://jakarta.apache.org/struts/ (2002). [Tai 2002] Tai, H., Nerome, T., and Hori, M.: Web Application Descriptor (WAD). Research Report RT-0468, IBM Tokyo Research Laboratory (2002). [Turbine] Jakarta Turbine. Apache Software Foundation, http://jakarta.apache.org/turbine/ (2002). [URI 1998] Uniform Resource Identifiers (URI): Generic Syntax. Internet Engineering Task Force (IETF), RFC 2396, http://www.ietf.org/rfc/rfc2396.txt (1998). [XForms 2002] XForms 1.0. W3C Working Draft, http://www.w3.org/TR/xforms/ (2002). [XML Schema-1 2001] XML Schema Part 1: Structures. W3C Recommendation, http://www.w3.org/TR/xmlschema-1/ (2001). [XML Schema-2 2001] XML Schema Part 2: Datatypes. W3C Recommendation, http://www.w3.org/TR/xmlschema-2/ (2001).

page 16




The Authors Hideki Tai IBM, Tokyo Research Laboratory 1623-14 Shimotsuruma, Yamato Kanagawa 242-8502 Japan [email protected]

Hideki Tai received his B.S in Information Sciences in 1995, and M.S in Information Sciences and

Electronics in 1997 from University of Tsukuba. His research interests include application development tools and runtimes. He is currently working at IBM Tokyo Research Laboratory. He is a member of the Information Processing Society of Japan. Takashi Nerome IBM, Tokyo Research Laboratory 1623-14 Shimotsuruma, Yamato Kanagawa 242-8502 Japan [email protected]

Takashi Nerome received his B.S.E and M.S.E. degrees, both in information engineering from

Ryukyu University, Japan in 1994 and 1996. His research interests include speculative processing and software development tools, develoment methods for web application. He is currently working at IBM Tokyo Research Laboratory. He is a member of the Information Processing Society of Japan. Mari Abe IBM, Tokyo Research Laboratory 1623-14 Shimotsuruma, Yamato Kanagawa 242-8502 Japan [email protected]

Mari Abe received her B.E in Electrical Engineering and M.E in Computer Science from Keio

University in 1998 and 2000, respectively. She is a Ph.D candidate at Keio University. Her research interests include Web content authoring and information visualization. She is currently working at IBM Tokyo Research Laboratory.



page 17


Masahiro Hori IBM, Tokyo Research Laboratory 1623-14 Shimotsuruma, Yamato Kanagawa 242-8502 Japan [email protected]

Masahiro Hori leads a research group for programming models and tools at IBM Tokyo Research

Laboratory. He received the M.E. and Ph.D. degrees in computer science from Osaka University in 1986 and 1989, respectively. His research interests include Web content authoring and adaptation, knowledge engineering methodologies, and object-oriented software reuse. Dr. Hori is a member of the Industrial Advisory Board of the IBROW project conducted under the IST program of the European Commission. He received Research Awards in 1992 and 1997 from Japanese Society for Artificial Intelligence (JSAI). He is a member of JSAI and the Information Processing Society of Japan.

Extreme Markup Languages 2002 Montréal, Québec, August 6-9, 2002 This paper was formatted from XML source via XSL Mulberry Technologies, Inc., August 2002

page 18

