CLOUD SUPPORT COMPONENT: CASE STUDY BASED ON ENCAPSULATED COMPONENT MODEL

CLOUD SUPPORT COMPONENT: CASE STUDY BASED ON ENCAPSULATED COMPONENT MODEL A dissertation submitted to The University of Manchester for the degree of Master of Science in the Faculty of Engineering and Physical Sciences 2014 HALIM FADHLI BIN AHMAD FUAD SCHOOL OF COMPUTER SCIENCE

2 TABLE OF CONTENTS TABLE OF CONTENTS 2 LIST OF FIGURES 6 LIST OF TABLES 8 LIST OF EQUATIONS 9 ACRONYMS 10 ABSTRACT 11 DECLARATION 12 INTELLECTUAL PROPERTY STATEMENT 13 ACKNOWLEDGEMENT 14 1. INTRODUCTION 15 1.1. AIM 16 1.2. OBJECTIVE 16 1.3. REPORT OUTLINES 17 2. BACKGROUND 18 2.1. OBJECT-ORIENTED DEVELOPMENT 18 2.2. IDEALISED COMPONENT LIFE CYCLE 18 2.3. CURRENT SOFTWARE COMPONENT MODEL 20 2.4. COMPONENT-BASED OR SERVICE ORIENTED SOFTWARE DEVELOPMENT 20 2.4.1. FRACTAL 21 2.4.2. ENTERPRISE JAVA BEANS (EJB) 22 2.4.3. X-MAN 22 2.5. CLOUD COMPUTING ARCHITECTURE 22 2.5.1. INFRASTRUCTURE AS A SERVICE (IAAS) 23

3 2.5.2. PLATFORM AS A SERVICE (PAAS) 23 2.5.3. SOFTWARE AS A SERVICE (SAAS) 23 2.6. EXTENSIBLE MARKUP LANGUAGE (XML) TECHNOLOGY 24 2.7. WEB SERVICES 25 3. ENCAPSULATED COMPONENT MODEL (CASE STUDY: X-MAN) 26 3.1. BRIEF INTRODUCTION 26 3.2. COMPUTATION UNIT 27 3.3. CONNECTORS 28 3.4. DATA CHANNEL 28 3.5. ATOMIC COMPONENT 29 3.6. COMPOSITE COMPONENT 29 3.7. DEPOSIT OR RETRIEVE ON REPOSITORY 29 3.8. CURRENT IMPLEMENTATION 30 3.8.1. GENERIC MODELLING FRAMEWORK (GME) 30 3.8.2. X-MAN IN ECLIPSE MODELLING FRAMEWORK (EMF) 32 4. MOTIVATION, THEORY AND DESIGN 35 4.1. PROJECT STORY 35 4.2. REQUIREMENT 36 4.3. DESIGN 37 4.3.1. XML DOCUMENT DESIGN 39 4.3.2. DATABASE DESIGN 41 5. METHODOLOGY 42 5.1. RATIONAL UNIFIED PROCESS 42 5.1.1. KNOWLEDGE GATHERING 43 5.1.2. INFORMATION ANALYSIS 43 5.1.3. DEVELOPMENT 43 5.1.4. PROJECT POST-MORTEM 44

4 5.2. DELIVERABLES 44 5.3. PROJECT TIMELINE 44 5.4. OUT OF SCOPE ISSUES 45 6. A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 47 6.1. TECHNOLOGY SELECTION 47 6.1.1. X-MAN CLIENT TOOL SELECTION 47 6.1.2. CLOUD PROVIDER 49 6.1.3. WEB SERVICE SELECTION 50 6.1.4. DATA TRANSFER FORMAT 51 6.1.5. CLOUD VIRTUAL MACHINE (CLOUD VM) 51 6.1.6. CLOUD VM JAVA COMPONENT EXECUTION ENVIRONMENT 51 6.1.7. CLOUD VM C# COMPONENT EXECUTION ENVIRONMENT 52 6.1.8. X-MAN REPOSITORY (DBAAS SELECTION) 52 6.2. CLIENT TOOL PROTOTYPE 53 6.2.1. DESKTOP AND WEB PROTOTYPE 53 6.2.2. MOBILE PROTOTYPE 54 6.3. X-MAN CLOUD ARCHITECTURE 56 6.3.1. COMMUNICATION MECHANISM X-MAN XML DOCUMENT 56 6.3.2. COMMUNICATION VALIDATION X-MAN XML SCHEMA 58 6.3.3. CLOUD MEDIATOR WEB SERVICE 59 6.3.4. COMPONENT EXECUTION ENVIRONMENT CLOUD VIRTUAL MACHINE 62 6.3.5. X-MAN REPOSITORY CLOUD DATABASE (DBAAS) 63 6.4. WORKFLOW 67 6.4.1. FLOWCHART 67 6.4.2. DEPOSIT 71 6.4.3. RETRIEVE 73 6.4.4. EXECUTE ATOMIC COMPONENT 77 7. TESTING AND EVALUATION 79

5 7.1. UNIT TESTING 79 7.2. INTEGRATION TESTING 80 7.3. REGRESSION TESTING 81 8. CONCLUSIONS AND FUTURE WORK 83 8.1. SUMMARY 83 8.2. CONTRIBUTIONS MADE 84 8.3. FURTHER WORK 84 8.3.1. INTRODUCING NEW DOCUMENT 84 8.3.2. INTRODUCING NEW RETRIEVE CONCEPT 84 8.3.3. FURTHER STUDY AND RESEARCH 85 REFERENCES 86 APPENDIX A 92 APPENDIX B 98 (21541 word counts)

6 LIST OF FIGURES Figure 2.1: Idealised Component Life Cycle 19 Figure 2.2: All categories of component life cycle today. 20 Figure 3.1: X-MAN Component Model 27 Figure 3.2: Atomic and Composite Design in GME 31 Figure 3.3: Data-routing view (Data channel) 32 Figure 3.4: Atomic Component Design 33 Figure 3.5: X-MAN in Eclipse Tool Design 34 Figure 4.1: Project Design 38 Figure 4.2: XML Document initial design idea 40 Figure 4.3: Database Design 41 Figure 5.1: Rational Unified Process Diagram 43 Figure 5.2: Project timeline (Gantt Chart) 45 Figure 6.1: BeanShell Interpreter usage code 52 Figure 6.2: CSharpCodeProvider custom class usage. 52 Figure 6.3: X-MAN desktop prototype for demonstration purpose 54 Figure 6.4: X-MAN web prototype for demonstration purpose 54 Figure 6.5: X-MAN mobile prototype for demonstration purpose 55 Figure 6.6: X-MAN XML Document (S2) 57 Figure 6.7: X-MAN Web Service - Getting list of atomic component (S1) 61 Figure 6.8: X-MAN Web Service - Getting list of services in a specified atomic component (S3) 61 Figure 6.9: X-MAN atomic component service execution (S5) 62 Figure 6.10: Amazon AWS Cloud VM Java and.net 63 Figure 6.11: X-MAN Repostiory on the cloud (DBaaS) 65 Figure 6.12: X-MAN Repository Data. Table: atomiccomponentt 65 Figure 6.13: X-MAN Repository Data. Table: method 66 Figure 6.14: X-MAN Repository Data. Table: service 66 Figure 6.15: X-MAN Repository Data. Table: serviceappinfo 67 Figure 6.16: Deposit Flowchart 68 Figure 6.17: Retrieve Flowchart 69 Figure 6.18: Component Execution Flowchart 70 Figure 6.19: Client Tools Atomic Component Modelling Phase 71 Figure 6.20: Client Tools Atomic Component Deposit Phase 72 Figure 6.21: Client Tools Atomic Component Deposit Successful 72 Figure 6.22: X-MAN Repository atomiccomponentt table with new data 73 Figure 6.23: Retrieve an atomic component from client web prototype tool 74 Figure 6.24: Atomic component model visualisation loaded from Component Retrieval process 74 Figure 6.25: XML document produced for "DateTime" atomic component 75

7 Figure 6.26: X-MAN Mobile Prototype initial view 76 Figure 6.27: Component Retrieval from X-MAN Mobile Prototype 76 Figure 6.28: Atomic Component Execution from X-MAN Web Prototype 78 Figure 6.29: Component execution from X-MAN Mobile Prototype 78 Figure 0.1: XML Schema for X-MAN atomic component XML document 99

8 LIST OF TABLES Table 4.A: Project Requirement 37 Table 6.A: X-MAN Tool Comparison 48 Table 6.B: Cloud Provider Comparison 49 Table 6.C: X-MAN Web Services 59 Table 7.A: Unit Testing List 79 Table 7.B: Integration Test Result 81 Table 0.A: Integration Test Case 1 92 Table 0.B: Integration Test Case 2 94 Table 0.C: Integration Test Case 3 96

9 LIST OF EQUATIONS Equation 1: Syntax Convention for Storing Application Specific Information... 64

10 ACRONYMS 1. Artefacts = any deliverables that are produced during the course of the project. 2. Composition = combining or attaching two components or objects using an appropriate mechanism. 3. Repository = container or database of the component. 4. Setup Script = code to set up the product that are usually executed only once and tend to be forgotten to be documented. 5. Test case = document containing relevant information of how test should be conducted, with its expected result and output. 6. Exogenous = encapsulated. 7. Validation = process of making sure the document sent are correct with regards to the structure plan compared to

11 ABSTRACT Component-based development (CBD) is not a new topic. It has enjoyed successful adoption from various big companies in IT world. However, cloud computing is still an area that yet to be successfully explored by the CBD. While any component model alone is not enough, encapsulated component model is worth noting for as it satisfies the idealised component lifecycle if compared to other component models. Being the new topic in the component-based development world, there is only one component model, X-MAN, as the component model embracing this encapsulated approach. However, there is still no true way of implementing any component model or X-MAN in the cloud. This project focus on identifying and demonstrating the idea through various stages. The result is a component development in the cloud that is not only reusable, but also collaborated between developers to a larger scale by providing a new dimension of capability for X-MAN and the encapsulated component model group.

12 DECLARATION No portion of the work referred to in the dissertation has been submitted in support of an application for another degree or qualification of this or any other university or other institute of learning.

13 INTELLECTUAL PROPERTY STATEMENT i. The author of this dissertation (including any appendices and/or schedules to this dissertation) owns certain copyright or related rights in it (the Copyright ) and s/he has given The University of Manchester certain rights to use such Copyright, including for administrative purposes. ii. Copies of this dissertation, either in full or in extracts and whether in hard or electronic copy, may be made only in accordance with the Copyright, Designs and Patents Act 1988 (as amended) and regulations issued under it or, where appropriate, in accordance with licensing agreements which the University has entered into. This page must form part of any such copies made. iii. The ownership of certain Copyright, patents, designs, trademarks and other intellectual property (the Intellectual Property ) and any reproductions of copyright works in the dissertation, for example graphs and tables ( Reproductions ), which may be described in this dissertation, may not be owned by the author and may be owned by third parties. Such Intellectual Property and Reproductions cannot and must not be made available for use without the prior written permission of the owner(s) of the relevant Intellectual Property and/or Reproductions. iv. Further information on the conditions under which disclosure, publication and commercialisation of this dissertation, the Copyright and any Intellectual Property and/or Reproductions described in it may take place is available in the University IP Policy (see http://documents.manchester.ac.uk/display.aspx?docid=487), in any relevant Dissertation restriction declarations deposited in the University Library, The University Library s regulations (see http://www.manchester.ac.uk/library/aboutus/regulations) and in The University s Guidance for the Presentation of Dissertations

14 ACKNOWLEDGEMENT I would like to express my greatest gratitude for Dr. Kung Kiu Lau who has given so many thoughtful inputs and guidance during the course of this project. He was influential, while keeping his patience, so the project would stay on course even though there were many times where self-motivations and self-dedications was truly challenged, but his words managed to keep everything on the line. I am also grateful for my wife, for providing endless support in finishing this project on time. Finally my friends, who has been helping me a lot with many useful opinions for making this project as exciting as it is.

CHAPTER 1: INTRODUCTION 15 1. INTRODUCTION Component-based development has been around for quite some time already and accepted by many computer science communities around the world. It is built on top of object-oriented programming, to further improvises and brings greater semantics of a component and reusability in software development world. This can help to define an executable software component properly and systematically from the requirement. This concept is achieved by proper model description and architectural pattern in a component model [1]. Various component models have been introduced and proved to be beneficial for solving many problems in software development area. Service-oriented software development, on the other hand, is closely related to component-based software development. Components were recognised as a unit in software development that contains both provided and required services. In this regard, service-oriented computing composition refers to service-orchestration with components as the artefacts that act as a middleware holding these services. Meanwhile in component-based computing, composition varies, relying on the underlying component-model. Nowadays, with cloud computing introduced, components and services may be utilized and have important roles as the basic software development of virtualized applications [2]. Component-based and service-oriented software development emphasizes on architectural design that promotes software development through component discovery and composition. Component models that fulfil or close to fulfilling the idealised component life cycle will have a repository as its components container. These repositories have worked well in containing the binaries of component to be composed later and stored locally. However, cloud computing is an area to be explored by the component-based development. Cloud computing are popular today, and many services adopting cloud services has proved to be successful. Cloud computing dedicates itself on the delivery of services through flexible and scalable resource virtualisation. Aligned with the component model s reusable criteria, cloud computing will improve the component model s reusability to a larger scale. This concept is the focus to be achieved for component-based development in the cloud.

16 CHAPTER 1: INTRODUCTION Amongst many different types of component model, encapsulated (exogenous) component model is the only component model that satisfies the completely idealised component lifecycle. However, the choice this kind is still limited. In the University of Manchester, there is an exogenous component model being developed under the guidance of Dr Kung-Kiu Lau. This component model is called X-MAN, where it fulfils all the idealised component life cycle being discussed. X-MAN in previous versions has gone under GME tool and currently it is being developed in Eclipse. On the other hand, for X-MAN repository, under previous implementation, it resides in local file systems. So component and service discovery in this case is somewhat limited to the machine that contains the repository. Therefore, aligned with the project goals, this component model is well suited to be adopted and to be studied on the possibility of component-based development in cloud computing. 1.1. Aim The project aims to research on the possibility of an exogenous component-based development for cloud computing while embracing the idealised component life cycle. Besides that, this project aims to utilise the component model building block s composition concept where it can be put to use for architectural design in cloud computing. Following current user s acceptance level on cloud services, this project aims to bring the component-based development community to the cloudcomputing world. 1.2. Objective The objective of the project has been primarily leaning towards researching on the possibility of component-based development in cloud computing to: i. Find out what is the current practice and investigate methods to be implemented, which will embrace the idealised component life cycle in cloud computing. ii. Investigate cloud-computing possibilities on what it can provide for component-based development. iii. Develop an executable prototype to demonstrate the concept of componentbased development in cloud computing while proving the improved criteria benefited from the implementation. iv. Produce a report, stating all the findings and results for this research.

CHAPTER 1: INTRODUCTION 17 1.3. Report Outlines The report contains five chapters. The report structure description is as the following: Chapter 1 introduces the idea of component-based development in cloud computing as well as specifying aim and objectives of the project. Chapter 2 contains the literature review of several topics that is with relation towards build-up to the project. Component-based development and cloud computing remains the main topic while the chapter also covers some small topics to assist in the build-up of the project background. Chapter 3 is an extension of the background covered in Chapter 2, with more specific coverage for encapsulated component based development and its model, X-MAN. Chapter 4 explains the project description, listing requirements of the project with what should be implemented and what may be implemented to improve the quality of the product features. End product diagram is included too in this section. Chapter 5 explains the methodology to be used to achieve the project goals including the detailed project timeline (Gantt chart). Other related areas covered are deliverables, software development methodology adopted, and issues that are out of topic to the project. Chapter 6 consists of project progress implementation. Prototype screenshots, demonstration and concerns identified during the course of project development are covered too. Chapter 7 contains report on project testing, with some evaluation involved for the prototype implemented Chapter 8 summarises the report with what lessons had been learnt from the progress so far, what had been done, what work has been contributed, and finally the future work. The end section contains appendices and a list of references (endnotes), which are used to relate this project.

CHAPTER 2: BACKGROUND 18 2. BACKGROUND Two principal components define the background of this project. Software development, which goes specifically for component-based or service-oriented development, and cloud computing architectures are two distinct topics that can be put together to the right use. However, each has its depth that requires proper comparison for the project implementation may or may not use. Additionally, several other areas have been included to explain better about the project. 2.1. Object-Oriented Development This area, though small, is described to explain better what component-based development is all about. Object-oriented programming gets proper support in many programming languages from Java, C++, Objective-C, and many other programming languages. In the programming world, code sharing has made object-oriented programming attractive as it is, and this is because it enables developers to share their code amongst completely different projects [3]. Along with the fact that it reduces the same code from being written more than once, it also reduces the amount of time required for a project to start if they have some code already written on a separate project. Therefore, a component in the object-oriented development is an object where it is reusable in many different projects or areas in the project. However, defining a component in an object can be hard as an object can have a very fine granularity [4]. This confusion happens because some component model defines its component from a collection of objects, whereas an object is described as a component from some other component model. Therefore, reusing a component can bring different semantics to different developers. 2.2. Idealised Component Life Cycle Idealised component life cycle describes the appropriate behaviour of a component model. It consists of three phases, design, deployment and run-time. Design phase, represents the initial phase where the component is constructed, described, with source code generation taking place after that. These processes benefited from the builder or a tool to assist in the component construction. Generation of binary code may as well happen in this phase where it would be deposited into the repository.

CHAPTER 2: BACKGROUND 19 Deployment phase is the phase where it will be handling the binaries of the components generated earlier, and then later on it would be deployed into the execution environment. It can make use of the repository, where it will be retrieved, further orchestrated, and deployed to the execution environment. Finally, the runtime phase represents the running system, executing the instantiated components created earlier [5]. Figure 2.1: Idealised Component Life Cycle i In the diagram above, Figure 2.1 illustrates the idealised component life cycle being discussed. In addition, Figure 2.1 shows that the composition process should be possible in any of the phases from Design and Deployment as the system is constructed. So in this case, component can be reused in any of the phases making repository truly flexible to accept any incoming components (deposit) and outgoing components (retrieve). i Adapted from Towards Composing Software Components in Both Design and Deployment Phases, by K.-K Lau, p. 2.

CHAPTER 2: BACKGROUND 20 2.3. Current Software Component Model Figure 2.2: All categories of component life cycle today. ii Following Mr Kung findings in his paper on unifying accepted terminology of component-based software engineering, there are four other categories of what current component models had adopted for their component life cycle [6, 7]. Figure 2.2 above illustrates the other four categories of component life cycle. The idealised component life cycle is the result of this extensive research by Mr Kung, and all of it was well-described in his lecture slides [8]. 2.4. Component-Based or Service Oriented Software Development Component and service are closely related. As described in Section 0 above, a component can be seen as a middleware for holding provided and required services for composing with each other. Component-based development offers yet another approach to the software development with its component models. Component model brings together its definition of how a component should be defined. This approach brought clearer semantics of what a component is and subsequently, improving the reusability of components created. In an object-oriented view, a component in component-based development can be made up of a single objects or a collection of objects [ 9 ]. Therefore, components are distinguishable and representable by the component model adopted. ii Adapted from "COMP61521: Component-based Software Development [PowerPoint slides]", by K.-K. Lau, 2012, Lecture 3: Current Software Component Models, p. 3. Copyright 2012 by the University of Manchester.

CHAPTER 2: BACKGROUND 21 There are several options available for component models adoption. As the actual idea is to meet the idealised component life cycle, Section 2.1 above describes the component model desired capabilities when adopted in cloud computing. The component-based development must have all of these criteria so designing, composing, depositing into repository and retrieving from repository in each phase of design and deployment is possible. In this case, the project will be conducted with idealised component life cycle as its fundamental for its result. There are many component models to be selected from, where few of them will be compared on its advantages and disadvantages. Three component models are comparable based on the student s preferences and preferred programming language with Java. These component models are Fractal, Enterprise Java Beans (EJB), and X-MAN. However, as described in the following points, X- MAN are chosen as the desired component model for the repository design and availability reason. 2.4.1. Fractal Fractal component model under Julia framework brings Java supportability in Fractal. Alongside the framework, there are several tools provided within Fractal to assist the implementation, assembling, deployment and management of components of Fractal in Java. The most notable tools are Fraclet and Fractal ADL (Architecture Description Language). Fraclet provides syntax in the form of annotations to describe and define components in Fractal. The approach makes writing a component can be done within a single file and thus can be seen as decreasing the amount of codes to be written by developers. Fractal ADL, on the other hand, contains additional files in the form of XML DTD for describing components. Everything from component types, component hierarchies, component implementations, and component bindings will be described in the DTD file [ 10, 11 ]. However, as illustrated from Figure 2.2, Fractal falls to Category 1 of component life cycle where it has no repository to work as its container. Every component designed and developed from the builder to be executed in the runtime directly. In addition, these components can only be dealt with its source code in the design phase [ 12 ]. Therefore making Fractal component model suitability with the project to test its potential capabilities in the cloud is decreased.

CHAPTER 2: BACKGROUND 22 2.4.2. Enterprise Java Beans (EJB) Written in Java programming language, Enterprise Java Beans provides architecture to set up enterprise beans (component). This component lives in a dedicated server as part of a computer network that embraces the client/server model. As popular as it is, components in EJB was known as servlets while the application or container that runs the servlets often called as an application server. Enterprise Java Beans originally comes from IBM, which was later on to be adopted by Sun Microsystem, and now to be under Oracle [13, 14]. According to the four categories of component model life cycle in Figure 2.2, EJB would have fallen into the category 2, which is design with deposit only repository. However, despite the existence of the repository as its container, the container in EJB is particular to the application where it is hosted and managed by the J2EE server. Repository in EJB can handle deposit process, but there is no retrieve mechanism as the container is part of the application itself, which will be executed in the runtime phase. So there is no assembler in the deployment phase to have a new composition towards runtime phase [15]. However, despite the existence of the repository, EJB repository still does not meet the idealised component life cycle to make the cut for this project. 2.4.3. X-MAN Different from other current component model available out there, X-MAN uses exogenous connector to build a system in component-based development (CBD) [16]. Exogenous connectors are a set of connectors in X-MAN that encapsulates control [17]. Currently, the released version of X-MAN can be implemented using a builder tool of Generic Modelling Environment (GME). The tool is designed and developed by the School of Computer Science at the University of Manchester. X- MAN is a component model developed to meet the full-idealised component lifecycle. Under GME tool, X-MAN repository is created with the database file type (*.db) that resides in a local machine. However, the repository capabilities do fulfil all the idealised component lifecycle criteria. There is another implementation of X- MAN, and it is under development in Eclipse. This implementation, however, still undergoes constant development process with Ph.D. students under Dr Kung. 2.5. Cloud Computing Architecture The project needs to consider on the advantages and disadvantages of cloud computing architecture since it has three layers. These layers stand

CHAPTER 2: BACKGROUND 23 from infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) [18]. Each could influence different implementation for the project, and it might as well change the result of this research. 2.5.1. Infrastructure as a Service (IaaS) It is the most basic cloud-computing layer where it provides computers, usually virtual machines where users have the most control. In this layer, the user handles everything from the operating system and runtime environment installation, patches, updates, storage, networks and provision processing [19, 20]. It is certainly an advantage since everything can be customised to the project needs. However, it still requires careful consideration since having control of everything means increasing workloads in maintaining this layer more than what another layer could provide. 2.5.2. Platform as a Service (PaaS) This layer sits in the middle of the architecture between IaaS and SaaS. It provides the underlying infrastructure (including operating system) and the application development platform (e.g. runtime environment) so the user controls the deployed application while specifying its settings to meet the provided infrastructure from the provider [19,21]. Adopting this layer is an advantage since there is many cloud providers providing many different kinds of combination to fit with the customer needs. However, the provider handles patches and updates thus; the project needs to consider whether this can bring any problem in the future. 2.5.3. Software as a Service (SaaS) SaaS sits on the top layer of the cloud computing architecture. It is software designed for end users to use through the cloud, and it is accessible by the user from various client devices [19,22]. Software like Git or Gmail is few examples of SaaS software that could deliver services remotely. It is the best option considering the software are used by many, and there are professionals behind these software products addressing its bugs. However, the process of the software might not be enough to demonstrate the idealised component life cycle for this project. Another concern would be the supportability of the component model desired by this project. Another notable cloud service that is part of the SaaS is Database as a Service (DBaaS). DBaaS offers a comprehensive product in the cloud, where user can use the database service as it is

CHAPTER 2: BACKGROUND 24 without requiring any installation or machine to run it. As described by Oracle in their paper (2013), it provides shared, consolidated platform to provision database services on and self-service model for provisioning those resources as well as providing chargeback based on database usage and elasticity to scale out or back the database resources [23]. It can run as it is in the cloud. Products like Heroku Postgres, Google Cloud SQL and ClearDB MySQL is one of the options of DBaaS for adoption in this project. 2.6. Extensible Markup Language (XML) Technology Extensible Markup Language (XML) creation motivation was pure. It was designed to describe data. It has been the core of many documents and has been successful at it. Today, documents like HTML, XHTML, RSS, SOAP, Atom and XAML are just a few example of famous documents based on XML technology [ 24 ]. Besides documents, many significant applications and even operating systems enjoyed their success by embracing the XML technology. Application like Microsoft Office, Apple s iwork to Mac OSX PLIST file, has adopted XML technology successfully [25, 26, 27]. This technology is a markup language for encoding documents by defining a set of rules. These rules are in a format that is both human and machine-readable [28]. These criteria aligned with its design goals for embracing generality, usability, simplicity and compatibility [29]. In accordance to the project, XML will be an essential framework for describing the application own markup language with its markup tags. Additionally, web services are one of many technologies embracing XML for representing arbitrary data structure [30]. Encapsulated component model, through its standard metadata that is shareable across the client application, will need to be represented through XML technology so it could achieve the desired purpose for component sharing in the cloud environment. Furthermore, many application programming interfaces (APIs) have been developed with XML as its data transport such as Google Maps API from Google and the license for XML is all free, open standards [31, 32].

CHAPTER 2: BACKGROUND 25 2.7. Web Services There are two primary web services architectural style available today. One is Simple Object Access Protocol (SOAP), and the other is Representational State Transfer (REST). Aligned with the project goals, RESTful web services are thought to be a better choice for its approach in focusing more towards the main content rather than protocol or formatting [33, 34]. While SOAP relies heavily on XML and protocol for the document format, REST provides an easier, lighter and flexible use for the web service. Despite being able to support four different HTTP 1.1 verbs from GET, POST, PUT, and DELETE, it also able to produce output from XML, CSV, JSON and RSS [35]. This capability means the application may produce a more appropriate output to the project rather than following the SOAP protocol on XML in every occasion. Though the choice between the two architectural styles of web services is still open towards the end of the full implementation of the project idea, RESTful web services deliver the intended result perfectly for the time being. This open option is because should the project requires serious distributed enterprise environment in the future; SOAP is language, platform and transport independent if compared to REST. Making SOAP provides better transportability, reliability and security [36].

CHAPTER 3: ENCAPSULATED COMPONENT MODEL 26 3. ENCAPSULATED COMPONENT MODEL (CASE STUDY: X-MAN) Encapsulated component model is the only component model that embraces idealised component lifecycle. This exogenous component model brings a different approach where control encapsulates component from outside and invocation only happens within the component without calling outside component [ 37 ]. Exogenous component model can be considered as a new topic under component-based development world. It can be considered as new because there are not many component models embracing this approach and none of them is a proven framework like Enterprise Java Beans (EJB), Component Object Models (COM) and Common Object Request Broker Architecture (CORBA) component model which has long been the main talking point for component-based development topic. However, there is one significant encapsulated component model that will be taken as the project subject. Under the University of Manchester, Dr. Kung-Kiu Lau introduces X-MAN with his research on exogenous component model. This chapter will discuss current capability of exogenous component model with X- MAN as the subject for component model to be adopted. While this chapter discusses the core component of X-MAN, it will not cover in depth on all X-MAN features and capabilities while covering only the area where it is most relevant to the project aims and objectives. 3.1. Brief Introduction As described from Section 2.4.3 above, X-MAN uses exogenous connector in order to build a Component-based Development (CBD) system [38]. It is a framework for compositional design developed by the Component-based Software Development group in the University of Manchester [37]. It is the only component model with encapsulated component [39.40]. Befitting its approach as encapsulated component model, computation in X-MAN is entirely control-driven where data flows together with control flow [41]. There are three main components in X-MAN that makes it suitable with the project: (i) computation unit, (ii) connectors, and (iii) data channel. These three components covers three basic elements in every software system;

CHAPTER 3: ENCAPSULATED COMPONENT MODEL 27 control, computation and data [17, 42 ]. These three main components play an important role in constructing two kinds of component in X-MAN. They are atomic component and composite component [41]. By applying composite design pattern in mind, these two components may be used interchangeably in constructing a system with atomic component as the leaf node of each branch. 3.2. Computation Unit The first main component of X-MAN, computation unit covers the most important element in every software system. Computation unit provides a set of methods for invocation. Each method may have their own execution codes or processing that is unique to them. Encapsulation concept limits the methods in one computation unit to be self-contained it does not call methods in other computation unit [37]. Any processing happens inside the method was influenced by the data passed to them, not by the invocation of other methods in another computation unit. Therefore, the implementation code written must have complete behaviour without relying on another computation unit to complete its behaviour. Additionally, codes within methods in a computation unit are written in a chosen programming language depending on the tool adopting it [43]. This situation can be seen from Figure 3.1 below, with computation unit is represented by the IU in Atomic component (a) and U represents methods associated with it. Together with the computation unit, there are services to serve as an interface and to expose these methods to the outside entity. Figure 3.1: X-MAN Component Model iii iii Adapted from X-MAN: An MDE Tool for Component-based System Development, by K.-K Lau, C.M. Tran. In 38 th Euromicro Conference on Software Engineering and Advanced Applications, (2012), p. 159.

CHAPTER 3: ENCAPSULATED COMPONENT MODEL 28 3.3. Connectors There are three types of connectors in X-MAN, invocation, composition and special connectors. These connectors can be called as exogenous connectors as it provides the core identity for X-MAN as an encapsulated component model. These connector s characteristics are that it encapsulates control in exogenous component model, so interaction and communication between components are directed from these connectors [44]. Invocation connector is connected to the computation unit to provide access and invoking the methods inside it [43]. In Figure 3.1, invocation connector is the link between computation unit (IU) and methods (U) where it provides access for computation unit towards the methods associated for it. However, the other type of connector, composition connector, is more important to the project. It is a composition mechanism for component. It coordinates the composed components execution, fulfilling the computation unit s characteristic where its method does not call other computation unit methods. Two basic composition connectors are Sequencer and Selector. Sequencer encapsulates components by providing sequence on which components should be run ahead of the other component, while Selector encapsulates components by offering branching and section on which components should be executed based on the data that flows with it [43]. Special connectors can be called as adaptors, with the examples of Loop and Guard. Different from composition connectors, it is a unary connector connected to a single component [45]. Figure 3.1 shows the composition connector (b) and how it composed two different atomic components inside a composite component (c). According to Dr. Kung-Kiu Lau and Cuong M. Tran in their paper, Loop allows for iteration over a single component while Guard offers gating on the component to be executed [43]. By embracing encapsulation characteristic, these connectors allow hierarchical component composition where every component has one top-level connector, which is either invocation connector in atomic component or composition connector in composite component [ 46 ]. Therefore, these characteristics of connectors make X-MAN as an encapsulated component model that is entirely control-driven. 3.4. Data Channel Data channel is another main component in X-MAN that is important to the project. It is a kind of connector or pipe, with a directed edge that connects two data ports of

CHAPTER 3: ENCAPSULATED COMPONENT MODEL 29 input and output. It transfers data from its source (output data port) to its target (input data port) [45]. 3.5. Atomic Component The first kind of component in X-MAN, it represents a very basic building block in encapsulated component model. In an object-oriented view, atomic component can be represented as a class. This atomic component contains computation unit providing it with a list of methods. As mentioned in Section 3.2, these methods do not call methods in another computation unit. So, it does not initiate any control, rather than providing services when invoked by connectors. The top-level connector for atomic component is the invocation connector, and atomic component is formed with it, where it acts as an interface for the component and exposing methods of the computation unit to be used by other connectors for composition [43, 47]. This feature ideally enables component with a black box status where reusing the component without requiring to know the inner structure and code is possible as well as its interface as the only point of access [48]. Figure 3.1 shows atomic component diagram on (a). 3.6. Composite Component Composite component consists of a set of components. In a hierarchical structure, its top-level connector is made up of composition connectors, composing components from atomic or composite components on its leaf nodes. While atomic component encapsulates computation, composite component encapsulates both computation and control [46]. In composite component, there is also data channel. Data channel directs the data from one component to another in order to invoke the execution of each component. Therefore, each component will not be aware of what happens during the execution of another component or what environment revolves around with it. This situation introduces a somewhat independently executable component with low coupling between them [49]. Figure 3.1 shows composite component diagram on (c). 3.7. Deposit or Retrieve on Repository Deposit and retrieve is a basic functionality for X-MAN to meet its idealised component lifecycle. The concept is simple; X-MAN has its proper repository to serve as its container to contain the component designed. For meeting the idealised

CHAPTER 3: ENCAPSULATED COMPONENT MODEL 30 component lifecycle, this repository enabled each component to be both deposited and retrieved on any phases from design and deployment phase. Deposit will store the component designed in the repository while retrieve will extract the stored component and reuse it in any phases. Retrieve is associated with composite component where component retrieval usually is intended for composing components [49]. 3.8. Current Implementation However, X-MAN is such a good framework and it is the only encapsulated component model available for now, the tool adopting it is still limited. There are only two tools implementing the X-MAN framework with two different languages. The first implementation is done in Generic Modelling Framework (GME) tool with the second on Eclipse. GME tool supports X-MAN framework with codes written in C, while Eclipse is embracing Java programming language for its code in the method. 3.8.1. Generic Modelling Framework (GME) Led by Dr. Kung-Kiu Lau with his Component-based Software Development group at the University of Manchester, they have developed X-MAN on GME tool using model-driven engineering. This tool development is part of the Cost-efficient methods and processes for safety-relevant embedded systems (CESAR) project a European funded project from Artemis Joint Undertaking (JU) [50]. However, GME tool is not a fully X-MAN dedicated tool. According to its official website, it is a GME framework instantiated with meta-models of X-MAN component models [51]. Using C compiler, X-MAN in GME tool supports code execution from C syntax inside its method code.

CHAPTER 3: ENCAPSULATED COMPONENT MODEL 31 Figure 3.2: Atomic and Composite Design in GME iv GME tool is a complete tool to be used and studied on the full extent of X-MAN capability. Though it is not on a very popular tool or IDE like Eclipse or Visual Studio, but it does simulate proper X-MAN features on a workable tool seamlessly. However, it is quite limited for community support on GME tool should its feature or functionality to be extended extensively. In Figure 3.2, screenshots of GME tool is shown with (a) showing the view for designing atomic component in the tool while (b) is showing the view for designing composite component. Yellow circle in Figure 3.2 (a) is showing the computation unit (IU) with its methods (U) associated to it through the invocation connector. Purple Square is showing services for exposing the Vote method in U and all of its expected inputs and outputs (data). While, on Figure 3.2 (b), a composite component design view is showing sequencer as its top-level connector (yellow circle), composing three components. A service is yet again used to expose the public method on this composite component so it will have a unified interface to access this component. iv Adapted from X-MAN: An MDE Tool for Component-based System Development, by K.-K Lau, C.M. Tran. In 38 th Euromicro Conference on Software Engineering and Advanced Applications, (2012), pp. 161-162.

CHAPTER 3: ENCAPSULATED COMPONENT MODEL 32 Figure 3.3: Data-routing view (Data channel) v Figure 3.3 shows data routing view in GME tool. This view intended to orchestrate data channel from each output to inputs or from publicly exposed parameters data mapped to the composed component method s data. This data channel encapsulates each method invocation and protects the invocation of each atomic component computation unit from coupling to the other computation unit. Therefore, processes inside one computation unit can be executed independently without any coupling from another computation unit. Additionally, repository in GME tool designed with *.db extension and it lives inside the local system. So only the GME tool that runs on the same system can retrieve the deposited component whereas the GME tool on a different system will have a different component container in their system. 3.8.2. X-MAN in Eclipse Modelling Framework (EMF) Compared to GME tool, Eclipse is more popular, and its community support is more widely known to the modern developers today. X-MAN in Eclipse is developed by Simone di Cola, led by Dr. Kung-Kiu Lau as part of his Component-based Software Development group. Though it is still under constant development, it provides a v Adapted from X-MAN: An MDE Tool for Component-based System Development, by K.-K Lau, C.M. Tran. In 38 th Euromicro Conference on Software Engineering and Advanced Applications, (2012), p. 162

CHAPTER 3: ENCAPSULATED COMPONENT MODEL 33 different approach by embracing Java programming language as its main compiler. X-MAN in Eclipse in this case is quite similar with X-MAN in GME tool. It is developed as a plugin for the Eclipse Modelling Framework (EMF) tool to provide a different dimension of features for the tool itself. Additionally, the tool provides a more familiar view on the IDE used to develop X-MAN. Figure 3.4: Atomic Component Design Figure 3.4 above shows the atomic component design view from EMF tool. With Eclipse project structure view for the components created, X-MAN in EMF provides a more familiar feel to the development process of X-MAN. Even though the icon is different from GME, it is quite straightforward from the screenshot shown in Figure 3.4. CU icon represents for a computation unit, and the play icon within it represents each method for the computation unit. Another icon showing d represents for data element. Deposit and retrieve button in this case, represents the same concept as the repository in GME tool. However, repository for X-MAN in EMF lives in the cloud virtual machine server. So, depositing and retrieving a component involves with the transaction between EMF in a client machine with the database in the cloud virtual machine.

CHAPTER 3: ENCAPSULATED COMPONENT MODEL 34 Figure 3.5: X-MAN in Eclipse Tool Design Figure 3.5 illustrates the design used by the X-MAN in Eclipse tool. The idea for the design is that the X-MAN in Eclipse tool to be served from the cloud virtual machine. This machine will handle all the transactions for depositing or retrieving components, and then to be stored safely in the repository (database) that is installed in the same machine. Therefore, Connected Data Objects Server (CDO Server) is installed within the cloud virtual machine to be used as a mediator for X-MAN repository handling. CDO Server offers many capabilities for the transaction like save points, branching, merging, versioning and many other useful capabilities. It works with the EMF tool to manage all EMF models and its meta-models in the repository [52]. So whether it is deposit or retrieve, CDO Server will handle the table creation process, as well as assigning appropriate keys, references and versioning. As things stand, this means that the X-MAN component in this repository will only be able to be used by the EMF tool. The vision for collaboration would be design it once, continue it anywhere. But in this case, it would be only for the user who uses the EMF tool only. In case if the idea would be extended to another tool, the component translation might not go too well with it. Also, utilising database that is installed in the same machine might not bodes well with the scalability issue should it requires expanding later.

CHAPTER 4: MOTIVATION, THEORY AND DESIGN 35 4. MOTIVATION, THEORY AND DESIGN The project main idea is to explore the capability of component-based development (CBD) in the cloud. With this idea in mind, X-MAN has been selected as the encapsulated component model to be used with the project. As described from Section 2.4.3 and Chapter 3 above, the main criteria for choosing X-MAN is for its lifecycle criteria, which meets the requirement of idealised component lifecycle. Another reason would be for it is the only encapsulated component model available so far to be adopted. The chapter will cover some project details to serve as backbone information for the coming chapters. 4.1. Project Story The project comes from Dr. Kung-Kiu Lau s idea of supporting CBD in the cloud. Regardless of the idea, supporting CBD in the cloud can be seen as too broad as there are many component models available today, yet each of them has their approach of defining a component and its underlying structure. Therefore, main characteristics of cloud computing and CBD are combined and analysed to narrow down the search of which component model is more suitable to be adapted to the project. From this research, encapsulated component model has been selected and X- MAN, as the only framework available under this category, will be used as part of the project implementation. Though there are many key criteria for cloud application development, few have been selected as key criteria for the project in this early phase such as interoperability, compatibility, availability and supportability [53]. So in theory, encapsulated component model with its full compliance of idealised component lifecycle will be able to provide these characteristics for supporting component in the cloud environment. Following the confirmation of what component model would be adopted; the main feature to be implemented would be deposit and retrieve of a component function. This means that X-MAN repository would have to be designed in the cloud so component repository would be available all the time to the client tools with access to the Internet. From Section 3.8, there are two implementations available currently for X-MAN but both of them neither have a similar repository design nor can be

CHAPTER 4: MOTIVATION, THEORY AND DESIGN 36 shared between them even though they are using the same X-MAN framework. As explained in Section 3.8.2, X-MAN in Eclipse tool has some implementation of a cloud repository. However this repository are working only for this particular Eclipse implementation with its CDO server. So in regard with cloud characteristics, the project design has to address these things and making sure that the prototype implemented aimed at delivering solution where X-MAN tools implementation by itself would not be made up of a very huge fragmentation. Since X-MAN and exogenous component model can be considered as a fresh topic, this is relatively important to avoid huge fragmentation earlier on for X-MAN adoption. So in a way, the project solution for cloud computing would have to consider something that both GME and Eclipse tool can use, including any other tools that may arise later on. Another feature potentially possible is based on the knowledge of X-MAN functionalities as described from Chapter 3. Data channel, connector and atomic component execution has open up a potential feature where each component could be executed directly from the cloud. It is described earlier in Section 3.5 on how each component can be seen as a black box component. This is because in X-MAN as exogenous component model, each atomic component cannot call other atomic component directly. Composition in this case must happen with the help of composition connector to provide control and data channel to provide coordination of data inside composite component. So the three main element of every software system from computation (invocation), control and data are separated in this matter [17, 42]. Additionally, another potential feature is possible in relation to the previous feature. Since each atomic component could be executed independently, supporting component in few different languages could be made possible too. Therefore, careful approach has to be made in this case considering the time constraint issue arises behind the progress of this project. 4.2. Requirement The initial requirement for the project has been brief, which requires the student to identify, analyse, and implement the working software that are able to demonstrate the idea of CBD in cloud computing. The detailed and concrete requirement comes after thorough studies, with the student defining the tools, component model and the process to be implemented to demonstrate the idea. The detailed and concrete

CHAPTER 4: MOTIVATION, THEORY AND DESIGN 37 requirements will be described using MoSCoW method in four prioritisation (categories); critical (must), important (should), optional (could) and unnecessary (won t). It lists the project story described from Section 4.1 in table form as below: Table 4.A: Project Requirement ID REQUIREMENT REQ1 The project must adopt X-MAN as a part of encapsulated component model to utilise its capabilities of meeting the idealised component lifecycle REQ2 The project must be able to demonstrate the deposit and retrieve process of a component to cloud environment REQ3 The project must manage the transaction and translate the component remotely in the cloud so local machine don t have to run additional processes REQ4 The project should consider any other collaboration features to be implemented REQ4.1 The project could implement the collaboration feature where components may be executed independently from the cloud REQ4.2 The project could implement the collaboration feature where components may be executed from any language from the cloud REQ5 The student should meet all the university milestones and treat it as deadlines of the product development lifecycle REQ6 The project must produce comprehensive report as required by the university 4.3. Design The design involves utilising data transfer format to produce a document for data transportation between the application and the cloud server. This would require complete understanding of the X-MAN metadata where general metadata of X-MAN will play the main part in the construction of the document for handling X-MAN in the cloud. The reason for data transfer format adoption is so that every tool would be able to communicate to the cloud without any constraint on the technology or

CHAPTER 4: MOTIVATION, THEORY AND DESIGN 38 language used. Then for this reason, XML were seriously considered for data transfer format as the other alternative, particularly JSON, were seen as more restrictive. The X-MAN document should be extensible from any other client tool to store some of their important information so supporting X-MAN component will be possible for any of the current implemented tool. The cloud interface also needs to be developed from scratch where its purpose is to handle this X-MAN document. For this reason, web services technology has been picked as one of the main component for this project to serve as the interface for the cloud infrastructure. This web service will handle the translation of X-MAN document between the database and the client application, executing the component and any other features. Database as a Service (DBaaS) has been selected from one of the many cloud services provider for the X-MAN repository. This approach would ensure the database scalability issue would not be a problem later on should the data storage needs increases. Additionally, dedicated DBaaS solution would deliver better security and many other features dedicated for the database environment. Figure 4.1: Project Design

CHAPTER 4: MOTIVATION, THEORY AND DESIGN 39 Finally, cloud virtual machine would be utilised for dedicated component execution environment. The initial focus for component execution will be primarily based on component with Java code. This machine will be used by the web service to request for component execution by sending component and data (input/output) related document. Later on, the idea of having more than one cloud virtual machine to handle different language environment for component execution will be tested carefully. The full design diagram is shown in Figure 4.1. 4.3.1. XML Document Design Designing XML document influence comes by the three artefact versions shown in Figure 4.2. It is easier to show the motivation behind the design by showing all these artefacts rather than trying to explain everything by words. The language used on each artefact can be ignored, as it is the result of discussions between the student and few other Component-based Development students under Mr. Kung. These artefacts show how all the important X-MAN elements will have their markup tags such as <services>, <computationunit>, and <connector>. The problem being discussed here is how the document could support extension for any application-specific information so this information would not be lost just for using the X-MAN cloud infrastructure. Another issue being discussed is the document s structure. By considering the document s parsing needs and readability to human eyes, this has been weighed around to compare its advantages and disadvantages. The third version, while it is more promising, brings some worry on its complexity because the student don t have enough knowledge yet on handling namespace aware XML document. Nevertheless, its still an opportunity to learn should the version 3 is preferable. Despite the design focused on XML, JSON data format is still considered if application specific information extensibility is deemed unnecessary later in the future. From various papers, JSON is a proven winner in performance if compared to XML due to its simplicity [54, 55]. However, as stated in an IBM article by Man and Malaika (2014), XML mechanisms from namespaces, schemas, XSL, and XQuery support makes XML suitable for data exchange or sharing between independent entities, systems, or applications, particularly where the domains is regulated while JSON is suitable for use of data exchange or sharing within an application [56]. Therefore, JSON can be seen as the better choice than XML if performance is the

CHAPTER 4: MOTIVATION, THEORY AND DESIGN 40 only measurement. However, XML s feature rich criteria provide something unique for this project to deliver its goals. Figure 4.2: XML Document initial design idea

CHAPTER 4: MOTIVATION, THEORY AND DESIGN 41 4.3.2. Database Design Initial database design stresses the main part of the X-MAN atomic component covered in this implementation. So far, the main elements covered within X-MAN atomic component in this project are atomic component itself, computation unit, method, service and (invocation) connector. Figure 4.3 illustrates the initial database design for the project. This also serves as the target to be covered in the project implementation later on. Main tables have been covered with the first table atomiccomponent table containing id, name and language for its field. This is so each atomic component will have predefined programming language to be covered for the codes their computation unit and methods. Meanwhile, other table contains the important criteria of their semantics while there is extension for each of these main elements. Table service_appinfo, connector_appinfo and computation_appinfo serves as extension of data for its corresponding parent tables. These tables will hold application specific information for each element that is provided by the client tools so adoption of this cloud infrastructure would not disrupt their way of defining the component in their tools. Figure 4.3: Database Design

CHAPTER 5: METHODOLOGY 42 5. METHODOLOGY The project is split into three main deliverables required as part of the Research Methods and Professional Skills course by the University of Manchester from Initial Report, Progress Report and finally the Final Dissertation. The project is conducted mainly on prototype implementation to prove the concept discussed in Chapter 4, but other artefacts and deliverables importance still weighs the same as the prototype itself. Artefacts here are any work, diagrams, sketching, image or any things produced that are related to the project [57,58]. Regarding to the project, every deliverables produced during the course of this project can be considered as important towards producing an enhanced final dissertation. So, this condition does affect the decisions made for this project to adopt Rational Unified Process as its methodology. 5.1. Rational Unified Process The project will adopt Rational Unified Process (RUP) as its methodology. While some might consider methodology is not important, but it does play an important role for the student to maintain the correct discipline while conducting the project. Therefore, several methodologies has been considered from waterfall to agile but RUP is considered to be the best compatible methodology to the student in particular for this project. Suited with its deliverables focus being not only for working prototype, RUP caters the priority of the deliverables for its working prototype as well as all of its artefacts. The deliverables are varied from a working product to any artefacts as well as the documentation available with it. Figure 5.1 shows the RUP diagram, detailing the work expectation for each phases and iterations associated with many different disciplines.

CHAPTER 5: METHODOLOGY 43 Figure 5.1: Rational Unified Process Diagram vi The project is managed by 4 different stages from: 5.1.1. Knowledge Gathering The first part of Research phase, representing reading on articles, journals, papers and books to obtain information required on the project. The topic covers from component-based development, cloud computing, cloud providers and common practices on the technology required. This stage matches the Inception phase of RUP methodology. 5.1.2. Information Analysis Second part of the Research phase to represent the information study activity from all the readings in the previous stage. This evaluation process will help to proceed on to the next activity where project opportunity will be evaluated and prototype design will be determined. This stage matches the Elaboration phase of RUP methodology. 5.1.3. Development The stage covers most of the development activity of the prototype. It includes implementation, testing and deploying the product activity. This stage matches the Construction phase of RUP methodology. vi Adapted from "IBM Developer Works [Website]", by Portier, B., April 5, 2007, SOA terminology overview, Part 2: Development processes, models and assets.

CHAPTER 5: METHODOLOGY 44 5.1.4. Project Post-Mortem The project post-mortem is closely related to Transition phase of RUP methodology. It includes fixing or maintaining the product, gaining feedbacks and project reflection activity. 5.2. Deliverables There are three deliverables involved that plays an important role during the whole course of this project. As mentioned before, the three deliverables are Initial Report, Progress Report and Final Dissertation. So, following these main deliverables there are other artefacts should be expected to be delivered from project plan Gantt Chart, screenshots or design of the prototype, any Unified Modelling Language (UML) models, feedback results, test cases and if available, any setup script as well as part of the reports. Working software, that is used to show the prototype produced, will be part of the main deliverables as well. In this case, the Eclipse tool built for the X-MAN will be used to demonstrate the working concept of X-MAN repository in the cloud. Working prototype, by the end of Progress Report milestone, will be reported to be a substantial proof for what should be expected by the end of the project. 5.3. Project Timeline The project spans up to 9 months from end of January to September. During this period, the timeline is guided by three deliverables as described previously. Figure 5.2 shows there are three key dates for the project from Initial Report, Progress Report and Final Dissertation datelines and those dates are made as the project milestones for the student to meet. Taking these three milestones into consideration, several activities are laid out carefully in four different phases of Knowledge Gathering, Information Analysis, Development, and Project Post-Mortem as described in Section 4.1. Componentbased development and cloud computing will be the fundamental topic to be studied in Knowledge Gathering phase, and later to be evaluated and reflected for towards the project in Information Analysis phase. Product design activity is the result of the findings obtained in building up a comprehensive prototype.

CHAPTER 5: METHODOLOGY 45 Figure 5.2: Project timeline (Gantt Chart) Development phase will revolve around three development phase from prototyping, versioning and collaboration feature with testing will be conducted continuously for all development activities. Finally Project Post-Mortem will conclude the project, with proper evaluation activity from the supervisor, and if needed, some user acceptance tests with the selected users. 5.4. Out of Scope Issues While X-MAN has been relatively new, there are not many tools adopting it. To go from scratch does seem to be a major out of scope effort to be made. The current implementation available is done as an extension for Generic Modelling Environment (GME) tool. To work with this tool, the student has to consider on how to reverse engineer the tool while it is not part of the scope of the project. There are assistance offered by Dr Kung on the previous developer who knows about the tool in the university, but the source code for X-MAN in GME tool has not been truly made public. There is a worry if student have to consider too deep in manipulating the tool to demonstrate its capabilities in the Cloud. Another tool available for X-MAN is done under Eclipse. However this tool is still under constant development by PhD students under Dr Kung. Constant changes should be expected, and many technologies used are not truly concrete yet. For example, the technology used by the tool can change from PostgreSQL to MySQL quickly should the main development team deem fit. If there is any dependencies

CHAPTER 5: METHODOLOGY 46 found in the tool that are conflicting or bringing any problem, fixing it or reengineering it does goes beyond the scope of the student project. The final approach, which is selected now, is to develop from scratch the client tool to demonstrate the X-MAN support in the cloud. However, the true focus is the cloud support for X-MAN, and not the full functionality of X-MAN in the client tool. So, expectation to implement full functionalities of X-MAN will be beyond the scope of the project while its true focus is to support and demonstrate the idea of collaboration features possible in the cloud for X-MAN.

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 47 6. A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN The project is conducted under the guidance and supervision of Dr Kung Kiu Lau. Even though the project vision can be blurry at times in earlier phases of the project, but Dr Kung has done commendably well in guiding the student through motivation and direction on what to read, useful advises and excellent events organised by him. This has helped the student a lot, as well as giving more exciting experience working under him. This section will be divided into several subsections directed towards the highlights of the project mainly from knowledge gathering, technology selection, current prototype screenshots and concerns identified on the project. 6.1. Technology Selection There are several parts to be considered under technology selection. This will be based on the project design from Figure 4.1. First is to choose the appropriate X- MAN tool, and secondly to choose cloud provider to be used on many different purpose database, virtual machine, and web service hosting. Next is to choose an appropriate web service technology to be used for this cloud infrastructure. While there are a few transactions or communication will be done between each of them, data transfer format will be chosen according to suitability of the project. Time, cost, creativity allowed and learning curve required would be the following criteria affecting the selection of these technologies. Thus it is never the best selection for any situation. Should the implementation to be made in a proper e-commerce environment, some technology selection might differs from what is covered in this section. 6.1.1. X-MAN Client Tool Selection While X-MAN is relatively new, there is not much tool supporting the component model currently. However, there are two tools available for X-MAN in Generic Modelling Environment (GME) tool and Eclipse Modelling Framework (EMF) tool. Alongside with these two tools, there is a third option where the student could develop the tool from scratch, enough just to demonstrate the capabilities of X-MAN

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 48 in the cloud. The tool at this point is not the main topic for the project. It is just a mechanism of demonstrating the concept once the implementation is done. The selection criteria for the student came primarily for its adaptation flexibility for the student. It means that the tool programming language used, current condition, support, learning effort required and source code availability will be compared. Table 6.A: X-MAN Tool Comparison GME tool EMF tool Develop from scratch Programming Based on COM Java Java or.net. Free to language component model decide Current Under a released Under development Needs to develop from condition version scratch Support Requires to contact The development No support. availability the previous team consists from developer who PhD students under knows about the Dr Kung. So support tool is possible Source code Requires to contact Available from the Available for the availability previous developer development team student from scratch. Learning Highest. Support High. Current Normal. Control is effort required and creativity allowed might not be available as the developer might not be dedicating development team does not allow too much changes from their implementation absolute for the student. But functionalities of X- MAN capable to be himself to the tool idea just in order to implemented will be development satisfy the student s limited due to time anymore project needs constraint. The tool chosen for the student in this comparison appears to weigh towards the new tool for its easier integration. While the X-MAN extension in GME tool is done, but the version is not truly released to the public yet. So community support and source code is not really open to the public. In another case for EMF tool, the constraints put upon the student for the creativity allowed to express the idea has put off the move to

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 49 proceed with the project implementation around this tool. Even though the project aims towards supporting all of these tools later on, it only requires these tools as demonstration tools for the client side while the true focus is placed towards the cloud infrastructure. So in this case, the client tool is not particularly important yet at this point and implementing a new tool for demonstrating the concept is enough in order to express the idea where all these tools could seamlessly adopt later on. 6.1.2. Cloud Provider Cloud provider is a mean for business. Though there is many cloud providers available, each of them delivers their own specific aims. One provider might offer cheaper to free pricing plan but with limited service, but another provider offer complete service solution but more expensive. So the first main concern is to find a cloud provider that ticks the criteria for the student to try on. The criteria are price, web application platform, data storage, programming language supported and signing up process. There are several cloud provider identified, from Amazon Web Services (AWS), Google Cloud Platform, Microsoft Azure and Heroku. Table 6.B: Cloud Provider Comparison Amazon Web Google Cloud Microsoft Heroku Services Platform Azure Web App Amazon EC2, Google App Runs on Runs on Linux Hosting Platform runs on Linux or Windows Engine (GAE), runs in Linux Windows or Linux Data Storage SQL Google Cloud SQL (GCSQL) - MySQL SQL Database PostgreSQL and MySQL Programming Java, PHP, Java, Python,.NET, Node.js, Java, Ruby, Language supported Python, Ruby, Windows and PHP and Go Java, ios, Android, Python, Node.js, PHP,.NET Windows, Clojure, Scala, PHP, Python, Play Ruby, Media Cloud Model IaaS PaaS IaaS PaaS

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 50 Amazon Web Google Cloud Microsoft Heroku Services Platform Azure Price Free for 12 Free on GAE Free for 1 Free for no months, price for 1GB quota, month, price time limit but varies on the but no free on varies on the with quota services GCSQL services Sign up Requires credit Free to sign up Requires credit Free to sign up process card card Table 6.B above compares these cloud providers with the criteria mentioned. With this comparison, none of these cloud providers have their own benefits in one area above the other. Amazon and Microsoft Azure provide a complete service as IaaS offering, but it does not always mean the best option. This is because even though Heroku and Google App Engine offer PaaS solution and less option as a whole, it is more comfortable to be adapted for specific targeted service like deploying code for web service hosting. This is justified when other cloud provider does provide wider alternative on operating system selection while Heroku runs only in Linux. But by offering PaaS solution, it means cloud virtual machine offering is not available for Heroku. So a mixture of cloud provider selection might be the best solution here. 6.1.3. Web Service Selection There are two options for web service technology SOAP and REST. However comparison between these two options is less complicated because of two main reasons JSON and four different HTTP 1.1 verbs support from GET, POST, PUT, and DELETE. JSON is said to be the best data transfer format for performance. Using SOAP web service means the communication will always be done using XML. While XML technology will still play an important role in this project, but some transaction is really simple and JSON support in this case simplifies the work. Nevertheless, the real purpose of web service is to be used as an interface for the X- MAN cloud infrastructure. So the best solution between SOAP and REST for the real product is still open for changes. But for current prototype implementation, REST is the best solution. Cloud provider chosen for web service hosting is Heroku. Both Heroku and Google App Engine offer the same solution that can be used by the project. However from

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 51 the student learning curve perspective, deploying web service code to Heroku is easier compared to Google App Engine because of past experience using Heroku. Amazon Web Service and Microsoft Azure in this case are out of option because student will need to setup the environment from scratch. Therefore Heroku is the chosen cloud provider for REST web service hosting. 6.1.4. Data Transfer Format Even though REST web service is chosen due to its support on JSON, XML technology is still the main data transfer format selected for this project. As described from Section 4.3.1 regarding XML document design, it is because of XML extensibility criteria. The idea for the project is so any tool can adopt this cloud environment. So with namespace feature in XML, the document is extensible for any tools and the web service may accept this document without any problem. This will be described more in implementation with screenshots later on. However for full functionality of X-MAN REST web service, both will be used accordingly. JSON specialises in handling small data transportation such as sending a list of components, returning the Boolean value for availability of a component, or returning the component id for a given component name while XML will handle the core component metadata sharing. 6.1.5. Cloud Virtual Machine (Cloud VM) Cloud virtual machine is used in this project to serve as execution machine for specific language component. From project design in Figure 4.1, two virtual machines aimed for two different programming languages of Java and C# is needed. In this case, Amazon Web Service is the chosen cloud provider because of its pricing plan offered for 12 months free subscription on selected service. Compared to Microsoft Azure 1 month free subscription, Amazon Web Service is the obvious choice as neither Heroku nor Google App Engine offers a cloud virtual machine as their service. 6.1.6. Cloud VM Java Component Execution Environment For Java Cloud VM, dedicated application is designed and implemented to handle component execution for Java language code atomic component. The implementation handles only X-MAN atomic component so far, with no parameter services for idea demonstration purpose. Bear in mind, the main feature is still

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 52 depositing and retrieving component in the cloud with this one as an optional feature to be implemented as mentioned in the requirement table from Table 4.A. To demonstrate the idea, this machine is dedicated to run Java Virtual Machine with the application handling component execution. Building this application, specific libraries dedicated to run arbitrary Java codes in runtime has been used. The library used is BeanShell that comes as free, small and embeddable interpreter that executes code written in Java [59]. To use BeanShell library for code with no parameter handling, it is straightforward as shown on Figure 6.1. Figure 6.1: BeanShell Interpreter usage code 6.1.7. Cloud VM C# Component Execution Environment This machine is similar with Java Cloud VM, while for dedicated C# code handling,.net Framework is installed for the application running the component with C# code. There is no reliable library yet to be used, but to handle code with no parameters, CSharpCodeProvider class is used to handle arbitrary code of C# or VB. The approach for executing C# code is more hands on, with all the codes are written from scratch to handle C# atomic component code execution without parameters. Figure 6.2: CSharpCodeProvider custom class usage. 6.1.8. X-MAN Repository (DBaaS Selection) Repository for X-MAN is designed with a DBaaS based on PostgreSQL selected from Heroku as the cloud provider. The reason is similar for its free pricing offering compared to other alternative, and using it has been fairly easy with many

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 53 documentation available from the official website teaching how to use the service seamlessly. 6.2. Client Tool Prototype There is two main implementations in this project the prototype of a working X- MAN tool, and X-MAN cloud infrastructure. The prototype of a working X-MAN tool is implemented only for simulation purposes. Thus, it would not have a full functionality of dedicated X-MAN tool like the two current implementations explained in Section 3.8.1 and 3.8.2 above as it is never the aim of the project to fulfil this. However, it aims only parts of the main area in X-MAN tool, which is the modelling part, for the cloud environment to simulate its capabilities in supporting X-MAN in the cloud. There is three prototype tools implemented to show the idea of this project. The first two prototype is done using C# language in.net technology for desktop and then ported out to web to have two tools in different environment. The third prototype is done using Java language in Android technology to have another possible X-MAN tool environment in mobile. The first two prototype will be covered as singular in this report since both doing the same thing with the same interface with only difference is its environment (desktop and web). 6.2.1. Desktop and Web Prototype The desktop and web prototype is developed with X-MAN visual modelling capability. Due to the focus not being on the making comprehensive X-MAN client tool, it only handles atomic component so far, so it is enough to demonstrate the project idea using this implementation. The feature includes designing the atomic component model, deposit it on the cloud, save it locally, retrieve the atomic component from the cloud, load the modelling visualisation again from the retrieved XML document and execute the services available in the atomic component from the cloud. Another focus on the tool being left out is this prototype does not compile or generate any Java or C# code of the designed component because the aim of the project is component execution from the cloud. There are two current implementations that are able to do this as described in Section 3.8 with GME tool as the better option for full functional X-MAN to be played with. Figure 6.3 and Figure 6.4 show both prototype for desktop and web. Since it is developed together, both shares the same interface and functionalities through porting. The aim here is to show it runs on different environment while sharing the same component. Both will

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 54 be treated as the same prototype in this report while using only the web interface screenshots to show its working process. Figure 6.3: X-MAN desktop prototype for demonstration purpose Figure 6.4: X-MAN web prototype for demonstration purpose 6.2.2. Mobile Prototype Mobile prototype is done on Android using Java. It delivers less functionality than both prototypes earlier where it doesn t have the modelling part. Therefore it only shows part of the functionality like retrieve the component XML document and

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 55 executing it while missing features like loading the X-MAN component visualisation using the retrieved XML document. However its purpose is to show part of the idea where components could be designed, stored, shared and executed totally on the cloud. Since X-MAN is largely modelling based, it seems possible to use X-MAN as a total cloud framework for development. Furthermore even though Android used Java as its development language, they are not using the standard Java Virtual Machine (JVM). They have Dalvik Virtual Machine (Dalvik VM), which is even though based on JVM, it handles its bytecodes differently than the standard JVM. Therefore, the Java codes compiled from standard Java compiler will not be executable on Dalvik VM unless it is pre-compiled by the Android SDK compiler [ 60 ]. Therefore, this project idea could open up another dimension of doing development in mobile with control and processing are executed from the cloud. This is similar with some big name cloud application approach like Dropbox, Google Docs, or even most online game for mobile. What is seen on the mobile is just a visualisation while data and computation are loaded totally by their own cloud system. Figure 6.5 shows the preview of what mobile prototype look like. Figure 6.5: X-MAN mobile prototype for demonstration purpose

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 56 6.3. X-MAN Cloud Architecture There is three layers setup in the cloud architecture web service, cloud virtual machine and cloud database (DBaaS). Between all these layers, XML document will be used as communication mechanism with the exception on the database. This design is illustrated in Figure 4.1. Web service will handle the component orchestration from translation of the XML document, storing or retrieving a component from the cloud database, and executing a document from either one of the distributed cloud computing s suitable. Using web service as mediator, it ensures the correct data is sent to every layer and avoiding broken document to be passed around. 6.3.1. Communication Mechanism X-MAN XML Document The main element of this implementation is the XML document for X-MAN component. This XML document is produced from the important metadata of an X- MAN component as its backbone structure with the vision of sharing it between client tools and platform. This structure is then constructed with the idea where it is extensible so multiple tools can share the same document with the help of namespaces. This decision is based on the combination of the artefact version 1 and version 3 from Figure 4.2. Figure 6.6 below shows one example of an X-MAN atomic component in XML form. This XML is used within the cloud architecture to be translated by the web service or shared with the cloud virtual machine and the client tool. For an atomic component XML document, the main element (markup tags) of services, methods, computation unit and (invocation) connector plays the role of backbone structure for an atomic document. This document though, is open to be extended by elements containing specific information from client tool such as id, coordination for modelling visualisation in the tool and so on. These extensible elements might not be part of the main X-MAN component metadata, but still useful to be provided for each client tools as mechanism to ensure important application specific information will retain as it is.

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 57 Figure 6.6: X-MAN XML Document (S2) Figure 6.6 shows few example of this elements such as <mvvm:info id= 1 /> or <mvvm:coord top="213.5" left="263.5"/>. These elements with mvvm namespace are the details produced from the web prototype. So, if the tool retrieves this XML document, the web prototype still knows its last visualisation location. This can be applied to many different client tools so each tools may have their own <info> or <coord> element with their own namespace to store their specific visualisation information. So long as they follow the rules of putting any of their namespace specific element inside <app-info> markup tags. Element <app-info> is designed so any namespace element can be put there thus making this document extendable for any application specific information to be stored. If this namespace extension concept is not applied, it might not be a problem from every new retrieval

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 58 of a component each client tools orchestrates the visualisation coordination by themselves. This will ensure the cloud infrastructure doesn t have to carry or store this extra information. However it is still prepared in case if there is really application specific information that will benefit from this XML extensible attribute later on. The next element <name> is for the atomic component name and this must be unique for the cloud infrastructure. This is because for sharing purpose, it is more appropriate to think the whole repository as one X-MAN environment. Therefore, duplicate component name would replace the old component thus preserving the unique name for the component. However, this is still open to change because in real e-commerce system, there is a lot more criteria to distinguish the component. The owner, language, access key, and region might influence the uniqueness of a component. Therefore, this is still a prototype way for preserving uniqueness of an atomic component in this cloud infrastructure. Then, <method> element is intended to store the method codes written from the client tool as long as it follows the syntax, rules and limitation of the targeted language. This implementation requires the client tool ability for syntax checking to make sure the code provided is correct, because syntax checking in cloud side might be overkill. It can be implemented though, to embrace the security criteria of the cloud where validation and verification should be done on every layer of cloud infrastructure to ensure its security and reliability is ensured. Finally, <language> element determines the language used in this component with id 1 for Java and 2 for C#. This <language> element also determines the language used and execution environment for the whole atomic component which means computation unit and methods under the same atomic component may not change their chosen programming language to be written or executed. 6.3.2. Communication Validation X-MAN XML Schema To ensure the communication does not get lost in transactions exchange, XML Schema for the X-MAN XML Document has been used to validate each document coming in to ensure the documents provided is not broken. The XML Schema generated in APPENDIX B is the result of the design decision for artefact version 1 and version 3 from Figure 4.2. All of the defined elements are designed to hold the structure of the X-MAN s atomic component XML document just as shown on

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 59 Figure 6.6. Starting with <atomic> as the root element, follows by <computationunit>, <connector> and <service> as its direct child element. Line 62-68 from the document in Figure 0.1 describes the element <app-info> are supposed to accept any elements inside it. This element lives inside many other elements from <computation-unit>, <connector>, <services> and so on. This is to ensure that if these parent elements need to be extended by the client tools using it, they are free to put any of their application specific information inside <app-info> element. Other elements such as <method>, <source> and <target> is a necessary markup tags to be provided to their corresponding parent elements. Using XML Schema has reduced the amount for mistranslation of document from both web service and client sides while increasing consistency in the documents provided greatly. 6.3.3. Cloud Mediator Web Service Web service is placed in the center of cloud infrastructure to be the handler of every transaction made. Its role varies from handling deposit and retrieving request, to handling component execution request based on the component language. This situation is where XML document created earlier will be translated to PostgreSQL database data in depositing component process. Translation of database data to X- MAN XML document will get done for another type of operation such as retrieving a component or executing a component. Therefore, a list of services is provided for invocation by the client tool. Despite its reliance on XML, JSON will be used on some light purpose services such as requesting a list of component or returning confirmation message for invoking POST method service to deposit a component. Table 6.C: X-MAN Web Services X-MAN Web Services ( xman-ws.herokuapp.com/services ) ID Links HTTP Method Description S1 /atomic GET Return a list of all atomic components stored in JSON format S2 /atomic/get/{id} GET Return an XML document of the specified atomic component. S3 /atomic/getmethods/{id} GET Return a list of methods (services) for

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 60 the specified component in JSON format. S4 /atomic/store POST Accepts an XML document, then extracts atomic component information to be stored into the repository S5 /atomic/run/{id}/{method} GET Invokes the method from an atomic component specified and return its result. * {id} can be integer for the component id or string for the component name. * {method} in string, specifying the name of the method Table 6.C shows the list of services provided by the X-MAN web service to handle many different transaction purposes. Service id S1 will return a list of atomic components while service id S3 will return a list of method (services) within the specified atomic component in JSON format. Figure 6.7 shows the list of atomic components returned in JSON format when invoked from a web browser. Figure 6.8 shows a list of services from component University returned. From the screenshot, it is requested by the component id (8). These services also supports request by the component name. The reason for JSON usage here is because these lists don t require any extensible markup characteristics from XML. Without this characteristic, JSON is the better option since it offers better performance compared to XML [61]. Furthermore, the prototype implemented is not evaluated by any non-functional values yet and for this reason XML provides better option to fulfil functional requirement of the project.

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 61 Figure 6.7: X-MAN Web Service - Getting list of atomic component (S1) Figure 6.8: X-MAN Web Service - Getting list of services in a specified atomic component (S3) This is similar to service id S4 where it will accept XML document as input and producing JSON for the output since the output is just a simple message. While accepting the XML document, it will translate elements within the document and

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 62 extract needed data to be stored into the repository. Then it returns the message whether the deposit process is successful or a failure. Service id S2 is a simple component retrieval process where it will extract the specified component data from the repository, translate it into X-MAN XML document, and then returns it to the client as XML document. The example of this XML document is as shown on the Figure 6.6. This document should be reusable with any other client with their own parsing process to extract their needed data from the document. Finally, service id S5 invokes the specified method (service) in a specified atomic component. This depends on the code inside the component. For this project, only Java and C# code is supported. Using University component as example, service CBD is invoked to show its execution from the cloud and returning the result. The code in method CBD can be read from the XML document in Figure 6.6. The result of the execution is shown in Figure 6.9 below. Figure 6.9: X-MAN atomic component service execution (S5) 6.3.4. Component Execution Environment Cloud Virtual Machine Cloud Virtual Machine is used here as part of larger distributed cloud virtual machines intended to handle component execution. These machines are set up depending on the targeted component language. There are two machines right now to handle two different languages requiring two different environments. Java requires Java Virtual Machine (JVM) while C# requires.net framework. These machines are handled by their own web service interface so each of them will have a similar interface for easier access and invocation. There is not much screenshots are able to be shown for this part besides discussing its set up because most of the processes are

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 63 handled by its interface on the web service. Figure 6.10 shows two running instances of Java and.net cloud virtual machine. For current implementation, it will accept an atomic component XML document, which then it will parse and find the targeted method to be executed. It does not have error handling for broken codes as for the current expectation, each codes sent for deposit are error free. This is enough for current expectation but beyond this, proper syntax checker and compiler will be required to ensure the X-MAN cloud repository is robust. Figure 6.10: Amazon AWS Cloud VM Java and.net 6.3.5. X-MAN Repository Cloud Database (DBaaS) Repository for X-MAN in the cloud is basically the SQL database on the cloud. Covering atomic component so far, the table stands from atomic component table to connector, data element, computation unit, methods, and services table. Using pgadmin III tool to access the cloud database, Figure 6.11 shows all the tables covered so far in this X-MAN repository. These tables are filled from translation of the atomic component XML data. Figure 6.12 shows the atomiccomponentt table, filled with component id and name with its language used. Language id in this case refers back to 1 as Java and 2 for C#. Next, Figure 6.13 shows the extracted method name and code from the X-MAN atomic component XML document and stored into the repository. This makes the codes or any other data extracted can be retrieved in a more specific way. For example in component execution process of a specific

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 64 method, the whole component metadata may not be necessary to be gathered as taking the targeted method code directly to be executed is more efficient. Additionally, each table with appinfo suffix contains application specific information, with its associated namespaces. So if these informations are to be translated back, the application specific information should be associated with its own namespaces. Figure 6.14 and Figure 6.15 shows one example of the appinfo tables with its parent table. Table serviceappinfo is the application specific information for table service. In Figure 6.15, the data is stored in text, with common convention for web service to parse. The current convention format is as shown in Equation 1. It meant to hold one element data for each row in the repository. For example, the markup tags <mvvm:info id= 1 >one</mvvm:info> on <service> element will produce a row of serviceappinfo data with this text: info id= 1 {one}. element attribute {text} Equation 1: Syntax Convention for Storing Application Specific Information This is helpful in both way for storing and retrieving the data. On retrieving, these serviceappinfo data will be combined into its parent table service, with the dedicated element tag <app-info> for the place to dump any application specific information to the document. This concept is similar for all other table with appinfo as its suffix. Finally, other tables are straightforward in relation to its name. Tables like connector contains the connector id and its own type with source and target information to be connected, methods table contains the method name and its associated code and finally computationunit, dataelement, and services table contains their own associated information.

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 65 Figure 6.11: X-MAN Repostiory on the cloud (DBaaS) Figure 6.12: X-MAN Repository Data. Table: atomiccomponentt

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 66 Figure 6.13: X-MAN Repository Data. Table: method Figure 6.14: X-MAN Repository Data. Table: service

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 67 Figure 6.15: X-MAN Repository Data. Table: serviceappinfo 6.4. Workflow This section will try to give the clearest explanation on the flow of the proposed idea. There are three workflows for this project in this stage with its atomic component the only support it could provide so far. The three workflows are deposit, retrieve and execute the component. These workflows should be the very basic process for any other possible feature later on. It describes the work process, which combines both sides of the cloud infrastructure and client tools. A client tool in this case is a prototype tool developed by the student. It is more desirable if the client tools adoption from the real implementation like GME tool or Eclipse is used to demonstrate this concept. But with complications around, this prototype is suffice for now to show the concept in action. 6.4.1. Flowchart There are three flowcharts covering the implementation workflow process from deposit, retrieve and executing a component. While these flowcharts are expandable in the future should a more concrete implementation arises, it serves as the basic workflow for each future work to be implemented later on.

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 68 Figure 6.16: Deposit Flowchart In Figure 6.16, the grey colour shapes represent the client tool activities while white colour shapes represent the web service activities. The diagram explains the beginning of deposit process actually starts from client tools. Starting with modelling or building the X-MAN component, it is then to be converted to XML before sending it to the web service interface. In web service layer, every XML document is then to be validated against the XML schema, which will proceed to parse the XML should it passed the validation. If it fails, it is then to be stopped on this activity, requiring the client tool to fix the model built to produce a valid XML document. After parsing the XML, the name of the component is checked from the repository whether it is already available or the name is free to use. If it is free, new ID is generated or else, it will take the existing ID so it would be use when the storing query is prepared and executed. Depending on the result, an error message or success message would be produced by the end of this process.

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 69 Figure 6.17: Retrieve Flowchart The next diagram in Figure 6.17 shows the retrieve workflow. This workflow is again start from client tool by preparing component name or id, and then the client tool to the web service invokes request for component retrieval. In the web service, the component is checked from repository whether it is available, and should it fail, the client tool is then asked to request again with the correct component id or name. However if it is available, the data will be collected from the repository to be transformed into X-MAN component s XML document. Then the XML document is sent to the client tool for it to be parsed back. Using the data obtained from the document, the model visualisation of the component should be done from the client tool to mark it as the end activity.

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 70 Figure 6.18: Component Execution Flowchart The final workflow in the project is the execution of a component. Figure 6.18 illustrates this workflow with an extra entity involved in the whole component execution workflow process. The black colour shapes represent execution environment for the component. Similar in this workflow, the start activity begins with client tools preparing component name or id and the targeted method name. Then, the client tool invokes execution request on the web service where it will check whether the specified component and method is valid. If it is not valid, the client tools are then asked to make a new request with the correct reference. If it is valid, data collection happens on the repository to be transformed into X-MAN XML document. This document is sent to execution environment, which is first to be parsed before executing the component while producing the output. This output is sent back by the web service to mark the end of the component execution activities.

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 71 6.4.2. Deposit Deposit process starts from modelling work from the client tools. This is where client tools are needed to provide metadata of X-MAN. Figure 6.19 shows the activity where one computation unit is placed and one method with the name getdate() is put inside the computation unit. Figure 6.19: Client Tools Atomic Component Modelling Phase The method code inside this method will return today s date by using Java s Calendar and DateFormat library. From the code, the output would be today is <date>. Meanwhile, Java has been selected as the language chosen from Figure 6.19 to reflect the language supported for this atomic component.

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 72 Figure 6.20: Client Tools Atomic Component Deposit Phase Figure 6.21: Client Tools Atomic Component Deposit Successful Figure 6.20 shows the simplest atomic component with one method and one service to expose this method with a connector connecting the service to the computation unit. Then deposit button is clicked, prompting a text box to define the name of the

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 73 atomic component. In this case, the atomic component is given a name DateTime. A successful deposit process message is displayed in Figure 6.21. The deposit transaction is handled to ensure there is only one atomic component with the name DateTime. Therefore, since this is the first time the deposit request is made with an atomic component named DateTime, a new id is generated to store it as a fresh data. Else, it will take the old component id with the name DateTime and run the update query using the component id obtained. The initial state before depositing the new atomic component can be seen from Figure 6.12 above and the new data inserted can be seen from Figure 6.22 below. Figure 6.22: X-MAN Repository atomiccomponentt table with new data 6.4.3. Retrieve Following the previous section, a new atomic component DateTime gets deposited successfully. In this section, the next workflow for retrieve will be shown using the client web and mobile prototype tools.

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 74 Figure 6.23: Retrieve an atomic component from client web prototype tool Figure 6.24: Atomic component model visualisation loaded from Component Retrieval process Figure 6.23 shows the initial process of getting a list of component from empty model. The popup box shows a list of all available atomic components to be loaded which is invoked from service id S1 in Table 6.C. Upon clicking on particular component, list of methods is shown on the second list box below by invoking

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 75 service id S3 in the same table. When Load button is clicked, an XML document is obtained from the web service, then XML parsing happens in client prototype tool to obtain its related data, producing the correct model visualisation as shown in Figure 6.24. The sample of the XML document produced by the web service can be seen from Figure 6.25 below. It contains all the related data from the component name, language id, method name and codes to coordination of those elements in the client prototype tool. Figure 6.25: XML document produced for "DateTime" atomic component

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 76 Figure 6.26: X-MAN Mobile Prototype initial view Figure 6.27: Component Retrieval from X-MAN Mobile Prototype Meanwhile, Figure 6.26 shows the initial view of the X-MAN Mobile prototype, listing all the atomic components. The first picture on Figure 6.27 shows the options to retrieve the selected component DateTime XML document. By selecting

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 77 Details button, it invokes the web service to produce DateTime atomic component s XML document to be retrieved by the mobile client. Second picture of Figure 6.27 shows the resulted document in mobile view, similar what would be produced on web version. In theory, since X-MAN is largely modelling based, development of X-MAN component in mobile can be deemed possible. It does not have to deliver full functionality of desktop client tool like Eclipse or GME. These tools could compile and generate the codes behind the modelling so it could be executed locally. However with this concept, this feature could be omitted and adopting cloud application model like Dropbox to let processes handling controlled from the cloud, while the client only to visualise the model. 6.4.4. Execute Atomic Component Executing an atomic component comes with a set of rules. However, since it does not have any parameters handling for the method, the list is short for now. The precondition for executing atomic component is the invoker should ready with the correct component name or id and the targeted method name. Future implementation for parameter handling and composite component execution should include another XML document for parameter handling to be carried around on each component s execution with parameters. The new XML document should include carrying the initial data declared for each instance in a composite component. Figure 6.23 shows list of atomic components obtained in X-MAN web prototype and by clicking one specific atomic component, the list of its method is listed on the method list box below it. In this case DateTime atomic component is chosen resulting with getdate method to be listed in the method list box. By selecting getdate method and clicking on the Execute button, a new pop up box appears with the output produced by the executed method as shown on Figure 6.28 below. This is reflected by the code inserted in the modelling phase earlier as shown in Figure 6.19 where the code uses Java Calendar and DateFormat library to show the date of the method is executed. From the same initial state in X-MAN mobile prototype as shown in Figure 6.26, the selection of specific atomic component would produce the list of its method beside it. So selecting DateTime atomic component would obtain getdate as the only method in the method list as illustrated in the first picture of Figure 6.29. Selecting

CHAPTER 6: A CLOUD INFRASTRUCTURE FOR SUPPORTING X-MAN 78 getdate method would invoke the request for the web service to execute the method and returning the output as shown in the second picture of Figure 6.29. Figure 6.28: Atomic Component Execution from X-MAN Web Prototype Figure 6.29: Component execution from X-MAN Mobile Prototype

CHAPTER 7: TESTING AND EVALUATION 79 7. TESTING AND EVALUATION This chapter will cover what has been done to test and evaluate the implementation. For prototype, the tests and evaluation conducted is more on internal evaluation. This is because this implementation is yet to reach full functionality that it will be ready for actual use. There is still lots more to be implemented to actually making it ready for actual usage. Criteria like security, performance, scalability and reliability is crucial to the cloud testing. However, this implementation is yet to touch on those non-functional criteria except for functional requirement. For example in security, it is always better to validates the XML produced and received everywhere from the client tools, to the web service layer. Cloud testing main coverage includes performance testing, stress testing, capacity testing, fail-over testing, load testing and application security testing [62, 63, 64, 65]. These tests indicate the product testing which are ready for actual usage. Therefore for this prototype, what is covered is mostly internal testing and leaning more on development testing to ensure the functional requirement covered is tested and evaluated well. 7.1. Unit Testing The very basic testing covered in this implementation, unit testing serve most of the code written to ensure tests on every service is covered. Until now, there are 153 unit tests covering around 2500 line of codes. It is intended to be the most basic test used to cover any mistakes or flaws early on. Top 10 most important unit tests are selected and listed in the Table 4.A below: Table 7.A: Unit Testing List Name testfakexmldoc() testdepositcomp() testretrievecomp() Comment This method generates fake XML document, to test service acceptance on XML document This method test full deposit component process, from translation of XML document to storing it in repository This method test full retrieve component process, from extracting data from repository to translation of XML

CHAPTER 7: TESTING AND EVALUATION 80 Name testexecutejavacode() Comment This method test arbitrary Java code execution testexecutejavacomp() This method test arbitrary Java component execution. From translation of XML to code execution testexecutecscode() testexecutecscomp() testgetlistcomp() testgetlistmethod() This method test arbitrary C# code execution This method test arbitrary C# component execution. From translation of XML to code execution This method test getting the list of components and the output format This method test getting the list of component methods and the output format. Including XML translation and data extraction testfulljavacycle() This method test getting the full cycle of X-MAN cloud testfullcscycle() service. From getting the list of component, depositing new fake component, retrieving it, getting list of methods and finally executing the component method From these tests, a project design mistake has been figured out which influenced the introduction of web services. In the initial implementation, the two-execution environment machine is accessed directly while the client tools handle component depositing and retrieving directly. Through these tests, a complication has been discovered and interface mechanism is thought to be necessary. Unified interface makes these processes to be handled in one place and maintenance effort of the whole cloud infrastructure will be optimised greatly. Therefore, web services has been chosen to be a great interface mechanism since it is touted to be language independent where any system written in any language could invoke it without compatibility problem. New cloud VM is considered too to be the unified interface processing, but web services in this case is more appropriate and more efficient. 7.2. Integration Testing Integration testing evaluates the execution of two or more features. Several test cases for integration testing has been introduced. It aims to test whether two or more different functionalities executed in sequence should work as expected. Various test

CHAPTER 7: TESTING AND EVALUATION 81 cases for integration testing is included in APPENDIX A. It requires behavioural evaluation as some tests like Table 0.A requires manual comparison of the two XML document. Comparison using automation test might not be possible because these two documents might be identical but not exactly the same. Comparison using automation tests might produce misleading test result. So, integration testing is done using partly automated testing with comparison using manual evaluation. Table 7.B: Integration Test Result Integration Test Result ID Activity Result Reason/Comment TCI01 Test deposit and OK It is similar, but not exactly the same. retrieval of component The only difference is only on spacing and how empty elements tag is closed Action: None. It is still acceptable because the difference does not affect its semantic TCI02 Test deposit and execute Action: None component OK Works successfully TCI03 Test deposit and execute FAIL Code execution does not recognise component using library reference used Action: Re-testing is done with the fixed reference by including its parent folder. For example, the code earlier will look like below: String hello = "Hello "; java.text.dateformat dateformat = null; java.util.calendar cal = java.util.calendar.getinstance(); dateformat = new java.text.simpledateformat("yyyy/mm/dd"); return hello + "today is " + dateformat.format(cal.gettime()); Re-testing Result: Success 7.3. Regression Testing Regression testing runs all the tests above frequently. It is run after every changes deployed to the Heroku repository. Besides that, several students from Component- Based Development class do participate unofficially from time to time conducting

CHAPTER 7: TESTING AND EVALUATION 82 several of the above tests. It helps in getting external opinion on the project idea, particularly regarding X-MAN atomic component XML document construction. Another activity that closely resembles regression testing is XML document validation. As described from Section 6.3.2, XML Schema is used to validate each time XML document is coming in or going out. For now, the XML schema validation declaration in the XML document is not been used yet. But, it is validated by the web service using the Java API for XML Processing (JAXP) library.

CHAPTER 8: CONCLUSIONS AND FUTURE WORK 83 8. CONCLUSIONS AND FUTURE WORK This report explains the progress and effort taken to develop a prototype for demonstrating an encapsulated component-based development (CBD) repository in the cloud. So far, the idea of repository in the cloud has been able to be demonstrated. Components can be deposited in the cloud, and it can be retrieved back successfully. Additional features such as component execution, which in the beginning is just a simple theory, has been successfully materialised to provide another dimension of capability to the encapsulated component model. 8.1. Summary After much effort has been put in delivering the project goals in such a short amount of time, there are many valuable lessons learnt just from indulging in this project. This project like any other project conducted in IT world, does not run from the fact it has its own problem to be faced. Human factors, technologies limitations, cost and many other factors paint many different colours to this project s overall experience. It is such a shame that this project implementation stops short by achieving the atomic component execution only. Though the difficulties is never mentioned anywhere in the report earlier, these small amount of features are implemented in just about a month, after phasing out of the initial progress reported from the progress report in May. However, many valuable lessons gained under the guidance of Dr. Kung Kiu Lau where X-MAN, in particular, could provide abundance of potential not just for component-based development community, but the whole information technology community. Cross language component s composition in X-MAN by now is still an unproven theory. But, given the basic concept proven in this project, it is not far from possible since data channel designed in X-MAN totally separates data and processes in the composition. The initial goal for component sharing in this case does not limit the X- MAN components only to be deposited and retrieved. It is now capable to share codes, processes and even making it a total cloud system. However, there is still much work left to do if this motivation is to be materialised. There are a lot of things to be introduced, fixed and tested.

CHAPTER 8: CONCLUSIONS AND FUTURE WORK 84 8.2. Contributions Made Along this project, the contributions made includes: - Provide the basic design or underlying infrastructure of supporting an encapsulated component model (X-MAN) in the cloud. - Provide the basic design or underlying structure for flexible data sharing with XML including its schema and repository design. - The prototype built to demonstrate all of the concepts and ideas claimed for this project. - Provides a new dimension of capability for cross language development in X- MAN. - Provides a new motivation for supporting development in mobile environment. 8.3. Further Work Going by the nature of this project where the student is left hanging with many unimplemented ideas, there is a lot of future work to be discussed. Many of these ideas were purely motivated assumptions, but it is interesting if it were to be proven in upcoming future works. 8.3.1. Introducing New Document Even though the project implements the concept up until atomic component only, introducing the composite component cannot be considered original but necessary. However, to support composite components in the cloud, new X-MAN XML document will need to be introduced for data or parameters. Using data channels as the basic concept, this X-MAN data document will be passed around along the data channels for it to be evolved by the processes in each atomic component s services. This can be seen as similar with X-MAN in GME tool XML document. Even though the document is meant for test cases, a nearly similar structure could work well with this idea so X-MAN will have a completely new dimension for component sharing in the cloud. 8.3.2. Introducing New Retrieve Concept Similar with composite components, introducing new execution environment at this stage is expected as long as it does not go too ambitious without first making sure the current execution environment is good. However, new concept for component retrieval can be reduced where despite being able to retrieve a component, now it can

CHAPTER 8: CONCLUSIONS AND FUTURE WORK 85 retrieve a component with reference. For example, current implementations retrieve a component by returning the instance of the retrieved component. It means the component binaries are generated and retrieved for the retriever to execute this instance as part of their system. However, retrieve with reference will provide just a reference to the component in the cloud rather than an instance of it. This means, components composition and execution will be redirecting the data flows to the cloud environment by transferring data through the data channels. This opens up a dimension where composition of components from different languages is possible. In GME tools visualisation, grey boxes with its selected service represent these instances. However, for this feature of retrieving with reference, it might have the initial R on top of the box earlier. For example, given a composite components declared as Java, the Java atomic component retrieval would return an instance of these Java atomic components to be composed. However, retrieving an atomic component with different language than Java would return them with a reference for it. During this component composition, the referenced component would mean composing it to the cloud s component execution feature. Executing it would mean that for this composite component to work or composed in a Java system, it would require Internet access so the atomic component with different language earlier can be executed directly from the cloud. 8.3.3. Further Study and Research This should be straightforward. Nevertheless, to be specific, many elements implemented do need further study and improvements. Repository data needs to be studied more on its true metadata structure. The current repository design just aims to deliver the current prototype demonstration. XML design too needs to be discussed more with experts on how to produce a better document for X-MAN. This could be resulted with X-MAN having its own dedicated markup language. Composite component composition orchestration too is one big stumble block for this implementation as it can be considered as out of topic focus. This is because this project should focus on extending X-MAN capability by reusing the current capability implemented. However, it is understandable that X-MAN is still new where its metadata and structure are still growing.

REFERENCES 86 REFERENCES [1] Gómez, J., Pastor, O., Insfrán, E., Pelechano, V.: From Object-Oriented Conceptual Modeling to Component-Based Development. [2] Lau, K.-K.: Component-based and Service-oriented Software Development in Cloud Computing. Retrieved (on February 6, 2014) from http://studentnet.cs.manchester.ac.uk/pgt/2013/comp60990/project/projectb ookdetails.php?projectid=20919 [3] Eddon, G., Eddon, H.: Inside COM+ Base Services, (Washington: Microsoft Press, 1999). Retrieved (on February 10, 2014) from http://thrysoee.dk/insidecom+/ch01b.htm [4] Gruntz, D., Murer, S.: Component Software Beyond Object-Oriented Programming Second Edition, (London: Pearson Education Limited, 2002). [5] Lau, K.-K., Ling, L. & Elizondo, P.V.: Towards Composing Software Components in Both Design and Deployment Phases, pp. 1-3. Retrieved (on February 10, 2014) from http://www.cs.man.ac.uk/~kung-kiu/pub/cbse07c.pdf [6] Lau, K.-K., Wang, Z.: A Taxonomy of Software Component Models, (2005), p. 4. Retrieved (on May 1, 2014) from http://www.cs.man.ac.uk/~kungkiu/pub/ecbse05.pdf [7] Lau, K.-K., Wang, Z.: A Taxonomy of Software Component Models, (Manchester: University of Manchester, 2005). Retrieved (on August 14, 2014) from http://www.cs.man.ac.uk/~kung-kiu/pub/ecbse05.pdf [8] Lau, K.-K.: Lecture 3: Current Software Component Models [PowerPoint slides], (Manchester: University of Manchester, 2012), p. 4. Retrieved from https://moodle.cs.man.ac.uk/mod/resource/view.php?id=9619 [9] Wallace, B.: A hole for every component, and every component in its hole, (May 19, 2010). Retrieved (on May 1, 2014) from http://www.existentialprogramming.com/2010/05/hole-for-every-component-andevery.html [10] Bruneton, E., Coupaye, T., Leclercq, M., Quéma, V., Stefani, J.-B.: The Fractal component model and its support in Java, (May 12, 2006). Retrieved (on May 1, 2014) from http://www.cs.colostate.edu/saxs/se/fractalcomponent.pdf [11] Coupaye, T., Stefani, J.-B.: Fractal Component-Based Software Engineering, (2006). Retrieved (on May 1, 2014) from http://www.istselfman.org/wiki/images/c/cc/fractalcbse.pdf

REFERENCES 87 [12] Lau, K.-K., Wang, Z.: A Taxonomy of Software Component Models, (2005), p. 6. Retrieved (on May 1, 2014) from http://www.cs.man.ac.uk/~kungkiu/pub/ecbse05.pdf [13] Johnson, R., Hoeller, J.: Expert One on One J2EE Development without EJB (Indiana: Wiley Publishing Inc, 2004). Retrieved (on April 1, 2014) from http://iclass.iuea.ac.ug/intranet/e- books/information%20technology/java/(java%20- %20Wrox)%20Expert%20One-on- One_%20J2EE%20Development%20without%20EJB.pdf [14] Johnson, M.: A beginner s guide to Enterprise Java Beans, (Oct 1, 1998). Retrieved (on May 2, 2014) from http://www.javaworld.com/article/2076777/learnjava/a-beginner-s-guide-to-enterprise-javabeans.html [15] Lau, K.-K., Wang, Z.: A Taxonomy of Software Component Models, (2005), p. 5. Retrieved (on May 1, 2014) from http://www.cs.man.ac.uk/~kungkiu/pub/ecbse05.pdf [16] Lau, K.-K.: Lecture 8: Software Component Models based on Encapsulated Components (Part1) [PowerPoint slide], (Manchester: University of Manchester, 2012). [17] Lau, K.-K., Taweel, F. M.: Data Encapsulation in Component-based Software Systems, (Manchester: University of Manchester, September, 2006). Retrieved (on March 20, 2014) from http://www.cs.man.ac.uk/~kung-kiu/pub/cspp39.pdf [18] Yau, S.S. & An, H.G.: Software Engineering Meets Services and Cloud Computing, (January 4, 2012). Retrieved (on February 28, 2014) from http://www.infoq.com/articles/ieee-software-engineeering-services-cloudcomputing/ [19] Mell, P., Grance, T.: The NIST Definition of Cloud Computing, (Gaithersburg: NIST, September, 2011), pp. 2-3. Retrieved (on April 4, 2014) from http://www.profsandhu.com/cs6393_s13/nist-sp800-145.pdf [20] Lenk, A., Menzel, M., Lipsky, J., Tai, S., Offermann, P.: What Are You Paying For? Performance benchmarking for Infrastructure-as-a-Service offerings, (IEEE, 2011). Retrieved (on April 20, 2014) from http://hostel.ufabc.edu.br/~cak/inf103/what_are_you_paying_for_performance_benc hmarking_iaas_offerings_cloud2011.pdf [21] Keller, E., Rexford, J.: The Platform as a Service Model for Networking. Retrieved (on April 20,2014) from http://static.usenix.org/event/inmwren10/tech/full_papers/keller.pdf [22] Turner, M., Budgen, D., Brereton, P.: Turning software into a service, (2003), Computer. 36 (10), pp. 38-44. Retrieved (on April 4, 2014) from http://dro.dur.ac.uk/624/1/624.pdf

REFERENCES 88 [23] Delivering Database as a Service (DBaaS) using Oracle Enterprise Manager 12c, (Oracle, October, 2013). Retrieved (on May 4, 2014) from http://www.oracle.com/technetwork/oem/cloud-mgmt/dbaas-overview-wp- 1915651.pdf [24] Cover, R.: XML Applications and Initiatives Contents Listing for XML Applications and Industry Initiatives [Website], (June 25, 2005). Retrieved (on July 20, 2014) from http://xml.coverpages.org/xmlapplications.html [25] Dekkers, M.W.H.: Office Productivity Suite Competitive Analysis, (2002). Retrieved (on June 15, 2014) from http://xml.coverpages.org/dekkers- OOocompanalysis.pdf [26] iwork Programming Guide, (Cupertino: Apple, November 9, 2005). Retrieved (on July 1, 2014) from http://www.filibeto.org/unix/macos/lib/dev/documentation/appleapplications/conce ptual/iwork2-0_xml/iwork2-0_xml.pdf [27] PLIST files. Retrieved (on May 28, 2014) from http://www.appleexaminer.com/macsandos/analysis/plist/plist.html [28] Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E., Yergeau, F.: Extensible Markup Language (XML) 1.0 (Fifth Edition) [Website], (November 26, 2008). Retrieved (on June 5, 2014) from http://www.w3.org/tr/rec-xml/ [29] Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E., Yergeau, F.: Origin and Goals. In Extensible Markup Language (XML) 1.0 (Fifth Edition) [Website], (November 26, 2008). Retrieved (on June 5, 2014) from http://www.w3.org/tr/rec-xml/#sec-origin-goals [30] Fennel, P.: Extremes of XML. In XML London 2013 Conference Proceedings, (London: XML London, June 15-16, 2013). Retrieved (on June 20, 2014) from http://xmllondon.com/2013/xmllondon-2013-proceedings.pdf#page=80 [31] XML Output Formats. In The Google Geocoding API [Website], (Last updated August 1, 2014). Retrieved (on August 18, 2014) from https://developers.google.com/maps/documentation/geocoding/#xml [32] W3C Document License [Website]. Retrieved (on August 10, 2014) from http://www.w3.org/consortium/legal/2002/copyright-documents-20021231 [33] Fielding, R.T.: Representational State Transfer (REST). In Architectural Styles and the Design of Network-Based Software Architectures, (Irvine: University of California, 2000). Retrieved (on August 1, 2014) from http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm [34] Fielding, R.T., Taylor, R.N.: Principled Design of the Modern Web Architecture, (Irvine: University of California, May, 2002). Retrieved (on August 2, 2014) from http://www.ics.uci.edu/~taylor/documents/2002-rest-toit.pdf

REFERENCES 89 [35] Mueller, J.: Understanding SOAP and REST basics [Website], (January 8, 2013). Retrieved (on May 20, 2014) from http://blog.smartbear.com/apis/understanding-soap-and-rest-basics/ [36] Francia, S.: REST vs SOAP, The Difference Between SOAP and REST [Website], (Jan 15, 2010). Retrieved (on June 1, 2014) from http://spf13.com/post/soap-vs-rest [37] He, N., et al.: Component-based Design and Verification in X-MAN (2012), pp. 1-2. Retrieved (on July 20, 2014) from http://www.cs.man.ac.uk/~kungkiu/pub/erts12.pdf [38] Chak, C.W.C.: Component-Based Software for the Automotive Domain, (Manchester: University of Manchester, May 11, 2012). Retrieved (on August 1, 2014) from http://studentnet.cs.manchester.ac.uk/resources/library/thesis_abstracts/projprogrept smsc12/chakwengchoong-christopher-progressreport.pdf [39] Lau, K.-K., Wang, Z.: Software Component Models. In IEEE Transactions on Software Engineering Vol. 33, No. 10, (October, 2007). Retrieved (on August 1, 2014) from http://lig-membres.imag.fr/donsez/ujf/m2r/glcs/composants/lau.pdf [40] Lau, K.-K., Ornaghi, M., Wang, Z.: A Software Component Model and Its Preliminary Formalisation. Retrieved (on August 1, 2014) from http://www.cs.man.ac.uk/~kung-kiu/pub/fmco05.pdf [41] Lau, K.-K., Safie, L., Štepán, P., Tran, C.: A Component Model that is both Control-driven and Data-Driven, pp. 41-42. Retrieved (on August 1, 2014) from http://www.cs.man.ac.uk/~kung-kiu/pub/cbse11.pdf [42] Lau, K.-K., Taweel, F.M.: Towards Encapsulating Data in Component-based Software Systems. In Gorton, I., et al.: Proceedings of Ninth International Symposium on Component-based Software Engineering, (Springer-Verlag, 2006). Retrieved (on July 28, 2014) from http://www.cs.man.ac.uk/~kungkiu/pub/cbse06b.pdf [43] Lau, K.-K., Tran, C.M.: X-MAN: An MDE Tool for Component-based System Development. In 38 th Euromicro Conference on Software Engineering and Advanced Applications, pp. 159-160. (2012). Retrieved (on August 1, 2014) from http://www.cs.man.ac.uk/~kung-kiu/pub/seaa12.pdf [44] Lau, K.-K., Velasco, P.E., Wang, Z.: Exogenous Connectors for Software Components. Retrieved (on August 1, 2014) from http://www.cs.man.ac.uk/~kungkiu/pub/cbse05.pdf [45] Lau, K.-K., Safie, L., Štepán, P., Tran, C.: A Component Model that is both Control-driven and Data-Driven, pp. 43-44. Retrieved (on August 1, 2014) from http://www.cs.man.ac.uk/~kung-kiu/pub/cbse11.pdf

REFERENCES 90 [46] Lau, K.-K., Ling, L. & Elizondo, P.V.: Towards Composing Software Components in Both Design and Deployment Phases, pp. 4-5. Retrieved (on February 10, 2014) from http://www.cs.man.ac.uk/~kung-kiu/pub/cbse07c.pdf [47] Lau, K.-K., Ling, L., Ukis, V., Elizondo, P.V.: Composite Connectors for Composing Software Components, pp. 2-3. Retrieved (on August 2, 2014) from http://www.cs.man.ac.uk/~kung-kiu/pub/sc07.pdf [48] Lüders, F., Lau, K.-K., Ho, S.-M.: Specification of Software Components. In Crnkovic, I., Larsson, M.: Building Reliable Component-based Software Systems, Chapter 2, pp. 23-38. (Artech House, 2002). Retrieved (on July 14, 2014) from http://www.cs.man.ac.uk/~kung-kiu/pub/cbsebook.doc [49] Lau, K.-K., Tran, C.M.: X-MAN: An MDE Tool for Component-based System Development. In 38 th Euromicro Conference on Software Engineering and Advanced Applications, pp. 161-164. (2012). Retrieved (on August 1, 2014) from http://www.cs.man.ac.uk/~kung-kiu/pub/seaa12.pdf [50] CESAR official website [Website]. Retrieved (on August 10, 2014) from http://www.cesarproject.eu/ [51] X-MAN tool homepage [Website]. Retrieved (on August 10, 2014) from http://www.cs.man.ac.uk/~tranc/xman/x-man_tool/home.html [52] Stepper, E.: CDO Model Repository Overview. Retrieved (on April 27, 2014) from http://www.eclipse.org/cdo/documentation/ [53] Key, D.: Requirements for Enterprise SaaS Applications. Retrieved (on August 10, 2014) from http://www.cloudstrategies.biz/requirements-for-building-enterprisesaas-applications/ [54] Barbeau, S.J., Saloranta, T.: Performance Evaluation of Transit Data Formats on a Mobile Device, (Tampa: University of South Florida, November 15, 2013). Retrieved (on August 15, 2014) from http://www.locationaware.usf.edu/wp- content/uploads/2014/01/performance-evaluation-of-transit-data-formats-on-a- Mobile-Device8.pdf [55] Peng, D., Cao, L., Xu, W.: Using JSON for Data Exchanging in Web Service Applications, (Shanghai: University of Shanghai for Science and Technology). In Journal of Computational Information Systems 7: 16, (USA: Binary Information Press, 2011). Retrieved (on August 15, 2014) from http://www.jofcis.com/publishedpapers/2011_7_16_5883_5890.pdf [56] Man, J., Malaika, S.: XML or JSON: Guidelines for what to choose for DB2 or z/os, (IBM, March 27, 2014). Retrieved (on September 4, 2014) from http://www.ibm.com/developerworks/data/library/techarticle/dm-1403xmljson/dm- 1403xmljson-pdf.pdf

REFERENCES 91 [57] Dewar, R. G.: Managing Software Engineering Artefact Metadata. Retrieved (on May 2, 2014) from http://www.macs.hw.ac.uk/cs/techreps/docs/files/hw- MACS-TR-0034.pdf [58] Rus, I., Lindvall, M.: Knowledge Management in Software Engineering, (June, 2002). Retrieved (on May 2, 2014) from http://www.computer.org/csdl/mags/so/2002/03/s3026.html [59] What is BeanShell? [Website]. Retrieved (on June 10, 2014) from http://www.beanshell.org/intro.html [60] Octeau, D., Jha, S., McDaniel, P.: Retargeting Android Applications to Java Bytecode. Retrieved (on August 14, 2014) from http://www.cse.psu.edu/~duo114/pubs/octeau-fse12.pdf [61] Nurseitov, N., Paulson, M., Reynolds, R., Izurieta, C.: Comparison of JSON and XML Data Interchange Formats: A Case Study, (Montana: Montana State University). Retrieved (on June 20, 2014) from http://www.cs.montana.edu/izurieta/pubs/caine2009.pdf [62] Pundhir, Y.S.: Cloud Computing Applications and Their Testing Methodology, (Uttar Pradesh: Integrated Academy of Management & Technology). In Bookman International Journal of Software Engineering Vol. 2 No. 1, (Bookman International Journals, March, 2013). Retrieved (August 27, 2014) from https://www.academia.edu/3587895/cloud_computing_applications_an D_THEIR_TESTING_METHODOLOGY [63] Lensmar, O.: What exactly is cloud testing anyway? (Network World, August 14, 2013). Retrieved (on August 20, 2014) from http://www.networkworld.com/article/2225173/opensource-subnet/what-exactly-is-- cloud-testing--anyway-.html [64] Xu, A.: Why you need application testing in the cloud, (IBM, August 26, 2013). Retrieved (July 3, 2014) from http://thoughtsoncloud.com/2013/08/why-you-needapplication-testing-in-the-cloud/ [65] Cloud Testing Best Practices, (Belatrix Software Factory). Retrieved (on July 2, 2014) from http://www.belatrixsf.com/downloads/belatrix-cloud-testing-best- Practices-2012-0322.pdf

APPENDIX A 92 APPENDIX A Table 0.A: Integration Test Case 1 Tested By: Halim Fadhli Test Type Integration Testing Test Case Number TCI-01 Test Case Name Test deposit and retrieval of component Test Case Description Test if the deposited component is stored successfully and the retrieval of the same component resulted with the same component including its appearance, coordination, codes, and its settings Item(s) to be tested 1 Deposit of the component 2 Retrieval of the component Pre-condition Post condition - Ready with stub class Stub1.java that could send and receive XML document - The repository data is cleaned using ResetRepo.java - X-MAN atomic component XML document template - Command prompt open pointing to desktop Specifications Expected Input Output/Result - Component s XML document - Identical component s XML document obtained Procedural Steps Create a fake X-MAN atomic component XML document. Use the template prepared 1 on filename xtemplate.xml in desktop and change the service and method name to TestMethod. Fill the method code in between <method name= TestMethod > and </method> 2 with the code return Test ; and finally save it as ix{day}{month}.xml. For example the date 7 August, save it as ix0708.xml On the stub class TCI01.java, find comment //READ XML DOC and make sure the 3 following code reads from the file saved earlier. For example: getxml(.. + ix0708.xml );

APPENDIX A 93 4 5 6 7 On the stub method, find comment //SAVE XML DOC and make sure the following code save to desktop with file name as ox{day}{month}.xml. This is similar with the two steps above Run the stub class by command line using this 2 command - javac Stub1.java - java Stub1.class Check on the desktop for the output file name mentioned from Step 4, and compare if it is similar with the input file name mentioned from Step 2 Clean the repository by running the stub class using this 2 command in command line - javac ResetRepo.java java ResetRepo.class

APPENDIX A 94 Table 0.B: Integration Test Case 2 Tested By: Halim Fadhli Test Type Integration Testing Test Case Number TCI-02 Test Case Name Test deposit and execute component Test Case Description Test if the deposited component is stored successfully and the execution of the same component service resulted with the ouput as the code inserted earlier Item(s) to be tested 1 Deposit of the component 2 Execution of the component Pre-condition Post condition - Ready with stub class Stub2.java that could send XML document and print out - The repository data is cleaned using ResetRepo.java the received output - X-MAN atomic component XML document template - Command prompt opened pointing its directory to desktop Specifications Expected Input Output/Result - Component s XML document - Print out from command line with welcome text and today s date Procedural Steps Create a fake X-MAN atomic component XML document. Use the template prepared 1 on filename xtemplate.xml in desktop and change the service and method name to TestMethod. Fill the method code in between <method name= TestMethod > and </method> 2 with the following code: String hello = "Hello "; return hello; 3 Find <atomic> element and change the name to ix{day}{month} and finally save it as ix{day}{month}.xml. For example the date 7 August, save it as ix0708.xml On the stub class TCI02.java, find comment //READ XML DOC and make sure the 4 following code reads from the file saved earlier. For example: getxml(.. + ix0708.xml );

APPENDIX A 95 On the stub method, find comment //EXECUTE COMP and make sure the next line 5 executes the correct component name and service name created earlier. For example: execcomp( + /ix0708/testmethod ); Run the stub class by command line using this 2 command 6 - javac Stub2.java - java Stub2.class 7 Make sure the output produced is Hello Clean the repository by running the stub class using this 2 command in command line 8 - javac ResetRepo.java - java ResetRepo.class

APPENDIX A 96 Table 0.C: Integration Test Case 3 Tested By: Halim Fadhli Test Type Integration Testing Test Case Number TCI-03 Test Case Name Test deposit and execute component using library Test Case Description Test if the deposited component is stored successfully and the execution of the same component service resulted with the ouput as the code inserted with library reference earlier Item(s) to be tested 1 Deposit of the component 2 Execution of the component Pre-condition Post condition - Ready with stub class Stub2.java and ResetRepo.java - The repository data is cleaned using ResetRepo.java - X-MAN atomic component XML document template - Command prompt opened pointing its directory to desktop Specifications Expected Input Output/Result - Component s XML document - Print out from command line with welcome text and today s date Procedural Steps Create a fake X-MAN atomic component XML document. Use the template prepared 1 on filename xtemplate.xml in desktop and change the service and method name to TestMethod. Fill the method code in between <method name= TestMethod > and </method> with the following code: String hello = "Hello "; 2 DateFormat dateformat = null; Calendar cal = Calendar.getInstance(); dateformat = new SimpleDateFormat("yyyy/MM/dd"); return hello + "today is " + dateformat.format(cal.gettime()); 3 Find <atomic> element and change the name to ix{day}{month} and finally save it as ix{day}{month}.xml. For example the date 7 August, save it as ix0708.xml

APPENDIX A 97 4 5 6 7 8 On the stub class TCI02.java, find comment //READ XML DOC and make sure the following code reads from the file saved earlier. For example: getxml(.. + ix0708.xml ); On the stub method, find comment //EXECUTE COMP and make sure the next line executes the correct component name and service name created earlier. For example: execcomp( + ix0708/testmethod ); Run the stub class by command line using this 2 command - javac Stub2.java - java Stub2.class Make sure the output produced is Hello today is following the date of today. Example: Hello today is 2014/08/07 Clean the repository by running the stub class using this 2 command in command line - javac ResetRepo.java - java ResetRepo.class

APPENDIX B 98 APPENDIX B 1. <?xml version="1.0" encoding="utf-8"?> 2. <xs:schema attributeformdefault="unqualified" elementformdefault="qualified" xmlns:xs="http://www.w3.org/2001/xmlschema"> 3. <xs:element name="atomic"> 4. <xs:complextype> 5. <xs:sequence> 6. <xs:element name="name" type="xs:string" /> 7. <xs:element name="language"> 8. <xs:complextype> 9. <xs:simplecontent> 10. <xs:extension base="xs:string"> 11. <xs:attribute name="id" type="xs:unsignedbyte" use="required " /> 12. </xs:extension> 13. </xs:simplecontent> 14. </xs:complextype> 15. </xs:element> 16. <xs:element name="computation-unit"> 17. <xs:complextype> 18. <xs:sequence> 19. <xs:element maxoccurs="unbounded" name="method"> 20. <xs:complextype> 21. <xs:simplecontent> 22. <xs:extension base="xs:string"> 23. <xs:attribute name="name" type="xs:string" use="requir ed" /> 24. </xs:extension> 25. </xs:simplecontent> 26. </xs:complextype> 27. </xs:element> 28. <xs:element ref="app-info" minoccurs="0"/> 29. </xs:sequence> 30. <xs:attribute name="id" type="xs:unsignedbyte" use="required" /> 31. </xs:complextype> 32. </xs:element> 33. <xs:element maxoccurs="unbounded" name="service"> 34. <xs:complextype> 35. <xs:sequence> 36. <xs:element ref="app-info" minoccurs="0"/> 37. </xs:sequence> 38. <xs:attribute name="name" type="xs:string" use="required" /> 39. <xs:attribute name="id" type="xs:unsignedbyte" use="required" /> 40. </xs:complextype> 41. </xs:element> 42. <xs:element maxoccurs="unbounded" name="connector"> 43. <xs:complextype> 44. <xs:sequence> 45. <xs:element name="source"> 46. <xs:complextype> 47. <xs:attribute name="id" type="xs:unsignedbyte" use="requir ed" /> 48. </xs:complextype> 49. </xs:element> 50. <xs:element name="target"> 51. <xs:complextype> 52. <xs:attribute name="id" type="xs:unsignedbyte" use="requir ed" />

APPENDIX B 99 53. </xs:complextype> 54. </xs:element> 55. <xs:element ref="app-info" minoccurs="0"/> 56. </xs:sequence> 57. </xs:complextype> 58. </xs:element> 59. </xs:sequence> 60. </xs:complextype> 61. </xs:element> 62. <xs:element name="app-info"> 63. <xs:complextype> 64. <xs:sequence> 65. <xs:any namespace="##any" minoccurs="0" maxoccurs="unbounded" proces scontents="lax"/> 66. </xs:sequence> 67. </xs:complextype> 68. </xs:element> 69. </xs:schema> Figure 0.1: XML Schema for X-MAN atomic component XML document