CLOUD SUPPORT COMPONENT: CASE STUDY BASED ON ENCAPSULATED COMPONENT MODEL

(1)

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

(2)

| 2

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)

| 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)

| 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)

| 9

LIST OF EQUATIONS

Equation 1: Syntax Convention for Storing Application Specific Information ... 64

(10)

| 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)

| 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)

| 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)

| 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)

| 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.

(15)

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 | 16

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 cloud-computing 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 component-based development in cloud computing while proving the improved criteria benefited from the implementation.

(17)

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.

(18)

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.

(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 run-time 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}

(20)

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,}

(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 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.

(22)

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

(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

(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].

(25)

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].

(26)

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;

(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.}

(28)

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

(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

(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.

(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.}

(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.}

(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.

(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.

(35)

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

(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

(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

R

E

Q

1 _{The project must adopt X-MAN as a part of encapsulated component model to} utilise its capabilities of meeting the idealised component lifecycle

R

E

Q

2 _{The project must be able to demonstrate the deposit and retrieve process of a} component to cloud environment

R

E

Q

3 _{The project must manage the transaction and translate the component remotely} in the cloud so local machine don’t have to run additional processes

R

E

Q

4

The project should consider any other collaboration features to be implemented

R

E

Q

4.1 The project could implement the collaboration feature where components may be executed independently from the cloud

R

E

Q

4.2 The project could implement the collaboration feature where components may be executed from any language from the cloud

R

E

Q

5 _{The student should meet all the university milestones and treat it as deadlines} of the product development lifecycle

R

E

Q

6

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

(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.

(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

(40)

only measurement. However, XML’s feature rich criteria provide something unique for this project to deliver its goals.

(41)

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.

(42)

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.

(43)

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,}

CLOUD SUPPORT COMPONENT: CASE STUDY BASED ON ENCAPSULATED COMPONENT MODEL