56
1 CHAPTER-1 INTRODUCTION 1.1 OVERVIEW For cloud services to be portable, their management must also be portable to the targeted environment, as must the application components themselves. Here, the authors show how plans in the Topology and Orchestration Specification for Cloud Applications (TOSCA) can enable portability of these operational aspects underneath all the hype, the essence of cloud computing is the industrialization of IT. Similar to mass production lines in other industries (such as the auto industry), cloud computing standardizes offered services and thus increases automation significantly. Consequently, enterprises are increasingly utilizing cloud technology; however, major challenges such as portability, standardization of service definitions, and security remain inadequately addressed. The ability to move cloud services and their components between providers ensures an adequate and cost-efficient IT environment and avoids vendor lock-in. Research has already addressed movability and migration on a functional level.1,2 However, no one has yet examined cloud service portability with regard to management and operational tasks, which are a significant and increasing cost factor. One reason is the lack of an industry standard for defining composite applications and their management. Without an appropriate standardized format, ensuring compliance, trust, and security the biggest area of critique preventing the cloud’s wider adoption is difficult. Dealing with these challenges in industry and research has the potential to bring cloud computing to the next level. TOSCA will enable the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behavior of these services (e.g., deploy, patch, shutdown)--independent of the supplier creating the service, and any particular cloud provider or hosting technology. TOSCA will also make it possible for higher-level operational behavior to be associated with cloud infrastructure management.

Portable Cloud Services Using Tosca

Embed Size (px)

Citation preview

Page 1: Portable Cloud Services Using Tosca

1

CHAPTER-1

INTRODUCTION

1.1 OVERVIEW

For cloud services to be portable, their management must also be portable to

the targeted environment, as must the application components themselves. Here, the

authors show how plans in the Topology and Orchestration Specification for Cloud

Applications (TOSCA) can enable portability of these operational aspects underneath

all the hype, the essence of cloud computing is the industrialization of IT. Similar to

mass production lines in other industries (such as the auto industry), cloud computing

standardizes offered services and thus increases automation significantly.

Consequently, enterprises are increasingly utilizing cloud technology; however, major

challenges such as portability, standardization of service definitions, and security

remain inadequately addressed. The ability to move cloud services and their

components between providers ensures an adequate and cost-efficient IT environment

and avoids vendor lock-in. Research has already addressed movability and migration

on a functional level.1,2 However, no one has yet examined cloud service portability

with regard to management and operational tasks, which are a significant and

increasing cost factor. One reason is the lack of an industry standard for defining

composite applications and their management. Without an appropriate standardized

format, ensuring compliance, trust, and security the biggest area of critique preventing

the cloud’s wider adoption is difficult. Dealing with these challenges in industry and

research has the potential to bring cloud computing to the next level.

TOSCA will enable the interoperable description of application and

infrastructure cloud services, the relationships between parts of the service, and the

operational behavior of these services (e.g., deploy, patch, shutdown)--independent of

the supplier creating the service, and any particular cloud provider or hosting

technology. TOSCA will also make it possible for higher-level operational behavior

to be associated with cloud infrastructure management.

Page 2: Portable Cloud Services Using Tosca

2

Fig 1.1 Service Template Architecture

1.2 SYSTEM ANALYSIS

1.2.1 EXISTING SYSTEM:

In the existing system portability, standardization of service definitions and

security remain inadequately addressed. The ability to move cloud services and their

components between providers ensures an adequate and cost-efficient IT environment

and avoids vendor lock-in. The immovability and migration on function level with

Page 3: Portable Cloud Services Using Tosca

3

regard to management and operational tasks, which are a significant and increasing

cost factor.

Disadvantages:

1) Portability, standardization of service definitions, and security is not effective in

existing system.

2) The industry standard for defining composite applications is not efficient.

1.2.2 PROPOSED SYSTEM:

In the offering phase, the cloud service provider creates a cloud service

offering based on a service template, adding all provider- and offering-specific

information. This includes aspects such as pricing and specific technical information

such as IP address range and application configurations. Finally, the offering is

published in a service catalog. In the subscription and instantiation phase, the cloud

service consumer browsing the service catalog can select and subscribe to the

respective offering. The consumer customizes the service through points of variability

(for example, selecting “small,” “medium,” or “large” for the service’s size), signs a

contract, and accepts the offering’s terms and conditions. This subscription process

triggers the instantiation of the cloud service instance. The cloud management

platform aggregates all the required resources from the common resource pools, for

example infrastructure components, and automatically deploys, installs, and

configures the service’s necessary pieces.

Advantages: 1) The management aspects of cloud services in a reusable way.

2) Use existing workflow technologies and research results to facilitate the portable,

automated, and reusable management of cloud services throughout their life cycle

Page 4: Portable Cloud Services Using Tosca

4

CHAPTER-2

LITERATURE STUDY

2.1 FEASIBILITY STUDY

The Feasibility of the project is analyzed in this phase and business is put forth

with a very general plan for the project and some cost estimates. During system

analysis the feasibility study of the proposed system is to be carried out. This is to

ensure that the proposed system is not a burden to the company. For feasibility

analysis, some understanding of the major requirements for the system is essential.

Seven key consideration involved in the feasibility analysis are

Economic feasibility study

Technical feasibility study

Schedule feasibility study

Organizational feasibility study

Cultural feasibility study

Legal feasibility study

Marketing feasibility study

2.1.1 ECONOMIC FEASIBILITY STUDY:

This involves questions such as whether the firm can afford to build the

system, whether its benefits should substantially exceed its costs, and whether the

project has higher priority and profits than other projects that might use the same

resources. This also includes that whether the project is in the condition to fulfill all

the eligibility criteria and the responsibility of both sides in case there are two parties

involved in performing any project.

2.1.2 TECHNICAL FEASIBILITY STUDY:

This involves questions such as whether the technology needed for the system

exists, how difficult it will be to build, and whether the firm has enough experience

using that technology. The assessment is based on an outline design of system

Page 5: Portable Cloud Services Using Tosca

5

requirements in terms of Input, Output, Fields, Programs, and Procedures. This can be

qualified in terms of volumes of data, trends, frequency of updating, etc.in order to

give an introduction of technical system.

2.1.3 SCHEDULE FEASIBILITY STUDY:

This involves questions such as how much time is available to build the new

system, when it can be built (i.e. during holidays), interference with normal business

operation, etc.

2.1.4 ORGANIZATIONAL FEASIBILITY STUDY:

This involves questions such as whether the system has enough support to be

implemented successfully, whether it brings an excessive amount of change, and

whether the organization is changing too rapidly to absorb it.

2.1.5 CULTURAL FEASIBILITY STUDY:

In this stage, the project's alternatives are evaluated for their impact on the

local and general culture. For example, environmental factors need to be considered.

2.1.6 Legal Feasibility study:

Not necessarily last, but all projects must face legal scrutiny. When an

organization either has legal council on staff or on retainer, such reviews are typically

standard. However, any project may face legal issues after completion too.

2.1.7 MARKETING FEASIBILITY STUDY:

This will include analysis of single and multi-dimensional market forces that

could affect the commercialization or success of a project's actual revenue (sales)

potential.

Page 6: Portable Cloud Services Using Tosca

6

CHAPTER-3

DESIGN

3.1 SOFTWARE AND HARDWARE REQUIRMENT SPECIFICATION

Software Requirements:

Front End : JSP,HTML

Language : Java

Back End : MySQL

Operating system : Windows XP

Hardware Requirements:

RAM : 512 MB

Hard Disk : 80 GB

Processor : Pentium IV

3.2 SYSTEM DESIGN

INPUT DESIGN:

Input design is the process of converting a user oriented description of the

inputs to a computer based business system into a program oriented specification.

The objectives in the input design:

To produce a cost-effective method of input.

To achieve a highest possible level of accuracy.

To ensure that input is acceptable to and understood by the user staff.

Page 7: Portable Cloud Services Using Tosca

7

INPUT STAGES

Several activities have to be carried out as a part of the overall input process. They

include

Data Recording – Collection of data at its source.

Data Description – Transfer of data to an input form

Data Conversion – Conversion of the input data to a computer acceptable

medium.

Data Verification – Checking the conversion

Data Control – Checking the accuracy and controlling the flow of data to the

computer.

Data Transmission – Transmission or transferring the data to the computer.

Data Validation – Checking the input data by program when it enters the

computer system.

Data Correction – Correction the errors that are found at any early stages.

OUTPUT DESIGN:

The output design is an ongoing activity almost from the beginning of the

project, and follows the principles of form design. Effects and well define an output

design improves the relationship of system and the user, thus facilitating decision-

making. A major form of output is a hard copy from the printer, however soft copies

re available.

The Types of output used in the system are: -

Internal outputs: Whose destination is within the organization and is the

user’s main interface with the computer.

Interactive outputs: This involves the user in communicating directly with

the computer.

External outputs: Whose destination is outside the organization and which

require special attention since they project the image of the organization.

Page 8: Portable Cloud Services Using Tosca

8

3.3 UML DIAGRAMS

3.3.1 CLASS DIAGRAM:

Fig 3.1 Class Diagram

administratorusernamepassword

login()logout()addOrganization()activateAccount()vieworganization()block()

organization adminsunamepasswordnameaddressmobile numberwebsiteEmailorganization admin

login()logout()createTeam()addEmp()activateEmp()viewEmp()

Employeesunamepasswordseckeyscepwdempnamedesignationteamrights

login()logout()createfile()uploadfile()downloadfile()viewfile()

filesfilenamefileType

Page 9: Portable Cloud Services Using Tosca

9

3.3.2 USECASE DIAGRAM:

Fig 3.2 use case for ADMIN

Add Organization

View Organization

Block Account

Login

Logout

Admins

Activate Account

Page 10: Portable Cloud Services Using Tosca

10

Fig 3.3 use case for ORGANIZATIONAL ADMIN

Create Team

Add Employees

View Employees

activate Account

Organization Admin

Logout

Change password

Login

Page 11: Portable Cloud Services Using Tosca

11

Fig 3.4 use case for EMPLOYEES

create file

upload file

view file

Download File

Log out

Employee

Login

Page 12: Portable Cloud Services Using Tosca

12

3.3.3 ACTIVITY DIAGRAM:

An activity diagram is characterized by states that denote various operations.

Transition from one state to the other is triggered by completion of the operation. The

purpose of an activity is symbolized by round box, comprising the name of the

operation. An operation symbol indicates the execution of that operation. This activity

diagram depicts the internal state of an object.

Fig 3.5 Activity Diagram for ADMIN

login

add

view organization

block

activate

Page 13: Portable Cloud Services Using Tosca

13

Fig 3.6 Activity Diagram for ORGANIZATION ADMIN

login

create team add employees block activate

logout

Page 14: Portable Cloud Services Using Tosca

14

Fig 3.7 Activity Diagram for EMPLOYEES

login

create file upload file download file view file

logout

Page 15: Portable Cloud Services Using Tosca

15

3.4.4 SEQUENCE DIAGRAM:

The sequence diagrams are an easy and intuitive way of describing the

system’s behavior, which focuses on the interaction between the system and the

environment. The sequence diagram has two dimensions: the vertical dimension

represents the time, the horizontal dimension represents different objects. The vertical

line also called the object’s lifeline represents the object’s existence during the

interaction.

Fig 3.8 Sequence Diagram for ADMIN

Admin organization Data Base

add organization

Store data in data base

organization added

view organizationfetch from DB

return datadisplay

Block Account

Activate Account

Log out

Page 16: Portable Cloud Services Using Tosca

16

Fig 3.9 Sequence Diagram for ORGANIZATION ADMIN

oraganization admin

Employee

add employee

login

view employee

Activate Account

check availability

create team

Page 17: Portable Cloud Services Using Tosca

17

Fig 3.10 Sequence Diagram for EMPLOYEES

employee file

login

create file

upload file

view file

delete file

download file

log out

Page 18: Portable Cloud Services Using Tosca

18

3.5 DATABASE TABLES

TABLE 3.1:

TABLE 3.1: Organization Details

TABLE 3.2:

TABLE 3.2: Employee Details

Page 19: Portable Cloud Services Using Tosca

19

TABLE 3.3:

TABLE 3.3: Login Details

TABLE 3.4:

TABLE 3.4: File Details

Page 20: Portable Cloud Services Using Tosca

20

TABLE 3.5:

TABLE 3.5: Team Details

Page 21: Portable Cloud Services Using Tosca

21

CHAPTER-4

IMPLEMENTATION

4.1 MODULE DESCRIPTION The main module involved in this project is:

1. Cloud Computing Reference Architecture(CCRA)

2. Cloud Service Life Cycle

3. Topology and Orchestration Specification

4. Planning Of Topology

5. Portability Of Plan

4.1.1 CLOUD COMPUTING REFERENCE ARCHITECTURE (CCRA):

Cloud Computing Reference Architecture (CCRA) defines three main roles

typically encountered in any cloud computing environment: the cloud service creator,

cloud service and cloud service consumer. The service creator develops cloud

services; the service provider runs those services, and provides them to service

consumers, which can also be IT systems. Consumers can be billed for all (or a subset

of) their interactions with cloud services and the provisioned service instances.

4.1.2 CLOUD SERVICE LIFE CYCLE:

In the definition phase, all management knowledge required for the specific

cloud service in particular, how to instantiate is captured in a service template. This

knowledge includes information about the cloud service’s internal structure along

with operational and management aspects to build, manage, and terminate cloud

services. In the offering phase, the cloud service provider creates a cloud service

offering based on a service template, adding all provider- and offering-specific

information. This includes aspects such as pricing and specific technical information

such as IP address range and application configurations. In instantiation phase, the

cloud service consumer browsing the service catalog can select and subscribe to the

respective offering. The consumer customizes the service through points of variability

Page 22: Portable Cloud Services Using Tosca

22

signs a contract, and accepts the offering’s terms and conditions. In the life cycle’s

production phase, the cloud management platform uses management plans to manage

the service instance for compliance with the service-level agreements (SLAs)

negotiated at subscription time.

4.1.3 TOPOLOGY AND ORCHESTRATION SPECIFICATION:

TOSCA describes composite applications and their management in a modular

and portable fashion. It thus defines service templates that contain a cloud service’s

topology and its operational aspects to deploy, terminate, and manage. The creator

of a cloud service captures its structure in a service topology graph with nodes and

relationships. TOSCA specifies the meta model for types and templates that is, the

language for defining them. Concrete types aren’t part of the specification and must

be standardized by the respective domain expert groups. Nodes in particular define a

range of information to deploy, terminate, and manage the cloud service: instance

states represent the node’s internal state during production as part of the topology

4.1.4 PLANNING OF TOPOLOGY:

Plans use the cloud service topology in three ways: First, plans orchestrate the

management interfaces and operations defined in TOSCA nodes. Operations are

described in the Web Services Description Language (WSDL), Representational State

Transfer (REST), or scripts that implement particular management operations on the

respective node. Second the service template is instantiate. Second, plans can inspect

the topology model to access a service’s nodes and relationships. This enables flexible

plans whose behavior is based on the topology and changes there in the respective

nodes. Finally, plans read and write a service’s instance information that is, the node’s

instance state, such as properties containing credentials, IP addresses, and so on.

4.1.5 PORTABILITY OF PLAN:

TOSCA plans’ portability is inherited from the workflow language and

engines used. In TOSCA, these services are explicitly described in the nodes as

operations. For operations referencing external services, portability isn’t a problem.

Page 23: Portable Cloud Services Using Tosca

23

TOSCA models contain myriad references to files, such as those with additional

TOSCA definitions, plans, and other artifacts. TOSCA allows service creators to

gather into plans those activities necessary to deploy, manage, and terminate the

described cloud service.

4.2 SYSTEM IMPLEMENTAION

Implementation is that stage of the project when the theoretical design is

turned into a working system. After testing the modules successfully, the necessary

privileges are given to the users. All the users are requested to handle the system

carefully. The real time problems that occur are successfully solved. The objective is

to put the tested system into operation. It consists of

1. Testing the developed program with sample data.

2. Detection and corrections of errors.

3. Making necessary changes in the system.

4. Checking of reports.

5. Creating computer compatible files.

6. Installation of hardware and software utilities.

An implementation description that shows implementation details for each

operation implied by message that is passes to an object. Implementation details

include information about the objects private part; that is, internal details about the

data structure that describe the objects attributes and procedural details that describe

operations.

An implementation description of an object provides the internal details that

are required for implementation but are not necessary for invocation. That is, the

designer of the object must provide an implementation description and must therefore

create the internal details of the object. However, another designer or implementer

who uses the object or other instances of the object requires only the protocol

description but not the implementation description.

Page 24: Portable Cloud Services Using Tosca

24

This system is implemented by installing the software on a machine with

Windows 2000 environment and connected to a network. The application is run to

check if it retrieves the necessary information from remote machines and thereby the

application is tested to check for consistency of output and for various kinds of input

data.

The module concerning the remote access of the server is also implemented in

an internet installed environment. The entire desktop control of any server of any

network is retrieved enabling to control the entire network in the Internet. The

software is implemented by giving the IPAddress of the server foreign countries and

found to work as intended. The grid resolution facility and the compression level also

working in a very perfect manner.

It is therefore advised to connect the server in the Internet by IP Address and

then control the network which enables the desktop contrail of the hosts also. The

server can be connected in any system provided with an Internet server.

4.3 JAVA TECHNOLOGY

About Java:

Initially the language was called as “oak” but it was renamed as “Java” in 1995.

The primary motivation of this language was the need for a platform-independent

(i.e., architecture neutral) language that could be used to create software to be

embedded in various consumer electronic devices.

Java is a programmer’s language.

Java is cohesive and consistent.

Except for those constraints imposed by the Internet environment, Java gives the

programmer, full control.

Finally, Java is to Internet programming where C was to system programming.

Importance of Java to the Internet:

Java has had a profound effect on the Internet. This is because; Java expands

the Universe of objects that can move about freely in Cyberspace. In a network, two

categories of objects are transmitted between the Server and the Personal computer.

Page 25: Portable Cloud Services Using Tosca

25

They are: Passive information and Dynamic active programs. The Dynamic, Self-

executing programs cause serious problems in the areas of Security and probability.

But, Java addresses those concerns and by doing so, has opened the door to an

exciting new form of program called the Applet.

Java can be used to create two types of programs:

Applications and Applets: An application is a program that runs on our Computer

under the operating system of that computer. It is more or less like one creating using

C or C++. Java’s ability to create Applets makes it important. An Applet is an

application designed to be transmitted over the Internet and executed by a Java –

compatible web browser.

An applet is actually a tiny Java program, dynamically downloaded across the

network, just like an image. But the difference is, it is an intelligent program, not just

a media file. It can react to the user input and dynamically change.

FEATURES OF JAVA

Security:

Every time you that you download a “normal” program, you are risking a viral

infection. Prior to Java, most users did not download executable programs frequently,

and those who did scanned them for viruses prior to execution. Most users still

worried about the possibility of infecting their systems with a virus. In addition,

another type of malicious program exists that must be guarded against. This type of

program can gather private information, such as credit card numbers, bank account

balances, and passwords. Java answers both of these concerns by providing a

“firewall” between a networked application and your computer.

When you use a Java-compatible Web browser, you can safely download Java

applets without fear of virus infection or malicious intent.

Portability:

For programs to be dynamically downloaded to all the various types of

platforms connected to the Internet, some means of generating portable executable

code is needed .As you will see, the same mechanism that helps ensure security also

Page 26: Portable Cloud Services Using Tosca

26

helps create portability. Indeed, Java’s solution to these two problems is both elegant

and efficient.

The Byte code:

The key that allows the Java to solve the security and portability problems is

that the output of Java compiler is Byte code. Byte code is a highly optimized set of

instructions designed to be executed by the Java run-time system, which is called the

Java Virtual Machine (JVM). That is, in its standard form, the JVM is an interpreter

for byte code.

Translating a Java program into byte code helps makes it much easier to run a

program in a wide variety of environments. The reason is, Once the run-time package

exists for a given system, any Java program can run on it.

Although Java was designed for interpretation, there is technically nothing

about Java that prevents on-the-fly compilation of byte code into native code. Sun has

just completed its Just In Time (JIT) compiler for byte code. When the JIT compiler is

a part of JVM, it compiles byte code into executable code in real time, on a piece-by-

piece, demand basis. It is not possible to compile an entire Java program into

executable code all at once, because Java performs various run-time checks that can

be done only at run time. The JIT compiles code, as it is needed, during execution.

Java, Virtual Machine (JVM):

Beyond the language, there is the Java virtual machine. The Java virtual

machine is an important element of the Java technology. The virtual machine can be

embedded within a web browser or an operating system. Once a piece of Java code is

loaded onto a machine, it is verified. As part of the loading process, a class loader is

invoked and does byte code verification makes sure that the code that’s has been

generated by the compiler will not corrupt the machine that it’s loaded on. Byte code

verification takes place at the end of the compilation process to make sure that is all

accurate and correct. So byte code verification is integral to the compiling and

executing of Java code.

Page 27: Portable Cloud Services Using Tosca

27

Javac .Java .Class

The above picture shows the typical Java programming uses to produce byte

codes and executes them. The first box indicates that the Java source code is located

in a. Java file that is processed with a Java compiler called java. The Java compiler

produces a file called a. class file, which contains the byte code. The class file is then

loaded across the network or loaded locally on your machine into the execution

environment is the Java virtual machine, which interprets and executes the byte code.

Java Architecture:

Java architecture provides a portable, robust, high performing environment for

development. Java provides portability by compiling the byte codes for the Java

Virtual Machine, which are then interpreted on each platform by the run-time

environment. Java is a dynamic system, able to load code when needed from a

machine in the same room or across the planet.

Compilation of code:

When you compile the code, the Java compiler creates machine code (called

byte code) for a hypothetical machine called Java Virtual Machine (JVM). The JVM

is supposed to execute the byte code. The JVM is created for overcoming the issue of

portability. The code is written and compiled for one machine and interpreted on all

machines. This machine is called Java Virtual Machine.

Java

Java byte code

Java VM

Page 28: Portable Cloud Services Using Tosca

28

Compiling and interpreting Java Source Code

During run-time the Java interpreter tricks the byte code file into thinking that

it is running on a Java Virtual Machine. In reality this could be a Intel Pentium

Windows 95 or SunSARC station running Solaris or Apple Macintosh running system

and all could receive code from any computer through Internet and run the Applets.

Source

Code

………..

………..

Windows 32

Macintosh

SPARC

Java

Byte code

Java

Interpreter

(PC)

Java

Interpreter

Java

Interpreter

Page 29: Portable Cloud Services Using Tosca

29

Simple

Java was designed to be easy for the Professional programmer to learn and to

use effectively. If you are an experienced C++ programmer, learning Java will be

even easier. Because Java inherits the C/C++ syntax and many of the object oriented

features of C++. Most of the confusing concepts from C++ are either left out of Java

or implemented in a cleaner, more approachable manner. In Java there are a small

number of clearly defined ways to accomplish a given task.

Object-Oriented

Java was not designed to be source-code compatible with any other language.

This allowed the Java team the freedom to design with a blank slate. One outcome of

this was a clean usable, pragmatic approach to objects. The object model in Java is

simple and easy to extend, while simple types, such as integers, are kept as high-

performance non-objects.

Robust

The multi-platform environment of the Web places extraordinary demands on

a program, because the program must execute reliably in a variety of systems. The

ability to create robust programs was given a high priority in the design of Java. Java

is strictly typed language; it checks your code at compile time and run time.

Java virtually eliminates the problems of memory management and de

allocation, which is completely automatic. In a well-written Java program, all run

time errors can –and should –be managed by your program.

4.4 JAVASCRIPT

JavaScript is a script-based programming language which was developed by

Netscape Communication Corporation. JavaScript was originally called Live Script

and renamed as JavaScript to indicate its relationship with Java.

JavaScript supports the development of both client and server components of

Web-based applications. On the client side, it can be used to write programs that are

executed by a Web browser within the context of a Web page. On the server side, it

can be used to write Web server programs that can process information submitted by a

Web browser and then updates the browser’s display accordingly

Page 30: Portable Cloud Services Using Tosca

30

Even though JavaScript supports both client and server Web programming, we

prefer JavaScript at Client side programming since most of the browsers supports it.

JavaScript is almost as easy to learn as HTML, and JavaScript statements can

be included in HTML documents by enclosing the statements between a pair of

scripting tags <SCRIPTS>. </SCRIPT>.

<SCRIPT LANGUAGE = “JavaScript”>

JavaScript statements

</SCRIPT>

Here are a few things we can do with JavaScript :

Validate the contents of a form and make calculations.

Add scrolling or changing messages to the Browser’s status line.

Animate images or rotate images that change when we move the mouse over

them.

Detect the browser in use and display different content for different browsers.

Detect installed plug-ins and notify the user if a plug-in is required.

We can do much more with JavaScript, including creating entire application.

JavaScript Vs Java:

JavaScript and Java are entirely different languages. A few of the most glaring

differences are:

Java applets are generally displayed in a box within the web document; JavaScript

can affect any part of the Web document itself.

While JavaScript is best suited to simple applications and adding interactive

features to Web pages; Java can be used for incredibly complex applications.

There are many other differences but the important thing to remember is that

JavaScript and Java are separate languages. They are both useful for different

things; in fact they can be used together to combine their advantages.

ADVANTAGES:

JavaScript can be used for Sever-side and Client-side scripting.

Page 31: Portable Cloud Services Using Tosca

31

It is more flexible than VBScript.

JavaScript is the default scripting languages at Client-side since all the

browsers supports it.

4.5 JDBC (Java Data Base Connectivity)

What Is JDBC?

JDBC is a Java API for executing SQL statements. (As a point of interest,

JDBC is a trademarked name and is not an acronym; nevertheless, JDBC is often

thought of as standing for Java Database Connectivity. It consists of a set of classes

and interfaces written in the Java programming language. JDBC provides a standard

API for tool/database developers and makes it possible to write database applications

using a pure Java API.

Using JDBC, it is easy to send SQL statements to virtually any relational

database. One can write a single program using the JDBC API, and the program will

be able to send SQL statements to the appropriate database. The combinations of Java

and JDBC lets a programmer write it once and run it anywhere.

What Does JDBC Do?

Simply put, JDBC makes it possible to do three things:

establish a connection with a database

send SQL statements

Process the results.

JDBC versus ODBC and other APIs

At this point, Microsoft's ODBC (Open Database Connectivity) API is that

probably the most widely used programming interface for accessing relational

databases. It offers the ability to connect to almost all databases on almost all

platforms.

So why not just use ODBC from Java? The answer is that you can use ODBC

from Java, but this is best done with the help of JDBC in the form of the JDBC-

ODBC Bridge, which we will cover shortly.

Page 32: Portable Cloud Services Using Tosca

32

The question now becomes "Why do you need JDBC?"

There are several answers to this question:

1. ODBC is not appropriate for direct use from Java because it uses a C interface.

Calls from Java to native C code have a number of drawbacks in the security,

implementation, robustness, and automatic portability of applications.

2. A literal translation of the ODBC C API into a Java API would not be

desirable. For example, Java has no pointers, and ODBC makes copious use of

them, including the notoriously error-prone generic pointer "void *". You can

think of JDBC as ODBC translated into an object-oriented interface that is

natural for Java programmers.

3. ODBC is hard to learn. It mixes simple and advanced features together, and it

has complex options even for simple queries. JDBC, on the other hand, was

designed to keep simple things simple while allowing more advanced

capabilities where required.

4. A Java API like JDBC is needed in order to enable a "pure Java" solution.

When ODBC is used, the ODBC driver manager and drivers must be manually

installed on every client machine. When the JDBC driver is written completely

in Java, however, JDBC code is automatically installable, portable, and secure

on all Java platforms from network computers to mainframes.

Two-tier and three-tier Models:

The JDBC API supports both two-tier and three-tier models for database access.

In the two-tier model, a Java applet or application talks directly to the

database. This requires a JDBC driver that can communicate with the particular

database management system being accessed. A user's SQL statements are delivered

to the database, and the results of those statements are sent back to the user. The

database may be located on another machine to which the user is connected via a

network. This is referred to as a client/server configuration, with the user's machine as

the client, and the machine housing the database as the server. The network can be an

Intranet, which, for example, connects employees within a corporation, or it can be

the Internet.

Page 33: Portable Cloud Services Using Tosca

33

Client machine

DBMS-proprietary protocol

Database server

In the three-tier model, commands are sent to a "middle tier" of services,

which then send SQL statements to the database. The database processes the SQL

statements and sends the results back to the middle tier, which then sends them to the

user. MIS directors find the three-tier model very attractive because the middle tier

makes it possible to maintain control over access and the kinds of updates that can be

made to corporate data. Another advantage is that when there is a middle tier, the user

can employ an easy-to-use higher-level API which is translated by the middle tier into

the appropriate low-level calls. Finally, in many cases the three-tier architecture can

provide performance advantages.

Client machine (GUI)

HTTP, RMI, or CORBA calls

Server machine (business logic)

DBMS-proprietary protocol

Database server

JAVA

Application

JDBC

DBMS

Java applet or

Html browser

Application Server (Java)

DBMS

Page 34: Portable Cloud Services Using Tosca

34

Until now the middle tier has typically been written in languages such as C or

C++, which offer fast performance. However, with the introduction of optimizing

compilers that translate Java byte code into efficient machine-specific code, it is

becoming practical to implement the middle tier in Java. This is a big plus, making it

possible to take advantage of Java's robustness, multithreading, and security features.

JDBC is important to allow database access from a Java middle tier.

JDBC Driver Types:

The JDBC drivers that we are aware of at this time fit into one of four

categories:

JDBC-ODBC bridge plus ODBC driver

Native-API partly-Java driver

JDBC-Net pure Java driver

Native-protocol pure Java driver

JDBC-ODBC Bridge:

If possible, use a Pure Java JDBC driver instead of the Bridge and an ODBC

driver. This completely eliminates the client configuration required by

ODBC. It also eliminates the potential that the Java VM could be corrupted by

an error in the native code brought in by the Bridge (that is, the Bridge native library,

the ODBC driver manager library, the ODBC driver library, and the database client

library).

What Is the JDBC- ODBC Bridge?

The JDBC-ODBC Bridge is a JDBC driver, which implements JDBC

operations by translating them into ODBC operations. To ODBC it appears as a

normal application program. The Bridge implements JDBC for any database for

which an ODBC driver is available. The Bridge is implemented as the

sun.jdbc.odbc Java package and contains a native library used to access

ODBC. The Bridge is a joint development of Intersolv and JavaSoft.

Page 35: Portable Cloud Services Using Tosca

35

FEATURES OF ORACLE:

Some of the features of Oracle supported for the project are as follows:

Large Database Management System:

Oracle supports large databases potentially tera bytes in size.

Many Concurrent database users:

Oracle supports large numbers of concurrent users executing a variety of database

applications operating on the same data. It minimizes data contention and

guarantees data concurrency.

High transaction processing performance:

Oracle maintains the preceding features with a high degree of overall system

performance. Database users do not suffer from slow processing performance.

Security:

By providing proper authentication oracle provides security to the database users.

4.5 JAVA SERVER PAGES (JSP)

Java server Pages is a simple, yet powerful technology for creating and maintaining

dynamic-content web pages. Based on the Java programming language, Java Server

Pages offers proven portability, open standards, and mature re-usable component

model .The Java Server Pages architecture enables the separation of content

generation from content presentation. This separation not eases maintenance

headaches; it also allows web team members to focus on their areas of expertise.

Now, web page designer can concentrate on layout, and web application designers on

programming, with minimal concern about impacting each other’s work.

Features of JSP:

Portability:

Java Server Pages files can be run on any web server or web-enabled application

Server that provides support for them. Dubbed the JSP engine, this support

Involves recognition, translation, and management of the Java Server Page

Lifecycle and its interaction components.

Page 36: Portable Cloud Services Using Tosca

36

Components:

It was mentioned earlier that the Java Server Pages architecture can include

reusable Java components. The architecture also allows for the embedding of a

scripting language directly into the Java Server Pages file. The components current

supported include Java Beans, and Servlets.

Processing:

A Java Server Pages file is essentially an HTML document with JSP scripting

or tags. The Java Server Pages file has a JSP extension to the server as a Java Server

Pages file. Before the page is served, the Java Server Pages syntax is parsed and

processed into a Servlet on the server side. The Servlet that is generated outputs real

content in straight HTML for responding to the client.

Access Models:

A Java Server Pages file may be accessed in at least two different ways. A

client’s request comes directly into a Java Server Page. In this scenario, suppose the

page accesses reusable JavaBeans components that perform particular well-defined

computations like accessing a database. The result of the Beans computations, called

result sets are stored within the Bean as properties. The page uses such Beans to

generate dynamic content and present it back to the client.

In both of the above cases, the page could also contain any valid Java code.

Java Server Pages architecture encourages separation of content from presentation.

Steps in the execution of a JSP Application:

1. The client sends a request to the web server for a JSP file by giving the

name of the JSP file within the form tag of a HTML page.

2. This request is transferred to the JavaWebServer. At the server side

JavaWebServer receives the request and if it is a request for a jsp file server

gives this request to the JSP engine.

3. JSP engine is program which can understand the tags of the jsp and then it

converts those tags into a Servlet program and it is stored at the server side.

This Servlet is loaded in the memory and then it is executed and the result

Page 37: Portable Cloud Services Using Tosca

37

is given back to the JavaWebServer and then it is transferred back to the

result is given back to the JavaWebServer and then it is transferred back to

the client .

The JDBC provides database-independent connectivity between the J2EE

platform and a wide range of tabular data sources. JDBC technology allows an

Application Component Provider to:

Perform connection and authentication to a database server

Manager transactions

Move SQL statements to a database engine for preprocessing and

execution

Execute stored procedures

Inspect and modify the results from Select statements

ROLE OF ORACLE IN DATABASE:

ORACLE 8i is one of the many database services that plug into a client /

server model. It works efficiently to manage resources, a database information,

among the multiple clients requesting & sending.

STRUCTURED QUERY LANGUAGE (SQL):

SQL is an inter-active language used to query the database and access data in

database. SQL has the following features:

1. It is a unified language.

2. It is a common language for relational database

3. It is a non-procedural language.

Page 38: Portable Cloud Services Using Tosca

38

CHAPTER-5

TESTING

5.1 INTRODUCTION

The purpose of testing is to discover errors. Testing is the process of trying to

discover every conceivable fault or weakness in a work product. It provides a way to

check the functionality of components, sub assemblies, assemblies and/or a finished

product It is the process of exercising software with the intent of ensuring that the

Software system meets its requirements and user expectations and does not fail in an

unacceptable manner. There are various types of test. Each test type addresses a

specific testing requirement.

Software testing is a critical element of software quality assurance and

represents the ultimate review of specification, design and coding. In fact, testing is

the one step in the software engineering process that could be viewed as destructive

rather than constructive.

A strategy for software testing integrates software test case design methods

into a well-planned series of steps that result in the successful construction of

software. Testing is the set of activities that can be planned in advance and conducted

systematically. The underlying motivation of program testing is to affirm software

quality with methods that can economically and effectively apply to both strategic to

both large and small-scale systems.

5.2 STRATEGIC APPROACH TO SOFTWARE TESTING

The software engineering process can be viewed as a spiral. Initially system

engineering defines the role of software and leads to software requirement analysis

where the information domain, functions, behavior, performance, constraints and

validation criteria for software are established. Moving inward along the spiral, we

Page 39: Portable Cloud Services Using Tosca

39

come to design and finally to coding. To develop computer software we spiral in

along streamlines that decrease the level of abstraction on each turn.

A strategy for software testing may also be viewed in the context of the spiral.

Unit testing begins at the vertex of the spiral and concentrates on each unit of the

software as implemented in source code. Testing progress by moving outward along

the spiral to integration testing, where the focus is on the design and the construction

of the software architecture. Talking another turn on outward on the spiral we

encounter validation testing where requirements established as part of software

requirements analysis are validated against the software that has been constructed.

Finally we arrive at system testing, where the software and other system elements are

tested as a whole.

Fig 5.1 Types Testing

UNIT TESTING

MODULE TESTING

SUB-SYSTEM TESING

SYSTEM TESTING

ACCEPTANCE TESTING

Component

Integration Testing

User Testing

Page 40: Portable Cloud Services Using Tosca

40

5.3 TYPES OF TESTS:

UNIT TESTING:

Unit testing involves the design of test cases that validate that the internal

program logic is functioning properly, and that program inputs produce valid outputs.

All decision branches and internal code flow should be validated. It is the testing of

individual software units of the application .it is done after the completion of an

individual unit before integration. This is a structural testing, that relies on knowledge

of its construction and is invasive. Unit tests perform basic tests at component level

and test a specific business process, application, and/or system configuration. Unit

tests ensure that each unique path of a business process performs accurately to the

documented specifications and contains clearly defined inputs and expected results.

INTEGRATION TESTING:

Integration tests are designed to test integrated software components to

determine if they actually run as one program. Testing is event driven and is more

concerned with the basic outcome of screens or fields. Integration tests demonstrate

that although the components were individually satisfaction, as shown by successfully

unit testing, the combination of components is correct and consistent. Integration

testing is specifically aimed at exposing the problems that arise from the combination

of components.

FUNCTIONAL TEST:

Functional tests provide systematic demonstrations that functions tested are

available as specified by the business and technical requirements, system

documentation, and user manuals.

Functional testing is centered on the following items:

Valid Input : identified classes of valid input must be accepted.

Invalid Input : identified classes of invalid input must be rejected.

Functions : identified functions must be exercised.

Output : identified classes of application outputs must be exercised.

Page 41: Portable Cloud Services Using Tosca

41

Systems/Procedures: interfacing systems or procedures must be invoked.

Organization and preparation of functional tests is focused on requirements, key

functions, or special test cases. In addition, systematic coverage pertaining to identify

Business process flows; data fields, predefined processes, and successive processes

must be considered for testing. Before functional testing is complete, additional tests

are identified and the effective value of current tests is determined.

SYSTEM TEST:

System testing ensures that the entire integrated software system meets

requirements. It tests a configuration to ensure known and predictable results. An

example of system testing is the configuration oriented system integration test.

System testing is based on process descriptions and flows, emphasizing pre-driven

process links and integration points.

WHITE BOX TESTING:

White Box Testing is a testing in which in which the software tester has

knowledge of the inner workings, structure and language of the software, or at least its

purpose. It is purpose. It is used to test areas that cannot be reached from a black box

level.

BLACK BOX TESTING:

Black Box Testing is testing the software without any knowledge of the inner

workings, structure or language of the module being tested. Black box tests, as most

other kinds of tests, must be written from a definitive source document, such as

specification or requirements document, such as specification or requirements

document. It is a testing in which the software under test is treated, as a black box

.you cannot “see” into it. The test provides inputs and responds to outputs without

considering how the software works.

Page 42: Portable Cloud Services Using Tosca

42

TEST RESULTS:

Unit Testing:

Unit testing is usually conducted as part of a combined code and unit test phase of

the software lifecycle, although it is not uncommon for coding and unit testing to be

conducted as two distinct phases.

Test strategy and approach

Field testing will be performed manually and functional tests will be written in

detail.

Test objectives

All field entries must work properly.

Pages must be activated from the identified link.

The entry screen, messages and responses must not be delayed.

Features to be tested

Verify that the entries are of the correct format

No duplicate entries should be allowed

All links should take the user to the correct page.

Integration Testing:

Software integration testing is the incremental integration testing of two or more

integrated software components on a single platform to produce failures caused by

interface defects.

The task of the integration test is to check that components or software

applications, e.g. components in a software system or – one step up – software

applications at the company level – interact without error.

Test Results: All the test cases mentioned above passed successfully. No defects

encountered.

Page 43: Portable Cloud Services Using Tosca

43

Acceptance Testing

User Acceptance Testing is a critical phase of any project and requires significant

participation by the end user. It also ensures that the system meets the functional

requirements.

Test Results: All the test cases mentioned above passed successfully. No defects

encountered.

Page 44: Portable Cloud Services Using Tosca

44

CHAPTER-6

RESULTS

Fig.6.1 Admin Login Page

Fig.6.2 Super Admin Login Page

Page 45: Portable Cloud Services Using Tosca

45

Fig.6.3 Admin Handler Page

Fig.6.4 Admin Adding a New Organization Page

Page 46: Portable Cloud Services Using Tosca

46

Fig.6.5 Activating the Organizations Page

Fig.6.6 Activating an Organization Page

Page 47: Portable Cloud Services Using Tosca

47

Fig.6.7 Home Page of Organization

Fig.6.8 Creating a Team

Page 48: Portable Cloud Services Using Tosca

48

Fig.6.9 Creating an Employee

Fig.6.10 Viewing Employees in Organization

Page 49: Portable Cloud Services Using Tosca

49

Fig.6.11 Activating an Employee

Fig.6.12 Moving To Employees Wallet

Page 50: Portable Cloud Services Using Tosca

50

Fig.6.13 Login Secure keys

Fig.6.14 Employee Activities

Page 51: Portable Cloud Services Using Tosca

51

Fig.6.15 Creating a File

Fig.6.16 Uploading a File

Page 52: Portable Cloud Services Using Tosca

52

Fig.6.17 Viewing Files

Fig.6.18 Viewing a File

Page 53: Portable Cloud Services Using Tosca

53

Fig.6.19 Details of Downloading File

Fig.6.20 Link for Downloading

Page 54: Portable Cloud Services Using Tosca

54

Fig.6.21 Downloaded File

Page 55: Portable Cloud Services Using Tosca

55

CONCLUSION

To address the third major challenge of cloud computing we identified in the

introduction, we’re researching how to ensure compliance and security throughout the

entire service life cycle. Security experts are enabled to annotate policies to TOSCA

elements. Policy-specific plug-ins will then enforce these policies in the management

environment during the cloud service’s whole life cycle. TOSCA provides an

exchange format for policies but no guarantee that the management environment and

providers also enforce these policies. This must be ensured by a trustworthy entity

through certification of management environments, providers, and services. TOSCA

models contain myriad references to files, such as those with additional TOSCA

definitions, plans, and other artifacts. Consequently, future work must be invested

toward a TOSCA archive, a self-contained package of these artifacts, similar to Java

EAR files. This cloud service could then be offered in the marketplace and, due to its

portability, operated in different management environments.

Page 56: Portable Cloud Services Using Tosca

56

BIBLIOGRAPHY

1.F. Leymann et al., “Moving Applications to the Cloud: An Approach Based on

Application Model Enrichment,” Int’l J.Cooperative Information Systems, vol. 20,no.

3, 2011, pp. 307–356.

2. T. Binz, F. Leymann, and D. Schumm “CMotion: A Framework for Migration of

Applications into and between Clouds,” Proc. Int’l Conf. Service-Oriented Computing

and Applications, IEEE Press, 2012, pp. 1–4.

3. Topology and Orchestration Specification for Cloud Applications (TOSCA),

OASIS specif ication, Oct. 2011; www. oasis-open.org/commit tees/tc_home.

4. M. Behrendt et al., “IBM Cloud Computing Reference Architecture,” Open Group

submission, Feb. 2011; www.opengroup. org/cloudcomputing/uploads/40/23840/

CCRA.IBMSubmission.02282011.doc.

5. G. Breiter and M. Behrendt, “Lifecycle and Characteristics of Services in the

World of Cloud Computing,” IBM J. Research and Development, vol. 53, no. 4,

2009, pp. 3:1–3:8.

6. Business Process Model and Notation (BPMN) Version 2.0, Object Management

Group specification, Jan. 2011.

7. Web Services Business Process Execution Language (BPEL) Version 2.0., OASIS

specification, 2007.