Ghent University Faculty of Engineering. Department of Electronics and Information Systems Head of the Department: Prof. Dr. Ir. Jan M.

Transcription

1

2 Ghent University Faculty of Engineering Department of Electronics and Information Systems Head of the Department: Prof. Dr. Ir. Jan M. Van Campenhout Designing a Dynamic Development Environment for Web Design Author: Toon G.Y. Macharis Promotor: Prof. Dr. Ir. Rik Van de Walle Research Assistant: Ir. Erik Mannens Master s Thesis Submitted to Obtain the Degree of Master of Science in Computer Science Engineering Academic Year

3 Preface At university, I haven t only studied. I also have been involved in international student organisations. When I entered university, I was a shy and introvert person, but I wanted to change. I wanted to see the world, meet people and become more extrovert. I wanted to interact with people. I have travelled to a lot of countries as a student and I have done so many things that I think I ve learned more outside university than I think I could learn at university. I haven t learned science in my social life, this I could only learn at university, but I have learned social and organisational skills that complement the science that is thought at university. It is from my social experiences that I became aware that science is needed in society. More specifically, websites that offer services could be very useful to communities and communities are all around us. Any given group of people that share an identity form a community, whether it be a group of friends, a non profit organisation, a department of the government or a company, many of them can use their own website on which they can offer their services to the outside world. However, many of these communities stumble over the technical difficulties to set up their custom website. There is a community craze going around lately. Though, the business model of these community portals that claim to be worth in the billions of dollars is flawed [OpenCommunity]. Communities don t want to set up their website at a portal and be controlled by it. They want to have their own custom website made for them and under their own control. And that is what I want to help looking a solution for. I thank BEST [BEST] and ESN [ESN] for my nice experiences and giving me the inspiration. I thank my parents to keep supporting me even though I have taken some longer to graduate. I thank Erik Mannens for recognising the value of my research and assisting me in writing it as my Master s thesis. I thank professor Rik Van de Walle for allowing me to write my Master s thesis on the subject of my choice.

4 Copyright Notice The author gives permission to reproduce parts of this document or the whole for personal, non profit or commercial use without any request for permission or without any compensation. The author requests though that with any reproduction of parts of this document or the whole the link to is included as the original source.

5 Designing a Dynamic Development Environment for Web Design Author: Toon G.Y. Macharis Master s Thesis Submitted to Obtain the Degree of Master of Science in Computer Science Engineering Academic Year Promotor: Prof. Dr. Ir. Rik Van de Walle Research Assistant: Ir. Erik Mannens Faculty of Engineering Ghent University Department of Electronics and Information Systems Head of the Department: Prof. Dr. Ir. Jan M. Van Campenhout Summary The aim of this research is to establish a development environment that separates the structure of a web application from the technical details so that the structure of the web application can be managed without knowledge of the technical details. This will allow organisations to better control their websites. Keywords: Model-View-Controller, Web Application Framework, Java

6 Designing a Dynamic Development Environment for Web Design Abstract Author: Toon G.Y. Macharis The aim of this research is to establish a development environment that separates the structure of a web application from the technical details so that the structure of the web application can be managed without knowledge of the technical details. This will allow organisations to better control their websites. Keywords Model-View-Controller, Web Application Framework, Java Introduction A website may be a useful communication tool for many organisations. If the aim of the website is to only inform its visitors, static technologies as XHTML and CSS suffice. However, often it is desirable that an organisation does not only provide information on its website, but also services. Such software services can be implemented using a variety of technologies. From an organisation s point of view it often doesn t matter which technology is used to provide the services. Things that matter are solutions that are cheap, solutions that are delivered fast, solutions of which the structure can be easily adjusted and solutions that are portable and scalable. A very important quality for an organisation is that the organisation controls the structure of its website and can easily adjust this structure according to its requirements, which may change over time. All too often, organisations have limited control over their website. The reason for this is that often organisations themselves do not have sufficient technical skills to develop their website and therefore they are dependent on external partners. These partners usually offer technical solutions that are not transparent to the organisation. Because of the lack of transparency and the lack of knowledge on how to make changes to a technical solution, organisations are often forced to accept solutions as an indivisible all or nothing solution. Such solutions are costly, because an organisation can not ask one software developer to create one part of the website

7 and another software developer to create another part; instead the whole website has to be made by one software developer only. If the organisation wants an alternative, they have to ask another software developer to create a complete solution as well. Because of the lack of transparency, the organisation does not know that if a requirement that is not fully implemented as desired, it is because the technical cost would genuinely be too high or because the software developer does not have the proper skills and hides behind fake technical arguments. The lack of transparency also hinders adjustments to be made to the website when requirements of the organisation evolve, as this may lead to a complete new website. In short, organisations are often forced to accept a technical solution for their website of which the structure is not transparent to them and because of this lack of transparency they are delivered over to the goodwill of software developers, who often use their influence to their own benefit at the cost of the organisations. The aim of this research is to establish a development environment that separates the structure of a web application from the technical details so that the structure of the web application can be managed without knowledge of the technical details. This will allow organisations to better control their websites. For a business plan on how this approach may be economically viable, I refer to the appendix. I write this dissertation in English so people who do not speak Dutch can read it. There is also a Dutch translation of this dissertation. References

8 Table of Contents 1. Motivation State of the Art Struts XML Configuration View ActionForm Class Action Class Controller What is Wrong with Struts Analysis of Struts An Alternative to Struts Software Architecture Requirements Functional Requirements Integrating Functionality Integrating the User Interface Quality Attributes Usability Flexibility Modifiability Portability User Management Use of EJB Architecture Module Decomposition View Process View Allocation View Planning Iterative Development Iteration Iteration Iteration Iteration Risks Dynamic Class Loading Remote Files Lightweight Persistence Flow Charts and User Management Independent Parts... 40

9 5. Demonstration Configuration Building a Simple Calculator The Model The View The Controller Element Container Element Registry Component Registry Application Configuration Demonstrating the Simple Calculator Restoring the Calculator Extending the Calculator The Model The View The Controller Demonstrating the Extended Calculator Demonstrating the Final Calculator Further Work Conclusion Appendices A Bibliography B Table of Figures C Software Schemas C.1 Preliminary C.2 Element Container C.3 Element Registry C.4 Component Registry D Business Plan

10 List of Abbreviations AJAX: Asynchronous JavaScript and XML, a web technology that allows dynamically updating some content of a webpage without having to refresh the whole webpage. API: Application Programming Interface, a set of interfaces through which certain functionality is accessible. CSS: Cascading Style Sheets, a web technology that specifies the presentation of certain XML elements. EJB: Enterprise JavaBeans, a subset of the Java Enterprise Edition technology. GPL: GNU General Public License, a free software license. GUI: Graphical User Interface, a graphical presentation through which a user interacts with a system. IDE: Integrated Development Environment, a software application that assists in developing software. JAR: Java ARchive, a file standard that extends the ZIP standard and allows bundling multiple files in one archive file. JNDI: Java Naming and Directory Interface, a Java API that gives access to a directory service. Data and objects are accessible through the directory service with their identifying name. JSP: JavaServer Pages, a Java technology that allows scripting in XHTML or other XML pages. LOB: Large Object, an object with an unspecified size and a high maximum size limit in a database.

11 MVC: Model-View-Controller: a software pattern that separates the software functionality from the user interface. PACITA: Pages, Actions and Conditions Iterations Abstraction, the name of the web application framework developed in this dissertation and the acronym of the three pillars around which it is built. PHP: PHP: Hypertext Preprocessor, a technology that allows scripting in XHTML pages. UML: Unified Modeling Language, a standardised specification language for object modelling. URI: Uniform Resource Identifier, a string used to identify a resource. URL: Uniform Resource Locator, a URI that also specifies how the identified resource can be accessed. SQL: Structured Query Language, a standard query language to manipulate data in a relational database. XHTML: Extensible HyperText Markup Language, a markup language for web pages that conforms the XML syntax. XML: Extensible Markup Language, a data format in which the structure of data is stored with the data and the structure is organised as nested, human readable tags.

12 Designing a Dynamic Development Environment for Web Design Every act of creation is first of all an act of destruction. Pablo Picasso 1. Motivation A website may be a useful communication tool for many organisations. If the aim of the website is to only inform its visitors, static technologies as XHTML and CSS suffice. However, often it is desirable that an organisation does not only provide information on its website, but also services. Such software services can be implemented using a variety of technologies. From an organisation s point of view it often doesn t matter which technology is used to provide the services. Things that matter are cheap solutions, solutions that are delivered fast, solutions of which the structure can be easily adjusted and solutions that are portable and scalable. A very important quality for an organisation is that the organisation controls the structure of its website and can easily adjust this structure according to its requirements, which may change over time. All too often, organisations have limited control over their website. The reason for this is that often organisations themselves do not have sufficient technical skills to develop their website and therefore they are dependent on external partners. These partners usually offer technical solutions that are not transparent to the organisation. Because of the lack of transparency and the lack of knowledge on how to make changes to a technical solution, organisations are often forced to accept solutions as an indivisible all or nothing solution. Such solutions are costly, because an organisation can not ask one software developer to create one part of the website and another software developer to create another part; instead the whole website has to be made by one software developer only. If the organisation wants an alternative, they have to ask another software developer to create a complete solution as well. Because of the lack of transparency, the organisation does not know that if a requirement that is not fully implemented as desired, it is because the technical cost would genuinely be too high or because the software developer does not have the proper skills and hides behind fake technical arguments. The lack of 1

13 transparency also hinders adjustments to be made to the website when requirements of the organisation evolve, as this may lead to a complete new website. In short, organisations are often forced to accept a technical solution for their website of which the structure is not transparent to them and because of this lack of transparency they are delivered over to the goodwill of software developers, who often use their influence to their own benefit at the cost of the organisations. The aim of this research is to establish a development environment that separates the structure of a web application from the technical details so that the structure of the web application can be managed without knowledge of the technical details. This will allow organisations to better control their websites. For a business plan on how this approach may be economically viable, I refer to the appendix. I write this dissertation in English so people who do not speak Dutch can read it. There is also a Dutch translation of this dissertation. 2

14 2. State of the Art 2.1. Struts There exist frameworks that separate a certain structure from a website from its technical implementation. These frameworks are often tied to a certain technology. The technology I will be considering will be Java. I have extensive experience with the popular scripting language PHP, though it is my opinion that Java is technically superior to PHP [JAVAvsPHP]. The only advantage PHP has over Java is that in practice there appear to be more PHP hosting providers than Java hosting providers and that one can find a cheap PHP hosting solution more easily than a cheap Java hosting solution. Java has fewer bugs, is more portable, has a broader API and has better development tools than PHP. One may argue that Java is not the best technology out there for making web applications. I think it is. I am not going to argue here what is the best technology indeed. I think every technology that solves your needs is valid. For me, Java does the trick, so I am going to stick with Java. I need to choose some technology to start working with, but the concepts I will be working out, will be applicable to all viable technologies. The most popular web framework for JAVA at the moment of writing is Struts [Struts1]. According to a recent article announced on this website [Struts2], Struts is still not over the peak of its popularity. In this chapter I will be explaining how Struts works. I used the tutorial [Struts3] as inspiration. 3

15 2.2. XML Configuration The Struts framework consists of 2 parts. One part consists of JSP pages that are used for sending output to the user and the other part consists of actions that process input from the user and forward to the new output after processing. Every action consists of 2 parts: an ActionForm object and an Action object. The ActionForm object contains the input from the user and the Action object processes the input. The ActionForm object and the Action object have to be configured in the WEB-INF/struts-config.xml file as explained below. The structure of the WEB-INF/struts-config.xml file looks like: <struts-config> <form-beans> <!-- ActionForm objects are defined here --> </form-beans> <action-mappings> <!-- Action objects are defined here --> </action-mappings> </struts-config> The definition of an ActionForm object looks like: <form-bean name="customform" type="strutsexample.customform"/> In this, the value of the name attribute defines the name of the ActionForm object and the value of the type attribute defines the fully qualified name of the ActionForm class. The definition of an Action object looks like: <action path="/customaction" type="strutsexample.customaction" name="customform" input="/error.jsp" scope="request"> <forward name="odd" path="/odd.jsp"/> <! there can be multiple forward tags --> <forward name="even" path="/even.jsp"/> </action> 4

16 A description of the attributes of the action tag: path: defines the URL pattern for which the action is executed. For this example, the custom action is executed at the URL pattern /customaction.do. type: defines the fully qualified name of the Action class name: defines the ActionForm object that is associated with this Action object input: defines the URL pattern to which control is forwarded if the ActionForm object generates an error while validating the input scope: defines the scope of the ActionForm object. This can either be request scope or session scope. The forward tags nested under an action tag define the URL patterns to which control can be forwarded after successful execution of an action. 5

17 2.3. View The view of a Struts application is implemented by JSP pages. These JSP pages have to use Struts custom tags instead of the XHTML input elements. The URL of the tag library descriptor of the struts input custom tags is WEB-INF/struts-html.tld. The source code of a webpage in a Struts application may thus looks like: <!-- imports the Struts custom tags --> <%@taglib uri="/web-inf/struts-html.tld" prefix="html"%> <html> <head><title>insert a Number</title></head> <body> <html:form action="customaction.do"> Insert a number: <html:text property="value"/> <html:submit/> </html:form> </body> </html> A browser would render this JSP page to: Figure 1: The Struts example JSP page seen in a browser If one clicks the submit button, the struts action associated with the URL pattern customaction.do is executed. If we use the XML configuration of the previous paragraph, clicking the submit button would cause the execution of a strutsexample.customaction Action object which in turn would use a strutsexample.customform ActionForm object to hold the input data. 6

18 2.4. ActionForm Class An ActionForm class is a normal Java class that extends the class org.apache.struts.action.actionform. The ActionForm class contains the properties that are defined in a JSP page that calls an associated action. The ActionForm class follows the JavaBeans specification [JavaBeans] for accessor methods to the properties. In the example of this chapter, the JSP page has one property, namely value and therefore, the ActionForm class defines the methods setvalue and getvalue. The ActionForm class may also override the validate method of its base class. Therefore, the ActionForm class definition could look like: package strutsexample; import javax.servlet.http.httpservletrequest; import org.apache.struts.action.*; public class CustomForm extends ActionForm { private String value; public void setvalue(string value) { this.value = value; } public String getvalue() { return value; } } public ActionErrors validate(actionmapping mapping, HttpServletRequest request) { ActionErrors errors = new ActionErrors(); try { Integer.valueOf(value); } catch(numberformatexception e) { errors.add("value", new ActionError("error.value")); } return errors; } Before an Action object processes the input from a JSP page, a new ActionForm object is created and its properties are set with its set-methods and the values of the properties in the JSP page. Consequently, the validate method of the ActionForm object is executed. If this method returns a non empty ActionErrors object, control is forwarded to the URL pattern that is defined in the input attribute of the action tag in the XML configuration. If the validate method returns an empty ActionErrors object, control is forwarded to the Action object. 7

19 If the validate method returns a non empty ActionErrors object, the errors in this ActionErrors object may be written to the output with the custom tag <html:errors/>. For proper output, one has to define the error messages in the file WEB- INF/classes/ApplicationResources.properties as in: errors.header=<b> errors.footer=</b> error.value=the inserted value is not a number! The effect of the <html:errors/> custom tag is that first the string associated with errors.header is written to the output, then one after the other the strings associated with the error.property values that are in the ActionErrors object and finally the string associated with errors.footer. 8

20 2.5. Action Class An Action class is a normal Java class that extends the class org.apache.struts.action.action. The Action class overrides the perform method of its base class, which is executed to process the input. In the example of this chapter, the Action class definition could look like: package strutsexample; import javax.servlet.http.*; import org.apache.struts.action.*; public class CustomAction extends Action { public ActionForward perform(actionmapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { CustomForm customform = (CustomForm)form; int value = Integer.valueOf(customForm.getValue()).intValue(); if ((value % 2) == 1) { return mapping.findforward("odd"); } else { return mapping.findforward("even"); } } } The perform method of the Action class is executed if the validate method of the ActionForm object has returned an empty ActionErrors object. The ActionForm object is passed as argument to this method. The Action object can access the properties of the JSP input page through this ActionForm object. After processing the values of the properties, the perform method returns an ActionForward object. This ActionForward object is created by calling the findforward method on the ActionMapping object that is passed to the perform method as an argument. The argument for the findforward method is the value of the name attribute of a forward tag nested in the action tag that defines the action object in the XML configuration. Control is forwarded to the URL pattern associated with this forward tag. 9

21 2.6. Controller The controller of the Struts framework consists of a servlet that is associated with the *.do URL pattern. Every time a request is made to such a URL pattern, the servlet identifies the URL pattern with an Action object and an associated ActionForm object. A new ActionForm object is created and its properties are set by calling the appropriate set-methods. The ActionForm object is validated. If there are validation errors, control is forwarded to a URL pattern that handles the validation errors. Otherwise, a new Action object is created and its perform method is executed to process the input. After processing the input, the perform method returns an object that determines to which URL pattern control is forwarded next. 10

22 3. What is Wrong with Struts 3.1. Analysis of Struts Struts is a technical solution for technical people. Moreover, one can conceive more elegant technical frameworks. Though Struts enforces to structure web applications into actions and pages and though the structure is separated from the code in the XML configuration file, it is hard to imagine that organisations are willing to understand the structure in the XML configuration file, let alone to manage it. Even though Struts may be a big aid for software developers, it hardly is of any use for an organisation that can t see through the technical obscurities. Organisations see Struts projects as monolithic solutions as well. If one is willing to step out of the realm of technical complexities for a moment and considers the absolute minimum of concepts that are necessary to describe the structure of a website, he may well come close to a design for a framework that is very user friendly. Let s take a first aim at it. Figure 2: an illustration of the basic definition of a computer or an information system 11

23 With some imagination, one can consider the figure on the left of Figure 2 as a user and the box on the right as a system he interacts with. The user gives input to the system. The system processes the input and returns the result of the processing to the user. The user observes this output, interprets it and invokes a new input. In all its simplicity, one may forget that Figure 2 illustrates the basic definition of a computer or an information system. Though, Figure 2 doesn t expose much structure. Let us therefore split the information system in 3 parts as in Figure 3. in User Interface View Functionality Model Presentation Controller Application Logic Output Data Resource Management out Figure 3: an information system split up according to the Model-View-Controller pattern 12

24 An information system can be split up in 3 parts according to the Model-View- Controller 1 pattern. The view is the part that a user interacts with: it shows the output to the user and it intercepts input from the user. It consists of the output data, the way it is presented and triggers for input. The model contains the functionality of the system. This functionality consists of the processing of user input (the application logic layer) and of input and output to other information systems (the resource management layer). The model consists of the dead code of the application. The controller is a running program that intercepts input from the user, interprets the input and dispatches the input to the right part of the model to process the input. When the input is processed, the controller intercepts the result, interprets how the result has to be presented and sends the presentation to the user. The controller glues the view to the model. The controller is generic. The view and the model on the other hand are highly customised. Also in contrast with the model, the controller is a living program that activates parts of the model when they are needed. If we analyse Struts, we find that the view consists of the JSP pages with the Struts custom tags; the model consists of the Action and ActionForm classes and the underlying logic they access; the controller consists of the servlet associated with the *.do URL pattern and the XML configuration file. 1 Apparently there are many different interpretations of the Model-View-Controller pattern. The only thing that all these different interpretations have in common is that they consist of three different parts. In some interpretations, the View is directly coupled with the Model or vice versa [MVCwiki]. Some other interpretations identify the Controller with the Application Logic Layer and the Model with the Resource Management Layer [CakePHP]. The interpretation of the Model-View-Controller pattern that I present is the most modular interpretation. 13

25 3.2. An Alternative to Struts In this dissertation, I will develop an alternative to struts. I will call the alternative framework PACITA (which is an acronym for Pages Actions Conditions, ITerations and Abstraction). The Struts framework and the PACITA framework are compared to each other in Figure 4. Struts deployed PACITA on the fly View Controller Model local pages only XML configuration local classes only JSP pages with struts custom tags for in and output local and remote pages JSP pages with 1 data custom tag for output GUI configuration with storage in XML Action class for actions ActionForm class for data no interface for conditions no interface for user accounts local and remote classes Action interface for actions Data interface for data Condition interface for conditions UserAccounts interface for user accounts Figure 4: comparing the Struts framework to the PACITA framework A first difference is that with the Struts framework, an application will have to be deployed to the server together with the Struts framework. Changing the application requires undeploying the old application and redeploying the new application. With the PACITA framework, only the framework itself has to be deployed to the server. The view and the model can be plugged into the system on the fly without requiring deployment. A second difference is that the Struts framework only can handle local pages and local classes. The PACITA framework can configure pages and classes that are on a remote server as well. Struts is configured in an XML file. PACITA is configured with a graphical user interface. The configuration of the PACITA framework can be exported to or imported from XML files. 14

26 Struts requires the use of a multitude of Struts custom tags to send input from or output to JSP pages. PACITA allows the use of standard XHTML input elements to send input from JSP pages and requires the use of only one generic data custom tag to send output to JSP pages. The data of a data custom tag can access the data of a parent data custom tag and the data of a data custom tag can be iterated. Struts uses the Action and ActionForm base class for actions and data. PACITA uses the Action and Data interface for actions and data. Struts has no interfaces for conditions or user account lists. PACITA uses the Condition interface for conditions and the UserAccounts interface for user account lists. Conditions make it possible to explicitly add control flow to the action chain structure. In Struts, an action decides internally about the next ActionForward and therefore, the control flow in Struts is not part of the external structure. The user account lists make it possible to define user groups. PACITA allows restricting access to parts of the user interface or certain functionality. The access can be restricted for certain users or for certain conditions to be met. Struts does not support restricting access to the user interface or to certain functionality. Because an application that uses the Struts framework has to be deployed to the server and because the structure of the application is configured in an XML file, it is probable that a technically skilled person takes care of installing a Struts application. The PACITA framework allows assembling an application on the fly with a GUI using remote classes and pages. The GUI reduces the technical complexities and therefore it is easier for an organisation to handle, whereas the inclusion of remote classes and pages makes it easier to split up the development of a web application in several roles that correspond with the parts in the Model-View-Controller pattern. The development of a web application may be split up in three roles as illustrated in Figure 5. layer View Controller Model actor user author editor linker designer programmer responsibility interacts with result formats pages manages components manages elements defines functional interfaces implements functionality Figure 5: development pipeline with roles split in accordance with the MVC pattern 15

27 One role corresponds to the model, in which a software developer provides the requested functionality. Another role corresponds to the view, in which a web developer provides the requested pages. The third role corresponds to the controller, in which the organisation integrates the delivered pages and functionality in its web application. It is noteworthy that a web application does not have to be developed at once. All of the three roles can work relatively independent of each other and build on partial results of the others. The web application can evolve in iterations. A website is not anymore an indivisible all or nothing realisation that lacks transparency, but a flexible structure that can be adjusted easily. The GUI and the flexible structure of the controller allow for iterative development of web applications. Advantages of iterative development are: fast results: part of the functionality can be used right away, instead of having to wait until all the functionality is implemented. Likewise, a preliminary user interface can be used before a more polished one is completed. low test costs: mistakes are discovered early on, while they are not accumulated yet, which makes it much easier to adjust them than if they would come all at once. high responsiveness: because of the early results, they can be evaluated fast and if an adjustment in the path of development would be desired, the development can be changed fast in the next iteration. 16

28 4. Software Architecture 4.1. Requirements Functional Requirements The functional requirements for the PACITA framework are on the one hand that functionality can be integrated in the web application and on the other hand that a user interface can be integrated in the web application Integrating Functionality Functionality is integrated by classes that implement one of the interfaces shown in Figure 6. Serializable Action execute(request : HttpServletRequest) Element Condition test(request : HttpServletRequest) : boolean UserAccounts Data check(user : String, password : String) : boolean getallusernames() : String[] getdatabean(session : HttpSession) : Object Figure 6: the interfaces for classes that provide functionality for the PACITA framework Classes that implement one such interface are called elements, as they are elementary or essential to provide the functionality of the system. 17

29 Integrating the User Interface The structure of the User Interface is composed by components. There are three different kinds of components: Page components constitute the view of the web application. A page component outputs the content of the web page that is linked to the component. A page component contains triggers for processing input. If a trigger is activated, control is forwarded to the component that is linked to the trigger. A page component contains beans that output dynamic content. A bean is a JavaBean object that is returned by the getdatabean method of the Data element that is linked to the bean. Action components are a part of the controller of the web application. An action component processes input by calling the execute method of the Action element that is linked to the component. After execution of the action, control is forwarded to the next component that is linked to the action component. Condition components are the other part of the controller of the web application. A condition component tests a condition by calling the test method of the Condition element that is linked to the component. If the condition holds, control is forwarded to the next positive component that is linked to the condition component. Otherwise, control is forwarded to the next negative component that is linked to the condition component. 18

30 The structure of a user interface that is composed by components can be shown graphically in a flow chart as in Figure 7. Calculator error result input calculate calculate input is number is reset reset is add add is subtract subtract Figure 7: the user interface components of a simple calculator A page is represented as how a class is represented in a UML schema. It is represented by a rectangle consisting of 3 sub-rectangles. The first sub-rectangle shows the name of the page, the second the beans of the page and the third the triggers of the page. Actions are represented by ovals and conditions by diamonds. Arrow connections between the figures represent the linking between the components. A flow chart as in Figure 7 can give a clear view of the structure of a website as opposed to configuration information in XML files. The PACITA framework aims to support such flow chart views over time. 19

31 Quality Attributes The functional requirements determine what the PACITA framework should do, while the quality requirements determine the architecture of the framework. The desired qualities for the framework are mentioned (in order of importance): Usability The most important quality for the PACITA framework is that it is usable. The framework has to be user friendly for an organisation. The organisation must be able to define the architecture of a website in a clear and simple way. Defining the architecture of a website must not require coding or configuring XML files. The architecture of a website must be defined with a user interface. The initial user interface will be as in Figure 8. Figure 8: the user interface of the PACITA framework The configuration of a web application occurs in 5 steps. These 5 steps will be explained in the next paragraph. The 5 tabs on top of the GUI correspond with these steps. One can switch between steps in the configuration by clicking the tabs. Every step has a sub-menu that consists of the icons in the left margin. One can switch between sub-steps by clicking these icons Flexibility If we assume the Model-View-Controller pattern as described in 3.1, we can deduce 3 different steps to configure a web application. One of the steps integrates the functionality in the web application. Another step integrates the pages in the web application. A last step restricts the access to pages and functionality to certain users and conditions. 20

32 However, if we only use 3 steps, we have to couple the user interface directly to the functionality. If we then update the functionality, we have to update the user interface as well. This is illustrated in the next figure. Figure 9: illustration of coupling (top) and decoupling (bottom) between front end and back end As an example, assume that there is a Data element that shows a picture album on a page 2. The page in question shows the last photo album that has been added to the web application. If a new photo album is added, the page has to link to another Data element. We can do this by replacing the old Data element with the new Data element in the step that links the Model without affecting the page. However, another page may still have to link to the old Data element. If we replace the old Data element with the new Data element, this other page will also link to the new Data element; unless there is a level of indirection. Therefore, we do not link components to elements directly. Instead we link components to references that link to elements. If a component has to link to a new element, the links from the components to the references can stay unchanged. Only the reference has to be linked to the new element, while no other references are affected. In the example, both pages can link to a different reference. These references initially point to the same old Data element. If we update one of the references to link to a new Data element, the other reference still points to the old Data element. 2 It is possible to program Data elements that show different photo albums depending on some input arguments. I assume here a Data element that does not interpret its input and always outputs the same photo album no matter what. 21

33 Therefore there are two steps for the Model instead of one. The first step is the Element Container step that links functionality in the system. The second step is the Element Registry step that contains references to the elements in the system. There are also two steps for the View. The first step for the View is the Component Registry step. This step defines the components of the user interface. The second step is the Application step and forms a level of indirection to the application composed by the components. This indirection allows one reference to an application to be updated while another reference to the same application can keep running the old application. The fifth step is the User Management step that allows restricting the access to the functionality and the user interface. The principle of decoupling by adding a level of indirection is also applied to pages. Pages do not link directly to the data they contain nor to the components that can be triggered from the page. Instead bean names link to Data elements and trigger names link to components Modifiability Not all required functionality can be developed right away and requirements may evolve over time, therefore the PACITA framework has to be able to evolve. This is made possible to a great extend by making the framework modifiable. The following measures are taken in the architecture of the framework to make it modifiable: The user interface of the framework is made independent of the application logic. They are explicit separate projects. The user interface can be changed without affecting the application logic. The user interface of the framework itself is made with a preliminary version of the PACITA framework. The user interface can be easily modified by changing the affected components or elements. The framework is subdivided in 5 independent projects according to the 5 steps in the user interface of the framework. The application logic and the user interface of any of these projects can be modified without affecting another of the projects. 22

34 Portability The framework and the websites made with it must be portable to any other system. The code of the functionality of a web application can be on any server (or different servers) to which the framework has access over the internet. The code of the functionality has to be wrapped in the four Java element interfaces. The code of the pages of a web application can be on any server (or different servers) to which the framework has access over the internet. The code of the pages can be written in any valid web technology. The structure of a web application and the state of a web application are stored on the server on which the framework is installed. The framework is programmed in Enterprise Java. The framework itself is thus easily ported to another system. The functionality and state of the web application are contained in objects from classes that implement one of the four element interfaces. These objects can be exported and imported with serialization to and from files. The configuration information of a web application can be exported and imported to and from XML files. The state and architecture of a web application are thus also easily ported from one server to another User Management The UserAccounts element interface allows an organisation to plug in a user account system in the architecture of its website. This user account system can be used to create user groups based on existing user accounts or to log in and log out users to the web application. A list of user groups can be defined for every component or element (in the User Management step). If a user is not in one of the user groups he can not access the component or element. Membership of a user group is disjunctive: a user is member if he is directly member of the user group or if he is member of another user group that is directly member of the user group. Authorisation for a component or an element is conjunctive: a user is only authorised to access the component or element if he is a member of all of the required user groups. 23

35 Use of EJB The framework is programmed in Enterprise Java using EJB session beans and entities. The EJB container provides support for several qualities such as scalability (with clustering and load-balancing) and transactions. 24

36 4.2. Architecture The architecture of the PACITA framework can be viewed from different perspectives. The views that are documented in this dissertation are: Module Decomposition View: this view specifies how the framework is composed logically of several parts. Process View: this view specifies the relationship between the core components of the framework and a sequence diagram of the controller. Allocation View: this view specifies how the logical parts are mapped to the file system. Software Schemas: this view shows schemas of the software. The schemas reveal structure of the software without having to decipher the source code. The schemas are included in the appendix Module Decomposition View The framework is split up in modules that correspond with the 5 architectural steps. 3 of the 5 steps are further split up in sub-modules. The decomposition in modules and sub-modules is illustrated in Figure 10. Every sub-module corresponds with a selectable item of the user interface. Application Management Application Configuration Application Emulation Component Management Component Registry Component View Page Flow View User Management User Group Registry User Component Registry User Element Registry User Log Element Registry Element Registry Figure 10: the architectural sub-modules of the PACITA framework Element Container Element Container 25

37 Here is a summary of the purpose of every sub-module: Element Container: holds serialized objects that constitute the functionality and state of web applications. Element Registry: holds references to the functionality in element containers. User Group Registry: contains user group definitions. User Component Registry: manages the access restrictions on components. User Element Registry: manages the access restrictions on elements. User Log: contains logs of user accesses to components and elements. Component Registry: contains the component definitions. Component View: shows the configuration of a component and its relationships to other components. Page Flow View: shows the data and triggers on a page and its relationships to other pages. Application Configuration: configures the web applications. A web application can be started in a pop up window. Application Emulation: emulates an application. It is possible to check the access to the components and the elements for a given user and application, without loading the components or functionality. 26

38 Process View The following schema illustrates the relationship between the core classes of the PACITA framework. StatefullSessionBeans ApplicationSessionRemote DataTag DataSession ComponentRegistry UserSession ElementRegistry UserGroupRegistry Log Figure 11: the core classes of the PACITA framework and their relationships ApplicationSessionRemote, DataSession and UserSession contain the session information of the web application. ComponentRegistry, ElementRegistry, UserGroupRegistry and Log contain the configuration information of the web application. The DataSession object can be retrieved by calling the getdatasession static method of the DataTag class. The ApplicationSessionRemote object can be retrieved by calling the get static method of the StatefullSessionBeans class and providing the ApplicationSessionRemote class as argument. The object of another class in the schema is retrieved by calling the appropriate get method of the class pointing to this other class in the schema. 27

39 Through the ApplicationSessionRemote object, one can retrieve the ComponentRegistry object and the standard component of a web application. Through the DataSession object, one can retrieve the bean defined by the current data custom tag and the beans defined by its parent data custom tags. One can also retrieve the number of times the current data custom tag or its parent data custom tags have been iterated and set if any of these data custom tags will be iterated another time or not. Through the UserSession object, one can log in a user, check if someone is logged in and retrieve the username and log out a user. For someone to be able to log in to the web application, a UserAccounts object has to be set for the web application. The ComponentRegistry object contains the definition of the components of the web application. The ElementRegistry object contains the references to the functionality of the web application. The UserGroupRegistry object sets the UserAccounts object for the web application and contains the definitions of the user groups. A web application does not need to have a UserGroupRegistry object defined if there is no user management in the web application. The Log object logs when a user logs in or out and which components and elements a user accesses. A web application does not need to have a Log object defined if the interaction of users with the web application is not logged. The process of the controller of the web application is as in Figure 12. ComponentRegistry PageSessionRemote ElementRegistry loop [controller component] alt [page component] Figure 12: an abstraction of the controller process 28

40 First, the current component of the web application is initialised. While the current component is either an action component or a condition component, the controller checks if it is authorised to access the component. If the controller has no such authorisation, the resolution of the component is terminated. If the controller is authorised to access the component, it asks the ElementRegistry object to execute the execute or test method of the associated element. After the execution of the method, the next current component is initialised and the loop is restarted. If the current component is a page component, the controller checks if it is authorised to access the page. If the controller has no such authorisation, the resolution of the page is terminated. If the controller is authorised to access the page, the beans and the triggers of the page are initialised. Consequently, the page is sent as output to the user. A data custom tag in the page causes the execution of the getdatabean method of the associated Data element. The bean that is defined by the data custom tag is set to the return value of this method. The method of an element is accessed as in Figure 13. ElementRegistry UserGroupRegistry Container loop loop Figure 13: authorised access to an element s method The controller checks if the current user is a member of all the user groups of the element. Then for every condition of the element, the authorisation procedure is called recursively. If and only if the user is a member of all the user groups and all the conditions are met, the method of the element is executed. 29

41 The authorisation for components is similar: a user is first checked to be a member of all the required user groups and then all the required conditions are tested. A user can only access a component if he is a member of all the required user groups and if all the required conditions hold. As soon as the user is not a member of a user group or a condition does not hold, the authorisation is aborted Allocation View Every sub-module is mapped to a software source code package: Element Container: be.macharis.toon.pacita.container Element Registry: be.macharis.toon.pacita.element User Group Registry: be.macharis.toon.pacita.user.group User Component Registry: functionality is implemented in the Component Registry package User Element Registry: functionality is implemented in the Element Registry package User Log: be.macharis.toon.pacita.user.log Component Registry: be.macharis.toon.pacita.component Component View: functionality is implemented in the Component Registry package Page Flow View: functionality is implemented in the Component Registry package Application Configuration: be.macharis.toon.pacita.application Application Emulation: functionality is implemented in the Component Registry package 30

42 Every sub-module is mapped to a URL pattern where the source files of the user interface can be found: Element Container: container Element Registry: element User Group Registry: user.group User Component Registry: user.component User Element Registry: user.element User Log: user.log Component Registry: component Component View: component.view Page Flow View: component.pageflow Application Configuration: application Application Emulation: application.emulation If <pattern> is the given pattern, then: The pages of the sub-module can be found at /pacita_ui_0_1/<pattern>/ The action elements of the sub-module can be found at pacita.<pattern>.actions The condition elements of the sub-module can be found at pacita.<pattern>.conditions The data elements of the sub-module can be found at pacita.<pattern>.data The custom tags of the sub-module can be found at pacita.<pattern>.tags 31

43 4.3. Planning It is difficult to estimate the time it takes to write software that satisfies a certain specification. An accurate estimation would require the knowledge of which code will be written and how long it takes to write each line of code. One has this knowledge only when the software project is completed. However, there exist methodologies that maximise the results of writing software for a given amount of time. These methodologies typically consist of dividing the software in small independent subprojects that can be accomplished relatively fast. The most important sub-projects are realised first and the already realised core can evolve over time to become more stable, efficient and general. The most important sub-projects are either those that provide a maximum of functionality for a minimum of effort or those that are the riskiest. Tackling risky sub-projects first minimises the accumulation of the risk to the other sub-projects. In this spirit, the PACITA framework has been built in iterations and it will continue to evolve in iterations. Each iteration builds on the previous one, extending it a bit. In the final iteration for this dissertation the risks were addressed first. The framework consists of independent modules as set out in the description of the modifiability quality attribute. 32

44 Iterative Development The current iteration of the PACITA framework is the 4 th iteration. The iterations are described below Iteration 1 The first iteration of the PACITA framework was developed in PHP. There was one PHP page that acted as controller. Pages contained direct references to dynamic data and to actions that could be triggered from the page. A trigger redirected to the controller page, which executed the associated action, set the dynamic content and sent the appropriate page to the user. Action chaining was not possible, though actions could be nested in the code block of another action. The code was organised in 3 parts in correspondence with the MVC-pattern. One directory contained the pages. These pages corresponded with the View. Another directory contained classes that implemented the functionality. These classes corresponded with the Model. A third directory contained the actions. These actions had one executable method that called the appropriate functionality of the classes. These actions corresponded with the Controller. Actions and pages were linked in a MySQL database table. If the controller needed to execute an action or include a page, it could find the path to the source file in the MySQL database Iteration 2 During development in PHP, it became apparent that PHP is not as portable or stable as Java. I could give a detailed description here of the issues I ve faced, though I will refer to [JAVAvsPHP] instead. Moreover, the API of PHP is not as broad as the API of Java and Java has better development tools. Again, I will not go into details. Fact is I chose to abandon PHP in favour of Java for some well motivated technical reasons, but I will not elaborate on these reasons as I think such elaboration would be a distraction of the main course of thought. 33

45 This iteration introduced the Action and Condition elements and the Action, Condition and Page components. The components could be chained to each other from this iteration onwards. Pages contained direct references to the components that could be triggered from the page. The direct reference had the disadvantage that the actual name of a component had to be used in a trigger. The name of the component had to be used as value for the trigger (which was implemented as the component parameter) and the View was coupled to the Model as explained in the paragraph about the flexibility quality attribute. Also all directly accessible components were exposed on all pages. The controller was configured hard wired in the code Iteration 3 This iteration introduced the Data element. Data elements, as well as the components that could be triggered from the page were indirectly referenced to from a page instead of directly. This allowed decoupling the name of the Data elements and components from the page. Also, only the Data elements and components that were declared for a page were accessible from the page, instead of all of them as in the previous iteration. The controller for a web application was configured with 2 XML files: one XML file to link the functionality in the framework and another XML file to link the user interface components in the framework. This is illustrated in Figure 14. Functionality Linking XML File Linking Schema Linking Registry Application Developer Application Editing XML File Editing Schema Component Registry Presentation Figure 14: configuration of the controller in the third iteration 34

46 The linking file would contain the definitions of the elements and be constrained by the linking schema. The editing file would contain the definitions of the components and be constrained by the editing schema. The controller resolved the components for running the application. The next iteration of the framework is built with this iteration as framework Iteration 4 The current iteration has included a lot of new features. First and foremost, the current framework configures a web application through a GUI. The configuration can be exported to and imported from XML files. The state of the binary objects can be serialized to and deserialized from files. The framework is implemented using an EJB 3.0 container. It uses lightweight persistence in the form of entities and no SQL code had to be programmed. Every change to the state of the web application is transactional. A web application is scalable and can be load-balanced. The classes of the web application do not have to be provided during deployment of the PACITA framework, but can be loaded dynamically at any time. Classes can be loaded as well from the local server as from a remote server. Pages that are on the local server as well as pages that are on a remote server can be integrated in the framework. The data custom tag is introduced to include Data elements on a page and the Data elements can iterate this tag or access Data elements from parent data custom tags. The data custom tag forms a complete alternative to custom tags in general. Therefore fully functional JSP pages can consist of XHTML code, data custom tags and getproperty JSP action only(!) This decouples the JSP pages completely from the application logic and simplifies the maintenance of the JSP pages considerably. 35

47 At the moment of writing, this iteration isn t finished yet. The features that are not yet implemented are flow charts of the user interface of a web application and support for user management. Flow charts will give a graphical overview of which components precede and follow a component and of which pages precede and follow a page. User management is made available by the UserAccounts element, which was introduced in this iteration. The user management will consist of being able to define user groups and to restrict access to components and elements for certain user groups and conditions to be met. It will be possible to log every access to an element or a component. It will also be possible to check for every user or user group in an emulation of the web application which components and elements they can access and which not, without running the application Risks The risks for realising the current iteration were primarily related to the added features. The assumed risks were dynamic class loading, reading files on a remote server, lightweight persistence and the flow charts and user management. The paragraphs below explain how these risks were addressed Dynamic Class Loading Dynamic class loading was a new concept and the explanation here makes clear that I managed to understand the details of it. Once I understood the details of class loading, it was clear that the only constraint on class loading that was not envisaged during initial planning is that the original class definitions have to stay available to be able to deserialize serialized objects. Class loaders have a hierarchy and classes are loaded from the class loader with the highest level in the hierarchy that contains the definition of the class. This prevents that class definitions would be overridden down the hierarchy with malicious code. Also, a security exception may be thrown if a new class definition down the hierarchy is in a package to which only class loaders up the hierarchy are authorised to have access. Once a class is loaded, it is conceptually always loaded. (Though a class object can be garbage collected when there are no more references to its class loader and to all the objects of the class loader.) 36

48 A class definition loaded in one class loader is incompatible with the same class definition loaded in another class loader. However, with using proxies and invocation handlers it is possible to access objects of both class definitions with the same interface. The standard ObjectInputStream deserializes objects to the system class loader. One can deserialize objects to a custom class loader by sub-classing the ObjectInputStream class and overriding the resolveclass method. Arguments of remote session beans are automatically serialized and deserialized using the system class loader. It is conceptually impossible to deserialize session bean arguments to a custom class loader and this is thus a shortcoming in the EJB container [EJBlimit]. However, it is possible to explicitly serialize objects before they are passed as an argument to a session bean method, pass the argument as a byte array and explicitly deserialize the byte array to a custom class loader inside the method. The loading of a class consists of three phases: loading: the binary data of the class definition is put in memory linking: the binary data of the class definition in memory is processed initialisation: the static initialisation of the class is executed. The following methods are of importance for class loading: ClassLoader.loadClass(String name): loads the class with the given name for the given class loader. ClassLoader.resolveClass(Class<?> c): links the given class for the given class loader. Class.forName(String name, boolean initialize, ClassLoader loader): loads and links the class with the given name for the given class loader. If the class is initialised depends on the value of the boolean initialize. ObjectInputStream.resolveClass(ObjectStreamClass desc): the method of ObjectInputStream that has to be overwritten if a class definition has to be loaded from a custom class loader. 37

49 Remote Files It appeared to be rather straightforward to read remote files. A code snippet like the one below would do the trick. The classes URI, URL and URLConnection are from the package java.net and the classes InputStream and BufferedInputStream are from the package java.io. // link is a string representation of the remote URI URI sourceuri = new URI(link); URL sourceurl = sourceuri.tourl(); URLConnection connection = sourceurl.openconnection(); InputStream in = new BufferedInputStream(connection.getInputStream()); // continue manipulating in Lightweight Persistence Lightweight persistence holds the promise to do away with user-generated SQL code and the maintenance that is tied to it. EJB 3.0 entities are a way to achieve lightweight persistence. However, the EJB 3.0 persistence specification [EJB3.0] is at the time of writing barely a year old and the available documentation is rather concise, unclear and ambiguous. It took some trial and error to get the grasps of the specification. 38

50 Some experienced issues: Entities can t have static methods. The primary key value of an entity can be configured as auto-increment. This increments the value of the primary key as stored in the database, however it does not affect the value of the primary key of the detached entity. Thus if one wants to create detached entities with an auto-increment primary key, one has to explicitly develop an algorithm for generating the primary key. Dependency injection appears not to work at times. In this case, an explicit JNDI lookup is to be made. The local interface for session beans appears not to work if they are accessed indirectly from outside the EJB container. A remote interface thus has to be used for all session beans used in practice. The EJB container appears to be allowed to create dummy entities. The default constructor should not contain initialisation code that conflicts with dummy entity creation. An early version of the Sun Application Server supporting the EJB 3.0 specification appears to not correctly handle LOB fields of an entity. These fields have to be serialized explicitly to byte arrays. The automatic generated code of Netbeans for updating entities in persistent storage or removing them from persistent storage is wrong (in combination with an ambiguous Java persistence specification). The next table shows the correction of the automatic generated code in the façade session bean for an entity. SQL equivalent automatic generated code correct code update em.merge(entity); Entity attached = em.merge(entity); attached.copy(entity); delete em.merge(entity); em.remove(em.merge(entity)); em.remove(entity); Figure 15: faulty automatic generated code for updating and removing entities and its correction Though once the persistence API was clear and it was clear to which conditions entities had to adhere to, there were no difficulties anymore to store, retrieve, update and remove entities. 39

51 Flow Charts and User Management The flow charts and the user management are no essential parts of the framework. Therefore, the risk is not in integrating them in the system. The risk is that their development takes time. The risk is addressed by developing the system initially without support for flow charts or user management and only after all other requirements are implemented, the support for flow charts and user management is developed. At the time of writing, the support for flow charts and user management isn t completed yet, though the framework is fully functional as all the essential parts of the framework have been implemented Independent Parts The project is broken up in smaller projects that can be developed independently of each other. Each of the smaller projects implements part of the functionality of the total project. At first the risks were tackled. It took about 3 weeks to understand the details of dynamic class loading and about 2 weeks to resolve all issues regarding EJB entities. Since then, there have been 4 development steps that took each about 3 weeks: The first development step focussed on the development of generic support classes. The second development step implemented the functionality and user interface for integrating functionality in the PACITA framework. The third development step implemented the functionality and user interface for creating references to the functionality that is integrated in the PACITA framework. This development step also implemented draft functionality for user management, which makes it easier to complete the functionality for user management later on. The fourth development step implemented the functionality and user interface for managing components and configuring applications with the PACITA framework. This development step also implemented draft functionality for flow charts, which makes it easier to complete the functionality for flow charts later on. These development steps are the same as the steps for which the software schemas that are in appendix are made. 40

52 5. Demonstration 5.1. Configuration To be able to run the PACITA framework, one needs Java SE 6 and a Java EE 5 application server. Java SE 6 can be downloaded at [JavaSE]. Netbeans with a Java EE 5 application server can be downloaded at [JavaEE]. The PACITA framework source code can be downloaded at [PACITAsource]. I will explain in this subchapter how the PACITA framework can be deployed on a test computer using Netbeans and the built in application server. After you installed the Java SE 6 Development Kit and the Netbeans Java EE 5 Tools Bundle, you have to download the source code of the PACITA framework and unzip it to a directory on your computer. Consequently, you start Netbeans. In the Netbeans menu, you select File Open Project. You browse to the directory where you unzipped the source code of the PACITA framework and select to open the projects PACITA-v0_2_8-ejb and PACITA-v0_2_8-war. The selection screen will look as in Figure 16. Figure 16: opening the EJB and Web project of the PACITA framework 41

53 After you have opened the projects in the Netbeans IDE, you have to right click on the name of the web project and select Properties as in Figure 17. Figure 17: selecting the properties of the web project 42

54 Under the properties of the web project, you have to select Libraries and see if there is a correct reference to the EJB project. If you download the source code and install it to a directory, the web project would have a reference to the EJB project, but the reference would be broken. (Unless you were using exactly the same directory structure as I am.) You would have to fix the reference by removing any broken reference and by adding a correct reference. You add a correct reference to the EJB project by clicking the Add Project button and selecting the EJB project. The properties window is illustrated in Figure 18. Figure 18: properties of the web project 43

55 After you have set the reference from the web project to the EJB project right, you have to compile the EJB project and the web project. You do this by right clicking on the name of the projects and selecting Clean and Build Project. This is illustrated in Figure 19 and Figure 20. Figure 19: compiling the EJB project Figure 20: compiling the web project 44

56 After the projects have been compiled, it is time to deploy them to the application server. You deploy the projects to the built in application server by right clicking their name and selecting Deploy Project as illustrated in Figure 21 and Figure 22. You first deploy the EJB project and then the web project. Figure 21: deploying the EJB project Figure 22: deploying the web project 45

57 After the projects have been deployed, you go to the URL This will initialise the PACITA framework and the output to the browser will be as in Figure 23. Figure 23: initialisation of the PACITA framework After the PACITA framework has been initialised, you can access the framework from a browser by going to the URL war/pacita/index.htm. The output to the browser will be as in Figure 24. Figure 24: home page of the PACITA framework 46

58 5.2. Building a Simple Calculator Now we have installed the PACITA framework, we will start with building a simple application. Following subchapters will demonstrate how the application can be flexibly adjusted. We will build a simple calculator. The graphical user interface of the calculator is illustrated in Figure 25. Calculator error result input calculate calculate input is number is reset reset is add add is subtract subtract Figure 25: the GUI of a simple calculator, dotted lines are the path followed if a condition is false, full lines are the path followed if a condition holds. To construct the calculator, three things are needed: the functionality, the web pages that users interact with and the configuration that links the web pages to the functionality. The functionality and the web pages do not have to be developed by an organisation. The functionality is developed by software providers in the form of elements. The web pages are developed by web developers. An organisation only has to set the configuration of its web application right through a graphical user interface. Nonetheless, in this simple example I will also present the elements and the web page for full disclosure on how the framework works. I will also explain the graphical user interface in depth by providing a screenshot of every small step. Later on, when I will show how the application can be adjusted after it is constructed I will not go in so much depth anymore, as it will be assumed that the reader will be aware of the details that are left out. 47

59 The Model The calculator requires the implementation of 3 Action elements, 4 Condition elements and 3 Data elements. The source code of the Action elements: public class Add implements Action { public void execute(httpservletrequest request) { HttpSession session = request.getsession(); int result = (Integer)session.getAttribute("result"); int input = (Integer)session.getAttribute("input"); session.setattribute("result", result + input); } } public class Reset implements Action { public void execute(httpservletrequest request) { HttpSession session = request.getsession(); session.setattribute("result", 0); session.setattribute("input", 0); } } public class Subtract implements Action { public void execute(httpservletrequest request) { HttpSession session = request.getsession(); int result = (Integer)session.getAttribute("result"); int input = (Integer)session.getAttribute("input"); session.setattribute("result", result - input); } } The source code of the Condition elements: public class InputIsNumber implements Condition { public boolean test(httpservletrequest request) { String input = request.getparameter("input"); HttpSession session = request.getsession(); try { session.setattribute("input", new Integer(input)); return true; } catch (NumberFormatException e) { session.setattribute("error", ""<i>" + input + "</i>" is not a valid number"); return false; } } } public class IsAdd implements Condition { public boolean test(httpservletrequest request) { return request.getparameter("operation").equals("add"); } } 48

60 public class IsReset implements Condition { public boolean test(httpservletrequest request) { return request.getparameter("operation").equals("reset"); } } public class IsSubtract implements Condition { public boolean test(httpservletrequest request) { return request.getparameter("operation").equals("subtract"); } } The source code of the Data elements: public class Error implements Data { public static class Bean { private String message; private Bean(String message) { this.message = message; } public String getmessage() { return message; } } public Object getdatabean(httpsession session) { String errormessage = (String)session.getAttribute("error"); if (errormessage!= null) { session.removeattribute("error"); return new Bean(errorMessage + "<br/><hr/>"); } else { return new Bean(""); } } } public class Input implements Data { public static class Bean { private String value; private Bean(String value) { this.value = value; } public String getvalue() { return value; } } public Object getdatabean(httpsession session) { Integer input = (Integer)session.getAttribute("input"); if (input == null) { input = 0; } return new Bean(input.toString()); } } public class Result implements Data { public static class Bean { private String value; private Bean(String value) { this.value = value; } public String getvalue() { return value; } } public Object getdatabean(httpsession session) { Integer result = (Integer)session.getAttribute("result"); if (result == null) { result = 0; } return new Bean(result.toString()); } } 49

61 The View The calculator has only one page. The source code of the page is: contenttype="text/html"%> pageencoding="utf-8"%> uri="/web-inf/tlds/pacita.tld" prefix="pacita"%> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" " <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"/> <title>basic Calculator</title> <script language="javascript"> <!-- function post(trigger, operation) { span = document.getelementbyid('args'); span.innerhtml = '<input type="hidden" name="trigger"' + ' value="' + trigger + '"/>' + '<input type="hidden" name="operation"' + ' value="' + operation + '"/>'; document.form.submit(); } //--> </script> </head> <body> <form name="form" action="?" method="post"> <pacita:data bean="error_bean"> <jsp:getproperty name="error_bean" property="message"/> </pacita:data> <pacita:data bean="result_bean"> Result: <b><jsp:getproperty name="result_bean" property="value"/></b><br/> </pacita:data> <span id="args"></span> <pacita:data bean="input_bean"> Input: <input type="text" name="input" value="<jsp:getproperty name="input_bean" property="value"/>"/> <br/> </pacita:data> <a href="javascript:post('calculate', 'reset')">reset</a> <a href="javascript:post('calculate', 'add')">add</a> <a href="javascript:post('calculate', 'subtract')" >subtract</a> </form> </body> </html> 50

62 Note that there is no server-side scripting in the webpage 3. There is no need for scripts in a webpage as the <pacita:data/> custom tag offers the full functionality of generic custom tags and the full functionality that scripting can deliver. Scripting in web pages is about the worst software anti-pattern [Antipattern] there exists, as it makes web pages unmaintainable. Scripting is the ultimate manifestation of spaghetti code [SpaghettiCode]. If you wouldn t believe me that scripting doesn t make sense, indulge yourself in it as much as you want, I am not going to argue with you, it is not my time you are wasting The Controller An organisation is only exposed to the details of the controller of a web application. The controller integrates the web pages with the elements. The controller is managed through the GUI of the PACITA framework. I will explain in the finest details through commented screenshots how one builds a simple calculator from the elements and page given in the previous two paragraphs. There will be four necessary steps to complete the configuration of a web application. These steps are the Element Container step, the Element Registry step, the Component Registry step and the Application Configuration step as explained in I will explain the four steps the one after the other. Only the necessary parts will be discussed. User management and flow charts, which are not implemented yet at the moment of writing and which are not essential, will not be discussed Element Container If one clicks the Element Container tab of the GUI and then clicks on the checkered flag, he gets to see a screen like the one below. 3 Yes, there is a bit of JavaScript, but that is client-side scripting 51

63 This screen lists all the containers that contain object instances of element classes. These containers thus contain the state and functionality of all web applications. In this screenshot and in screenshots that follow there will already be configuration information of some existing test applications. I ve left the configuration information of these other test applications in the framework, to stress that the framework can support multiple applications at the same time. We make a new container to hold the elements of our simple calculator. For this, we have to write the name of the container in the text field and click on the little sun on the right of the text field. This creates a new empty container with the specified name, in case there did not yet exist a container with that name. I entered calculator functionality in the text field and clicked the yellow sun. In the screen shot above, the empty container with this name is already created. After this, we click the green check mark on the left of the calculator functionality container. This leads us to the next screen. The screen above shows the elements in the selected container. As we created a new empty container, there are no elements in the container yet. To load elements in the container, we click on Load and get to see the screen below. We get to see a text field in which we can enter a source URI that contains the class definitions of element. This URI points to a JAR file. The JAR file can be either on the local server or a remote server. In this case the JAR file is on the local server. The JAR file is located at the root of the server and the name of the JAR file is basic.jar. After I ve entered the URI and I click on Select, I get to see the screen below. 52

64 The PACITA framework identifies all classes in the JAR file and outputs their fully qualified names in a list. The user can choose to select some of these classes or not by checking the checkbox in front of the class names. The example JAR file contains the class definitions of which the source code is shown in and no other class definitions. Apparently, every Data element in the example given has one Bean inner class and one anonymous inner class (identified with 1). I have to guess where the anonymous inner classes come from 4, but I assume that it is related to the Bean inner class. I checked the checkboxes as in the screen above and clicked on Load Selected. This returns us to the page where we can enter a source URI from which we can load other elements. A screenshot is shown below. 4 I don t know what the Java compiler does. I only know how to write Java code and how to compile and run it. I assume that the Java compiler creates the anonymous classes for some reason, but what for, I can only guess. 53

65 The page shows a notice on top that 10 elements are loaded in the container and that 2 classes that were not elements were discarded. The selected classes that were not elements were basic.data.error$bean and basic.data.error$1. These are inner classes of the basic.data.error Data element, but they are not elements themselves and thus they are discarded. All other selected classes are elements as they implement one of the interfaces specified in A new object is created for all of these classes by invoking the no argument constructor and this object is stored in the container. We don t want to add other elements to the container and therefore, this time we click Back. This brings us back to the page that shows the elements in the container, as seen below. Before, the container was empty and no elements were shown to be in it. Now we have loaded elements in the container, we get to see a list that shows the fully qualified name of the class of the elements, the date when they were added, the URI that contains the class definition of the element and how many times an element method has been invoked by the PACITA framework. The element methods are the methods of the interfaces that are defined in Since the elements are freshly loaded in the container, their functionality hasn t been called yet and therefore the number of invocations is still 0 for all elements. We don t have to make any changes in the container anymore and therefore, we click Go Back to Container List. This returns us the start page that shows the list of containers as shown below. 54

66 We first click on Save. This saves the changes we made to the configuration. Changes aren t saved automatically as multiple people could be changing the configuration at the same time. If changes were saved automatically, changes from different sources would interfere with each other. Instead, changes to the configuration aren t stored automatically in the PACITA framework. They are only kept locally in the session. Only if a user explicitly chooses to save his configuration, it is written to the PACITA framework. It is still possible that one user overwrites the configuration of another user in the framework. Though the local configuration a user is working with is unaffected by changes made by other users. A user can at any time load the configuration that is stored in the framework by clicking Refresh. 5 After we ve clicked Save, we select the calculator functionality container by checking the checkbox in front of the name and then we click Back Up. This brings us to the screen below. 5 I know, concurrency control in changes to the configuration of the PACITA framework can still be improved, but working out a better solution would have taken extra time. This is one thing to work on as the framework evolves. 55

67 From this page we can export the content of the containers we selected at the previous page to a file. We can also load the content from containers that we previously stored in a file. Right now we will store the content of the calculator functionality container. We enter calculator.ser in the New storage file text field and click the yellow sun next to the text field. This stores the content of the calculator functionality container in the file calculator.ser and returns us to start page as seen below. The screenshot above also shows the name of already existing backup files. When we return to the start page, we receive a notification that the calculator.ser file was created and that the content of the calculator functionality container was stored in it. That was all it takes to configure the element containers Element Registry If we click the Element Registry tab and then the checkered flag, we see the page to configure element registries, as below. This page shows the name of the element registries. We create a new empty element registry with name calculator linking. We enter the name in the text field, click the yellow sun and then click on the green check mark in front of the name. We get to see the page below that shows the element references in the element registry. 56

68 As the element registry is empty at the moment, there are no element references in it yet. We create element references by adding their name in the text field and clicking on the yellow sun next to the text field. This way, we create the element references as shown in the screenshot below. When new element references are created, they don t refer to a container or element yet, as shown in the screen above. After the references have been created, we select the add action reference by clicking the green check mark in front of the name. This brings us to the page below. We get to see the element containers in the PACITA framework. We select the calculator functionality container. This leads us to the next page. 57

69 The page above shows the elements in the selected container. We select the basic.actions.add element. This returns us to the page that gives the overview of the element references in the selected element registry, as shown below. Now the add action reference refers to the basic.actions.action element in the calculator functionality container. This element is an Action element, but not a Condition element or a Data element, as shown in the is action, is condition and is data columns 6. We link the other references to their corresponding elements in the calculator functionality container also and end up as shown on the next screenshot. 6 One can observe that there is no column for UserAccounts elements. UserAccounts elements do not provide functionality that is to be embedded in the user interface as the other types of elements do. Therefore, UserAccounts elements are not to be shown in the Element Registry step. Instead, UserAccounts elements can be selected in the User Management step to create user groups from user account list. These user groups can be used to limit the access to elements and components in the User Management step. 58

70 Now that all the elements are linked, we click on Go Back to Registry List. This returns us to the start page as shown in the next screenshot. We save the configuration by clicking Save. We select the calculator linking registry and click on Back Up. This leads us to the following page. We save the content of the calculator linking registry in the calculator.xml file. After we have saved the file, we are returned to the start page and get a notification of the storage to the XML file as below. 59

71 This is all it takes to configure element registries Component Registry If we click the Component Registry tab and then the checkered flag, we see the page to configure component registries, as below. We created the calculator components registry. Upon creation, a component registry is empty and is not linked to an element registry. We click on select element registry next to calculator components to link the component registry to an element registry. We get to see the next page. The page above shows the names of the element registries in the PACITA framework. We select calculator linking. This returns us to the start page as shown below. We click on Save. The calculator components component registry is now linked to the calculator linking element registry. 60

72 We select the calculator components registry by clicking the green check mark in front of the name. We get to see the page below that shows the components in the component registry. As the component registry is still empty, there are no components shown yet. We create the components for the web application by entering their name in the text field and clicking on the appropriate create link next to the text field. This creates uninitialised components. We get the result as shown below. We select the add action component. We get to see the page below. 61

73 The add action component isn t linked to an action or a next component yet. We select the green check mark next to no embedded action and get to see the list of Action elements in the element registry to which the component registry is linked: We select add action. The add action element is now embedded in the add action component, as can be seen below. Now we select the green check mark next to no next component and get to see the list of components in the component registry: 62

74 We select calculator as the next component. This results in the following: If the PACITA framework resolves the add action component, it will first execute the add action element and afterwards pass control to the calculator page component. The add action component is configured, so we hit Go Back to Component List. This shows us the list of components in the component registry again: We configure the other action components the same way as we configured the add action component. Consequently, we select the is add condition component. We get to see the page below. 63

75 The is add condition component isn t linked to a condition element or to next components yet. We select the green check mark next to no embedded condition. We get to see the list of Condition elements in the element registry to which the component registry is linked: We select is add condition. The is add condition element is now embedded in the is add condition component, as can be seen below. In the page below the next components for the is add condition component are also already set. They are set the same way that a next component for an action component is set. If the PACITA framework resolves the is add condition component, it will first test the is add condition element. If the test fails, control is passed to the is subtract condition component, if the test succeeds, control is passed to the add action component. The is add condition component is configured, so we click on Go Back to Component List. This shows us the list of components in the component registry again: 64

76 We configure the other condition components the same way as we configured the is add action component. Consequently, we select the calculator page component. We get to see the page below. The page component is not linked to an actual web page and there are no beans or triggers defined for the page. We click on the green check mark next to no page linked. This brings us to the following screenshot. 65

77 In the text field in the screenshot above, we fill in the URI of the page to which the page component has to link. If the URI starts with a /, the page will be included from the local server. Otherwise, the page will be included from over the internet. We click Select to save the string value for the URI. This brings us again to the configuration page for the page component: We add beans and triggers to the page by entering their name in the text field and clicking on the appropriate create link next to the text field. This results in the following: 66

78 The beans and triggers initially refer to nothing. Note that I used an underscore in the bean names instead of a space. The <jsp:getproperty/> JSP action cannot deal with spaces in the name of a bean. We click on the green check mark next to error_bean and get to see the list of Data elements in the element registry to which the component registry is linked: We select error data. The error data element is now embedded in the calculator page as the error_bean bean as can be seen on the next screenshot: We link the other beans on the page in the same way: 67

79 The /calculator/basic.jsp page will be able to access the beans returned by the getdatabean method of the Data elements. The page can access such a bean through the bean name that links to its Data element. After we have linked the beans of the page component, we click the green check mark next to calculate. This shows us the list of components in the component registry: We select input is number. This links the calculate trigger to the input is number condition component. Thus if the calculate trigger is activated on the /calculator/basic.jsp page, control will be passed to the input is number condition component. The final configuration of the calculator page component can be seen on the next screenshot. 68

80 We click Go Back to Component List and get to see: We click Go Back to Registry List and get to see: We click Save. We select the calculator components registry and click Back Up. This shows us the page from where we can export the content in the calculator components registry to an XML file: 69

81 We save the content of the calculator components registry in the calculator.xml file. After saving the content, we return to the start page and receive a notice that the content has been saved: This is all there is to configure component registries Application Configuration If one clicks the Application tab of the GUI and then clicks on the checkered flag, he gets to see a screen like the one below. Like in the previous steps, we create a new empty registry by entering its name in the text field of the start page and clicking the yellow sun next to the text field. Here we created the calculator application registry. After creation, we got to see the page above. We then click on select component registry, next to calculator application. We get to see the list of component registries in the PACITA framework, as below. 70

82 We select calculator components. The calculator application registry now links to the calculator components registry. We click select standard component next to calculator application. We get to see the list of components in the component registry to which the application registry links: We select the calculator page component as standard component. We return to the start page as below: We click on Save. We select calculator application and click Back Up. We get to see the following page: 71

83 We store the content of the calculator application registry in the file calculator.xml and return to the start page: The backup that has been made in all the steps is not necessary to run the application. The backup files make it possible though to export the whole application including state to another server or to restore the application to a previous state. Now the web application is live on the server! If you click the green check mark next to calculator application, a new browser window will pop up that runs the application. This is illustrated in the next subchapter. 72

84 5.3. Demonstrating the Simple Calculator The application shown here is fairly simple compared to the exhaustive configuration for it shown above. It should be noted that the configuration explained above is into details and that much more complex applications do not require a more complex configuration. There is no scripting language or full functional web technology of which the power can be completely demonstrated in 50 screenshots. About 50 screenshots suffice to explain the full core of the PACITA framework, no matter how complex the web application that uses the PACITA framework is. To continue to our simple application, that will be extended later on: The screenshot on the left is what you get to see if you start the application. In the right you see that the user has changed the value in the text field to 5. If the user clicks on add after he changed the value in the text field to 5, he gets to see the screenshot on the left below. If he clicks another time on add, he gets to see the screenshot in the middle below. If a user clicks add, the value in the text field is remembered and the result is incremented with this value. In the screenshot on the right below, the user changes the value in the text field to a non numerical value. If the user clicks add when the value in the text field is not a number, an error message is shown to the user as in the screenshot on the left below. The old input value is restored. In the screenshot on the right below, the user changes the input value to 3. 73

85 If the user now clicks subtract, the value in the text field is subtracted from the result as shown in the screenshot on the left below. If the user clicks reset, the result and the value in the text field are reset to 0. 74

86 5.4. Restoring the Calculator Before we extend the calculator, I will demonstrate how one restores an application from the backup files. First we go to the start page of one of the steps as shown below: Then we click on Purge, this removes all the containers of the step in the PACITA framework and cleans the database. We get to see the page below. We click on Back Up and get to the following page: We select the file calculator.ser by clicking on the green check mark in front of the name. This shows us the list of the containers that are stored in the file. As there is only one container stored in the file, namely the calculator functionality container, we get only to see the name of this one container: 75

87 We select the container and click Load. This loads all the selected containers in the user session and returns us to the page where we can store containers to files or load containers from files. We receive a notification that the selected containers were loaded: We click Back and return to the start page. The calculator is now loaded in the user session: We click Save to store the configuration in the user session to the PACITA framework. We do this also for the 3 other necessary steps and the application is restored. After the calculator application has been restored, we test it a couple of times and then select the calculator functionality container: 76

88 We see the list of elements in the container and see that each of the elements has been invoked a couple of times. From the basic.conditions.inputisnumber line, we can deduce that we have clicked 22 times on add, subtract or reset. The is reset condition has been tested 19 times, which means that (22 19) = 3 times we entered a non numerical value in the text field. The reset action has been executed once and thus the is add condition has been tested (19 1) = 18 times. The add action has been executed 7 times and thus the is subtract condition has been tested (18 7) = 11 times. The subtract action has been executed 11 times. The calculator page has been shown 23 times and thus the error, result and input data elements have been accessed 23 times. However, for some reason the double amount of this is shown for the invocations. This means there is a bug somewhere that either invokes the data elements twice or that multiplies the number of invocations with 2. 77

89 5.5. Extending the Calculator While the calculator is live, we will extend it with the operations multiply and divide. We will also link the start page to another page that will show a custom message a number of times. Changes to the graphical user interface will look like in Figure 26. Calculator is subtract subtract calculate to message is multiply multiply is divide divide to message store message to calculator mod 10 Message result modulo parent message child message to calculator Figure 26: changes to the graphical user interface of the calculator The Model The extension requires the implementation of 4 Action elements, 2 Condition elements and 3 Data elements. I will not show the implementation of the multiply, is multiply, divide and is divide elements as they are similar to the implementation of the add and is add elements. The implementation of mod 10 and store message: public class Mod10 implements Action { public void execute(httpservletrequest request) { HttpSession session = request.getsession(); int result = (Integer)session.getAttribute("result"); int input = (Integer)session.getAttribute("input"); session.setattribute("modulo", result % input); } } public class StoreMessage implements Action { public void execute(httpservletrequest request) { String message = request.getparameter("message"); request.getsession().setattribute("message", message); } } 78

90 The implementation of modulo, parent message and child message: public class Modulo implements Data { public static class Bean { private String value; private Bean(String value) { this.value = value; } public String getvalue() { return value; } } public Object getdatabean(httpsession session) { Integer result = (Integer)session.getAttribute("modulo"); if (result == null) { result = 0; } return new Bean(result.toString()); } } public class ParentMessage implements Data { public static class Bean { private String message; private Bean(String message) { this.message = message; } public String getmessage() { return message; } } public Object getdatabean(httpsession session) { return new Bean((String)session.getAttribute("message")); } } 79

91 public class ChildMessage implements Data { public static class Bean { private HttpSession session; private Bean(HttpSession session) { this.session = session; } public String getmessage() { DataSession datasession = DataTag.getDataSession(this); Reference selfreference = datasession.getcurrentreference(); int maxiterations = (Integer)session.getAttribute("modulo"); int iterations = datasession.gettotaliterations(selfreference); if (iterations < maxiterations) { datasession.setrepeat(selfreference, true); } Reference parentreference = datasession.getparentreference(selfreference); if (parentreference == null) { return "#" + iterations + ": No parent to expose!"; } else { Object parentdata = datasession.getdata(parentreference); String parentmessage; try { parentmessage = (String)parentData.getClass().getMethod("getMessage", new Class[] {}).invoke(parentdata, new Object[] {}); } catch (Exception e) { return "#" + iterations + ": Exposing parent: parent has no message"; } return "#" + iterations + ": Exposing parent's message: " + parentmessage; } } } public Object getdatabean(httpsession session) { return new Bean(session); } } The View The extension requires the creation of two pages, one page that replaces the old calculator page and a new message page. I will not show the source code of the new calculator page. However I will show the source code of the message page as it will demonstrate that the data custom tag can be nested and iterated: 80

92 contenttype="text/html"%> pageencoding="utf-8"%> uri="/web-inf/tlds/pacita.tld" prefix="pacita"%> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" " <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"/> <title>message</title> </head> <body> <pacita:data bean="result_bean"> <b><jsp:getproperty name="result_bean" property="value"/></b> mod 10 = </pacita:data> <pacita:data bean="modulo_bean"> <b><jsp:getproperty name="modulo_bean" property="value"/></b> <br/><br/> </pacita:data> <pacita:data bean="parent_bean"> Parent's Message: <jsp:getproperty name="parent_bean" property="message"/><br/> <pacita:data bean="child_bean"> Child's message: <jsp:getproperty name="child_bean" property="message"/> <br/> </pacita:data> </pacita:data> <br/> <a href="?trigger=to%20calculator">back to calculator</a> </body> </html> The child bean will get the message from the parent bean and print it a number of times that is equal to ((the result % 10) + 1). 81

93 The Controller The following 5 screenshots show the configuration for the extended calculator: 82

94 83

95 Demonstrating the Extended Calculator If we start the calculator application we get to see the following screen: We enter 3 in the Input text field and click add and get to see the following screen: With 3 in the Input text field, we click multiply and see the following: 84

96 We enter 2 in the Input text field as in the following screenshot: Now we click divide and see the following: We enter 1000 in the Input text field, click add and enter My test message in the Secret Message text field as in the following screenshot: We click to message and we get to see the message page as below. The value of (result % 10) is calculated and the entered value for the message is displayed by a parent data custom tag. A child data custom tag extracts the message from the parent and displays it (1 + (result % 10)) times. If we click Back to calculator, we return to the calculator page as shown below. 85

97 Demonstrating the Final Calculator To conclude the demonstration, we change the configuration of the two page components as in the following two screenshots: 86

98 The calculator page of the web application is then changed live to look like: If we click on to message, we are forwarded to the external page with URL 87