Modeling Web Applications Using Java And XML Related Technologies

Modeling Web Applications Using Java And XML Related Technologies Sam Chung Computing & Stware Systems Institute Technology University Washington Tacoma Tacoma, WA 98402. USA chungsa@u.washington.edu Yun-Sik Lee Computer Engineering & Graduate School Venture Hoseo University Asan, Chungnam 366-795. Korea yslee@fice.hoseo.ac.kr Abstract The purpose this paper is to propose visual models for a web application using Java and XML related technologies. We consider a web application that uses 3- tier architecture and each tier is distributed onto web, application, and data base servers. In the web applications, various Java and XML related technologies are employed in the form different languages: clientside script language, server-side script language, objectoriented programming language, markup language, style sheet language, data language, schema definition language, etc. When diverse technologies are applied to a web application, stware engineers need to understand how the components using the technologies are interrelated in terms stware architecture. By applying the RUP with UML to the web application, we show how visual models can be constructed for the web application. Even, we show that we can model components in the web application using non objectoriented languages such as script, markup, style sheet, schema definition, and data languages. In order to compare the modeling complexity components, we propose a degree modeling complexity based upon two criteria - the degree language dependency and the degree location dependency. Through the comparison criteria, we try to quantify how relatively difficult it is for us to model which components. Based upon the degree modeling complexity, it is relatively difficult to model XHTML among components using non object-oriented languages. Among Java related technologies, since JSP has a higher degree language dependency and a higher degree location dependency, it is more difficult for us to model the JSP components. 1. Introduction Since the advent the Internet and World Wide Web (WWW) in the early 1990 s, many organizations have developed their own web applications by integrating WWW and their existing business logics. Due to two strong benefits web, any time anywhere, the size and the number web applications have been very rapidly increased. However, the maintenance a web application is getting difficult due to the inherent complexity the system [1, 2, 5, 8]. In this paper, we consider a web application that uses various Java and XML related technologies. The web application employs 3-tier architecture presentation, business logic, and data access tiers. For the presentation tier, extensible Hyper Text Markup Language (XHTML), Cascading Style Sheet (CSS), JavaScript, extensible Markup Language (XML), XML Schema Document (XSD), and Java Server Page (JSP) are used. For the business logic tier, JavaBean is used. For the data access tier, MySQL Database Management System (DBMS) and its type-4 Java Database Connectivity (JDBC) driver are employed. Each tier is distributed onto an Apache web server, a Tomcat JSP server, or a MySQL database server on a Linux platform, respectively. When diverse technologies are applied to a web application, stware engineers need to understand how components using the technologies are interrelated in terms stware architecture. In this paper, a component means a physical and replaceable part a system that confirms to provide the realization a set interfaces according to [2]. In order to explain stware architecture, a visual modeling technique has been used in stware industry. However, the previous modeling efforts have been limited to how to use a modeling language with a stware development process in order to develop stware architecture a stware system [2, 8] and have focused on systems using specific markup languages such as HTML or XML [3]. To model a web application using various languages and diverse technologies, we are interested in the following questions: How can we construct visual mode for a web application using Java and XML technologies? How can we model components in the web application using different language types such as

script, markup, style sheet, schema definition, and data languages, in addition to object-oriented language? How can we compare the models the components, based upon what criteria? The purpose this paper is to propose visual models for web applications using Java and XML related technologies and analyze the models based upon our novel criteria for relative model comparisons. For this purpose, a distributed computing environment for web application using Java and XML technologies is built and a web application is implemented in the environment. We consider a web application that uses 3-tier architecture and each tier is distributed onto web, application, and data base servers, respectively. By applying the Rational Unified Process (RUP) with Unified Modeling Language (UML) to the web application, we show how visual models can be constructed for the web application that uses objectoriented or non object-oriented languages. In order to compare the modeling complexity components, we propose two criteria the degree language dependency and the degree location dependency. Through the comparison criteria, we try to quantify how relatively difficult it is for us to model which components. This paper starts with previous efforts in modeling web applications in Section 2. In Section 3, a modeling process using UML, RUP, is described [2, 8]. In Section 4, a simple web application, which employs Java and XML technologies, is proposed as an example. In Section 5, based upon the approach in Section 3, we explain how visual models the web application in [4] are built. In Section 6, the visual models are analyzed in terms deployment, implementation, and design models. Also, for comparing different technologies, we propose two criteria and compare the technologies based upon the criteria. Finally, in Section 7, conclusions this paper and future areas investigation are presented. 2. Previous Efforts Since the Object Management Group (OMG) accepted the UML as the standard modeling language in 1997, many stware companies have adapted the UML to visualize, specify, construct, and document their stware products. Much information UML modeling has been published in [2]. Most the information was related to how to use UML with or without a stware process. Also, some researchers applied the modeling techniques to web sites, Java applets, and database. Conallen introduced an approach for modeling web application specific elements with UML [5]. By using UML extension mechanism, Conallen showed class diagrams specific web elements HTML such as forms, tables, etc. However, Conallen's approach is limited to design models web pages that strongly depend upon design/logical view and class diagrams. Booch and et al in [2] used class and sequence diagrams to model a simple Java applet. They showed a component diagram for a simple web page, which consists the applet and an image file. However, their main concern was to show an example models with UML. Recently, Carlson modeled XML by using a schema the XML [3]. The XML schema was relatively easily modeled by using the well-defined tree structure the XML. Also, for modeling database systems, UML has been used instead Entity-Relationship (ER) modeling. Gornik showed how UML could be used for data modeling in [7]. However, to the author s knowledge, all previous efforts were limited to an application using a specific language, not the whole web application, in which many different languages are used. 3. RUP with UML There are several different stware development processes [6]: extreme programming (XP), crystal family, open source, adaptive stware development, scrum, feature driven development, dynamic system development method, Rational Unified Process (RUP), etc. Among them, since the RUP supports different views for a stware system and its artifacts are more than source codes [8], it is chosen in this paper. By applying the RUP to a stware system, we can show architectural views models. In the RUP, models are the artifacts workflows. The RUP has six core workflows requirements, analysis, design, implementation, test, and deployment. The artifacts each workflow, visual models, are generated in an iterative and incremental manner through four phases inception, elaboration, construction, and transition. The artifacts each workflow in the RUP, the models, are visualized by using UML [2, 4]. Visual modeling is a process to visualize, specify, construct, and document work products in standardized diagrams. Since the advent UML in 1997, stware industries have rapidly accepted UML as a standard modeling language for stware intensive systems. UML supports nine diagrams: use case, class, object, component, deployment, sequence, collaboration, state chart, and activity diagrams. Some the nine diagrams are fully or partially used to represent the model. The artifacts each workflow are represented in a visual model to show an architectural view the workflow. Each model consists 4+1 views (use case

view, logical view, process view, component view, and deployment view). However, among the 4+1 views, the process view is integrated into use case and logical views within a UML supporting Computer Aided Stware Engineering (CASE) tool. Therefore, only 4 views, which are use case, logical, components, and deployment views, are practically shown in the CASE tool. Table 1 shows the relationships among models, views, and diagrams each workflow. 4. A Simple Web Application Considering the distinct characteristics a web application, we propose a simple web application with the following guidelines. The implementation the system should not be hard but shows the typical architecture a web application. The client-side scripting languages, server-side scripting languages, and application languages are similar to reduce the language learning time stware developers. The cost the development environment should almost be zero to make the stware developers free from stware licenses. Based upon the guidelines, we consider a simple web application: A client can create his or her user e-mail account through the Internet by entering a text e-mail name and a numeric e-mail name. The double e-mail accounts are detected when the client tries to enter the same text and numeric e- mail names. The entry is stored into a database. Internally, the system creates e-mail addresses for all clients by combining a text e-mail name, its numeric e-mail name, and the prefixed e- mail extension. The results are displayed in XML format to the system administrator to be transferred to other systems. To implement the demo system according to the given guidelines, first we consider three tier architecture presentation, business logic, and data access tiers. For each tier, we select proper technologies, languages, and open source (or free) stware components. We assume Linux platforms are used. For client-side script programming, JavaScript is selected. For server-side script programming, JSP is chosen. For developing server-side applications, JavaBean is used. To design an input web page, XHTML is used with CSS and the input data is validated with JavaScript. For displaying an output, XML is employed. For validating the XML, an XML XSD is implemented and published at a platform. To host web pages, an Apache web server is used. To support JSP and JavaBean, Tomcat JSP server and Java Standard Development Kit (SDK) are used. For data storage, MySQL DBMS and its JDBC are chosen. 5. Modeling a Web Application In this paper, since we assume that the simple web application was already developed and the source codes the system are only available, we do reverse engineering on the system. A visual model is generated at each workflow and the model is expanded at next workflow. The workflow starts from deployment and ends with requirement. Among the six workflows in Section 3, we consider three workflows that are strongly related to stware developers - deployment, implementation, and design workflows in order. 5.1. Building and analyzing the deployment model First, we start to build a deployment model, which is the artifact deployment workflow. In the deployment workflow, we are interested in the following questions: What workstations are employed to deploy the system? What packages and/or components are deployed onto the workstations? Where are the components located at the workstations? The questions system deployment can be answered by showing an architectural view a deployment model. The deployment model in Figure 1 shows that the web application is deployed onto a Linux platform called turing. The Linux platform consists three servers: an Apache web server shown as the httpd package, a Tomcat JSP server shown as the jakarta-tomcat-4.0.1 package, and a MySQL DBMS server shown as the mysql package. Two shell script files, java.sh and tomcat.sh, are used for Tomcat and Java SDK, respectively. For web-based input interface, email_info_entry.html is used. The HTML file uses a CSS file for display format, email_info_entry.css, and a JavaScript file for input data validation, email_info_entry.js. The email_info_display.html component calls email_info_insertion.jsp to store the given e-mail names into the Email_Info table in the HICSS database through a JDBC API, mm.mysql-2.0.11-bin.jar file. For webbased output interface, email_list_in_xml.jsp is used. The

email_list_in_xml.jsp displays the list e-mails all users in XML format. Figure 1 shows how components using different languages are represented in the deployment diagram by using file extension and/or file location information. By using the.html file extension, the email_info_entry.html shows that HTML is used. The Email_info_entry.js shows that JavaScript is used. The Email_Info_Entry.css means that it is an external CSS file. The jsp extensions both the email_info_insertion.jsp and the email_list_in_xml.jsp show that JSP is used for them. The EmailBean.class means that JavaBean has been used. The location HTML component is determined according to the web server s configuration. The HTML component is located at a special directory, public_html that can be recognized by the Apache web server. The locations JavaScript and CSS components are dependent upon how HTML components call. The JSP and JavaBean components need to be located in the Tomcat JSP server to be recognized. The relational database HICSS and its table Email_Info is recognized by their locations. MySQL DBMS includes the HICSS database and it has Email_Info table. 5.2. Building and Analyzing the Implementation Model In addition to components that are deployed for the web application, there are different types components such as source code files, library, and documents. In the implementation workflow, we are interested in the following questions: What components are used for implementing the system? How are the components interrelated to the components that were deployed in the deployment diagram? Where are the components located? These implementation issues can be explained by using the architectural view the implementation model. The implementation model in Figure 2 shows that a Java program, EmailBean.java, was implemented on another different platform, lovelace Windows workstation, and its compiled version, EmailBean.class, was deployed onto the Linux workstation, turing. Since the source program does not have to be deployed onto the production system called turing Linux server, it is found from a development system called lovelace Windows workstation. It shows that Java technology is platform independent and the JavaBean source code exists on a different machine. 5.3. Building and Analyzing the Design Model Third, we start to build a design model with UML. Although UML is a good modeling language, its foundation comes from object-oriented modeling concepts. A component can be implemented in either a non-object oriented language or multiple different languages. In the design workflow, we are interested in the following questions: How are the components designed? What packages are used? What classes which packages are used? The questions component design can be answered by showing an architectural view a design model. First, JavaBean is considered. A JavaBean is a reusable general-format component in Java that can be handled by JSP action tags. All attributes a JavaBean are private. The values the attributes are accessed through accessor methods the JavaBean. Since all properties JavaBean follow the ones Java and the UML supports object-oriented design, the modeling a JavaBean can be done easily by using class notation in UML. EmailBean.java is modeled in the class diagram Figure 3. Second, a database and tables the database are considered. Instead using the ER modeling on a relational table, a class in UML is used to represent the table. Attributes the class represent columns. Operations the class show entity integrity, referential integrity, or other constraints. A database is represented as a package in the class diagram. In Figure 4, the database HICSS package shows the HICSS database, in which there is only one table, Email_Info. Also, Figure 4 shows the directory structures org/gjt/mm/mysql and a class Driver for JDBC. Third, a CSS component is modeled by using a class diagram. A CSS component consists style rules. Each style rule consists a rule name and a rule definition. The rule name represents one or more system-defined class i.e. HTML tags or user-defined class names. (The class in CSS does not mean the class in object-oriented concept.) Each rule definition consists attributes and their values. In Figure 5, we assign each style rule to a class in UML. The class name shows a style rule name. Its attributes consist the rule definitions. Its operations are always empty. Fourth, a JavaScript component is modeled with a class. The class name a JavaScript component comes

from the logical interpretation its physical file name. A class for JavaScript may not have any attributes. Only the operations, which are function definitions in the JavaScript component, can be shown. Figure 9 shows a class diagram for a JavaScript Component. Fifth, an XHTML component is modeled in Figure 10. The predefined XHTML tags are defined as classes under xhtml package. The name the XHTML component is represented as the name the class. The names forms or tables are represented as attributes the class. By making separate components for CSS and JavaScript and saving them into separate packages, the XHTML modeling can be done on only XHTML tags. Sixth, an XML component is modeled in Figure 8. Instead modeling an XML format directly, the schema definition the XML format is modeled as Carlson used in [3]. From the given XML schema definition the XML format for displaying the e-mail list, the type names elements are used as class names. Seventh, JSP is modeled in Figure 9. Since various language types can be used in implementing a JSP component, a class diagram a JSP component is generally complicated. A general structure JSP is modeled in Figure 9. A directive in JSP is considered as a class with only attributes. The action tags are considered as operations in the JSP class. The class name a JSP component comes from the logical interpretation its physical file name. Also, many packages for JSP, java, and javax, are employed in the class diagram a JSP component. 6. Discussions on Models The deployment and the implementation models show distinct characteristics a web application. First, instead one type component, many different types components are deployed. Through the extensions each component in Table 1, we can guess how many different technologies are used. Second, components are distributed onto different platforms through the network. In this example, the source code a JavaBean and the XML schema document are developed at a Windows platform. However, their (executable) components are deployed at the Linux platform. In order to compare design models each component, we propose the degree modeling complexity. The degree modeling complexity represents how much the component is complicated for building its design model. The degree is measured by the combination the degree language dependency and the degree location dependency. The degree language dependency denotes how many different languages are used to implement the component. The degree location dependency shows how much the component needs to be located at a predefined directory. The degree language dependency has more effects on the degree modeling complexity than the degree location dependency does since the location dependency does not need specific modeling techniques, except for creating packages and showing their relationships. Table 1. Components and their file extensions Components File Extension Platform Definition s Email_Info_Entry.html XHTML Linux Email _Info_Entry.css Cascading Style Sheet Linux Email _Info_Entry.js JavaScript Linux email _info_insertion.jsp Java Server Page Linux email_list_in_xml.jsp Java Server Page Linux EmailList.xsd XML Schema Document Linux EmailBean.class Java Class Linux EmailBean.java Java Windows Table 2. The degree modeling complexity Lang. Low Medium High Loc. Modeling Complexity Low 0 Medium 1 High 2 Low 3 Medium 4 High 5 Low 6 Medium 7 High 8 Each degree can have low, medium, and high values as shown in Table 2. The values are determined relatively. If a component A uses more languages than another component B for implementation, the degree language dependency the component A is relatively higher than one the component B. If two components use only one language and the language a component is an object-oriented language, its degree language dependency is relatively lower to the other component. If

a component A uses more languages than another component B for implementation, the degree language dependency the component A is relatively higher than one the component B. If the component A s location needs to be predefined, its degree location dependency is higher than others. The value the degree modeling complexity is determined by the combination the degree language dependency and the degree location dependency. Each degree has a relative value from low, medium, to high. From the two criteria, there are nine combinations. If the combination two degrees is low and low, the lowest rank 0 is assigned to the degree modeling complexity. If the combination two degrees is high and high, the highest rank 8 is assigned to the degree modeling complexity. Since the modeling components using objectoriented languages are relatively easier than one components using non object-oriented languages, the degree modeling complexity is applied to the two different groups: one uses object-oriented languages. The other one uses non object-oriented language. Table 3. Comparisons modeling components using non-object oriented languages Languages Used Lang. Loc. Modeling Complexit y CSS Style sheet Low Low 0 Markup XHTM Style sheet High Medium 7 L Objectbased Markup XML Schema Medium Low 3 definition SQL Database Low High 2 Table 3 shows the measurements for components using non-object oriented languages with the values the degrees modeling complexity in Table 2. Based upon the degree modeling complexity, we can say that modeling a CSS component is relatively the easiest one among the four components. Since each rule in a CSS component is described in only one language and its location is not predefined, a CSS component can be easily modeled by using a class diagram. Modeling a component using SQL is relatively easier but harder than the CSS component since the tables are located within a database and the location database is defined by the given DBMS. Modeling XML is relatively easier than modeling XHTML components since XML support hierarchical concepts through a schema definition language and is represented by XML language. However, modeling an XHTML component is complicated since many different languages can be used for a web page implementation. For example, in-line or embedded styles and functions can be implemented by using CSS and JavaScript, respectively. In order to reduce the degree the language dependency, we can use modular design concepts. Each module uses only one language and can be imported or referenced from the XHTML file. Also, some XHTML components need to be placed at a special place according to web server configuration. Table 4 shows the degree modeling complexity for components using Java technologies with the values in Table 2. A JavaBean component can be modeled easily compared to a JavaScript component since it uses an object-oriented language Java. JavaBean and JSP components depend on the location the components since the JSP sever needs to recognize them. Since a JSP component can use different languages, its degree language dependency is high. Therefore, the modeling a JSP component is harder than other components. Table 4. Comparisons modeling components using java technologies Java Script JSP Java Bean Languages Used Objectbased Objectoriented Markup Style sheet Objectoriented Lang. Loc. Modeling Complexit y Medium Low 3 High High 7 Low High 2 7. Conclusions and Future Researches We show how we can model the architecture a web application using Java and XML related technologies. By applying the RUP to the system, we follow workflows the RUP. The results each workflow are represented in a model to show how the architecture the system looks like. A visual model consists four different views use case, logical, component, and deployment views. Each view consists some the nine UML diagrams. By incrementally and iteratively integrating the models workflows into a model, which we call a base model, the whole architecture is represented.

Second, we show that we can model components in the web application using non object-oriented languages such as script, markup, style sheet, schema definition, and data languages. By using UML and its customization notation, we can also model components using non object-oriented languages. Third, in order to compare the modeling complexity components using either object-oriented or non objectoriented languages, we propose the degree modeling complexity based upon two criteria degree language dependency and degree location dependency Fourth, by using the degree modeling complexity, we can quantify how relatively difficult it is for us to model which components. Based upon the criteria, it is relatively difficult to model XHTML among components using non object-oriented languages. Among Java related technologies, since JSP has a higher degree language dependency and a higher degree location dependency, it is more difficult for us to model the JSP components. The modeling components using non-objectoriented languages needs more researches. By using more examples the components, more modeling techniques need to be discussed. Also, by expanding the application modeling to more web applications, design patterns among the models need to be recovered to understand design ideas for other implementations. The design patterns can be used for reasoning better web application design. 8. References [1] Brereton, P., Budgen, D., and Hamilton, G. (1998). Hypertext: The Next Maintenance Mountain. IEEE Computer. December 1998. pp. 49-55. [2] Booch, G., Rumbaugh, J., and Jacobson, I. (1999). The Unified Modeling Language User Guide. Addison- Wesley, Menlo Park: CA. [3] Carlson, D. (2001). Modeling XML Applications with UML: Practical e-business Applications. Addison- Wesley, Menlo Park: CA. [4] Coleman, D. and et al. (1998). UML: the language blueprints for stware? OOPSLA, 1998. pp. 201-205. [5] Conallen, J. (1999). Modeling Web Application Architectures with UML. The Communications the ACM. October 1999. Vol. 42. No. 10. pp. 63-70. [6] Fowler, M. (2001). New Methodology. ThoughtWorks, Inc. http://martinfowler.com/articles/newmethodology.html [7] Gornik, D. (2002). UML Data Modeling Prile. Rational Stware White Paper. http://www.rational.com/media/whitepapers/tp162.pdf [8] Jacobson, I., Booch, G., and Rumbaugh, J. (1999). The Unified Stware Development Process. Addison- Wesley, Menlo Park: CA. Figure 1. Deployment model

Figure 2. Implementation model Figure 3. A class diagram for the EmailBean.java component Figure 4. A class diagram for the HICSS database and MySQL JDBC Figure 5. A class diagram for the email_info_entry.css component

Figure 6. A class diagram for the email_info_entry.js component Figure 7. A class diagram for email_info_entry.html component Figure 8. A class diagram for user_email_info.xsd component

(a) A class diagram for JSP (b) A class diagram for email_info_insertion.jsp component (c) A class diagram for email_list_in_xml.jsp component Figure 9. Modeling a.jsp component