Institute of Architecture of Application Systems
University of Stuttgart
Universittsstrae 38 D-70569 Stuttgart
Studienarbeit Nr. 2446 Improving and updating the
Nefolog system
Na Chen
Course of Study: Computer Science Examiner: Prof. Dr. Frank Leymann Supervisor: Dr. Vasilios Andrikopoulos
Commenced: December.12, 2013 Completed: June.13, 2014
CR-Classification: D.2.1, D.2.9, H.3.3, H.5.2
Abstract An increasing number of companies are offering nowadays Cloud Computing services. For example, they offer different services like doing calculations on virtual machines with different CPU cores and RAM sizes. A growing number of enterprises take advantage of these services for efficient data processing. The Nefolog system helps users to identify the most cost efficient cloud provider for their needs. However, the existing system provides RESTful services and does not offer a graphical interface for direct interaction with the users. This work designs and implements such an interface as a Web application, so that users can get information out of the Nefolog system in an easy to use manner.
iii
Contents 1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Problem Definition and Goal . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Background 5
2.1 Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Cloud Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Migration to the Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Migration Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.2 Decision Support Systems . . . . . . . . . . . . . . . . . . . . . . . 9 2.4 The Nefolog Decision Support System . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Database of Nefolog system . . . . . . . . . . . . . . . . . . . . . . 10 2.4.2 Decision Support Services . . . . . . . . . . . . . . . . . . . . . . . 13 2.4.3 Basic knowledge for the web technology . . . . . . . . . . . . . . . 13 2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Specification & Design 15
3.1 Project overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.1 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . 15 3.2.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . 15 3.3 System Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.1 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3.2 The graphical user interface . . . . . . . . . . . . . . . . . . . . . . 17 3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Implementation 23
4.1 Communication to Nefolog . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2 The graphical user interface . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1 Building trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.2 Candidate search view . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2.3 Implementation of the graphical user interface . . . . . . . . . . . 33
5 Evaluation 41
5.1 Nefolog Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.2 Comparison with MiDSuS . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6 Conclusions 47
6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
v
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Bibliography 49
vi List of Figures
1.1 Structure of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Cloud Deployment Models [3] . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Software as a Serice (SaaS) [4] . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Platform as a Service (PaaS) [3] . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Infrastructure as a service(IaaS) [3] . . . . . . . . . . . . . . . . . . . . . . 8 2.5 Conceptual Model of Decision Support System for Cloud Migration[10] . . 11 2.6 Nefolog system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.7 Entity-Relation Diagram of Nefolog System[11] . . . . . . . . . . . . . . . 12
3.1 The Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Mockup - Provider View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3 Mockup - Service Type View . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4 Mockup - Offering View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.5 Mockup - Cost Calculation View . . . . . . . . . . . . . . . . . . . . . . . 21 3.6 Mockup - Offering Matcher View . . . . . . . . . . . . . . . . . . . . . . . 22
4.1 Restful Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2 Tree starting from providers . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3 screenshot starting point from provider . . . . . . . . . . . . . . . . . . . . 34 4.4 screenshot starting point from provider with configuration selected . . . . 34 4.5 screenshot starting point from service type . . . . . . . . . . . . . . . . . . 35 4.6 screenshot showing performance view . . . . . . . . . . . . . . . . . . . . . 36 4.7 screenshot of costcalculator function . . . . . . . . . . . . . . . . . . . . . 36 4.8 screenshot of costcalculator result . . . . . . . . . . . . . . . . . . . . . . . 37 4.9 screenshot of costcalculator result2 . . . . . . . . . . . . . . . . . . . . . . 37 4.10 screenshot of candidate search . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.11 screenshot of candidate search 2 . . . . . . . . . . . . . . . . . . . . . . . . 39 4.12 screenshot of tooltip for cost calculator . . . . . . . . . . . . . . . . . . . . 40
5.1 Evaluation - Cost calculation screen 1 - Search and select offering . . . . . 42 5.2 Evaluation - Cost calculation screen 2 - Entering of details . . . . . . . . . 42 5.3 Evaluation - Cost calculation screen 3 - Results of calculation . . . . . . . 43 5.4 screenshot of MiDSuS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.5 Screenshot of MiDSuS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.6 Evaluation - Candidate search view . . . . . . . . . . . . . . . . . . . . . . 46
vii
List of Tables
3.1 Non functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 URL Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1 Cost calculation service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.2 Candidate search comparison . . . . . . . . . . . . . . . . . . . . . . . . . 44
ix
Listings
4.1 Function getRestDataFromURL . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2 http://localhost:8080/nefolog/providers . . . . . . . . . . . . . . . . . . . 26 4.3 http://localhost:8080/nefolog/providers/Google . . . . . . . . . . . . . . . 27 4.4 http://localhost:8080/nefolog/offerings/AppEngine . . . . . . . . . . . . . 27 4.5 http://localhost:8080/nefolog/offerings/AppEngine/configuration 33 . . . 27 4.6 source code the tree from provider . . . . . . . . . . . . . . . . . . . . . . 28 4.7 Code block to fill the performance block . . . . . . . . . . . . . . . . . . . 29 4.8 Code block to get necessary parameters for cost calculator . . . . . . . . . 30 4.9 css structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.10 Dynamical building of the input form for the calculator . . . . . . . . . . 31 4.11 Build URL to Calculator and get the result . . . . . . . . . . . . . . . . . 31 4.12 Query for getting variables for offering matcher . . . . . . . . . . . . . . . 32 4.13 Function getUnitFromFieldname . . . . . . . . . . . . . . . . . . . . . . . 38
xi
1 Introduction Cloud computing develops quickly from day to day. For many companies, this brings advantages like resource conservation and reduction of costs because it is not necessary to run an own computer center. Another benefit is that the use of cloud computing normalizes the IT-System and gets it safely without having to do run redundant hardware or doing backups by the company itself. This chapter introduces the motivation, the specific problems, as well the outline of this thesis.
1.1 Motivation Nowadays, almost all companies need IT-support independent of if the size of the company is large, medium, or small. IT-support is also needed forall kinds of business, both in the IT domain, but also in other domains, e.g. chemical companies etc. IT-technical support plays an important role for the company infrastructure. A successful IT-support can also bring profit for the company However, building the IT-department it costs the company relatively much investment, employees, equipment, and space. For large size companies using cloud services or having own equipment is possible. Such companies anyway have a large computing department with professional IT-engineers and advanced equipment. However, for a small size of companies, they don't have a professional team for the IT-system. Here cloud computing could be a good solution for them, so they don't need to employ people for the IT-service by themselves, also they don't need a large server for storing the data. Another advantage is that the hardware needed for processing can be scaled with demand. If the company at peak times needs more performance than usually this can be easily handled using clould services. Secondary but very important services like doing backups of the data are included in the service.
For example, if small company uses Google Apps and Google Docs, not just for data processing, like to creating tables or powerpoint, the data are also always saved in the same place and can be accessed wherever you are. The advantage of giving the data to the provider is that the provider takes care about that the resources in the computing center are fit for the need as well as data protection is taken care about. Small or Midsize companies may not have the time to pay attention on such details. Instead of that such companies can concentrate on their main business safely end efficiently.
Because of that Mid-size companies are the main users for cloud computing. First those companies have own IT technical personal but they do not pay attention on how to build the basic technical infrastructure. They are challanged on how to integrate the IT into the business processes to maximize the benefit for the company. Secendly mid sized companies are often in the state of expansion. In this process the focus is mostly
1
1 Introduction on the own business and not on the IT-Department. These days, more and more cloud computing providers are bringing lots of different offerings, main like data processing and data storage. The cloud market is very segmented with many kinds of configurations, performance and location offerings. At different providers all of those might be called differently. The user wants to find the best solution for the problem with the lowest costs. As the market for Cloud computation is growing rapidly the prices of the services are changing fast. In addition, new offerings are coming up with higer performances. Because of this rapid changes the knowledge base of any decision support system for application migration needs to be kept up-to-date by steadily updating the database with new information from the different providers. In this way the user can find the exact solution in the database.
For the purposes of this work, we assume that the users are searching for their solutions in the Nefolog system database.[1] An interface that the users can directly use is necessary for this purpose. For getting a user friendly interface it is planed to create a dynamic web page where the user can easily find database entries. This should be possible without the user manually having to query the database for offerings.
1.2 Problem Definition and Goal The user can give a request with it's needs to the system. The visualization system then takes the request and summarizes all the information from the providers. The system should then give an overview so that the user can find the best offering. In the end the system should calculate the costs resulting about using a solution. The Nefolog database which is used by the visualization contains the web services defined by providers and offerings. The offerings are segmented into service type and configuration.
1.3 Outline This thesis consists of six chapters, the first chapter is introducing the main idea of this work. Chapter two introduces the technology background. Like the Figure1.1 shows, Chapter three to Chapter five present the specification of the system, the design and the details of the , as well as the evaluation of this work. The thesis ends with some conclusions and future work.
2 Improving and Updating the Nefolog system
1 Introduction Figure 1.1: Structure of Thesis Improving and updating the Nefolog system 3
2 Background In this chapter will introduce some background about cloud computing, like what is cloud, the different types of cloud, three kinds of Cloud Service Models.
2.1 Fundamentals Cloud computing portends a major change in how store information and run applications, instead of running programms and data on an individual desktop computer, everything is hosted in a nebulous assemblage of computers and servers accessed via the internet. [2] That is the integration of the development of Grid Computing, Distributed Computing, Parallel Computing, Network Storage Technologies. The core idea is to run a program on many connected computers at the same time. The user may be using a different own computing system. The user does not need to understand how the infrastructure is built like. The cloud offers the possibility to call programs or applications or to store data or doing other computing tasks through the internet.
The idea of cloud computing went through four phases at first the Power Plant model [2]:The idea of cloud computing was to have a cheap replacement for an uninterruptible power supply (UPS). The second phase was the Utility Computing: in the 1960s the computing devices were very expensive, not every company could afford them, the idea of utility computing should solve the problem. The server, storage system and application were integrated from different locations to share them to the users. The user could then pay dependent on usage. The idea of Grid Computing is to distribute a big computing prolem to small segments. These segments can then be calculated in parallel on devices with low compution capabilities.
2.2 Cloud Types Currently Cloud-based applications provide a wide range of solutions to the user. The National Insitute of Standards and Technology (NIST) describes the cloud solutions based on the system's Deployment Models and the Cloud Service Models, as shown in Figure 2.1.
* Community Cloud: Two or more organizations or companies from the same branch
share the private cloud of each other which only can be accessed by the members of the community.
* Hybrid Cloud: A Cloud that consists of two or more public, private or community
clouds.
5
2 Background Figure 2.1: Cloud Deployment Models [3]
* Public Cloud: Makes resources, such as applications and storage available to the
general public over the internet. Using a public cloud is least intensive, even could be free, but that is less secure.
* Private Cloud: Owned by a specific entity and normally used only by that entity
or one of its customers. A private cloud offers increased security at a greater cost. [3]
There are three kinds of Cloud Service Models available: Software as a Service (SaaS), the application for the user is web-based. Platform as a Service (PaaS) which provides a computing platform and a solution as service. A PaaS solution includes hardware, operating systems, development tools and administrative tools. Infrastructure as a service(IaaS) is the most basic cloud service model, the provider offers computers or virtual machines or storage. Those three models are independent, but also have some dependency relationships.
* Software as a Serice (SaaS): As the Figure 2.2 shows, SaaS is the most common
and most earliest cloud computing service. Through the internet browser the user can directly connect with application on cloud. The provider offers to maintain the hardware and software of cloud. The cost is depend on the way the service is used and the amount of the users. For example like Google Apps, that included Gmail, Google Calendar, Google Docment, and other online-based office tools. The advantages of the SaaS solution for the user is that it is easy to use. When there is an internet connection available the user can access the Saas service at any time. The user does not need to care about the technology behind the service. Another advantage of this is safety of the storage and security of data transfers can be granted. This solution uses the basic web technologies like HTML, JavaScript and CSS.
* Platform as a Service (PaaS): The user creates the software, uses the tools and
libraries from the cloud provider. The user also cares about controlling the software developing and configuration settings, but doesn't care the maintrainance
6 Improving and Updating the Nefolog system
2 Background Figure 2.2: Software as a Serice (SaaS) [4] of the servers, storage, and operating systems, like the Figure 2.3 shows. Examples for this are the Google App Engine, Windows Azure Plattform and Heroku. The Windows Azure Plattform is the PaaS resolution product from Microsoft, it provides a cloud services operating system and a set of services to support easy development and operation of applications for the platform. The platform provides the functionality to build and manage applications that span from consumer Web to enterprise scenarios. The solution under this are usally technologies like REST (Representational State Transfer), parallel processing and distributed cache.
* Infrastructure as a service(IaaS): In this case the user gets infrastructure as service. The provider offers a datacenter where the client gets one or more physical or virtual machines with storage and network connectivity. The user is then still responsible for installing and maintaining the software on the system. Dependent on the technology used this can be also a virtual machine, so that the acquisition cost will be reduced. The advantage of using this technology is that the IT infratructure can scale with the need of the customer. If the customer for instance needs more CPUs this can be simply realized by changing the configuration of the virtual machine. The same applies for the needed memory or mass data storage, like the Figure 2.4 shows. Examples for this are: Amazon EC2, IBM Blue Cloud, Cisco UCS and Joyent. Distributed storage system like Google BigTable can be used for mass data storage.
Improving and updating the Nefolog system 7
2 Background Figure 2.3: Platform as a Service (PaaS) [3] Figure 2.4: Infrastructure as a service(IaaS) [3] 8 Improving and Updating the Nefolog system
2 Background 2.3 Migration to the Cloud 2.3.1 Migration Type As the research by Andrikopoulos et al. discusses[5], there are four types of migration:
* Type I: Replace component(s) with cloud offering: One or more components are
replaced by cloud services, that is the least invasive type of migration. When switching to a cloud offering istead of a local component it is possibly necessary to rewrite some interfaces or doing other adaptations. For example when people use the Google App Engine Datastore instead of the local MySQL database.
* Type II: Partially migrate some of the application functionality to the Cloud:
Those components are from one or more application layers and have an interconnectionrelationship. For example instances to host data and business logic for HIC use Amazon SimpleDB and EC2.
* Type III: Whole software stack migration of the application to the cloud: that
means to encapsulate the application of a whole software stack in the VMs on the cloud. That is also the most common type migration to the cloud.
* Type IV: Cloudify the application: The application is completely migrationed: The
application is re-engineered as a composition of cloud services and runs exclusively in the cloud.
Besides to this also other decision systems like the CloudGenius and the Cloud Adoption Toolkit do exist. The CloudGenius decision system was developed by by Menzel et al. [6]. Regarding to Xiu [1] this is a continual evolutionary migration process. The Cloud Adoption Toolkit is another approach created by Khajeh-Hosseini et al. [7]. This toolkit includes a collection of tools which focus on both cost calculation and socio-technique. It is based on a checklist of questions.
2.3.2 Decision Support Systems
A DSS is an interactive, flexible and adaptable computer based information system that utilises decision rules, models, and model base coupled with a comprehensive database and the decision maker's own insights, leading to specific, implementable decisions in solving problems that would not be amenable to management science models per se. Thus, a DSS supports complex decision making and increases its effectiveness. [8]
The following five categories of DSS, there the Driven is the tool or component, that provide the domiant functionality in the Decision Support System.[9]
* Data-Driven DSS are the most common of those five category of the DSS. They
are used for analysis of large amounts of structured data. The system provides operation with use the internal company data and some external data, like for example the data warehousing, analytical systems.
Improving and updating the Nefolog system 9
2 Background
* Model-Driven DSS. A system that is using some kind of model like a financial
model, an optimization model or a representational model. Model-Driven DSS emphasize access and manipulation of the model.
* Knowledge-Diven DSS, can suggest or recommend actions to the managers, and
are person-computer systems with specialized problem-solving expertise. There the expertise like kind of to understand the problem from a particular domain and to solve the problem.
* Document-Driven DSS, these DSS is focused on helping managers to retrieve and
manipulate unstructured information or documents from different electronic formats. Those DSS can be divided in oral, video and written.
* Communications-Driven and Group DSS, pays attention on communication get
collaboration and coordination between groups of people, enables share the information and support the decision tasks from the group. For example the audio conferencing is supported from the group.
When the user wants to find the appropriate offering from the system, there will be some kinds of decisions, that they should be made. Between the different decisions, the user also need take care about the relationships and the influences. The research by Andrikopoulos et al [10] introduced the basic decisions that need to be made when migrating an application to the cloud. Like the Figure 2.5 shows, there is a model of decision support system, desision and task with different actions, the decisions (distribute application, select service provider/offering, defne multi-tenancy requirements and defne elasticity strategy). Those decisions are supported by seven different tasks (work load profling, compliance assurance, identifcation of security concerns, identifcation of acceptable QoS levels, performance prediction, cost analysis and effort estimation). The transparent arrows show the influences between them. For example in this figure that the performance prediction can descide the select service provider/offering, and effort estimation can also send feedbacks to the select service provider/offering.
2.4 The Nefolog Decision Support System Like the Figure 2.6 shows, there are two parts, one is the web application and other is the Nefolog system which developed by Mingzhu Xiu in 2014 [1]. She built the web services and the database, implemented the offerings matcher, and costs calculator. The aim of the system is to help the customer to move components of applications to the cloud. It helps to identify a suitable cloud provider service. In the end the Nefolog system retrieves the values for the candidate offerings search service and offerings cost calculation service from the database which is connected to the Nefolog system.
2.4.1 Database of Nefolog system All of the functions and database in the Nefolog system are designed based on the system MDSS [11], like this Entity-Relation Figure 2.7 shows. The Nefolog database
10 Improving and Updating the Nefolog system
2 Background Figure 2.5: Conceptual Model of Decision Support System for Cloud Migration[10]
Figure 2.6: Nefolog system Improving and updating the Nefolog system 11
2 Background Figure 2.7: Entity-Relation Diagram of Nefolog System[11] contains the data of six providers: Windows Azure, Amazon Web Services, Goolge, Hp Cloud, Flexiscale and Rackspace. All of those providers offer multiple kinds of offerings, which can be classifed in different 25 service types. One offering from one provider can have multiple configurations, which are sorted by kinds of performance. For example the Hp Cloud has offerings like HP Cloud Compute (Standard Instance Type), with different configurations like for standard extra small, standard small, standard medium and so on. The performace of the extra small cloud compute is with 1 HP computation unit, one virtual core, 1GB RAM, and 20GB of disk space. The customer can according to the self demand choose the configuration with compatible performance. The cost of configuration is calculated by each calculation formula, different location, and data transfer. The Nefolog database has a total 68 offerings, 547 performances, 656 configurations, 15 locations, 4890 different calculation methods (coefficient).
12 Improving and Updating the Nefolog system
2 Background 2.4.2 Decision Support Services The advantage of the Web services is that they are platfom and program languageindependent, the user doesn't need to worry about which kind of the platform or program language was used, either Windows or Linux, either C or Java. All of the resources from the database will be indentified by the URIs. The client side sends their request through the query with URI to the server side. The server side does for instance a calculation and sends the result back in standard representations like XML or JSON. In the Nefolog system there are two important services: The candidate search service and the cost calcultor service. Furthermore there are commands allowing to request the database content like the available providers etc.
* Candidate Search Service The candidate search service is like a function of the
offering matcher. There are nonumerical performance characteristics and numerical performance characteristics. Non numerical performance characteristics are used for the operating system, the software license and IO. The other performance characteristics are stored as numerical performance characteristics. Before the user continues to the cost calculation service the information retrieved by the function can be evaluated by the user. [1]
* Cost Calculator Service The cost calculations service consists of two parts. There
is a static calculator and a dynamic calculator available. The difference between the static calculator and the dynamic calculator is that the dynamic calculator needs additional logic. The total costs include the usage amout of costs, the data transfer costs and the upfront costs. It also needs to be checked whether they are served by the same data center, if not there could be a difference in the calculation. [1]
2.4.3 Basic knowledge for the web technology The following list of web technologies are nowadays very commonly used for the development of interactive web pages. This is why they are also used for the implementation of this project:
* JavaScript JavaScript is a programming language built into the web browser, that
is one of the best ways to add interactivity to website, because it's the only crossbrowser language that works directly with web browsers[12].
* JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is
easy for humans to read and write. It is easy for machines to parse and generate [13].
* Cascading style sheets CSS is a modern standard for the website presentation,
it can combined with a structural markup language like HTML, and XML. The cascading style sheets provide Internet browsers with the specified visual structure format [14].
Improving and updating the Nefolog system 13
2 Background 2.5 Summary This chapter introduced some basic knowledge for the rest of this work like some cloud types, migration types and also the Nefolog system. This background information of the Nefolog system is the basic knowledge for this new work, because this new system will be implemented as a web application based on Nefolog. In order to work it needs connection to the web services of the Nefolog system, which does the calculation and accesses the data from the database. The next chapter will explain the new web application with requirements and specifications.
14 Improving and Updating the Nefolog system 3 Specification & Design This chapter identifies the requirements for a decision support system extending the Nefolog system to a requirements specification and design specification document.
3.1 Project overview The Nefolog system consists of a database as well as a java server page offering web services to access the data. It contains cloud computing providers with their offered services and prices. The Nefolog system also contains a cost calculator which can compare the price dependent on the services needed and which provider is used. The existing Nefolog system is the base for a decision support system whose graphical user interface which shall be described here in this document. It shall offer a user friedly access to the existing providers, the available services and the resulting prices.
3.2 Requirements To realize this project the following requirements should be used. It is didived into functional and non functional requirements. The functional requirements shall describe what functionalities should be offered by the system. The non- functional requirements should describe the environmental requirements for the project e.g. the target operating system.
3.2.1 Non-Functional Requirements The non-functional requirements shown in Table 3.1 have been defined for this project. HTML, javascript and CSS sheets should be used for the design of web application. The user can access the Nefolog database dynamically. The web presentation of the information is user-friendly.
3.2.2 Functional Requirements Table 3.2 shows the functional requirements for the project. The visual Navigation of the database will go through the available providers or service types. The access should use the available RESTful API of the Nefolog system. A human oriented interaction with the offerings matcher and a cost calculator shall be built, so that the user can get the offering or price of offering efficiently.
15
3 Specification & Design Table 3.1: Non functional requirements Requirement ID Title Description NFR1 Web based implementation
The implementation of the system shall be done using Javascript, HTML and CSS sheets.
NFR2 User interface The user interface should be implemented allowing the user to dynamically access date entries in the Nefolog database. This should be possible by using a web browser.
NFR3 Necessary user environment
In order to run the user interface for the user a browser needs to be available as well as a network connection to the server, or can be installed locally.
NFR4 User friendly presentation
The web based presentation of the information retrieved by the Nefolog shall be provided in a user-friendly representation.
Table 3.2: Functional requirements Requirement ID Title Description FR1 A Web GUI shall
be available which provides dynamic interaction with the Nefolog system
Navigation through the available providers, service types etc. shall be possible. The access should build on the RESTful API provided by Nefolog.
FR2 Interaction with offerings matcher and cost calculator
Human oriented interaction with the the offerings matcher and cost calculator services shall be possible.
16 Improving and Updating the Nefolog system
3 Specification & Design Figure 3.1: The Use Case Diagram 3.3 System Specification 3.3.1 Use Case Diagram Figure 3.1 shows the use case diagram of the project. The right side of the diagram shows the Nefolog system which accesses the database. The Nefolog system itself is accessed via restful communication. Because this project does not focus on the functionality of the Nefolog system the right side of the figure is intentionally pictured without details. The left side of the diagram shows the interaction of the system with the user. The user can use the following features:
* Select a startpoint for browsing the Nefolog database
* Visualize the information in the shape of a tree, dependent on the startpoint
* Show the candidates matching the selected features
* Calculate the costs resulting on chosen specific provider with defined features
3.3.2 The graphical user interface The graphical user interface is the main feature for this project. Therefore a user-friedly representation of the system is essential. It should enable to user to use the system without having to read a manual before. The user interface for this project shall be implemented as a lightweight web interface. This means that the calculation intensive operations should be running on the server. The communication to the client is based on TCP/IP as low level transport layer. Therefore the client can run on the same machine as as server but it can easily also run on another machine which has a network connection
Improving and updating the Nefolog system 17
3 Specification & Design Figure 3.2: Mockup - Provider View to the server. The protocol above is HTML, therefore no special application needs to be installed on the client computer. The advantage of this is also that this enables a cross platform usage. You can also use a client running any operation system as long as it offers a web browser supporting HTML5 and Java script. It would also be possible to render everything at the server and don't use a script language at the client but this would enhance the developlent effort of the system and would also lead to a higher latency in case of a slow network connection. The latency describes the reaction time between a user input and the response of the system. If this time is too long this has a negative effect on the user experience.
Provider View The intention of the main screen is to provide an interface for the user which allows to easily search the database for providers. Afterwards it should be possible to trigger a cost calculation.
The start point for browsing for providers is shown in Figure 3.2. The user first can choose the startpoint for the intended search. This can be a provider an offering or a search type. Depending on the choice a tree is built. The advantage of a tree is that it gives a good top down overview. The user only can see the information based on the
18 Improving and Updating the Nefolog system
3 Specification & Design Figure 3.3: Mockup - Service Type View choice which was done before. From the performance point of perspective it offers the possibility that the database query is done step by step as the user refines his choice. Alternativerly to that it is also possible to do a general database query and give the java script tree already all information.
In this screen the user firstly selected to start browsing from the providers. Therefor a tree spans with all providers listed in the database. Then the user can click on a provider. If different price models are available the user can choose one. From there it is then possible to calculate the price for the desired services.
Service Type View The main screen in Figure 3.3 offers the selection of the start point for queries. This screen is active if "Service Type" was selected as a start point.
The service type start point is useful if a user already knows what service type is needed e.g. Application server, web server... etc. The user can choose one and then further refine the decision by choosing an offering. The result of the query is then a list of providers offering what is needed. When this choice is done it is possible again to calculate the costs.
Improving and updating the Nefolog system 19
3 Specification & Design Figure 3.4: Mockup - Offering View Offering View The screen in Figure 3.4 is active if Öffering" was selected as a start point. This view should be chosen if the needed offering is the base of the request. Offering means a specific cloud service, web site, sql database etc offered by a cloud provider, e.g. Amazon Web Services' Elastic Cloud Computing (EC2) solution. In the next step the query can be refined and then the calculation of the costs can be triggered.
Cost Calculation View Choosing a provider from the main screen is possible in the different view modes mentioned above. Independent from which screen a provider was chosen it is possible to calculate the costs with the cost calculator screen (See Figure 3.5).
In order to make possible to calculate the costs it is necessary to enter more details in this screen. These are information like the number of CPU cores, the CPU speed, etc. From the implementation aspect it would be the easiest way to offer text fields where the user should enter the details. From the user point of view entering information in a text box is uncomfortable. This is the case even more because there are more and more computers in usage which don't have a keyboard any more like tablets and smart phones. Another disadvantage of a text box is that the user could enter anything there which might not be intendet. In this case a message needs to be shown to the user telling what has to be entered into the text box.
20 Improving and Updating the Nefolog system
3 Specification & Design Figure 3.5: Mockup - Cost Calculation View To make the entering of information as easy to use as possible one solution would be a drop down menu.
Offerings Matcher View As Figure 3.6 shows, the user should give some parameters about the required performance, like CPU cores, memory, bandwidth and so on. Through the candidate search service in the Nefolg system the inappropriate configurations will be filtered out and the configuration IDs of the appropiate providers will be returned. There are parameters with numerical parameters and non-numerical parameters. Both searches for parameters will be built with the drop down boxes, because for the selection of non-numerical parameters can be more difficult, if the user writes the parameters different like it is called in the database. For instance if a user is searching for the string "Linux" but the String Übuntu" is stored in the database this could not be found with a query. In opposite to that it works if the user is choosing from a drop down box with the entries of the database.
Improving and updating the Nefolog system 21
3 Specification & Design Figure 3.6: Mockup - Offering Matcher View 3.4 Summary In this chapter we designed the functional and non functional requirements. The functional requirement describe for example a web GUI shall be available which provides dynamic interaction with the Nefolog system. The non functional requirements describe which kind of technology will be used for implementation. In addition, a design of the system was discussed through mockups.
22 Improving and Updating the Nefolog system
4 Implementation This chapter describes the implementation and design of the graphical user interface. The chapter consists of three parts: one is the graphical user interface, based on Nefolog. The other two are the candidate search view and cost calculator, which use the RESTful APIs offered by Nefolog system.
4.1 Communication to Nefolog As the requirements on chapter 3 Table 3.2 defined the communication to the Nefolog System shall be done using Restful web technology. This means that the communication to the server is done like the communication from a web browser to a web server. The client sends a HTTP request to the server and the server then returns the requested data in a representation format that is understood by the client. This could be XML or JSON for example. The Nefolog system returns the results as XML code. The advantage of this is that the communication is completely platform independent. The client does not need to know what operating system the server is running. Even the programing language used for writing the web service can be different from the one which is used at the client side.
The Nefolog system offers web services (See Table 4.1) for requesting information. These were used to build the GUI servlet.
4.2 The graphical user interface It is the aim of a graphical user interface to build an easy to user interface between the user and the system. For this project a web based user interface was chosen using HTML, Javascript and CSS. Javascript is only used for smooth user interactions. Most logic is kept at a Java server page. The idea of this is to only have a low dependency of the used browser version and features. The Restful communication is going on between the gui-servlet and the Nefolog system. The reason for this is that the gui-servlet and Nefolog system are most probably running on the same server or at least having a high bandwith connection between each other. The connection speed to the browser is then not so significant for the reaction time of the system.
23
4 Implementation Figure 4.1: Restful Communication
Table 4.1: URL Table URL Description /nefolog/providers Returns the list of
providers which are stored in the database.
/nefolog/providers/{Provider} Returns the list of offerings and service types which are supported by a specific provider
/nefolog/offerings/{Offering} Returns the list of
configurations which do support the requested offering
/nefolog/offerings/{Offering}/{Configuration_XYZ} Returns the supported
performances covered by a given configuration like the number of available CPUs etc.
/nefolog/costCalculator?configid={ConfigID} Returns the possible parameters for the selected configuration
../costCalculator?configid={ConfigID}?{parN}=x&... Returns the calculated
costs for the selected configuration
24 Improving and Updating the Nefolog system
4 Implementation 4.2.1 Building trees In order to give a good overview of the available content of the Nefolog system a tree scheme was chosen. The user can first select where to start (Providers or Service Types), then a tree is built out of the data retrieved by the Nefolog system. The implementation of this is built on the XML scheme which always contains a link to following nodes as well as on a function written by me which does an HTTP request and returns the retrieved XML file as a list of nodes. The network communication and parsing is done centrally at this globally used function. The function is named getRestDataFromURL (See Listing 4.1). It expects one parameter which delivers the URL needed to request and a XML tag which is used to parse the XML data returned by the service.
Listing 4.1: Function getRestDataFromURL 1 NodeList getRestDataFromURL ( String url , String tag ) 2 { 3 CloseableHttpClient inst = null ; 4 CloseableHttpResponse resp = null ; 5 String result = ""; 6 NodeList nList = null ; 7 8 try { 9 inst = HttpClientBuilder . create () . build () ; 10 resp = inst . execute ( new HttpGet ( url )); 11 } catch ( IOException ie ) { 12 ie . printStackTrace () ; 13 } 14 15 if ( resp == null ) { 16 // out . write (" Error connecting to url ") ; 17 return null ; 18 } 19 20 try { 21 final HttpEntity entity = resp . getEntity () ; 22 if ( entity != null ) { 23 result = EntityUtils . toString ( entity ); 24 } 25 26 resp . close () ; 27 } 28 catch ( IOException ie ) { 29 ie . printStackTrace () ; 30 } 31 32 // Parse 33 try { 34 DocumentBuilderFactory dbFactory = DocumentBuilderFactory .
newInstance () ; 35 DocumentBuilder dBuilder = dbFactory . newDocumentBuilder () ; 36 37 Document doc = dBuilder . parse ( new ByteArrayInputStream ( result .
getBytes ( StandardCharsets . UTF_8 ))); 38 39 doc . getDocumentElement () . normalize () ;
Improving and updating the Nefolog system 25
4 Implementation 40 nList = doc . getElementsByTagName ( tag ); 41 } 42 catch ( Exception ie ) { 43 ie . printStackTrace () ; 44 } 45 46 return nList ; 47 }
From line 3 to line 40 of the code an HTML connection to the server is being established and the resulting XML data from the server is stored in a buffer. Line 33 to 44 are using the integrated DOM based XML parsing capabilities of JAVA. Using DOM parsing a XML document is nearly done with one function call. The information is then already available as a tree and can be easily processed further on. Another approach for parsing the XML files would have been SAX. In opposite to DOM it is not parsing the whole XML file as a block but it is calling functions while the XML data is beeing parsed. This also allows parsing of big amounts of data but makes the processing more complicated. The disadvantage of using DOM is that the complete XML data is processed and stored in the memory at once. Therefore it is not optimal to be used with huge amout of data. For the size of the single XML data blocks which have to be processed in this project it is a suitable solution.
Technical details To build the tree starting from providers the first step is to do a REST request to the Nefolog system asking for the available providers. This is done by sending an HTTP GET request: http://localhost:8080/nefolog/providers The Nefolog system is then answering with the following block of XML data:
Listing 4.2: http://localhost:8080/nefolog/providers 1 2 < resource > 3 providers 4 5 6 Google 7 / providers / Google 8 9 ... 10 ... 11 12
The providers are specified with a name and an URI. This URI then leads to offerings that the chosen provider can do. In order to jump to the offerings this link has to be called and the provided content has to be parsed again:
26 Improving and Updating the Nefolog system
4 Implementation Listing 4.3: http://localhost:8080/nefolog/providers/Google 1 2 3 Google 4 5 6 AppEngine 7 / offerings / AppEngine 8 < servicetype > 9 application 10 / serviceTypes / applications 11 12 ... 13 ... 14 15
To get the available configurations starting from the previous point it is necessary to follow the URI specified in the section:
Listing 4.4: http://localhost:8080/nefolog/offerings/AppEngine 1 2 3 AppEngine 4 5 < configuration > 6 free 7 / offerings / AppEngine / configuration_32 8 9 ... 10 ... 11 12
To be able to render the content in the performance section of the window the URL given in the section can be called and parsed. Here one can find parameters like the number of available CPUs etc.
Listing 4.5: http://localhost:8080/nefolog/offerings/AppEngine/configuration 33 1 2 3 paid 4 33 5 6 < performance > 7 sla 8 0.99950000000000006 9 10 11
In order to present the user a tree on the screen a the freely available Javascript package dtree was used. With this code a tree gets built by doing some initialization and then
Improving and updating the Nefolog system 27
4 Implementation Figure 4.2: Tree starting from providers calling [add.(Unique ID, Subnode of)]. When the tree is built it can be drawn. Therefore the JSP page goes recursably threw the whole tree in order to read the text fields and the links necessary for building the tree. Figure 4.2 shows a fraction of the links needed to build a visualisation tree.
Listing 4.6 shows the source code of the java server page building the tree starting from providers. This code implements the communication flow described earlier in this section. As is can be seen the code contains three nested for loops. Dependent on the number of database entries this takes processing time. The advantage of this is that this is only done once when the page is called. Then everything is available as Javascript code in the browser which leads to quick response times even with a slow network connection.
Listing 4.6: source code the tree from provider 1 if ( startpoint == 0) // Provider as startpoint 2 { 3 // Get providers via Rest 4 NodeList pList = getRestDataFromURL ( PROVIDER_URL , " provider "); 5 6 for ( int i = 0; i < pList . getLength () ; i ++) { 7 Node pNode = pList . item (i); 8 if ( pNode . getNodeType () == Node . ELEMENT_NODE ) { 9 Element pElement = ( Element ) pNode ; 10 11 lastpNode = listID ; 12 out . println ("d. add (" +( listID )+" ,0,'"+ pElement .
getElementsByTagName (" name "). item (0) . getTextContent () +"
','');"); 13 // Increase ID for next tree entry 14 listID ++; 15 16 NodeList oList = getRestDataFromURL ( BASE_URL + pElement .
getElementsByTagName (" uri "). item (0) . getTextContent () , "
28 Improving and Updating the Nefolog system
4 Implementation offering "); 17 for ( int i2 = 0; i2 < oList . getLength () ; i2 ++) { 18 Node oNode = oList . item ( i2 ); 19 if ( oNode . getNodeType () == Node . ELEMENT_NODE ) { 20 Element oElement = ( Element ) oNode ; 21 lastcNode = listID ; 22 out . println ("d. add (" +( listID )+" ," +( lastpNode )+" ,'"+
oElement . getElementsByTagName (" name "). item (0) .
getTextContent () +" ','');"); 23 // Increase ID for next tree entry 24 listID ++; 25 26 NodeList cList = getRestDataFromURL ( BASE_URL + oElement
. getElementsByTagName (" uri "). item (0) .
getTextContent () , " configuration "); 27 for ( int i3 = 0; i3 < cList . getLength () ; i3 ++) { 28 Node cNode = cList . item ( i3 ); 29 if ( cNode . getNodeType () == Node . ELEMENT_NODE ) { 30 Element cElement = ( Element ) cNode ; 31 out . println ("d. add (" +( listID )+" ," +( lastcNode )
+" ,'"+ cElement . getElementsByTagName (" name "). item (0) . getTextContent () +" ','"+
GET_PERFORMANCE_URL + BASE_URL + cElement . getElementsByTagName (" uri "). item (0) . getTextContent () +" ');"); 32 // Increase ID for next tree entry 33 listID ++; 34 } 35 } 36 37 } 38 } 39 } 40 } 41 }
Listing 4.7: Code block to fill the performance block 1 // Get performance from URL 2 String performanceURL = request . getParameter (" perfID "); 3 if ( performanceURL != null ) 4 { 5 NodeList nList = getRestDataFromURL ( performanceURL , " performance "); 6 for ( int temp = 0; temp < nList . getLength () ; temp ++) { 7 Node nNode = nList . item ( temp ); 8 if ( nNode . getNodeType () == Node . ELEMENT_NODE ) { 9 Element eElement = ( Element ) nNode ; 10 out . println (" name : " + eElement . getElementsByTagName (" name ")
. item (0) . getTextContent () ); 11 out . write ("
"); 12 out . println (" value : " + eElement . getElementsByTagName (" value
"). item (0) . getTextContent () ); 13 out . write ("
"); 14 } 15 } 16 }
Improving and updating the Nefolog system 29
4 Implementation After having parsed the tree up to to configuration nodes it is possible to read the supported functions out of the Nefolog system. These are then shown in the HTML block displaying the performances of the selected configuration.
Listing 4.8: Code block to get necessary parameters for cost calculator 1 List < String > parameters = new ArrayList < String >() ; 2 3 NodeList pList = getRestDataFromURL ( COST_CALC_URL + configID , " content "); 4 for ( int i = 0; i < pList . getLength () ; i ++) { 5 Node pNode = pList . item (i); 6 if ( pNode . getNodeType () == Node . ELEMENT_NODE ) { 7 Element pElement = ( Element ) pNode ; 8 9 int i2 =0; 10 String result = null ; 11 while ( pElement . getElementsByTagName (" variable "). item ( i2 ) !=
null ) 12 { 13 String parameter = pElement . getElementsByTagName (" variable "). item (
i2 ). getTextContent () ; 14 15 // Store value in array list for building the request to the
calculator 16 parameters . add ( parameter ); 17 i2 ++; 18 } 19 } 20 }
The visualization created in this work is based on Java Server Pages creating and using HTML, Javascript and CSS code. CSS was used for changing the appearance of the Javascript tree as well as for dividing the screen into different view. Listing 4.9 shows one CSS file that was used. For instance of the thinkness of the borders needs to be adapted this can be done easily by changing the value in the CSS file. As it can be seen absolut coordinates have been used for implementing the user interface. In order to support a wider range of screen resolutions it would also make sense to dynamically divide the screen into sections.
Listing 4.9: css structure 1 \ label { listing_visu_css } 2 /* --------------------------------------------------| 3 | Nefolog visualization | 4 |----------------------------------------------------| 5 | Copyright (c) 2014 Chen | 6 |---------------------------------------------------- */ 7 8 # Performance { 9 position : absolute ; 10 top :130 px ; 11 left :800 px ; 12 width :420 px ; 13 padding :10 px ;
30 Improving and Updating the Nefolog system
4 Implementation 14 margin :0 px ; 15 border :7 px solid #0000 EE ; 16 }
In order to do calculations different parameters are necessary for different configurations. To know these parameters it takes one request to the Nefolog system with the configuration ID as parameter. The Nefolog system is then returning the possible parameters for this configuration. Since later this parameter list is also needed for other purposes the result of the query is stored in a list called parameters.
Listing 4.10: Dynamical building of the input form for the calculator 1
|