Upload
saikrishna-reddy
View
132
Download
3
Tags:
Embed Size (px)
Citation preview
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.
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
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
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
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.
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.
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.
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
9
3.3.2 USECASE DIAGRAM:
Fig 3.2 use case for ADMIN
Add Organization
View Organization
Block Account
Login
Logout
Admins
Activate Account
10
Fig 3.3 use case for ORGANIZATIONAL ADMIN
Create Team
Add Employees
View Employees
activate Account
Organization Admin
Logout
Change password
Login
11
Fig 3.4 use case for EMPLOYEES
create file
upload file
view file
Download File
Log out
Employee
Login
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
13
Fig 3.6 Activity Diagram for ORGANIZATION ADMIN
login
create team add employees block activate
logout
14
Fig 3.7 Activity Diagram for EMPLOYEES
login
create file upload file download file view file
logout
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
16
Fig 3.9 Sequence Diagram for ORGANIZATION ADMIN
oraganization admin
Employee
add employee
login
view employee
Activate Account
check availability
create team
17
Fig 3.10 Sequence Diagram for EMPLOYEES
employee file
login
create file
upload file
view file
delete file
download file
log out
18
3.5 DATABASE TABLES
TABLE 3.1:
TABLE 3.1: Organization Details
TABLE 3.2:
TABLE 3.2: Employee Details
19
TABLE 3.3:
TABLE 3.3: Login Details
TABLE 3.4:
TABLE 3.4: File Details
20
TABLE 3.5:
TABLE 3.5: Team Details
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
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.
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.
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.
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
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.
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
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
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
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.
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.
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.
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
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.
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.
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
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.
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
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
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.
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.
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.
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.
44
CHAPTER-6
RESULTS
Fig.6.1 Admin Login Page
Fig.6.2 Super Admin Login Page
45
Fig.6.3 Admin Handler Page
Fig.6.4 Admin Adding a New Organization Page
46
Fig.6.5 Activating the Organizations Page
Fig.6.6 Activating an Organization Page
47
Fig.6.7 Home Page of Organization
Fig.6.8 Creating a Team
48
Fig.6.9 Creating an Employee
Fig.6.10 Viewing Employees in Organization
49
Fig.6.11 Activating an Employee
Fig.6.12 Moving To Employees Wallet
50
Fig.6.13 Login Secure keys
Fig.6.14 Employee Activities
51
Fig.6.15 Creating a File
Fig.6.16 Uploading a File
52
Fig.6.17 Viewing Files
Fig.6.18 Viewing a File
53
Fig.6.19 Details of Downloading File
Fig.6.20 Link for Downloading
54
Fig.6.21 Downloaded File
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.
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.