a front end architecture for - Åbo...
TRANSCRIPT
A Front-end Architecture for
Video Transcoding in Cloud
Junaid Iqbal
Master of Science ThesisSupervisors: Prof. Johan Lilius, Dr. Sébastien Lafond
Embedded Systems LaboratoryDepartment of Information Technologies
Åbo Akademi UniversityApril 2014
Abstract
Cloud computing is a popular technology now a days. Efficiently using cloudresources is an open question that needs to be addressed. As a result ofadopting cloud technology, resources such as data, applications, documentsand even multimedia contents are stored on cloud. Multimedia contents arenow being created and shared more often than few years back. With this gi-gantic increase, researchers are continuously developing algorithms to storeand retrieve multimedia contents on-line. Video transcoding is one of theseon-going research areas which deal with the conversion of different types ofvideo formats, for different device types and over the different networks. Dueto distributed nature of cloud platforms, one might need to control and mon-itor the performance of the deployed algorithms. Towards this goal, this thesispresents a front-end architecture , which can be used to test and monitor de-sired algorithms on cloud platforms. Based on the concept of distributedcomputing, designed front-end architecture is developed by incorporatingWeb services , which in turn provides flexibility, portability, openness andtransparency. The above stated architecture is successfully used to monitorStream-Based Admission Control and Scheduling for Video Transcoding in CloudComputingt as presented in [1].
T
Keywords: Cloud computing, Web services, Vaadin framework, WSDL, Java,Front-end Architecture
i
Abbreviations
ASCII American Standard Code for Information Interchange
COM Component Object Model
EAI Enterprise Application Integration
HTTP Hyper Text Transfer Protocol
IP Internet Protocol
MIME Multi-purpose Internet Mail Extensions
MVC Model View Controller
TCP Transmission Control Protocol
UDP User Datagram Protocol
UDDI Universal Description, Discovery and Integration
URL Universal Resource Locator
XML eXtensible Markup Language
XSD XML Schema Definition
ii
Contents
Abstract i
Abbreviations ii
Contents iii
List of Figures v
1 Introduction 11.1 Problem Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Thesis structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Evaluation of Web Application Frame-works 42.1 Web Application Framework . . . . . . . . . . . . . . . . . . . . 42.2 Java based Web Frameworks Comparison . . . . . . . . . . . . . 72.3 User Interface Requirements . . . . . . . . . . . . . . . . . . . . . 82.4 Communication Model . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Middle-ware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Web Services Architecture 143.1 Web Services Architecture . . . . . . . . . . . . . . . . . . . . . . 143.2 Simple Object Access Protocol (SOAP) . . . . . . . . . . . . . . . 183.3 Web Services Description Language (WSDL) . . . . . . . . . . . 23
4 Front-end Architecture Implementation 254.1 Front-end Architecture . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Frontend Implementation . . . . . . . . . . . . . . . . . . . . . . 38
iii
5 Experiments and Results 505.1 Experimental Set-up . . . . . . . . . . . . . . . . . . . . . . . . . 505.2 Experiments Parameters . . . . . . . . . . . . . . . . . . . . . . . 505.3 Remote Client : Simulator . . . . . . . . . . . . . . . . . . . . . . 545.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6 Conclusion 60
Bibliography 62
Appendices 65
A Class Diagrams 66
B Sequence Diagrams 75
C Source Listing 87
D Front-end API 93
iv
List of Figures
2.1 Framework scores for all features(raw) and average(weighted) [2] 82.2 A Web service allows access to application code using standard
Internet technologies [3]. . . . . . . . . . . . . . . . . . . . . . . . 112.3 Web services provide an abstraction layer between the applica-
tion client and the application code.[3] . . . . . . . . . . . . . . . 112.4 The Principal of Web Service.[4] . . . . . . . . . . . . . . . . . . 12
3.1 Web service internal and external architecture. [5] . . . . . . . . 153.2 Conventional middle-ware as an integration platform for basic
programs and applications [5] . . . . . . . . . . . . . . . . . . . . 163.3 Directory service . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4 XML messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5 The SOAP message structure . . . . . . . . . . . . . . . . . . . . 203.6 SOAP document-sytle interaction . . . . . . . . . . . . . . . . . . 213.7 SOAP RPC-style interaction . . . . . . . . . . . . . . . . . . . . . 223.8 Basic RPC messaging architecture . . . . . . . . . . . . . . . . . 23
4.1 Logical Front-end Architecture . . . . . . . . . . . . . . . . . . . 264.2 Vaadin Application Architecture [6] . . . . . . . . . . . . . . . . 274.3 Vaadin Runtime Architecture [6] . . . . . . . . . . . . . . . . . . 294.4 Typical Tomcat Server Architecture . . . . . . . . . . . . . . . . . 334.5 Apache CXF Architecture [7] . . . . . . . . . . . . . . . . . . . . 344.6 Use case diagram for Front-end Architecture. . . . . . . . . . . . 384.7 Activity Diagram of Front-end Architecture . . . . . . . . . . . . 394.8 Sub Activity diagram for initialising Front-end. . . . . . . . . . 404.9 Main View State diagram . . . . . . . . . . . . . . . . . . . . . . 41
v
4.10 Arrival Pattern View activity diagram . . . . . . . . . . . . . . . 414.11 Typical arrival Pattern loaded in arrival pattern view . . . . . . 424.12 Stream list loaded in Stream List View . . . . . . . . . . . . . . . 434.13 Flow Chat for parameter generations activity . . . . . . . . . . . 444.14 WSDL generated due to end-point publishing on server . . . . 454.15 A typical Vaadin Timeline consists of main area and Browser
part at the bottom. . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1 Arrival Pattern 1: Relatively Normal Load with Low Arrival Rate 525.2 Arrival Pattern 2: Relatively Normal Load with High Arrival
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.3 Arrival Pattern 3: Highly Variable Load with Low Arrival Rate 545.4 Arrival Pattern 4: Highly Variable Load with High Arrival Rate 545.5 Simulation Results : Relatively Normal Load with Low Arrival
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.6 Simulation Results : Relatively Normal Load with High Arrival
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.7 Simulation Results : Highly Variable Load with Low Arrival Rate 575.8 Simulation Results : Highly Variable Load with High Arrival
Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.1 Context Level Class Diagram . . . . . . . . . . . . . . . . . . . . 67A.2 Front-end Main Class- UI-Milestone1 Diagram . . . . . . . . . . 68A.3 Main View Class Diagram . . . . . . . . . . . . . . . . . . . . . . 69A.4 User Pattern View Class Diagram . . . . . . . . . . . . . . . . . 70A.5 RequesFileView Class Diagram . . . . . . . . . . . . . . . . . . . 71A.6 OptionView Class Diagram . . . . . . . . . . . . . . . . . . . . . 72A.7 Time Line View Class Diagram . . . . . . . . . . . . . . . . . . . 73A.8 Web services Class Diagram . . . . . . . . . . . . . . . . . . . . . 74
B.1 Sequence diagram: UI_milestone1UI . . . . . . . . . . . . . . . . 76B.2 Sequence Diagram : MainView . . . . . . . . . . . . . . . . . . . 77B.3 Sequence Diagram: UI-MileStone1 Initialisation . . . . . . . . . 78B.4 Sequence diagram : Main View . . . . . . . . . . . . . . . . . . . 79B.5 User Pattern View Sequence Diagram . . . . . . . . . . . . . . . 80B.6 Sequence diagram: Request file view . . . . . . . . . . . . . . . 81
vi
B.7 Sequence diagram: Option View . . . . . . . . . . . . . . . . . . 82B.8 Sequence diagram : Time line View . . . . . . . . . . . . . . . . 83B.9 Sequence diagram : Web Service Broker . . . . . . . . . . . . . . 84B.10 Sequence diagram : Web Service Implementation Create Time
Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85B.11 Sequence diagram : Web Service Implementation . . . . . . . . 86
vii
Chapter 1
Introduction
In post 2000 era, Cloud computing emerged as one of the most promisingtechnologies which changed the computing paradigm. Software as Service(SaaS), Platform as Service (PaaS), Infrastructure as a service (IaaS), Hard-ware as a Service (HaaS) and Every-thing as Service (EaaS) are associatedwith Cloud computing. The On-demand self-service characteristic, allowsusers to obtain, configure and deploy cloud services themselves using cloudservice catalogues, without requiring any technical assistance [8].
The ability to automatically add or subtract computing resources commen-surate with demand made cloud technology, a suitable candidate for runningon demand-video transcoding. To implement cost efficient on demand cloudbased video transcoding, many researchers and organisations are investigat-ing various methods and techniques.
The Embedded System Lab at Åbo Akademi University was an active part-ner in "The Cloud Software Program", funded by TEKES and coordinated byDIGILE Oy. The aim of this program was to improve the competitive positionof the Finnish software intensive industry in the global market. The active
1
research areas of above mentioned project was to develop a suitable cloudsoftware services and to develop a scalable distributed video transcoding oncloud platform.[9].
1.1 Problem Overview
Due to heavy computational requirements, video processing applications re-quire lots of power. Numerous efforts are made to increase the efficiency ofsuch applications by applying different techniques.
The Video transcoding of a large number of video streams requires a largescale cluster-based distributed system. Moreover, to handle varying amountsof load in a cost-efficient manner, the cluster should be dynamically scalable.Cloud computing can provide resources to deploy new applications in a se-cure, reliable and scalable manner. The main objective of this thesis work isto design and implement a front-end architecture for distributed transcodingapplications on cloud platform. This architecture will be able to run exper-iments based on the developed distributed transcoding platform. The pro-posed front-end architecture provides the following features:
• Ways to define different transcoding parameters
• Ways to define a set of data used as input
• Ways to define experiment/demonstration parameters
• Ways to collect statics about the system states
In this thesis we will develop a front-end architecture (possibly a scalabledistributed architecture) by using existing technologies and verify its imple-mentation for monitoring and controlling video transcoding in a cloud plat-form.
2
1.2 Thesis structure
The thesis is divided into two parts. The first part presents available tech-nologies and approaches to develop distributed application and presents anevaluation of Web application frameworks. The second part describes theimplementation based on the selected technologies and approaches.
• Chapter 1: Explains the problems that are the basis of this thesis workand also explains the challenges that need to be addressed. In addition,a short introduction of the research area is given in a more abstract waysuch that readers are introduced to the work done and its relevance.
• Chapter 2 and Chapter 3: Explains the basic principles related to the Webapplications and Web Service architecture. These theories and principlesare then used as basic building blocks of the thesis work.
• Chapter 4: Presents the details of the implementation and approach usedto develop the Front-end Architecture. Details of the actual implementa-tion and used platforms are discussed. In addition, the general architec-ture of the system is explained along with the detailed class descriptions,class diagrams, sequence diagrams and source code (as needed).
• Chapter 5: Presents tests and experimental results related to evaluate thedeveloped architecture.
• Chapter 6: Concludes the document through mentioning the most im-portant findings of the work and a recommendation on further futurework.
• Appendix: Contains class diagrams, sequence diagrams and source codelisting. An API reference is also a part of appendix for future use.
3
Chapter 2
Evaluation of Web Application Frame-works
In the beginning of this chapter, we briefly introduce the notion of Web ap-plication framework. It is also useful to discuss about some Java based webapplication frameworks and features, which will influence the decision of se-lection of an appropriate framework for developing proposed architecture.Later in this chapter, we will also discuss about the user requirements andtheir impact on selection of framework. At the end of this chapter, we willdiscuss about the communication model and middle-ware support offered bydifferent frameworks.
2.1 Web Application Framework
According to [10] "a web application framework is a type of framework, or found-ation, specifically designed to help developers build web applications. These frame-works typically provide core functionality common to most web applications, such asdata persistence, user session management and user authentication, security, caching,template systems and administrative interface. By using an appropriate framework,
4
a developer can often save a significant amount of time building a web site". Webapplication frameworks also provide advance features which are difficult andtime consuming to an average developer to re-implement. In the followingpart of this section, we will briefly discuss the core-features as mentioned by[10].
Data Persistence
As described by [11] "Persistence-the ability of data to outlive an instance of a pro-gram is central to modern applications". Unlike static pages, almost all modernweb applications are generated from persistence data. Every Web applicationhas its own requirements of data and structure to persist. A web applicationframework must provide such a feature which is transparent or at least easyto implement [10].
Session Management and User Authentication
Session management is the process used to track and maintain users’ activit-ies during their interaction with a computer. It identifies the user’s identity,manages login process, and tracks the activity across sessions [12]. Web ap-plication framework provides user level authentication and session manage-ment but application specific logic needs to be built on top of it [10].
Security
Some applications require that resources can only be accessible and visibleto authenticated users. Typically, the framework can automatically check therequired authentication before giving access to any resources. In additionto authentication requirements, the framework can also provides role-based-access [10]. These features are handled by developer based upon applicationrequirements.
Caching
To improve Web application performance, Web developers will often cachecertain contents so it does not need to be regenerated on each page request.
5
Frameworks can offer a common interface to disk or database storage ofcached contents [10].
Templating
Templates provide a basic design for a Web page. A Web page templateincludes components that are commons on several pages [13]. Web pagetemplate keeps business logic separate from presentation. As written by [10]"a framework may provide one or more templating systems or engines with consistentinterfaces for developers. Most often the framework will make available developer-defined fields or data structures available within templates (i.e. push). Converselya templating system may request data back through the framework (i.e. pull). Thetemplating system may be something as simple as keyword replacement or may berobust enough to automatically generate content such as form fields from parameters".
Administrative Interface
It is very common for dynamic web sites to need a section specifically built forsite administrators. Here the site can be configured and data can be altered.Administrators might create user accounts, manage permissions, change pagecontents, generate reports, or anything else as required [10]. Web applicationframeworks administrative interface can perform tasks such as:
• Define navigation structure.
• Provide common interface such as a date format, pop-up calendar, cur-rency symbol, language etc.
• Automatic generation of Web pages from persistent data structures.
The act of designing and implementing a complete Web application can bea complex task. Without a few clear goals, development can easily get boggeddown with inconsistencies and code bloat [10].
6
2.2 Java based Web Frameworks Comparison
In this section, we will present a feature-to-feature comparison between somepopular Java based Web application frameworks. This comparison will helpus to select a Web application framework to implement Front-end architec-ture. This comparison is presented in [2].
Top 8 Java Based Web Frameworks
According to [2], eight popular Java Web Frameworks are namely, SpringMVC, Grails, Vaadin, Google Web Toolkit(GWT), Apache Wicket, Play, Strutsand JSF. To benchmark their performance, a set of application types wereselected as follows:
• CRUD (Create, Read, Update, Delete) application.
• e-Commerce application.
• Video/streaming application.
• Desktop application port.
• Mobile application.
• Multi-user application.
• Some Prototype application.
After the selection of real-world scenarios, the following indicators wereused to evaluate above stated Web frameworks.
• Rapid Application development.
• Framework Complexity
• Ease of use.
• Documentation and community.
• Framework echo system.
7
• Throughput / Scalability.
• Code maintenance/ updates.
• User-Interface / Look and Feel.
• Testability.
• Security.
Based on the above indicators, Figure 2.1 shows that Vaadin stands outfor its performance, user-interface/look and feel, ease of use, less frameworkcomplexity and rapid application development.
Spring Grails Vaadin GWT Wicket Play Struts JSF
30
32
34
36
38
40
42
44
35
4241.5
36.5
35.5
40
29.5
3635.6
41.7
43.3
37.337.8
40.5
30.2
36.8
Features(raw scorces)Averages
Figure 2.1: Framework scores for all features(raw) and average(weighted)[2]
2.3 User Interface Requirements
The user interface layout and functionalities we intend to design are based onthe following requirements:
8
• Ways to define different transcoding parameters
• Ways to define a set of data used as input
• Ways to define experiment/demonstration parameters
• Ways to collect statics about the system states
To define different transcoding parameters, user must be able to upload alist of streams, which contains all parameters needed to run a simulation orreal environment. The list of streams will act as a set of input data required bythe simulator or the real environment. The simulator or real environment thendecide which parameters are required to collect statics and will be sent backto the front-end. Finally, the front-end will collect these statics and representthem visually in a graphical manner on time line.
2.4 Communication Model
To understand the communication model used in this thesis, it is essential tounderstand the socket communication and web services model. In this sectionwe will briefly discuss both communication models.
Socket Communication
According to Tanenbaum et al. [4] "Conceptually, a socket is a communicationend point to which an application can write data that are to be sent out over theunderlying network, and from which incoming data can be read. A socket forms anabstraction over the actual communication end point that is used by the local operat-ing system for a specific transport protocol". The use of raw sockets gives us thebenefit of being able to control of our own protocol format (how our messagedata is structured). Due to this over control we can secure our messages, makecommunication faster and more robust. All that control comes at the cost ofcomplexity and maintenance and usually requires lot of debugging and extracode. Another downside of sockets communication is a higher probability ofbeing blocked by firewalls.
Moreover, here are few drawbacks indicated by Tim Jones [14]:
9
• Ignoring return Status: Socket return status are indicator of success-ful, partially successful or failed. Keep track of each and every socketoperation is a tiresome job.
• Peer socket closure: Some functions in Socket API can produce peersocket closure indicator falsely while the user never intended to closethe communication.
• Address in use: This problem commonly associated with bind proced-ure. When it attempts to associate a name with the port which is alreadyin use. The pitfall is that no active socket may exist, but binding to theport is still disallowed, which is caused by the TCP socket TIME_WAITstate. This state keeps a socket around for two to four minutes after itsclosure. After the TIME_WAIT state has exited, the socket is removed,and the address can be rebound without issue [14].
• Sending structured data: Sockets are perfect for sending binary un-structured data or ASCII streams. Representing binary data over socketcauses wrong interpretation of data which in turn causes the value to beinterpreted incorrectly.
• Framing assumptions: TCP is a stream based protocol which assumesthat the data being communicated is unstructured. However, User Da-tagram Protocol (UDP) is a message oriented protocol which preservesthe boundary of the messages between the sender and the receiver.
Web Services
A Web service is a network accessible interface to application functionalities,built using standard Internet technologies [3].
10
NetworkWeb service
Application Servers Users
Figure 2.2: A Web service allows access to application code using standardInternet technologies [3].
As shown in Figure 2.2, Web service acts like an interface between theapplication code and the user of that code. It acts like an abstraction and hidesall implementation details of application logic by providing a neat interface.The application functionalities can be accessed by this interface.
Platform and language specific communication
Platform and language specific communication
Application code Application client
Web service
Figure 2.3: Web services provide an abstraction layer between the applic-ation client and the application code.[3]
Figure 2.3 illustrates the Web service abstraction, which provides interop-erability and flexibility. Clients from different platforms can be integratedwith less configuration.
11
Communication Subsystem
Client application
Client Stub
Communication Subsystem
Server application
Server Stub
Service description (WSDL)
Generated stub from WSDL description Generated stub from WSDL
description
Publish service
Look up service
SOAP
Figure 2.4: The Principal of Web Service.[4]
The basic principal behind a Web service is very simple as shown in Figure2.4. Some clients can use the services provided by application server. Stand-ardization is enforced by an Interface Description Language (IDL), in Webservice case it is the Web Service Description Language (WSDL). The mainrequirement is that service call proceeds along the rules set by the serverapplication. This principle closely resembles a remote procedure call (RPC).
2.5 Middle-ware
Gustavo el at. [5] suggested that "Middle-ware offers programming abstractionsthat hide some of the complexities of building a distributed application. Instead ofthe programmer having to deal with every aspect of a distributed application, it isthe middle-ware that takes care of some of them. Through these programming ab-stractions, the developer has access to functionality that otherwise would have to beimplemented from scratch" [7].
Middle-ware provides an abstraction to complex, large foot print and in-creasing programming infrastructure. This complex infrastructure can bebased on different technologies namely Remote Procedure Calls (RPC), Trans-action Processing (TP), Object Broker (OMG), Message-oriented Middle-ware(MoM).
12
Remote Procedure Call (RPC)
RPC is a basic and transparent infrastructure which converts procedure callsto remote procedure calls. SOAP, presented in more details in the follow-ing sections, uses RPC calls wrapped in XML messages to interact with Webservice over HTTP or some other transport protocol [7].
Transaction Processing
The oldest middle-ware are based on Transaction Processing Systems (TPS).These have been used for many years in enterprise level applications andknown for their reliability . Transaction Processing systems can be seen asRPC with transaction processing capabilities [7].
Object Broker
Object Broker were used to facilitate Object Oriented languages. These plat-forms are more advanced in their specifications. The underlying mechanismuses RPC to implement remote procedure calls. The most popular class ofobject broker is the Common Object Request Broker Architecture (CORBA)by Object Management Group (OMG) [7] and Microsoft (D)COM [15].
Message-oriented Middle-ware
Message-oriented Middle-ware is a software or hardware infrastructure whichsupports sending and receiving messages between distributed systems. Themiddle-ware creates a distributed communication layer which hides imple-mentation details of the various operating system and network interfaces.The reason behind using message-based communication protocol is its abilityto store, route and transform messages while conveying them from sendersand receivers [16]. However, using MoM requires an extra component (mes-sage broker), which can lead to reduction in performance, reliability and moreefforts to maintain the system [16].
13
Chapter 3
Web Services Architecture
A Web service is a standard-based, language-agnostic software entity thataccepts specially formatted requests from the software entities on remote ma-chines via vendor and transport neutral communication protocols and pro-duce application specific responses. These Web services exists independentlyand can be modified without affecting the others entities. The Web serviceprovides easy access to organisation data and enable easier communicationwithin or across the organisation [17].
In the beginning of this chapter, we briefly discuss the notion of Web ser-vices architecture and their characteristics. In section two, we briefly discussSimple Object Access Protocol (SOAP) with respect to thesis. In section three,a brief introduction of Web Service Description Language is presented.
3.1 Web Services Architecture
The term Web service has been used for many years. There are many defini-tions used to describe a Web service. In layman terminology, Web service isan application to be accessible to other application over the Web [18]. Thisdefinition is very open. It appears that anything which has URL is a Web
14
service. David et al. [15] wrote "A Web service is a piece of business logic, locatedsomewhere on the Internet, that is accessible through standard-based Internet proto-cols such as HTTP or SMTP. Using a web service could be as simple as logging intoa site or as complex as facilitating a multi-organization business negotiation".
As Figure 3.1 shows, the Web service architecture is composed of twocomponents. First, exposure of internal options over Web, so that these canbe called remotely. This can be referred to as internal middle-ware. The secondis to use external Middle-ware.
Internal architecture
Internal service Internal service
middleware
Webservice Interface
Access to Internal systems
Web service Web service
Web service
Web service
Web service
External architecture
Client
Figure 3.1: Web service internal and external architecture. [5]
Internal Architecture of a Web service
The term Enterprise Application Integration (EAI) platform is used to referspecifically to software systems that facilitate the integration of heterogen-eous, coarse-grained applications [5]. In EAI, the middle-ware is used tobuild the multi-tier architecture. By using functionalities provided by middle-ware, the complexity of the underlying system is hidden and combined intohigher order applications, which in turn is hidden under the new service ab-
15
stractions. As shown in Figure 3.2, these abstractions of Web service act asbuilding blocks for new Web service and might be repeated many times tomake a multi-tier system.
Resource manager Resource manager
middleware
Service interface
Integration logic
Resource manager Resource manager
middleware
Service interface
Integration logic
middleware
Service interface
Integration logic
Other tiers
Figure 3.2: Conventional middle-ware as an integration platform for basicprograms and applications [5]
Web services act as a conventional middle-ware on a large scale. Theinternals of a Web services consist of message format converters (packaging)between Web service and a middle-ware. This additional format conversioncauses overhead in processing the messages. This is the primary reason touse Web services for course-grained operations, where overhead caused bythe conversion is smaller than operation execution time [5].
16
External Architecture of a Web service
To implement the internal architecture of a Web service, it is a natural choiceto opt middle-ware. In case of external architecture, the location of middle-ware is not clear. In Local Area Network (LAN) based systems, middle-wareand application run next to each other. It is easy for the middle-ware toprovide the necessary brokerage and services. In case of distributed envir-onment where application units reside on different places, the location of themiddle-ware is a question to be answered.
There are two popular solutions to answer the question. First, middle-wareimplementation as a peer-to-peer system, where all units agree to provideservices. Second solution is to implement intermediary or broker acting likea middle-ware [5]. Currently only one type of Web service broker has beenstandardised providing name and directory services.
Client Procedure call
Client stub:Bind
MarshalSerialize2. find5. send
Communication module
Server procedure
Server stub:0. registerUnmarshalDeserialise7. receive
Dispatcher (select stub)
Communication module
Name and directory service (binder)
6. Invoke procedure3. Query for server implementing
The procedure
1. Register server and procedure
Server ProcessClient Process
Figure 3.3: Directory service
Figure 3.3 shows the idea how directory service takes place in Web Ser-vice environment. A Service provider creates a Web service, generates servicedescriptions and defines an interface to invoking those services. The next stepis to publish the corresponding service description in a service directory. Whena service request is trying to find a service, it queries the service registry. Ser-vice registry provides details where to find the service and how to invoke it.
17
The service requester then bind to service provider and invoke the service [5].
3.2 Simple Object Access Protocol (SOAP)
Simple Object Access Protocol (SOAP) is a standardised packaging protocol asdiscussed in section 3.1. The specification defines a XML-based envelope forthe information being transferred, and a set of rules to translate applicationand platform-specific data types into XML representations. SOAP’s designmakes it suitable for a wide variety of application messaging and integrationpatterns [3].
SOAP is based on XML messaging. Because XML is not associated with aparticular operating system or programming language, it provides a flexibleway to communicate and exchange information using XML documents.
Application XML Message Application
Figure 3.4: XML messaging
Figure 3.4 shows the fundamental idea that how two applications, regard-less of operating system, programming language, or any other technical im-plementation detail, may openly share information using nothing more thana simple message encoded in a way that both applications understand. SOAPprovides a standard way to structure XML messages [3]. SOAP is a statelessand one-way communication protocol. It ignores the semantics of the mes-sages being exchanged through it. SOAP defines how to organize informa-tion using XML in a structured and typed manner so that it can be exchanged
18
between peers.Gustavo et al. [5] describes SOAP specification as :
• A message format for one-way communication, describing how information canbe packaged into an XML document.
• A set of conventions for using SOAP messages to implement the RPC interac-tion pattern, defining how clients can invoke a remote procedure by sending aSOAP message and how services can reply by sending another SOAP messageback to the caller.
• A set of rules that any entity that processes a SOAP message must follow, defin-ing in particular the XML elements that an entity should read and understand,as well as the actions these entities should take if they do not understand thecontent.
• A description of how a SOAP message should be transported on top of HTTPand SMTP. Bindings to other transport protocols will probably be defined infuture versions of the specification.
The key feature of SOAP is its accessibility and all conversation to carryout via binding to a lower level protocol, the underlying protocol likely HTMLor SMTP. It is also possible to create SOAP binding for almost any protocol,however currently HTTP is the de facto standard. [15]
3.2.1 SOAP Structure
It is essential to understand the SOAP message structure in order to clarify itsinternals and functionalities.
19
SOAP Messages
Header Block
SOAP Header
Header Block
SOAP Body
Message Body
Figure 3.5: The SOAP message structure
A SOAP message consists of an envelope containing an optional header anda required body, as shown in Figure 3.5 [5, 3]. SOAP assumes that everymessage has a sender, an ultimate receiver, and an arbitrary number of inter-mediaries (called nodes) that process the message and route it to the receiver[5].
20
SOAP Envelope
SOAP body
Document (message contents)
SOAP Envelope
SOAP body
Acknowledgement
Figure 3.6: SOAP document-sytle interaction
The information sender wants to send, is contained in the body of the mes-sage. Any intermediate and value services are enclosed into its header. Thebasic requirement for a SOAP message is to have a header and a body. Thereare two ways to construct header and body of a SOAP message : interactionstyle and encoding rules. Generally, SOAP is used in two interaction styles :doc-ument style and RPC-style. In document-style interaction, as shown in Figure3.6, both applications must agree upon the structure of documents exchangedbetween them. SOAP messages are used to transport these documents fromone application to the other [5].
21
SOAP envelope
SOAP body
Method name
Input parameter 1
Input parameter 2
SOAP envelope
SOAP body
Method return
Return value
Figure 3.7: SOAP RPC-style interaction
In RPC-style interaction, as shown in Figure 3.7, one SOAP message en-capsulates the request while another message encapsulates the response, justas in document-style interaction. However, these are constructed differently.The body of the request message contains the actual call, which includes in-voked procedure name and input parameters. The body of the response mes-sage contains the result and output parameters. Thus, the two interactingapplications have to agree upon the RPC method signature as opposed to thedocument structures. The task of translating the method signature in SOAPmessages is typically hidden by the SOAP middle-ware [5].
The structure of a SOAP message is based on encoding rules, which definehow a data structure is represented in XML. In order to successfully interop-erate, both client and sever must agree on how the content of SOAP messagesare encoded. These rules define how data structure including basic data typessuch as integers, strings and complex data types are serialised into XML [5].
SOAP over HTTP
Due to pervasive use of HTTP over internet, HTTP is the most common trans-port mode used for SOAP messages. Because HTTP is a request-responsemodel, it works perfectly with SOAP’s RPC-style.
22
SOAP ServerSOAP Client
Request message
Response messages
Figure 3.8: Basic RPC messaging architecture
Figure 3.8 shows how SOAP request messages posted with HTTP-requestand HTTP-response contain SOAP response message.
3.3 Web Services Description Language (WSDL)
In section 3.2.1, we briefly discussed the structure of SOAP message. To im-plement SOAP messaging format, Web Service Description Language (WSDL)was introduced.
David el at. [15] describes WSDL as an XML grammar for describing aweb service as a collection of access endpoints, capable of exchanging mes-sages in a procedure or document-oriented fashion. A WSDL document is arecipe used to automate the details involved in an application-to-applicationcommunication. WC3 [19] defines WSDL as a document, which define ser-vices as a collection of network end-points or ports. WSDL document usesthe following elements to define the network services.
• Types: a container for data type definitions using some type system(such as XSD).
• Message: an abstract, typed definition of the data being communicated.
• Operation: an abstract description of an action supported by the service.
• Port Type: an abstract set of operations supported by one or more end-points.
• Binding: a concrete protocol and data format specification for a partic-ular port type.
23
• Port: a single endpoint defined as a combination of a binding and anetwork address.
• Service: a collection of related endpoints.
A WSDL document contains only abstractions: it is just the definitionof the parameters and constraints for how the communication should occurat runtime. The Web service implementation has to follow the guidelinesdefined in the WSDL document. The WSDL also provides the ability to definea binding that attaches an abstract set of message definitions to a concreteprotocol or data format. A binding-extension is a type of binding defined fora major protocol. The WSDL defines out-of-the-box binding extensions forSOAP 1.1, HTTP GET, HTTP POST, and MIME [15].
24
Chapter 4
Front-end Architecture Implementa-tion
The major goal of this thesis is to implement a front-end architecture whichis able to control and monitor the remote systems. To achieve this objective,we have designed and implemented a front-end architecture which providesflexibility and transparency. The Implementation of the front-end architectureutilises the Web Service and SOAP client approach. The front-end implementsall functionalities to control and monitor the system. It is also responsible topublish Web services and provide data to client and real system to performits functions. In order to test front-end functionalities, a test case is needed.Video Transcoding on cloud, discussed in following text, is selected as a testcase. Video Transcoding test case consist on two different clients. First is thesimulator and second is the real transcoding system. Both of these clientsreceives parameter from the front-end, processes the requests and posts theout put to front-end by using Web service. By using web services we achieveflexibility and transparency to place our front-end architecture without anyphysical limitations.
25
GUI
Application
Middleware
Web Services
Parameter Generator
Network / Internet
Server Stub
Client
Client stub
SOA
P messages
SOA
P m
essa
ges
Figure 4.1: Logical Front-end Architecture
Figure 4.1 illustrates the abstract logical structure of the developed Front-end architecture for video transcoding. Video Transcoding refers to a processwhich decode a video stream and then re-encode it with desired parameters.These parameters include frame-rate, height and width, codecs, bit-rate etc.Due to extensive computation requirements, Video Transcoding is currentlyan active area of research.
The Front-end acts as an interface to control and monitor a distributedvideo transcoding application on simulator or in real environment. In orderto achieve proper functioning, the simulator requires a list of streams, streamarrival pattern. List of stream consist of stream information such as codecs,height and width, number of I, B and P frames, bit-rate, output codecs, outputwidth and height and desired bit-rate. Arrival pattern consist of number ofconcurrent request at a particular instance of time. After receiving streamslist, arrival pattern from user, front-end generates a streams request data file.This data file is then transferred to the client via the middle-ware and Webservice. However, the client stub is responsible to receive and parse the datafile. After extracting the required parameters, client starts processing them.Real measurements are sent as SOAP-RPC to front-end to log and display
26
results. The following section provides more details about the platform andtools used to implement the front-end architecture.
4.1 Front-end Architecture
In this section, we will discuss about the internal structure of the front-endarchitecture. Figure 4.1 shows the major components of the front-end archi-tecture. In the following subsections, we will discuss each part individuallyand present the inside details. To implement the front-end architecture weselected different tools and platforms for different functionalities.
4.1.1 GUI : Vaadin
Vaadin is an open source server-side Web application framework for rich In-ternet applications. Ajax technology is used at the browser-side to ensurea rich and interactive user experience [6]. The server-side application archi-tecture has two major parts namely server-side framework and a client-sideengine. The client side based on JavaScript code usually runs in a browser.It renders the user interface, and interact between the user and the server.The logic behind the User Interface (UI) runs on a Java application server asa Servlet. Vaadin enable the development of Rich Internet Application (RIA).RIA application runs on thin clients (i.e Web browsers) and are as responsiveand interactive as desktop applications. To make Vaadin an RIA applicationplatform, AJAX (Asynchronous JavaScript and XML) is used at the best level.Developer can develop user interface logic and appearance separately.
Figure 4.2: Vaadin Application Architecture [6]
27
Following are the important features of Vaadin presented in [20]:
• Vaadin is based on Java. All coding is done solely in Java. There isno need to learn a different technologies besides Java and Vaadin’s ownApplication Programming Interface (API).
• There is no need to install any plug-in on the user browser. It providesthe same look and feel on all browser.
• The user interface (UI) components are developed using object-orientedapproach.
• No need to maintain Javascript.
• It conforms to standards defined for Hyper Text Markup Language(HTML) and Cascading Style Sheets (CSS).
• Usually supports Mobile devices, perhaps applications are not intendedto be designed for mobile devices.
Vaadin Runtime architecture
Figure 4.3 illustrates Vaadin runtime architecture. A Vaadin applicationruns on a Java Web server /application server (e.g. Tomcat, Jboss, ApacheGlassfish). The client connects to Web server /application server and sendHTTP request. These requests are forwarded to Vaadin servlet, which in-terprets them as an event for a particular session. All the events which areassociated with User interface (UI) are sent to their related Event listeners. Inresponse, if the server makes some changes to the UI then the servlet rendersthem to web browser. The client side part of the engine receives these updatesand refreshes the Web page as required [6].
28
Figure 4.3: Vaadin Runtime Architecture [6]
The major parts of Vaadin runtime as listed in [6] are as follows:
User Interface (UI): The user interface is an essential part of Vaadin applic-ations. It provides access to interact with the business logic and the data ofthe application.
User Interface Components / Widgets: Each Vaadin User Interface (UI) con-sist of components and widgets. These components laid out by application.Each server side component has it’s counterpart widgets. These widgets arerendered by the browser. Widgets are the basic elements in the user interfacethrough which user interact with user interface [6].
Client-Side Engine: The basic purpose of the Client-side engine is to com-municate between widgets and server-side components. It updates server-side components in response to the user interaction with widgets and viceversa [6].
29
Vaadin Servlet: Vaadin servlet is a wrapper over the Java servlet API. It isresponsible to maintain the session information with the help of cookies. Itdelegates the requests to their corresponding sessions [6].
Themes: Separation of appearance and structure of the components is oneof the Vaadin’s core feature. All the application logic which is required to runan application is handled in Java. However, all presentation logic is definedin Cascading Style Sheets (CSS). Developer is able to change one withoutaffecting the other [6].
Events: When user interacts with the widgets, it creates events. These eventsare first processed on client-side and then transferred to the componentsat server via HTTP server. The application executes corresponding event-listeners and send back the response in the same way to Web browser toupdate the User Interface [6].
Server Push: Vaadin application framework supports server push. Serverpush is defined as "a mechanism for sending unsolicited (asynchronous) data froma web server to a web browser"[21]. Server push makes it possible to changethe User Interface without client request. These changes can be triggeredeither by some internal events or by the other users, interacting with the sameapplication [6].
Data Binding: All field level components such as text fields, check boxesand selection components (combo box, list box, radio buttons etc.) can bedirectly bound to the application data. There is no explicit need to write codeto handle the data form these components [6].
Client-Side Application: Client-side applications use the same widgets, themesand back-end as the server-side Vaadin applications. These are intended forhighly responsive logic required in on-line games or with huge number ofclients [6].
Back-end: Vaadin is built for the User Interface design and it is recommen-ded that User interface should be kept separate. However, both application
30
logic and the user interface can run on the same machine. They are usuallyseparated by the Java API [6].
4.1.2 Front-end middle-ware
In this front-end implementation, the internal middle-ware architecture con-sists of a Web server, servlet container and the Web service framework. ApacheTomcat is used as Web server and servlet container. The Apache CXF is usedfor the Web service framework. In following text, a brief discussion on thesetechnologies is presented.
Apache Tomcat Server:
Java platform is a de facto standard for developing server-side Java applica-tions. Java Enterprise Edition (Java EE) extends Java platform to support theWeb services, enterprise component model, management APIs and commu-nication protocols [22].
Occasionally, the decision to select whether to use an application serveror a Web server depends on application requirements, communication needs.Hanson[22] describes a Java enterprise application as combination of follow-ing technologies and components:
• Enterprise Archive(EAR) files
• Java Servlets
• Java Server Pages (JSP) or Java Server Faces
• Enterprise Java Beans (EJB)
• Java Authentication and Authorisation Service (JAAS)
• J2EE Connector Architecture
• Java Beans Activation Framework (JAF)
• Java Mail
• Java Message Service (JMS)
31
• Java Persistence API (JPA)
• Java Transaction API (JTA)
• Java Management Extensions (JMX) API
• Java API for XML-based RPC (JAX-RPC)
• Java API for XML processing (JAXP)
• Java Architecture for XML Binding (JABX)
• SOAP with Attachments API for Java (SAAJ)
• Java Database Connectivity (JDBC).
However, Java Web application is a subset of Java enterprise applicationcomponents namely, WAR files, Java Servlets, Java Server Faces or Java ServerPages and Java Database Connectivity (JDBC) [22].
32
Servlet Container
Request Dispatcher
Application Flow Processer
View Manager
Server Facade
HTML Client
Web Service Client
Request
Responce
Request
Response
Figure 4.4: Typical Tomcat Server Architecture
As a Web server, as shown in Figure 4.4, Tomcat can be used with any com-bination to meet application requirements. As a result, Apache Tomcat can beused as an application server for less complex Web application. Using Tomcatas an application server is a popular approach due to ease of use and supportfor many Java EE application features. Additionally Tomcat 7 supports JavaSpecification Request (JSR) 109 , which is used to resolve the Web service ref-erences. Runtime performance of Tomcat server over other competitors makeit a favourite choice for light-weight Web application development.
Apache CXF
Apache CXF is an open-source Web service framework. CXF is commonlyused for Java API, XML Web services, SOAP, WSDL, Message Transmission
33
Optimization Mechanism (MOTM), Web service reliable messaging, Web ser-vice secure-conversion and web service security [23, 7]. Figure 4.5 illustrateoverall architecture of Apache CXF.
Bus
Messaging and
Interceptors
Service Model
Protocol Binding
Front-ends
Transport Data Binding
Figure 4.5: Apache CXF Architecture [7]
Bus: The bus is the core component of Apache CXF architecture. The CXFbus is consist of a configuration file. This configuration file is loaded whenservlet engine initialises. It defines common setting for all end-points. Italso connects all runtime infrastructure and provides a common applicationcontext [7].
Front-end: CXF facilitates front-end APIs to create the Web services. Theseservices also provide a way to create the dynamic Web service clients.
JAX-WS: JAX-WS is a part of CXF front-end. It is based on Java-basedAPIs and simplifies Web service development and deployment. It complieswith the Web service Basic Profile 1.1 which deals with language and plat-
34
form independently. Some other prominent features of CXF front-end areJava Architecture for XML Binding (JAXB) and SOAP with Attachment API forJava (SAAJ).
JAXB supports developers to map the Java classes to XML representation.JABX allows storing and retrieving memory object in an XML format. Con-verting Java objects into XML and XML to Java objects is known as marshallingand un-marshalling. This marshalling and un-marshalling gives user freedomto convert the Java object to XML and vice-versa without implementing thecomplex XML loading and saving routines [24].
SAAJ provides an easy and simple way to construct SOAP messages withoutwriting XML. The core functionality of SAAJ is to manipulate and send SOAPmessages from one entity to another entity. It also facilitates a reliable deliv-ery of message which triggers SOAP messages to construct in a special way[25]. SOAP message created with SAAJ may include one or more attachmentparts. These attachment parts can contain any portion of data along withMIME header. The MIME header provides details about the type of data itcontains [26].
Service Endpoint Interface To expose Java Objects to be used as Web ser-vice, these Java objects are annotated with @WebService. This annotation ex-poses all abstract methods to the clients. These exposed methods are referredto Service Endpoint Interface (SEI) [27].
Web Service Development Approaches: JAX-WS supports two Web servicedevelopment approaches. Code-first approach and Contract-first approach [7]. Incode-first approach, the Java classes and interfaces are developed first andthen annotated as web service. This approach is useful when Java imple-mentation are already available and only need to be exposed as Web service.Contract-first approach is useful when developers are sure about the inter-face and methods to expose. A WSDL contract, as discussed in section 3.3is written first and later used to generate the Java classes to implement the
35
contract. Different elements in WSDL contract can be directly mapped to theJava classes. For instance, wsdl:portType element is directly mapped to SEIand wsdl:service is mapped to a Java class, which is used by the client toaccess Web service [7].
The WSDL2Java tool can be used to generate Java classes from the existingWSDL. These classes serves as a client and the server stub. In addition, thesestubs also provide the data types to implement client-side stub and server-side Java classes for the Web services [28].
Messaging and Interceptors: The Interceptor components intercept the mes-sages which are passed between Web service clients and server components[7]. When a web service is invoked, an interceptor chain is created and in-voked. Each interceptor can read, transform, process headers and validatethe messages. These interceptors process SOAP header and select appropri-ate operation for it. Creating XML Streamreader, which is responsible to readinput stream for transport. It turns a multi-part/related message into seriesof attachments. [29].
Service Model: The Service Model, models Web service to represent a ser-vice in WSDL-like model. It creates various WSDL elements such as opera-tions, binding, end-points etc [7].
Data Binding: The Mapping between Java objects and XML elements iscalled Data Binding. Data binding is a core to any Web service development.In web services, messages are exchanged in the form of XML. Data bindingprovides a convenient way to transform the Java objects to XML and viceversa. This basic type of binding is supported via JAXB [7]. In order to trans-fer the binary data, SOAP Message Transmission Optimization Mechanism(MTOM) is used. The binary data is then encoded in base64 format [30].Base64 is a group of similar binary-to-text encoding schemes which repres-ent binary data in ASCII string format. This transformation is done by usingradix-64 representation of binary data [31]. The base64 encoded binary databecomes an attachment to XML messages.
36
Protocol Binding: Balani el at. [7] describes Protocol binding as " Protocolbindings are related to port types in WSDL. Port types defines the input and outputparameter in abstract manner. These messages are called logical messages. ProtocolBinding translates these logical binding into actual payload data defined by underly-ing protocol". Apache CXF supports SOAP 1.x, CORBA and Pure XML bindingprotocols.
Transport: The transport protocols are associated with end-points. End-point communicates with the help of transport protocol. These Transportprotocol define the high-level routing to transmit the message over physicalnetwork. Service end-points are physical representation of service interface[7]. Different combinations of binding and transport protocol can be usedto transmit the data. For instance, SOAP can be used as a binding protocoland HTTP can be used as a transport protocol. Apace CXF supports HTTP,CORBA, and JMS as a transport protocol for its end-points.
37
4.2 Frontend Implementation
The implementation of developed front-end architecture is illustrated as acontext level use-case diagram in Figure 4.6. In principal, control systemconsists of many other use-cases namely define/upload arrival pattern, up-loading List of streams, generate database, generate parameters and start ser-vice. Monitoring system interacts between front-end and remote system tovisualise the system activity.
Control System
Define / uploadpattren
Upload Streamlist
GenerateDatbase
GenerateParameter file
<<include>>
Start Service
<<include>>
<<include>>
<<include>>
<<include>>
Monitor System
Front-end User Remote system
Figure 4.6: Use case diagram for Front-end Architecture.
38
Initialise Front-end Environment
Receive arrival pattern
Receive Stream list
Generate database
Generate parameter file
Publish Web services
Receive values from remote system
Update front-end
Transfer parameter file to remote
system
Figure 4.7: Activity Diagram of Front-end Architecture
Figure 4.7 shows the top level activity diagram. Each of these activities arediscussed in details later in this section. In the beginning, front-end environ-ment is initialised with the required components. In next step, user uploadsarrival pattern for streams. List of streams is uploaded after arrival patternwith the required parameters. After successful uploading of arrival patternand list of streams, a database is generated according to the arrival pattern,which contains time-stamp for streams. A parameter file is then generatedfor the remote systems. The Web service, which is responsible to transferthe parameter file to the remote system and receiving updates from remotesystem, is then published. When the remote system is successfully connec-
39
ted with the Web service, a parameter file is transferred to the remote systemto perform either simulation or real transcoding. However, simulator or realtranscoding system starts its operation and update frond-end with values re-quested by front-end user. These values are plotted on a time line graph tovisualise the performance.
Initialise Front-end Environment
The initialising activity consist of many sub-activities as illustrated in Figure4.8.
Initialise Servlet container
Initialise Vaadin UI
Configure O/S related parameters
Initialise Navigator
Figure 4.8: Sub Activity diagram for initialising Front-end.
Front-end user interface is extended from Vaadin UI and configured withannotations. As discussed earlier in subsection 4.1.1, Vaadin is composedof different components which provide functionality to develop the GraphicUser Interface (GUI). Navigator is one of these components which providesnavigation and view management functionality in Vaadin Framework. Everyview managed by Vaadin navigator is identified by distinct URI fragments[6]. These URI fragments can be bookmarked for future use. Each navigatorview represents an activity as illustrated in Figure 4.7.
40
Main View
View
Arrival Pattern
View
Stream List
View
Option View
View
Time Line View
Figure 4.9: Main View State diagram
Figure 4.9 shows state diagram of main view. Listing C.1 shows a codesegment for Main view implementation.
Arrival Pattern
According to Figure 4.7, the next logical activity is Receive stream arrival patternfrom user.
Initialise Arrival Pattern View
Yes
Draw pattern
Upload pattern file
Refresh View
Upload?
Download file
No
Figure 4.10: Arrival Pattern View activity diagram
Figure 4.10 illustrates arrival pattern view activity diagram. Arrival pat-tern is a sequence of numbers of streams arriving at a particular instance of
41
time. Arrival pattern view consists of a Vaadin Chart, Upload and File Down-load add-ons. Vaadin Charts are interactive, feature rich chart library whichprovides one-dimension and two-dimensions visualisation of numeric data.User can interact with theses charts in various ways. This chart library alsoprovides Time Line Chart, which is a specialised chart to visualise time relateddata [6]. The Time line chart will be discussed in section 4.2.2. Figure 4.11shows a typical arrival pattern loaded in arrival pattern view.
Figure 4.11: Typical arrival Pattern loaded in arrival pattern view
Stream List
The stream list view mainly composed of Vaadin UI table, upload and Vaadintable export add-ons. Vaadin table is one of the most versatile componentsand it presents the data organised in rows and columns format. Vaadin tablesupports Lazy loading, means that only those rows which are included in PageLength are loaded into memory [6]. Upload component allows user to uploadfiles to server by showing a common dialogue box. User easily selects filesand upload them with this component. Vaadin table-export component ex-ports table data in a downloadable file in Microsoft Excel or CSV format.When user uploads a list of streams with upload component, the list is parsedand loaded into table to display on the screen. The list of streams must con-
42
tains a header row, which is used to set the columns header in table. Inaddition to setting the column headers, the header row is also used to gen-erate the parameter file. Figure 4.12 shows a typical stream list loaded inStream List View.
Figure 4.12: Stream list loaded in Stream List View
Parameter Generation
Parameter generation is mainly composed of two parts. The first part is data-base table generation and the second part is parameter file generation. Duringdatabase table generation, stream list view table as discussed in section 4.2 isread in row manner. A unique record for each row in the stream list table iscreated in the database table. When database table is populated with all rowsfrom the stream table, the next step is to generate the parameter file.
43
Start
Arrival pattern
Database table
While arrival list != null
Parameter file
Read arrival pattern/ get number for
streams
Randomly read N streams from table
Write time stream entry in Parameter
file
Exit
Attach time-stamp to stream
Figure 4.13: Flow Chat for parameter generations activity
Figure 4.13 shows a flow chart for parameter file generation activity. Theparameter file generation consists of following activities:
• Read arrival pattern and get the number of streams for a time instance.
• Pick number of streams randomly from database table.
• Create stream entry for each selection in the parameter file.
This parameter file is then ready to transfer to remote system for simula-tion or real transcoding system for execution.
4.2.1 Publish Web Service
As discussed in sub-section 4.1.2, Web service is a back-bone for communica-tion between the server and the remote system. Front-end uses SOAP/WSDLcombination to implement RPC. Code-first approach, as discussed in sub-section 4.1.2, is used to generate the server and client stubs. First, Serverpublishes it’s service on an end-point at specified port number. Then the re-mote system, which wants to communicate to server binds to this port andquery end-point for the exposed RPC. These RPCs are then used to send
44
measurement values to the server. The server plots these values on time-lineto visualise the activity of the remote system.
Server Stub
Listing C.2 shows an interface of the Web Service, publishing it’s methodswith annotation @Webservice. Annotation @SOAPBinding (style=Style.RPC)
defining the binding mechanism. Functions which are available through Webservice, are annotated with @WebMethod. Implementation of this interface con-sist of a separate class as shown in listing C.2.
CallWebServiceImplServiceCallWebServiceImplService
CallWebServiceImplPort
http://localhost:8081/cal
CallWebServiceCallWebService
addTimeLinevalue
inputarg0 string
arg1 stringArray
output return int
CreateTimeSerise
input arg0 string
output return int
downloadFile
input arg0 string
output return base64Binary
SimulaterReady
input arg0 int
output no part specified
SimulaterFileready
input no part specified
output return int
createTimeLineSeries
input
arg0 string
arg1 string
arg2 int
arg3 int
output return int
Startsimulator
input no part specified
output return int
Figure 4.14: WSDL generated due to end-point publishing on server
The implementation class annotated with @MTOM, as discussed in sub-section4.1.2, is used to transfer the parameter file from front-end to the remote sys-tem. The The annotation @WebService(endpointInterface=".....") pub-lishes an end-point, as discussed in sub-section 4.1.2 for remote system tomake RPC calls. As a result of this service publication, a WSDL as discussedin 3.3, is generated on server and available on port specified in Web Service
45
class shown in listing C.4. The graphical representation of Web service inter-face is shown in Figure 4.14
Client Stub
Successful publication of end-point results in a WSDL document. This doc-ument is then used to generate client stub. By using WSDL2Java utility, clientstub can be easily generated from WSDL document. WSDL2Java takes WSDLdocument as input and generates fully annotated code to implement a service[18]. WSDL2Java also provides facility to define external binding file, which in-cludes type of RPC methods (i.e synchronous, asynchronous etc.). ListingC.5 shows a typical binding file to generate asynchronous mapping for Webmethod. WSDL2Java generate the interface and implementation classes. Theseimplemetation classes contain all necessary functions and references to com-municate with the remote server. Listing C.6 shows the generated classes forclient stub.
4.2.2 Time Line View
The Time line view is based on Vaadin time-line component. Vaadin time-line component allows time related data to be represented as graphs [6]. Inthis very thesis, we use Vaadin time-line to represent measurements valueswhich are collected remotely. Graphical representation of data gives user avisual feedback about events happening at the remote systems. Vaadin time-line can be configured for multiple graphs at the same time. Graphs can berepresented as line, bar or scatter graphs [6]. A scroll bar area at the bottomof the graph is used to scroll through the time-line. Figure 4.15 depicts atypical Vaadin time-line with graphs.
Figure 4.15: A typical Vaadin Timeline consists of main area and Browserpart at the bottom.
46
In order to plot values on time-line, First, user has to create containerswhich hold both graph and time data. Whenever, a new value is added onthe graph, the corresponding time event should also be recorded into timecontainer. The time container can be incremented as per user’s needs. Forinstance, it can be incremented in seconds, minutes, hours, days , weeks andeven in a yearly manner. Due to this flexibility, the time-line facilitates userto plot any time related graphs. The zoom in and zoom out capability providesuser a freedom to zoom at many levels.
When remote system starts sending measurements to the front-end servervia remote procedure calls, the corresponding time-line is updated. An eventis added to the time-line with value and time stamp. As long as the remotesystem sends the measurements values, the time-line graphs are updated ac-cording to events and time.
4.2.3 Class Diagrams
The front-end architecture is developed in Java, which is an object orientedlanguage. The basic unit of implementation in Java language is a class. In or-der to discuss the front-end architecture implementation in detail, this sectiondescribes how the classes relate to each other and how interaction is done atclass level.
Context level
Figure A.1 shows context level of class diagram. Mainly, Front-end archi-tecture is implemented as a servlet. UI_milestone1UI extends the Vaadin UIclass and contains a servlet class which is extended from Vaadin servlet. Byoverriding Vaadin servlet init function, front-end implements its own initial-ising routines. Figure B.1 illustrates a sequence of operations executed duringinitialising a front-end. After initialising the environment, a Vaadin navigatoris attached with views to browse front-end. A GUI is presented to the user tointeract with the front-end. Figure A.2 shows main servlet class diagram. Adetailed sequence of events are shown in figure B.3.
47
Request File List View Class
Figure A.5 illustrates Request File View Class Diagram. This class deals withthe list of streams, controlling and finalising the streams information. This in-formation is then used to generate the parameter file for the client. This classcontains two nested classes (helper classes), namely Stream Table and UploadReceiver Table. Stream table class uses Vaadin table class to create a lazy tablecontainer. Upload Receiver Table class is responsible for handling user selec-ted list of streams file. It uploads the list of streams file, parses it and thengenerates the columns and header according to the file structure. Whenever,user uploads a list of streams file into Request File view, the stream table re-freshes itself dynamically. User can also modify the streams parameters asrequired.
User Pattern View Class
The structure of User Pattern View Class is depicted in Figure A.4. Mainly,this class consists of Vaadin Charts. Vaadin Charts are interactive feature richchart library which provides one-dimension and two-dimensions visualisa-tion of numeric data. User can interact with these charts in various ways [6].This class contains two helper classes namely UploadReceiverChart and Worker-Thread. Either User can manually define arrival pattern with mouse clicks orcan upload an arrival pattern file. The upload receiver chart controls the fileuploading process. A Worker Thread is instantiated to perform non-blockingupdates. When background thread finishes updating the user pattern graph,user pattern graph refreshes itself to display the updated graph on screen.Figure B.5 shows the detailed sequence diagram for user pattern view class.
Option View Class
The option view consists of two helper classes namely GenerateData and Work-Thread. As discussed in section 3.3, it also uses Web service class to initialisethe end-point and publish the Web service on user desire port. After upload-ing list of stream s and arrival pattern, GenerateData class is used to generatethe parameter file. WorkerThread class does this task in background to avoidblocking of front-end. When parameter file is generated and Web service
48
is published, remote clients are able to connect to front-end and be able todownload the parameter file. When front-end issues a start instruction to re-mote system, the remote system starts it’s execution and post back results viaRPC. Figure B.11 and Figure B.10 illustrate sequence of events and FigureA.8 shows implementation of web service interface and associated methods.
Time Line View Class
Time line view class as depicted in Figure A.7, is the heart of the monitoringpart of front-end architecture. When remote client starts the execution andsending updates to front-end, time line view shows these updates in form ofgraphs. The structure of time line view class consist of two helper classes i.eTimelineSetting and CGDS. Timeline setting class deals with the visual settingof the time-line. The CGDS class, as discussed in section 4.2.2, creates con-tainers for the graph and for the event data source. These containers are thenused to plot the values on graphs. Figure B.8 shows sequence of events forTime line view class.
49
Chapter 5
Experiments and Results
5.1 Experimental Set-up
The experimental set-up used to test front-end utilise at-least two Computers(PC). The first PC is used to deploy front-end architecture and the second oneis used to run a Video Transcoding simulator. Table 5.1 shows the main prop-erties of the PCs used in the experiments. Note that computers are connectedto internet and physically located on different places.
5.2 Experiments Parameters
In order to test the front-end architecture, we need a list of streams and aarrival pattern. Following paragraphs discusses the details about the structureof list of streams file and arrival patterns.
50
Platform DescriptionPC-1 Front-endHardware Intel r CoreTM2 CPU 6600 @ 2.40 GHz X 2
O/S Type: Linux (Ubuntu) 64-bitRAM: 4.0 GBInternet Connection
Software Java Development Kit version 1.7.0 (64-bit)Apache Tomcat Server 7.0Apache CXF 3.0
PC-2 Remote ClientHardware Intel r CoreTM i3 CPU M370 @ 2.40 GHz
O/S Type : Windowsr 7 Professional 64-bitRAM : 4.0 GBInternet Connection
Software Java Runtime Environment (JRE) 1.7 (64-bit)Transcoding Simulator
Table 5.1: Platform details
List of Streams
The List of streams file contains approximately 430 individual stream entries.Each stream entry consist of the attributes listed in Table 5.2.
Arrival Patterns
The stream arrival pattern consists of number of streams at a given instanceof time. As discussed in section 4.13, a parameter file is generated accordingto the arrival pattern. During these experiments, we use different arrivalpatterns as presented by Ashraf, Adnan and Jokhio, Fareed et al. [1].
Arrival Pattern 1: Relatively Normal Load with Low Arrival Rate
The objective of this arrival pattern is to simulate a low arrival rate withrelatively normal load. The maximum number of streams are 200 at twodifferent peaks. For first peak, a new stream is added every 100 seconds andremain constant for one hour. The streams are ramped-down to 100 streamsand again ramped-up to 200 while adding a new stream every 150 seconds.
51
Stream Attributes
Source Video Attributes
• VID: A unique video id• Duration (Total Play time)• Width (pixels)• Height (pixels)• Bit rate• Codecs• Frame Rate (per second)• Number of I,B and P frames• Frame sizes (I,B and P)• Size (in bytes)
Output Video Attributes
• Codec• Bit rate• Width• Height• Output frame rate
Table 5.2: Video stream attributes
[1]. Figure 5.1 depicts the graphical representation, loaded in the front-endarchitecture.
Figure 5.1: Arrival Pattern 1: Relatively Normal Load with Low ArrivalRate
52
Arrival Pattern 2: Relatively Normal Load with High Arrival Rate
The Figure 5.2 shows the graphical representation of arrival pattern for nor-mal load with high arrival rate. The maximum load at the peaks are 200streams. However, a new stream was added every 20 seconds for the firstpeak and added after 30 seconds for the second peak. [1].
Figure 5.2: Arrival Pattern 2: Relatively Normal Load with High ArrivalRate
Arrival Pattern 3: Highly Variable Load with Low Arrival Rate
This arrival rate pattern was used to test a highly variable stream rate tosimulate a highly variable video demand. The maximum load is 290 streamsand six different peaks were generated ranging from 0 to 170, 110 to 290,210 to 280, 215 to 250 and 100 to 170. The ramp-up rate is 1 stream per 150seconds. [1]. Figure 5.3 shows a graphical representation of arrival pattern 3.
53
Figure 5.3: Arrival Pattern 3: Highly Variable Load with Low Arrival Rate
Arrival Pattern 4: Highly Variable Load with High Arrival Rate
Fareed et al. [1] presented a high variable load with high arrival rate similarlyto Arrival Pattern 3. A different time for adding a new stream, 30 seconds wasused. Figure 5.4 shows arrival pattern 4.
Figure 5.4: Arrival Pattern 4: Highly Variable Load with High ArrivalRate
5.3 Remote Client : Simulator
In order to test our front-end architecture, we used CloudSim Based Simulatorfor Distributed Video Transcoding [32]. This simulator was developed as intern-
54
ship work by Habtegebreil Kassaye Haile, at Embedded Systems Laboratory,Department of Information Technologies, Åbo Akademi University. The mainpurpose of this Java based simulator is to validate and simulate the approachfor stream based admission control and job scheduling for video transcodingpresented in [1].
The client stub, as listed in C.6, is added into the simulator to link it withthe front-end. With this added functionality, the simulator is able to sendstatics to front-end for plotting on time-line. These statics consist of namelyNumber of Virtual Machines, Predicted Transcoding Rate, Total Play Rate and TotalTranscoding Rate.
Table 5.3 shows list of experiments, Number of streams used to generateparameter file and number of streams generated for each experiment.
5.4 Results
Figures 5.5, 5.6, 5.7 and 5.8 respectively show simulation results of experi-ments listed in Table 5.3.
Figure 5.5: Simulation Results : Relatively Normal Load with Low ArrivalRate
55
No.
Expe
rim
ent
Inpu
tSt
ream
sG
ener
ated
Stre
ams
Sim
ulat
ion
Tim
e1
Rel
ativ
ely
Nor
mal
Load
wit
hLo
wA
rriv
alR
ate
435
1072
800
3.5
Hou
rs2
Rel
ativ
ely
Nor
mal
Load
wit
hH
igh
Arr
ival
Rat
e43
547
0350
1.59
Hou
rs3
Hig
hly
Var
iabl
eLo
adw
ith
Low
Arr
ival
Rat
e43
529
5936
510
.59
Hou
rs4
Hig
hly
Var
iabl
eLo
adw
ith
Hig
hA
rriv
alR
ate
435
9884
853.
10H
ours
Tabl
e5.
3:Ex
peri
men
tsde
tails
56
Figure 5.6: Simulation Results : Relatively Normal Load with High ArrivalRate
Figure 5.7: Simulation Results : Highly Variable Load with Low ArrivalRate
57
Figure 5.8: Simulation Results : Highly Variable Load with High ArrivalRate
5.4.1 Key Characteristics
The developed front-end architecture possesses some key characteristics namelyTransparency, Openness and Geographic Scalability.
Transparency
The front-end architecture makes it easy for the users and applications toaccess remote resources and share them in a controlled and efficient way.Representation of data, access method and location is transparent to the users.The front-end architecture can be relocated physically with ease. Many userscan concurrently access and share data among them. The actual physicallocation of the developed front-end architecture can be hidden due to use ofthen Universal Resource Locator (URL) [4].
Openness
The remote systems are offered services according to the standards whichdescribe rules and semantics. The services are specified through InterfaceDefinition Languages (IDL) as described in section 3.3.
58
Interoperability
The implementation of systems and components which belongs to differentvendors and manufactures can work together by merely relying on each oth-ers. In our developed front-end architecture, Vaadin Framework, Apache CXFand Tomcat application server glued together with the help of Web Servicesin order to perform required functionality.
Portability
Due to the fact that developed front-end architecture is Java based, it can beported to any operation system (OS) and architecture which supports Java.
Extendible
The component based architecture allows the developed front-end architec-ture’s functionality to be extended as required.
59
Chapter 6
Conclusion
The current advancements in distributed computing has provided us withnew ways of utilizing the computational resources. Web Services offer spe-cial features such as transparency, openness, interoperability, portability andextendibility. By exploiting these features, any architecture can be easily de-veloped by gluing the required components. To prove this concept, a test case,the front-end architecture was selected.
The front-end architecture was made using Vaadin GUI framework, ApacheCXF, Tomcat Server. Vaadin was mainly used to implement user interface.The Apache CXF was used to provide Web Service infrastructure and TomcatServer is used to run the GUI for controlling and monitoring the transcodingsimulator as a client.
Web services provide a high level abstraction for the communication betweenone or more clients. Apparently, requires less effort to develop a distributedapplication as compared to socket based communication. Additionally, Webservices follow standards which are adopted by industries and different or-ganisations. Consequently, it is very easy to extend, interoperate, port andgeographically scale the developed application to new requirements.
In order to test the above mentioned features, some simulations were ran
60
on different geographical locations and different operation system. The testclient (Transcoding Simulator) was run firstly on local machine with front-end architecture, secondly on some other computer with in the premises.Thirdly, ran on a computer system located in Middle-east and finally run ona computer system located in Indian subcontinent. All of these tests providesame results with some time difference due to network latency. However,based on RPC, the developed front-end architecture and client must be activeat the time of communication.
The architecture of front-end is developed in such a way that it can beutilised by other researchers who require remote monitoring. Detailed class-diagrams, sequence-diagrams and API reference are attached as Appendix fortechnical details.
61
Bibliography
[1] Adnan Ashraf, Fareed Jokhio, Tewodros Deneke, Sebastien Lafond, IvanPorres, and Johan Lilius. Stream-based admission control and schedul-ing for video transcoding in cloud computing. In Pavan Balaji, DickEpema, and Thomas Fahringer, editors, 13th IEEE/ACM InternationalSymposium on Cluster, Cloud and Grid Computing (CCGrid), page482–489. IEEE Computer Society, 2013.
[2] RebelLab. The 2014 decision makers guide to java web frame-works, 2014. URL: http://zeroturnaround.com/rebellabs/the-2014-decision-makers-guide-to-java-web-frameworks/.
[3] J. Snell, D. Tidwell, and P. Kulchenko. Programming Web Services withSOAP. O’Reilly Media, 2001. URL: http://books.google.fi/books?id=ALo1LxID5q0C.
[4] A.S. Tanenbaum and M. Van Steen. Distributed Systems: Principles andParadigms. Pearson prentice hall legal series. Pearson Prentice Hall,2007. URL: http://books.google.fi/books?id=UKDjLQAACAAJ.
[5] Gustavo Alonso, Fabio Casati, Harumi Kuno, and Vijay Machiraju. Webservices. In Web Services, Data-Centric Systems and Applications, pages123–149. Springer Berlin Heidelberg, 2004. URL: http://dx.doi.org/10.1007/978-3-662-10876-5_5, doi:10.1007/978-3-662-10876-5_5.
[6] M. Grönroos. Book of Vaadin. Vaadin Limited, 2011. URL: http://books.google.fi/books?id=rXYItwAACAAJ.
[7] N. Balani and R. Hathi. Apache CXF Web Service Development: Developand Deploy SOAP and RESTful Web Services. From technologies tosolutions. Packt Publishing, Limited, 2009. URL: http://books.google.fi/books?id=v1kIPmAnEDoC.
[8] David Perera. The real obstacle to federal cloud comput-ing, 2012. URL: http://www.fiercegovernmentit.com/story/real-obstacle-federal-cloud-computing/2012-07-12#ixzz2xIbdNyUp.
62
[9] Cloud Software Finland:. Finland national cloud software program, 2010.URL: http://www.cloudsoftwareprogram.org/.
[10] DocForge. Web application framework, 2013. URL: http://docforge.com/wiki/Web_application_framework.
[11] C. Bauer and G. King. Java Persistence With Hibernate. Manning PubsCo Series. Manning Publications Company, 2007. URL: http://books.google.fi/books?id=0LmuQgAACAAJ.
[12] H. Ning. Unit and Ubiquitous Internet of Things. Taylor & Francis, 2013.URL: http://books.google.fi/books?id=5csnAAAAQBAJ.
[13] S.K. Gunter and J. Valade. Master VISUALLY Dreamweaver CS3 andFlash CS3 Professional. Master VISUALLY. John Wiley & Sons, 2007.URL: http://books.google.fi/books?id=YSi4JFMqFkAC.
[14] M. Tim Jones. Five pitfalls of linux sockets programming, 2005. URL:http://www.ibm.com/developerworks/library/l-sockpit/.
[15] D.A. Chappell and T. Jewell. Java Web Services. Java Series. O’Reilly,2002. URL: http://books.google.fi/books?id=wiXOyXdvHO8C.
[16] Wikipedia. Message-oriented middleware, 2014. URL: http://en.wikipedia.org/wiki/Message-oriented_middleware.
[17] Ioannis G. Baltopoulos. Introduction to web services, 2005. URL: https://www.cl.cam.ac.uk/~ib249/teaching/Lecture1.handout.pdf.
[18] VirgilioA.F. Almeida. Capacity planning for web services techniquesand methodology. In MariaCarla Calzarossa and Salvatore Tucci, ed-itors, Performance Evaluation of Complex Systems: Techniques andTools, volume 2459 of Lecture Notes in Computer Science, pages 142–157. Springer Berlin Heidelberg, 2002. URL: http://dx.doi.org/10.1007/3-540-45798-4_7, doi:10.1007/3-540-45798-4_7.
[19] Greg Meredith Sanjiva Weerawarana Erik Christensen, Fran-cisco Curbera. Web services description language (wsdl) 1.1, 2001.URL: http://www.w3.org/TR/wsdl.
[20] N. Fränkel. Learning Vaadin 7: Second Edition. Packt Publishing, 2013.URL: http://books.google.fi/books?id=pQDJAAAAQBAJ.
[21] Wikipedia. Push technology. URL: http://en.wikipedia.org/wiki/Push_technology.
63
[22] Jeff Hanson. Tomcat in the enterprise, 2008. URL: http://www.javaworld.com/artical/2077826/open-source-tools/tomcat-in-the-enterprise.html.
[23] Wikipedia. Apache cxf, 2014. URL: http://en.wikipedia.org/wiki/Apache_CXF.
[24] Wikipedia. Java architecture for xml binding, 2014. URL: http://en.wikipedia.org/wiki/Java_Architecture_for_XML_Binding.
[25] K. Topley. Java Web services in a nutshell. In a Nutshell. O’Reilly, 2003.URL: http://books.google.fi/books?id=LpxVAAAAMAAJ.
[26] Oracle. The java ee5 tutorial, 2010. URL: http://docs.oracle.com/javee/5/tutorial/doc/bnbhg.html.
[27] Wikipedia. Endpoint interface, 2013. URL: http://en.wikipedia.org/wiki/Service_Endpoint_interface.
[28] Yang Herong. What is wsdl2java?, 2013. URL: http://www.herongyang.com/WSDL/WSDL2Java-What-is-WSDL2Java.html.
[29] The Apache Software Foundation. Apache cxf: Interceptors and phases.URL: http://cxf.apache.org/docs/interceptors.html.
[30] The Apache Software Foundation. Apache cxf: Mtom attachment withjaxb. URL: http://cxf.apache.org/docs/mtom-attachment-with-jaxb.html.
[31] Wikipedia. Base64, 2014. URL: http://en.wikipedia.org/wiki/Base64.
[32] Habtegebreil Kassaye Haile. Cloud sim based simulator for distributedvideo transcoding. Technical report, Åbo Akademi University, 2014.
64
Appendices
65
Appendix A
Class Diagrams
66
Cla
ss L
evel
Con
text
Dia
gram
com
exam
ple
ui_m
ilest
one1
Up
load
Rec
eive
rTab
leS
trea
mT
able
Up
load
Rec
eive
rCh
art
<<In
terf
ace>
>C
allW
ebS
ervi
ce
Cal
lWeb
Ser
vice
Imp
l
Mai
nV
iew
Bu
tto
nL
iste
ner
Res
etF
ron
tEn
d
Op
ts
Wo
rkT
hre
adG
ener
ateD
ata
Req
ues
tFile
Lis
tVie
w
Tim
eLin
eCh
artV
iew
Tim
eLin
eSet
ting
sC
GD
S
Ui_
mile
sto
ne1
UI
Ser
vlet
Use
rPat
tern
Vie
w
Up
load
Wo
rkT
hre
adW
ebS
ervi
ceB
roke
r
Web
Ser
vice
sS
trea
mT
able
1w
b
1+
TL
1
+C
GD
S
1S
R1
+U
R1
+O
V
1
+st
ream
tabl
e
Figu
reA
.1:C
onte
xtLe
velC
lass
Dia
gram
67
UIM
ileS
tone
1Cla
ss
+S
trea
mfil
eNam
e : S
trin
g =
nul
l+
dilim
iter
: Str
ing
= n
ull
+B
asep
ath
: Str
ing
= V
aadi
nSer
vice
.get
Cur
rent
().g
etB
aseD
irect
ory(
).ge
tAbs
olut
ePat
h()
+na
viga
tor
: Nav
igat
or
#ini
t(re
ques
t : V
aadi
nReq
uest
) : v
oid
Ui_
mile
sto
ne1
UI
Ser
vlet
Figu
reA
.2:F
ront
-end
Mai
nC
lass
-U
I-M
ilest
one1
Dia
gram
68
mai
nvie
w
+M
ainV
iew
()+
ente
r(ev
ent :
Vie
wC
hang
eEve
nt)
: voi
d+
setS
trea
mB
utto
n(st
ate
: boo
lean
) : v
oid
Mai
nV
iew
+B
utto
nLis
tene
r(m
enui
tem
: S
trin
g)+
butto
nClic
k(ev
ent :
Clic
kEve
nt)
: voi
d
Bu
tto
nL
iste
ner
+re
set(
) : v
oid
Res
etF
ron
tEn
d
Figu
reA
.3:M
ain
Vie
wC
lass
Dia
gram
69
Use
r P
atte
rn V
iew
+U
serP
atte
rnV
iew
()~
Cle
arP
atte
rnV
iew
() :
void
+en
ter(
even
t : V
iew
Cha
ngeE
vent
) : v
oid
Use
rPat
tern
Vie
w
+U
ploa
dRec
eive
rCha
rt(s
erie
s : L
istS
erie
s)+
rece
iveU
ploa
d(fil
enam
e : S
trin
g, m
imeT
ype
: Str
ing)
: O
utpu
tStr
eam
+up
load
Suc
ceed
ed(e
vent
: S
ucce
eded
Eve
nt)
: voi
d+
uplo
adF
aile
d(ev
ent :
Fai
ledE
vent
) : v
oid
Up
load
Rec
eive
rCh
art
+ru
n()
: voi
d
Wo
rkT
hre
ad
Figu
reA
.4:U
ser
Patt
ern
Vie
wC
lass
Dia
gram
70
Req
uest
File
Vie
w
+R
eque
stF
ileLi
stV
iew
()+
ente
r(ev
ent :
Vie
wC
hang
eEve
nt)
: voi
d
Req
ues
tFile
Lis
tVie
w
+ad
dCol
umn(
id :
Obj
ect,
cls
: Cla
ss, d
efau
ltVal
ue :
Obj
ect)
: vo
id+
setC
olH
eade
r(id
: O
bjec
t, he
ader
: S
trin
g) :
void
+S
trea
mT
able
()-f
illR
eque
stT
able
(file
Nam
e : S
trin
g, d
ilim
iter
: Str
ing)
: vo
id+
head
erS
trin
g()
: Str
ing
+S
trea
mT
able
Ref
reas
h(fil
enam
e : S
trin
g, d
ilim
iter
: Str
ing)
: vo
id+
Del
eteT
able
Con
tent
s()
: voi
dStr
eam
Tab
le
+re
ceiv
eUpl
oad(
filen
ame
: Str
ing,
mim
eTyp
e : S
trin
g) :
Out
putS
trea
m+
uplo
adS
ucce
eded
(eve
nt :
Suc
ceed
edE
vent
) : v
oid
+up
load
Fai
led(
even
t : F
aile
dEve
nt)
: voi
d
Up
load
Rec
eive
rTab
le
Figu
reA
.5:R
eque
sFile
Vie
wC
lass
Dia
gram
71
optio
nVie
w d
iagr
am
+O
pts(
)+
ente
r(ev
ent :
Vie
wC
hang
eEve
nt)
: voi
d+
enab
leD
BB
utto
n(en
b : b
oole
an)
: voi
d
Op
ts
+ru
n()
: voi
d
Wo
rkT
hre
ad
+G
ener
ateD
ata(
)+
Gen
erat
e()
: voi
dGen
erat
eDat
a
+W
ebS
ervi
ces(
Hos
tNam
e : S
trin
g, P
ort :
Str
ing)
+S
tart
Ser
vice
() :
void
+S
topS
ervi
ce()
: vo
id
Web
Ser
vice
sus
es
Figu
reA
.6:O
ptio
nVie
wC
lass
Dia
gram
72
Tim
eLin
eCha
rtV
iew
+T
imeL
ineC
hart
Vie
w()
+A
ddT
imeL
ineP
oint
(Str
ing,
Str
ing
[]) :
int
+A
ddG
raph
(Tim
elin
e, S
trin
g, S
trin
g, in
t, in
t) :
bool
ean
+cr
eate
Gra
phD
ataS
ourc
e(S
trin
g) :
Inde
xed
+ch
ange
Attr
ibut
es(T
imel
ine,
Str
ing,
Col
or, S
trin
g, in
t) :
bool
ean
-che
ckG
raph
Nam
e(S
trin
g, In
dexe
d) :
bool
ean
+en
ter(
Vie
wC
hang
eEve
nt)
: voi
d
Tim
eLin
eCh
artV
iew
+T
imeL
ineS
ettin
gs()
+T
imeL
ineS
et(T
imel
ine)
: vo
id
Tim
eLin
eSet
tin
gs
+cr
eate
Mar
kerD
ataS
ourc
e()
: Ind
exed
+cr
eate
Eve
ntD
ataS
ourc
e()
: Ind
exed
+cr
eate
Gra
phD
ataS
ourc
e()
: Ind
exed
CG
DS
1
CG
DS
Figu
reA
.7:T
ime
Line
Vie
wC
lass
Dia
gram
73
web
serv
ices
+A
ddG
raph
Poi
nt(x
: in
t) :
int
+C
reat
eTim
eSer
ise(
Ser
iseN
ame
: Str
ing)
: in
t+
dow
nloa
dIm
age(
nam
e : S
trin
g) :
Imag
e+
uplo
adIm
age(
data
: Im
age)
: S
trin
g+
dow
nloa
dFile
(file
Nam
e : S
trin
g) :
Dat
aHan
dler
+cr
eate
Tim
eLin
eSer
ies(
grap
hnam
e : S
trin
g, le
gend
: S
trin
g, c
olor
: in
t, T
hick
ness
: in
t) :
int
+ad
dTim
eLin
eval
ue(s
erie
s : S
trin
g, v
alue
s : S
trin
g [])
: in
t+
Sim
ulat
erF
ilere
ady(
) : i
nt+
Sim
ulat
erR
eady
(sta
tus
: int
) : v
oid
+S
tart
sim
ulat
or()
: in
t+
hello
Arr
ay(n
ame
: Str
ing
[]) :
Str
ing
<<In
terf
ace>
>C
allW
ebS
ervi
ce
+w
b : W
ebS
ervi
ceB
roke
r =
new
Web
Ser
vice
Bro
ker(
)
+do
wnl
oadI
mag
e(na
me
: Str
ing)
: Im
age
+up
load
Imag
e(da
ta :
Imag
e) :
Str
ing
+A
ddG
raph
Poi
nt(x
: in
t) :
int
+C
reat
eTim
eSer
ise(
Ser
iseN
ame
: Str
ing)
: in
t+
dow
nloa
dFile
(file
Nam
e : S
trin
g) :
Dat
aHan
dler
+ad
dTim
eLin
eval
ue(S
erie
s : S
trin
g, v
alue
s : S
trin
g [])
: in
t+
Sim
ulat
erF
ilere
ady(
) : i
nt+
Sim
ulat
erR
eady
(sta
tus
: int
) : v
oid
+S
tart
sim
ulat
or()
: in
t+
crea
teT
imeL
ineS
erie
s(gr
aphn
ame
: Str
ing,
lege
nd :
Str
ing,
col
or :
int,
Thi
ckne
ss :
int)
: in
t+
hello
Arr
ay(n
ame
: Str
ing
[]) :
Str
ing
Cal
lWeb
Ser
vice
Imp
l
+ca
l : C
alen
dar
= C
alen
dar.
getIn
stan
ce()
+W
ebS
ervi
ceB
roke
r()
+A
ddT
imeL
ineP
oint
(tim
elin
e : T
imel
ine,
gra
phna
me
: Str
ing,
val
ues
: Str
ing
[]) :
int
+A
ddG
raph
(tim
elin
e : T
imel
ine,
gra
phna
me
: Str
ing,
lege
nd :
Str
ing,
col
: in
t, th
ickn
ess
: int
) : b
oole
an+
crea
teG
raph
Dat
aSou
rce(
Gra
phna
me
: Str
ing)
: In
dexe
d+
chan
geA
ttrib
utes
(tim
elin
e : T
imel
ine,
gra
phna
me
: Str
ing,
col
or :
Col
or, l
egen
d : S
trin
g, th
ickn
ess
: int
) : b
oole
an-c
heck
Gra
phN
ame(
grap
hnam
e : S
trin
g, c
onta
iner
: In
dexe
d) :
bool
ean
Web
Ser
vice
Bro
ker
1w
b
Figu
reA
.8:W
ebse
rvic
esC
lass
Dia
gram
74
Appendix B
Sequence Diagrams
75
sd com.example.ui_milestone1.Ui_milestone1UI.init(VaadinRequest)
opt
opt
[osName.equals("Linux")]
[osName.equals("Windows 7")]
navigator : com.vaadin.navigator.Navigator
() : ()e : eInetAddress : InetAddressSystem : System: Ui_milestone1UI
1.15:
1.14: navigateTo(MainView.VIEW_NAME)
1.13: addView(Opts.VIEW_NAME, new Opts())
1.12: addView(TimeLineChartView.VIEW_NAME, new TimeLineChartView())
1.11: addView(RequestFileListView.VIEW_NAME, new RequestFileListView())
1.10: addView(UserPatternView.VIEW_NAME, new UserPatternView())
1.9: addView(DashboardView.VIEW_NAME, new DashboardView())
1.8: addView(MainView.VIEW_NAME, new MainView())
1.7:
1.6: setTitle("Transcoding Control and Monitoring Environment ")
1.5: getPage()
1.4: getenv("COMPUTERNAME")
1.3: printStackTrace()
1.2: getLocalHost()
1.1: getProperty("os.name")
1: init()
Figure B.1: Sequence diagram: UI_milestone1UI
76
sdco
m.e
xam
ple.
ui_m
ilest
one1
.Mai
nVie
w.M
ainV
iew
()
logo
ut :
com
.vaa
din.
ui.B
utto
n
pane
l : c
om.v
aadi
n.ui
.Pan
el
grid
: co
m.v
aadi
n.ui
.Grid
Layo
ut
ov :
com
.vaa
din.
ui.B
utto
n
timeL
ine
: com
.vaa
din.
ui.B
utto
n
stre
amF
iles
: com
.vaa
din.
ui.B
utto
n
user
Inpu
tPat
tern
: co
m.v
aadi
n.ui
.But
ton
Res
etF
ront
End
: co
m.v
aadi
n.ui
.But
ton
sim
Sta
rt :
com
.vaa
din.
ui.B
utto
n
men
uCon
tent
: co
m.v
aadi
n.ui
.Ver
tical
Layo
ut
men
u : c
om.v
aadi
n.ui
.Pan
el
hLay
out :
com
.vaa
din.
ui.H
oriz
onta
lLay
out
: Mai
nVie
w
1.47
:
1.46
: add
Com
pone
nt(lo
gout
)
1.45
: add
Com
pone
nt(S
ervi
ceS
tatu
s)
1.44
:
1.43
: set
Exp
andR
atio
(hLa
yout
, 1.0
f)
1.42
: add
Com
pone
nt(h
Layo
ut)
1.41
: set
Exp
andR
atio
(pan
el, 1
.0f)
1.40
: add
Com
pone
nt(p
anel
)
1.39
: set
Siz
eFul
l()
1.38
:
1.37
: add
Com
pone
nt(m
enu)1.
36: s
etC
onte
nt(m
enuC
onte
nt)
1.35
: set
Mar
gin(
true
)
1.34
: set
Wid
th(n
ull)
1.33
: add
Clic
kLis
tene
r(ne
w B
utto
n.C
lickL
iste
ner(
) {
/** * */
priv
ate
stat
ic fi
nal l
ong
seria
lVer
sion
UID
= 1
L;
@O
verr
ide
publ
ic v
oid
butto
nClic
k(C
lickE
vent
eve
nt)
{
new
Not
ifica
tion(
"Res
ting
fron
dend
",nu
ll,N
otifi
catio
n.T
ype.
HU
MA
NIZ
ED
_ME
SS
AG
E)
.sho
w(P
age.
getC
urre
nt()
);
Res
etF
ront
End
rst
fend
= n
ew R
eset
Fro
ntE
nd()
;rs
tfend
.res
et()
;U
i_m
ilest
one1
UI.n
avig
ator
.nav
igat
eTo(
MA
INV
IEW
);} })
1.32
: add
Clic
kLis
tene
r(ne
w B
utto
n.C
lickL
iste
ner(
) {
/** * */
priv
ate
stat
ic fi
nal l
ong
seria
lVer
sion
UID
= 1
L;
@O
verr
ide
publ
ic v
oid
butto
nClic
k(C
lickE
vent
eve
nt)
{
Mai
nVie
w.T
L.S
tart
sim
ulat
or =
0;
} })
1.31
: add
Com
pone
nt(g
rid)
1.30
: set
Sty
leN
ame(
"wid
e de
faul
t")
1.29
: set
Sty
leN
ame(
"wid
e de
faul
t")
1.28
: set
Siz
eFul
l()
1.27
: set
Siz
eFul
l()
1.26
: set
Siz
eFul
l()
1.25
: set
Siz
eFul
l()
1.24
: set
Sty
leN
ame(
"wid
e de
faul
t")
1.23
: set
Sty
leN
ame(
"wid
e de
faul
t")
1.22
: set
Sty
leN
ame(
"wid
e de
faul
t")
1.21
: set
Sty
leN
ame(
"wid
e de
faul
t")
1.20
: add
Com
pone
nt(R
eset
Fro
ntE
nd, 0
, 6)
1.19
: add
Com
pone
nt(s
imS
tart
, 0, 5
)
1.18
: add
Com
pone
nt(u
serI
nput
Pat
tern
, 0, 4
)
1.17
: add
Com
pone
nt(s
trea
mF
iles,
0, 3
)
1.16
: add
Com
pone
nt(t
imeL
ine,
0, 2
)
1.15
: add
Com
pone
nt(o
v, 0
, 1)
1.14
:
1.13
:
1.12
:
1.11
: add
Clic
kLis
tene
r(ne
w B
utto
nLis
tene
r(R
eque
stF
ileLi
stV
iew
.VIE
W_N
AM
E))
1.10
:
1.9:
1.8:
1.7:
1.6:
set
Wid
th(n
ull)
1.5:
set
Hei
ght(
"100
%")
1.4:
1.3:
set
Siz
eFul
l()
1.2:
1.1:
set
Siz
eFul
l()
1: M
ainV
iew
()
Figu
reB.
2:Se
quen
ceD
iagr
am:M
ainV
iew
77
Figure B.3: Sequence Diagram: UI-MileStone1 Initialisation
78
sd Main View
logout
panel
grid
ov
timeLine
streamFiles
userInputPattern
ResetFrontEnd
simStart
menuContent
menu
hLayout
1.45:1.44: addComponent(logout)
1.43: addComponent(ServiceStatus)
1.42:
1.41: setExpandRatio(hLayout, 1.0f)
1.40: addComponent(hLayout)
1.38: setExpandRatio(panel, 1.0f)
1.39: addComponent(panel)
1.37: setSizeFull()
1.36:
1.35: addComponent(menu)
1.33: setContent(menuContent)
1.34: setMargin(true)
1.32: setWidth(null)
1.31: addComponent(grid)
1.29: setStyleName("wide default")
1.30: setStyleName("wide default")
1.27: setSizeFull()
1.28: setSizeFull()
1.25: setSizeFull()
1.26: setSizeFull()
1.23: setStyleName("wide default")
1.24: setStyleName("wide default")
1.21: setStyleName("wide default")
1.22: setStyleName("wide default")
1.20: addComponent(ResetFrontEnd, 0, 6)
1.19: addComponent(simStart, 0, 5)
1.16: addComponent(userInputPattern, 0, 4)
1.17: addComponent(streamFiles, 0, 3)1.18: addComponent(timeLine, 0, 2)
1.15: addComponent(ov, 0, 1)
1.14:
1.13:
1.12:
1.11: addClickListener(RequestFileListView)
1.10:
1.9:
1.8:
1.6:
1.7: setWidth(null)
1.5: setHeight("100%")
1.4:
1.3: setSizeFull()
1.2:
1.1: setSizeFull()
1: MainView()
Figure B.4: Sequence diagram : Main View
79
Figure B.5: User Pattern View Sequence Diagram
80
Figure B.6: Sequence diagram: Request file view
81
Figure B.7: Sequence diagram: Option View
82
Figure B.8: Sequence diagram : Time line View
83
Figure B.9: Sequence diagram : Web Service Broker
84
Figure B.10: Sequence diagram : Web Service Implementation Create TimeLine
85
Figure B.11: Sequence diagram : Web Service Implementation
86
Appendix C
Source Listing
package .......;
import ......;
@Theme("runo")
@PreserveOnRefresh
public class Ui_milestone1UI extends UI {
// Initialise Global variables
public static .....;
public static ......;
public static String Basepath = VaadinService.getCurrent ().getBaseDirectory ().
getAbsolutePath ();
public Navigator navigator;
@WebServlet(value = "/*", asyncSupported = true)
@VaadinServletConfiguration(productionMode = false , ui = Ui_milestone1UI.class
, widgetset = "com.example.ui_milestone1.widgetset.Ui_milestone1Widgetset"
)
public static class Servlet extends VaadinServlet {
}
@Override
protected void init(VaadinRequest request) {
java.util.logging.Logger.getLogger(
"com.sun.xml.ws.server.sei.EndpointMethodHandler").setLevel(
java.util.logging.Level.FINE);
// Configure basepath and other Global variable.
. . . . . .
// Create a navigator to control the views
87
navigator = new Navigator(this , this);
// Create and register the views
navigator.addView(MainView.VIEW_NAME , new MainView ());
navigator.addView(DashboardView.VIEW_NAME , new DashboardView ());
navigator.addView(UserPatternView.VIEW_NAME , new UserPatternView ());
navigator.addView(RequestFileListView.VIEW_NAME ,new RequestFileListView ());
navigator.addView(TimeLineChartView.VIEW_NAME , new TimeLineChartView ());
navigator.addView(Opts.VIEW_NAME , new Opts());
navigator.navigateTo(MainView.VIEW_NAME);
}
}
Listing C.1: Main View Class with navigation views
package ......;
import ......;
import ......;
import ......;
@WebService ()
@SOAPBinding(style=Style.RPC)
public interface CallWebService extends Remote
{
@WebService ()
@SOAPBinding(style=Style.RPC)
public interface CallWebService extends Remote
{
@WebMethod (operationName ="CreateTimeSerise")
public int CreateTimeSerise(String SeriseName);
@WebMethod (operationName ="downloadFile")
public DataHandler downloadFile(String fileName);
@WebMethod(operationName ="CreateTimeLineSeries")
public int createTimeLineSeries(String graphname , String legend , int color ,
int Thickness);
@WebMethod(operationName ="AddTimeLineValue")
public int addTimeLinevalue(String series , String [] values);
@WebMethod (operationName ="SimulaterFileready")
public int SimulaterFileready ();
@WebMethod (operationName ="SimulaterReady")
public void SimulaterReady(int status);
@WebMethod (operationName ="Startsimulator")
public int Startsimulator ();
Listing C.2: Web Service Interface
package .......;
import ........;
import ........;
import ........;
88
@MTOM
@WebService(endpointInterface="com.example.ui_milestone1.CallWebService")
public class CallWebServiceImpl implements CallWebService {
public WebServiceBroker wb = new WebServiceBroker ();
@Override
public int CreateTimeSerise(String SeriseName){
// implementation code
.......;
.......;
.......;
}
@Override
public DataHandler downloadFile(String fileName) {
// implementation code
.......;
.......;
.......;
}
@Override
public int addTimeLinevalue(String Series ,String [] values) {
// implementation code
.......;
.......;
.......;
}
@Override
public int SimulaterFileready () {
// implementation code
.......;
.......;
.......;
}
@Override
public void SimulaterReady(int status) {
// implementation code
.......;
.......;
.......;
}
@Override
public int Startsimulator () {
// implementation code
.......;
.......;
.......;
}
@Override
public int createTimeLineSeries(String graphname , String legend , int color ,
int Thickness) {
89
// implementation code
.......;
.......;
.......;
}
@Override
public String helloArray(@WebParam(name = "name") String [] name) {
// implementation code
.......;
.......;
.......;
}
}
Listing C.3: Web Service Interface
public WebServices(String HostName , String Port){
this.HOSTNAME=HostName;
this.PORT=Port;
}
public void StartService (){
synchronized (this) {
java.util.logging.Logger.getLogger(
"com.sun.xml.ws.server.sei.EndpointMethodHandler").setLevel(
java.util.logging.Level.FINE);
if(! status){
endpoint = Endpoint.publish("http ://" + HOSTNAME + ":"+PORT+"/cal",
new CallWebServiceImpl ());
status=true;}
System.out.println("WebService Published :" + endpoint.isPublished () +" at
HostName :" + HOSTNAME + "and Port :"+PORT);
}
}
public void StopService (){
if (endpoint.isPublished ()){
endpoint.stop();
status = false ;}
}
public boolean getStatus (){
return endpoint.isPublished ();
}
Listing C.4: Web Service class defining Host and port for service endpoint
<bindings xmlns:xsd="http://www.w3.org /2001/ XMLSchema"
90
xmlns:wsdl="http:// schemas.xmlsoap.org/wsdl/"
wsdlLocation="http:// localhost:8081/cal?wsdl"
xmlns="http: //java.sun.com/xml/ns/jaxws">
<bindings node="wsdl:definitions/wsdl:portType[@name='CallWebService ']/
wsdl:operation[@name='addTimeLinevalue ']">
<enableAsyncMapping >true</enableAsyncMapping >
</bindings >
</bindings >
Listing C.5: WSDL Binding file example, enabling asynchronous mappingfor web method
// Web service interface Class
package .......;
import ........;
/**
* This class was generated by Apache CXF 3.0.0- milestone1
* 2013 -12 -24 T00 :12:26.271+02:00
* Generated source version: 3.0.0- milestone1
*
*/
@WebService(targetNamespace = "http :// ui_milestone1.example.com/", name = "
CallWebService")
@XmlSeeAlso ({net.java.dev.jaxb.array.ObjectFactory.class })
@SOAPBinding(style = SOAPBinding.Style.RPC)
public interface CallWebService {
@WebResult(name = "return", targetNamespace = "http :// ui_milestone1.example.
com/", partName = "return")
@WebMethod(operationName = "CreateTimeSerise")
public int createTimeSerise(
@WebParam(partName = "arg0", name = "arg0")
java.lang.String arg0
);
.
.
.
.
.
.
.
// ///////////////////////////// Web Service Implementation Class
////////////////////////////////////////
/**
* This class was generated by Apache CXF 3.0.0- milestone1
* 2013 -12 -24 T00 :12:26.243+02:00
* Generated source version: 3.0.0- milestone1
*
*/
@javax.jws.WebService(
serviceName = "CallWebServiceImplService",
portName = "CallWebServiceImplPort",
targetNamespace = "http :// ui_milestone1.example.com/",
// wsdlLocation = "http :// localhost :8081/ cal?wsdl",
wsdlLocation = "http :// kappa.abo.fi :8081/ cal?wsdl",
91
endpointInterface = "com.example.ui_milestone1.
CallWebService")
public class CallWebServiceImpl implements CallWebService {
private static final Logger LOG = Logger.getLogger(CallWebServiceImpl.class.
getName ());
/* (non -Javadoc)
* @see com.example.ui_milestone1.CallWebService#createTimeSerise(java.lang.
String arg0 )*
*/
public int createTimeSerise(java.lang.String arg0) {
LOG.info("Executing operation createTimeSerise");
System.out.println(arg0);
try {
int _return = 643875396;
return _return;
} catch (java.lang.Exception ex) {
ex.printStackTrace ();
throw new RuntimeException(ex);
}
}
.
.
.
}
Listing C.6: Client Stub classes generated by WSDL2Java
92
Appendix D
Front-end API
93
Front-end architecture API
by Junaid IqbalCopyright 2014
Package
com.example.ui_milestone1
Page 2 of 41
com.example.ui_milestone1Interface CallWebService
public interface CallWebServiceextends java.rmi.Remote
All Known Implementing Classes:CallWebServiceImpl
Author:jiqbal
Methods
AddGraphPointpublic int AddGraphPoint(int x)
CreateTimeSerisepublic int CreateTimeSerise(java.lang.String SeriseName)
downloadImagepublic java.awt.Image downloadImage(java.lang.String name)
uploadImagepublic java.lang.String uploadImage(java.awt.Image data)
downloadFilepublic javax.activation.DataHandler downloadFile(java.lang.String fileName)
This method is used to download file from server with given name
Parameters:fileName
Returns:DataHandler Object
(continued on next page)
Page 3 of 41
com.example.ui_milestone1.CallWebService
(continued from last page)
createTimeLineSeriespublic int createTimeLineSeries(java.lang.String graphname, java.lang.String legend, int color, int Thickness)
This method is used to create a graph on time-line.
Parameters:graphname - : name of the graphlegend - : text to display graph on time-linecolor - : Color of graphs ( 0 - 5 ) ( red, blue, green, yellow, magenta) default is blackThickness - : thickness of graph line
Returns:
addTimeLinevaluepublic int addTimeLinevalue(java.lang.String series, java.lang.String[] values)
This method is used to add a graph point on time-line graph.
Parameters:series - : name of the graphvalues - : array of value to be added on graph
Returns:: on success returns 1 otherwise 0
SimulaterFilereadypublic int SimulaterFileready()
Returns:0 if the file is ready else not ready
SimulaterReadypublic void SimulaterReady(int status)
Parameters:status - 0 if file delivered to Simulator and Ready
Startsimulatorpublic int Startsimulator()
Returns:0 if If Start simulator command is issued
Page 4 of 41
com.example.ui_milestone1.CallWebService
helloArraypublic java.lang.String helloArray(java.lang.String[] name)
Page 5 of 41
com.example.ui_milestone1.CallWebService
com.example.ui_milestone1Class CallWebServiceImpl
java.lang.Object | +-com.example.ui_milestone1.CallWebServiceImpl
public class CallWebServiceImplextends java.lang.Objectimplements CallWebService
This class contains the implementation of Call webservice Interface. It Contains a webservice Broker object to interact with front-end
All Implemented Interfaces:CallWebService
Author:Junaid Iqbal
Fields
wbpublic com.example.ui_milestone1.WebServiceBroker wb
Constructors
CallWebServiceImplpublic CallWebServiceImpl()
Methods
downloadImagepublic java.awt.Image downloadImage(java.lang.String name)
uploadImagepublic java.lang.String uploadImage(java.awt.Image data)
AddGraphPointpublic int AddGraphPoint(int x)
Page 6 of 41
com.example.ui_milestone1.CallWebServiceImpl
CreateTimeSerisepublic int CreateTimeSerise(java.lang.String SeriseName)
downloadFilepublic javax.activation.DataHandler downloadFile(java.lang.String fileName)
addTimeLinevaluepublic int addTimeLinevalue(java.lang.String Series, java.lang.String[] values)
SimulaterFilereadypublic int SimulaterFileready()
SimulaterReadypublic void SimulaterReady(int status)
Startsimulatorpublic int Startsimulator()
createTimeLineSeriespublic int createTimeLineSeries(java.lang.String graphname, java.lang.String legend, int color, int Thickness)
helloArraypublic java.lang.String helloArray(java.lang.String[] name)
Page 7 of 41
com.example.ui_milestone1.CallWebServiceImpl
com.example.ui_milestone1Class MainView
java.lang.Object | +-VerticalLayout | +-com.example.ui_milestone1.MainView
public class MainViewextends VerticalLayout
This Main View class builds main GUI layout of Front-end architecture. This class create static instances of User pattern viewclass, Time line chart class, Option view class, Request File View class.
Author:Junaid Iqbal
Fields
serialVersionUIDprivate static final long serialVersionUID
Constant value: 1
basepathpublic static java.lang.String basepath
MAINVIEWprotected static final java.lang.String MAINVIEW
Constant value: MAINVIEW
panel Panel panel
VIEW_NAMEpublic static final java.lang.String VIEW_NAME
Constant value: MAINVIEW
URpublic static com.example.ui_milestone1.UserPatternView UR
Page 8 of 41
com.example.ui_milestone1.MainView
(continued from last page)
TLpublic static com.example.ui_milestone1.TimeLineChartView TL
SRpublic static com.example.ui_milestone1.RequestFileListView SR
OVpublic static com.example.ui_milestone1.Opts OV
ServiceStatuspublic static final Label ServiceStatus
streamFilespublic static final Button streamFiles
Constructors
MainViewpublic MainView()
Methods
enterpublic void enter(ViewChangeEvent event)
setStreamButtonpublic void setStreamButton(boolean state)
Parameters:state - of stream list view in navigation column.
Page 9 of 41
com.example.ui_milestone1.MainView
com.example.ui_milestone1Class MainView.ButtonListener
java.lang.Object | +-com.example.ui_milestone1.MainView.ButtonListener
class MainView.ButtonListenerextends java.lang.Object
This button listener class implements a button click listener class which is used to navigate between different views
Author:junaid iqbal
Fields
serialVersionUIDprivate static final long serialVersionUID
Constant value: 1
menuitem java.lang.String menuitem
Constructors
MainView.ButtonListenerpublic MainView.ButtonListener(java.lang.String menuitem)
Methods
buttonClickpublic void buttonClick(ClickEvent event)
Page 10 of 41
com.example.ui_milestone1.MainView.ButtonListener
com.example.ui_milestone1Class MainView.ResetFrontEnd
java.lang.Object | +-com.example.ui_milestone1.MainView.ResetFrontEnd
public class MainView.ResetFrontEndextends java.lang.Object
This class performs reset action of front-end. It clears all contents in Table, Clears pattern view and remove all graphs from timeline graphs.
Author:jiqbal
Constructors
MainView.ResetFrontEndpublic MainView.ResetFrontEnd()
Methods
resetpublic void reset()
Method used to reset front-end
Page 11 of 41
com.example.ui_milestone1.MainView.ResetFrontEnd
com.example.ui_milestone1Class Opts
java.lang.Object | +-VerticalLayout | +-com.example.ui_milestone1.Opts
public class Optsextends VerticalLayout
This option class perform action such as starting the web Service, generating parameter file based on stream list loaded in streamlist view
Author:jiqbal
Fields
serialVersionUIDprivate static final long serialVersionUID
Constant value: -3376621634886913057
VIEW_NAMEpublic static final java.lang.String VIEW_NAME
Constant value: OptView
SimulaterReadypublic static int SimulaterReady
SimulaterFilereadypublic static int SimulaterFileready
createDBfinal Button createDB
wpublic volatile Window w
Page 12 of 41
com.example.ui_milestone1.Opts
(continued from last page)
pbpublic final ProgressBar pb
Constructors
Optspublic Opts()
Methods
enterpublic void enter(ViewChangeEvent event)
enableDBButtonpublic void enableDBButton(boolean enb)
Page 13 of 41
com.example.ui_milestone1.Opts
com.example.ui_milestone1Class Opts.WorkThread
java.lang.Object | +-java.lang.Thread | +-com.example.ui_milestone1.Opts.WorkThread
class Opts.WorkThreadextends java.lang.Thread
All Implemented Interfaces:java.lang.Runnable
Constructors
Opts.WorkThreadOpts.WorkThread()
Methods
runpublic void run()
Page 14 of 41
com.example.ui_milestone1.Opts.WorkThread
com.example.ui_milestone1Class Opts.GenerateData
java.lang.Object | +-com.example.ui_milestone1.Opts.GenerateData
public class Opts.GenerateDataextends java.lang.Object
This class generate parameter file which used in simulation or real time environment. It create a Sqlite3 database and put allstreams lists in a database base with a sequence number. Following that it read stream count from user input pattern and selectrandom streams from database and added them to parameter list file.
Author:Junaid Iqbal
Fields
c java.sql.Connection c
stmt java.sql.Statement stmt
stmt2 java.sql.Statement stmt2
Constructors
Opts.GenerateDatapublic Opts.GenerateData()
Methods
Generatepublic void Generate()
Page 15 of 41
com.example.ui_milestone1.Opts.GenerateData
com.example.ui_milestone1Class RequestFileListView
java.lang.Object | +-VerticalLayout | +-com.example.ui_milestone1.RequestFileListView
public class RequestFileListViewextends VerticalLayout
This class deals with RequestFileView. It extends vertical view and implements Vaadin View.
Author:Junaid Iqbal
Fields
serialVersionUIDprivate static final long serialVersionUID
Constant value: 1
VIEW_NAMEpublic static final java.lang.String VIEW_NAME
Constant value: RequestFileListView
streamtablepublic final com.example.ui_milestone1.RequestFileListView.StreamTable streamtable
deleteButtonpublic final Button deleteButton
txtDimlimiterpublic final TextField txtDimlimiter
Constructors
RequestFileListViewpublic RequestFileListView()
Page 16 of 41
com.example.ui_milestone1.RequestFileListView
(continued from last page)
Methods
enterpublic void enter(ViewChangeEvent event)
Page 17 of 41
com.example.ui_milestone1.RequestFileListView
com.example.ui_milestone1Class RequestFileListView.UploadReceiverTable
java.lang.Object | +-com.example.ui_milestone1.RequestFileListView.UploadReceiverTable
class RequestFileListView.UploadReceiverTableextends java.lang.Object
Fields
serialVersionUIDprivate static final long serialVersionUID
Constant value: -1276759102490466761
filepublic java.io.File file
basepath java.lang.String basepath
Constructors
RequestFileListView.UploadReceiverTableRequestFileListView.UploadReceiverTable()
Methods
receiveUploadpublic java.io.OutputStream receiveUpload(java.lang.String filename, java.lang.String mimeType)
uploadSucceededpublic void uploadSucceeded(SucceededEvent event)
Page 18 of 41
com.example.ui_milestone1.RequestFileListView.UploadReceiverTable
uploadFailedpublic void uploadFailed(FailedEvent event)
Page 19 of 41
com.example.ui_milestone1.RequestFileListView.UploadReceiverTable
com.example.ui_milestone1Class RequestFileListView.StreamTable
java.lang.Object | +-Table | +-com.example.ui_milestone1.RequestFileListView.StreamTable
public class RequestFileListView.StreamTableextends Table
This class extends vaadin Table which is used to list user uploaded stream list.
Author:Junaid Iqbal
Fields
serialVersionUIDprivate static final long serialVersionUID
Stream Table ClassConstant value: -7944908518630432378
debugLimitpublic int debugLimit
Constructors
RequestFileListView.StreamTablepublic RequestFileListView.StreamTable()
Methods
addColumnpublic void addColumn(java.lang.Object id, java.lang.Class cls, java.lang.Object defaultValue)
Parameters:id
cls
defaultValue
Page 20 of 41
com.example.ui_milestone1.RequestFileListView.StreamTable
(continued from last page)
setColHeaderpublic void setColHeader(java.lang.Object id, java.lang.String header)
Parameters:id - Column Idheader - String Header
fillRequestTableprivate void fillRequestTable(java.lang.String fileName, java.lang.String dilimiter)
Parameters:fileName - Physical file Name to load data
headerStringpublic java.lang.String headerString()
StreamTableRefreashpublic void StreamTableRefreash(java.lang.String filename, java.lang.String dilimiter)
DeleteTableContentspublic void DeleteTableContents()
This method use to delete table contents
Page 21 of 41
com.example.ui_milestone1.RequestFileListView.StreamTable
com.example.ui_milestone1Class TimeLineChartView
java.lang.Object | +-VerticalLayout | +-com.example.ui_milestone1.TimeLineChartView
public class TimeLineChartViewextends VerticalLayout
This class create a time line view and add all required elements needed to plot a graph on time line view.
Author:Junaid Iqbal
Fields
serialVersionUIDprivate static final long serialVersionUID
Constant value: 1
VIEW_NAMEpublic static final java.lang.String VIEW_NAME
Constant value: TimeLineChartView
Startsimulatorpublic volatile int Startsimulator
calpublic java.util.Calendar cal
timelinepublic final Timeline timeline
countpublic static long count
Page 22 of 41
com.example.ui_milestone1.TimeLineChartView
refresherpublic Refresher refresher
tlspublic com.example.ui_milestone1.TimeLineChartView.TimeLineSettings tls
LOGGERprivate static final java.util.logging.Logger LOGGER
timelinevmpublic final Timeline timelinevm
Constructors
TimeLineChartViewpublic TimeLineChartView()
Methods
AddTimeLinePointpublic int AddTimeLinePoint(java.lang.String graphname, java.lang.String[] values)
This method is used by web services to plot a graph point on time line.
Parameters:graphname - : name of the time line graphvalues - : value to added on on graph
Returns:return 1 on success otherwise returns 0
AddGraphpublic boolean AddGraph(Timeline timeline, java.lang.String graphname, java.lang.String legend, int col, int thickness)
Page 23 of 41
com.example.ui_milestone1.TimeLineChartView
(continued from last page)
Parameters:graphname - Graph Name to Used to Identify Graphlegend - Caption to Used to Display on TimeLinecolor - (java.awt.color) of the GraphLinethickness - line Thickness
Returns:
createGraphDataSourcepublic Container.Indexed createGraphDataSource(java.lang.String Graphname)
Parameters:Graphname - name of the graph
Returns:indexed container with graph data source
changeAttributespublic boolean changeAttributes(Timeline timeline, java.lang.String graphname, java.awt.Color color, java.lang.String legend, int thickness)
Parameters:graphname - Name of the Graphcolor - color of the graphline (java.awt.color)legend - Caption of the Graphthickness - Line Thickness
Returns:Ture if all setting are done else return false
checkGraphNameprivate boolean checkGraphName(java.lang.String graphname, Container.Indexed container)
Parameters:graphname - String name to be checked in timeline Graphs collection.container - Container checked against the name
Returns:Ture if container is the graphname else return false
enterpublic void enter(ViewChangeEvent event)
Page 24 of 41
com.example.ui_milestone1.TimeLineChartView
com.example.ui_milestone1Class TimeLineChartView.TimeLineSettings
java.lang.Object | +-com.example.ui_milestone1.TimeLineChartView.TimeLineSettings
public class TimeLineChartView.TimeLineSettingsextends java.lang.Object
This class used to define setting for Time line graph
Author:jiqbal
Fields
CGDSpublic com.example.ui_milestone1.TimeLineChartView.CGDS CGDS
Constructors
TimeLineChartView.TimeLineSettingspublic TimeLineChartView.TimeLineSettings()
Methods
TimeLineSetpublic void TimeLineSet(Timeline timeline)
Page 25 of 41
com.example.ui_milestone1.TimeLineChartView.TimeLineSettings
com.example.ui_milestone1Class TimeLineChartView.CGDS
java.lang.Object | +-com.example.ui_milestone1.TimeLineChartView.CGDS
public class TimeLineChartView.CGDSextends java.lang.Object
Constructors
TimeLineChartView.CGDSpublic TimeLineChartView.CGDS()
Methods
createMarkerDataSourcepublic Container.Indexed createMarkerDataSource()
Creates a marker container with a marker for each seven days
Returns:indexed container with marker data source
createEventDataSourcepublic Container.Indexed createEventDataSource()
Returns:Container.Indexed containing event data source
createGraphDataSourcepublic Container.Indexed createGraphDataSource()
This class create a time line graph data source and
Returns:returns a Indexed container
Page 26 of 41
com.example.ui_milestone1.TimeLineChartView.CGDS
com.example.ui_milestone1Class Ui_milestone1UI
java.lang.Object | +-UI | +-com.example.ui_milestone1.Ui_milestone1UI
public class Ui_milestone1UIextends UI
This class is the main class for front-end architecture. This class extends Vaadin GUI class and contains static vaadin servlet classwhich is an entry point to Front-end architecture. Mainly, Front-end architecture is implemented as a servlet. This class extendsVaadin UI class and contains a servlet class which is extended from Vaadin servlet. By overriding Vaadin servlet initfunction,front-end implements its own initialising routines. After initialising the environment, it registers view with Vaadinnavigator to browse front-end. A GUI is presented to user to interact with front-end and select different options and performdifferent settings.
Author:Junaid iqbal
Fields
StreamfileNamepublic static java.lang.String StreamfileName
delimiterpublic static java.lang.String delimiter
Basepathpublic static java.lang.String Basepath
navigatorpublic static Navigator navigator
Constructors
Ui_milestone1UIpublic Ui_milestone1UI()
Page 27 of 41
com.example.ui_milestone1.Ui_milestone1UI
(continued from last page)
Methods
initprotected void init(VaadinRequest request)
Page 28 of 41
com.example.ui_milestone1.Ui_milestone1UI
com.example.ui_milestone1Class Ui_milestone1UI.Servlet
java.lang.Object | +-VaadinServlet | +-com.example.ui_milestone1.Ui_milestone1UI.Servlet
public static class Ui_milestone1UI.Servletextends VaadinServlet
Constructors
Ui_milestone1UI.Servletpublic Ui_milestone1UI.Servlet()
Page 29 of 41
com.example.ui_milestone1.Ui_milestone1UI.Servlet
com.example.ui_milestone1Class UserPatternView
java.lang.Object | +-VerticalLayout | +-com.example.ui_milestone1.UserPatternView
public class UserPatternViewextends VerticalLayout
This class used to define userpattern view layout. It Implements Vaadin view class. Main layout contains a vaadin chartcomponent. When user uploaded a arrival pattern, parses it and plot the values in chart. It also provides functionality to downloadpattern as text file.
Author:Junaid Iqbal
Fields
serialVersionUIDprivate static final long serialVersionUID
Constant value: 1
VIEW_NAMEpublic static final java.lang.String VIEW_NAME
Constant value: UserPatternView
seriespublic final ListSeries series
chartpublic final Chart chart
Constructors
UserPatternViewpublic UserPatternView()
Methods
Page 30 of 41
com.example.ui_milestone1.UserPatternView
(continued from last page)
ClearPatternViewvoid ClearPatternView()
This method clears the User pattern view by setting data series to 0
enterpublic void enter(ViewChangeEvent event)
Page 31 of 41
com.example.ui_milestone1.UserPatternView
com.example.ui_milestone1Class UserPatternView.UploadReceiverChart
java.lang.Object | +-com.example.ui_milestone1.UserPatternView.UploadReceiverChart
class UserPatternView.UploadReceiverChartextends java.lang.Object
This class implement a Receiver, SucceededListener, FailedListener. A successful upload triggers succeeded listener which in turnrun a thread to up date chart in non-blocking mode.
Author:Junaid Iqbal
Fields
serialVersionUIDprivate static final long serialVersionUID
Constant value: -1276759102490466761
seriespublic ListSeries series
filepublic java.io.File file
basepath java.lang.String basepath
Constructors
UserPatternView.UploadReceiverChartpublic UserPatternView.UploadReceiverChart(ListSeries series)
Methods
Page 32 of 41
com.example.ui_milestone1.UserPatternView.UploadReceiverChart
(continued from last page)
getSeriespublic ListSeries getSeries()
setSeriespublic void setSeries(ListSeries series)
receiveUploadpublic java.io.OutputStream receiveUpload(java.lang.String filename, java.lang.String mimeType)
uploadSucceededpublic void uploadSucceeded(SucceededEvent event)
uploadFailedpublic void uploadFailed(FailedEvent event)
Page 33 of 41
com.example.ui_milestone1.UserPatternView.UploadReceiverChart
com.example.ui_milestone1Class UserPatternView.UploadReceiverChart.UploadWorkThread
java.lang.Object | +-java.lang.Thread | +-com.example.ui_milestone1.UserPatternView.UploadReceiverChart.UploadWorkThread
class UserPatternView.UploadReceiverChart.UploadWorkThreadextends java.lang.Thread
This class create a thread to update user pattern view in a non-blocking way. It reads uploaded file and parse it. I added values fromuploaded file to series.
All Implemented Interfaces:java.lang.Runnable
Author:Junaid Iqbal
Fields
event SucceededEvent event
Constructors
UserPatternView.UploadReceiverChart.UploadWorkThreadUserPatternView.UploadReceiverChart.UploadWorkThread()
Methods
runpublic void run()
Page 34 of 41
com.example.ui_milestone1.UserPatternView.UploadReceiverChart.UploadWorkThread
com.example.ui_milestone1Class WebServiceBroker
java.lang.Object | +-com.example.ui_milestone1.WebServiceBroker
public class WebServiceBrokerextends java.lang.Object
This class used to bridge between web service implementation and front-end interface. it contains methods which interact withfront-end.
Author:Junaid Iqbal
Fields
calpublic static java.util.Calendar cal
Constructors
WebServiceBrokerpublic WebServiceBroker()
Methods
AddTimeLinePointpublic static int AddTimeLinePoint(Timeline timeline, java.lang.String graphname, java.lang.String[] values)
Parameters:timeline - : name of the time-linegraphname - : graph name on time-linevalues - : values to added on graph
Returns:: on success return 1 otherwise 0
Page 35 of 41
com.example.ui_milestone1.WebServiceBroker
(continued from last page)
AddGraphpublic static boolean AddGraph(Timeline timeline, java.lang.String graphname, java.lang.String legend, int col, int thickness)
Parameters:graphname - Graph Name to Used to Identify Graphlegend - Caption to Used to Display on TimeLinecolor - (java.awt.color) of the GraphLinethickness - line Thickness
Returns:
createGraphDataSourcepublic static Container.Indexed createGraphDataSource(java.lang.String Graphname)
Parameters:Graphname - Name is used to identify Graph
Returns:Indexed container for Timeline addGraphDataSourse Method
changeAttributespublic static boolean changeAttributes(Timeline timeline, java.lang.String graphname, java.awt.Color color, java.lang.String legend, int thickness)
Parameters:graphname - Name of the Graphcolor - color of the graphline (java.awt.color)legend - Caption of the Graphthickness - Line Thickness
Returns:Ture if all setting are done else return false
checkGraphNameprivate static boolean checkGraphName(java.lang.String graphname, Container.Indexed container)
Parameters:graphname - String name to be checked in timeline Graphs collection.container - Container checked against the name
Page 36 of 41
com.example.ui_milestone1.WebServiceBroker
(continued from last page)
Returns:Ture if container is the graphname else return false
Page 37 of 41
com.example.ui_milestone1.WebServiceBroker
com.example.ui_milestone1Class WebServices
java.lang.Object | +-com.example.ui_milestone1.WebServices
public class WebServicesextends java.lang.Object
This class is used to publish end-point with given host-name and port. Method Start service published the web service end-pointand StopSerive un-publish it
Author:Junaid Iqbal
Fields
HOSTNAMEprivate java.lang.String HOSTNAME
PORTprivate java.lang.String PORT
endpointprivate javax.xml.ws.Endpoint endpoint
statuspublic volatile boolean status
Constructors
WebServicespublic WebServices(java.lang.String HostName, java.lang.String Port)
Parameters:HostName - for end-pointPort - of end-point
Page 38 of 41
com.example.ui_milestone1.WebServices
(continued from last page)
Methods
StartServicepublic void StartService()
publishes end-point with host name and port.
StopServicepublic void StopService()
Un-publish an end-point
getStatuspublic boolean getStatus()
Returns:status of end-point
Page 39 of 41
Index
IndexA
addColumn 20
AddGraph 23, 35
AddGraphPoint 3, 6
AddTimeLinePoint 23, 35
addTimeLinevalue 4, 7
B
Basepath 27
basepath 8, 18, 32
buttonClick 10
ButtonListener 10
C
c 15
cal 22, 35
CallWebServiceImpl 6
CGDS 25, 26
changeAttributes 24, 36
chart 30
checkGraphName 24, 36
ClearPatternView 30
count 22
createDB 12
createEventDataSource 26
createGraphDataSource 24, 26, 36
createMarkerDataSource 26
createTimeLineSeries 3, 7
CreateTimeSerise 3, 7
D
debugLimit 20
deleteButton 16
DeleteTableContents 21
delimiter 27
downloadFile 3, 7
downloadImage 3, 6
E
enableDBButton 13
endpoint 38
enter 9, 13, 17, 24, 31
event 34
F
file 18, 32
fillRequestTable 21
G
Generate 15
GenerateData 15
getSeries 32
getStatus 39
H
headerString 21
helloArray 5, 7
HOSTNAME 38
I
init 27
L
LOGGER 23
M
MAINVIEW 8
MainView 9
menuitem 10
N
navigator 27
O
Opts 13
Page 40 of 41
Index
OV 9
P
panel 8
pb 13
PORT 38
R
receiveUpload 18, 33
refresher 23
RequestFileListView 16
reset 11
ResetFrontEnd 11
run 14, 34
S
serialVersionUID 8, 10, 12, 16, 18, 20, 22, 30, 32
series 30, 32
ServiceStatus 9
Servlet 29
setColHeader 20
setSeries 33
setStreamButton 9
SimulaterFileready 4, 7, 12
SimulaterReady 4, 7, 12
SR 9
StartService 38
Startsimulator 4, 7, 22
status 38
stmt 15
stmt2 15
StopService 39
StreamfileName 27
streamFiles 9
StreamTable 20
streamtable 16
StreamTableRefreash 21
T
timeline 22
TimeLineChartView 23
TimeLineSet 25
TimeLineSettings 25
timelinevm 23
TL 9
tls 23
txtDimlimiter 16
U
Ui_milestone1UI 27
uploadFailed 19, 33
uploadImage 3, 6
UploadReceiverChart 32
UploadReceiverTable 18
uploadSucceeded 18, 33
UploadWorkThread 34
UR 8
UserPatternView 30
V
VIEW_NAME 8, 12, 16, 22, 30
W
w 12
wb 6
WebServiceBroker 35
WebServices 38
WorkThread 14
Page 41 of 41
Index