secure file storage on

cloud using hybride

cryptography

Objective:

We propose a novel method called secure erasure code based algorithm for cloud data
security in distributed storage systems.

ABSTRACT:

High-speed networks and ubiquitous Internet access become available to

users for access anywhere at any time. Cloud computing is a concept that treats the resources
on the Internet as a unified entity, a cloud. Cloud storage is a model of networked online
storage where data is stored in virtualized pools of storage which are generally hosted by
third parties. Hosting companies operate large data centers, and people who require their data
to be hosted buy or lease storage capacity from them.
The data center operators, in the background, virtualize the resources
according to the requirements of the customer and expose them as storage pools, which the
customers can themselves use to store files or data objects. Physically, the resource may span
across multiple servers.
 Data robustness is a major requirement for storage systems. There have been
many proposals of storing data over storage servers. One way to provide data robustness is to
replicate a message such that each storage server stores a copy of the message. A
decentralized erasure code is suitable for use in a distributed storage system. We construct a
secure cloud storage system that supports the function of secure data forwarding by using an
AES and Proxy re encryption. In this model initial phase owner will upload the data with
AES Encryption. Next phase, inside of cloud again the data has divided into small pieces, for
this process we will apply a dividing key. Data will place in different storage lactations. The
information of data storage will monitor by a unique data distributors. If the valid user
accessing the data cloud will retrieve the data as reversible manner.

EXISTING SYSTEM: In Existing System we use a straightforward integration method. In

a straightforward integration method Storing data in a third party’s cloud system causes
serious concern on data confidentiality. In order to provide strong confidentiality for
messages in storage servers, a user can encrypt messages by a cryptographic method before
applying an erasure code method to encode and store messages. When he wants to use a
message, he needs to retrieve the
Codeword symbols from storage servers, decode them, and then decrypt them by using
cryptographic keys. General encryption schemes protect data confidentiality, but also limit
the functionality of the storage system because a few operations are supported over encrypted
data. A decentralized architecture for storage systems offers good scalability, because a
storage server can join or leave without control of a central authority.

DISADVATAGES:

❖ The user can perform more computation and communication traffic between the user

and storage servers is high.

❖ The user has to manage his cryptographic keys otherwise the security has to be

broken.
 ❖ The data storing and retrieving, it is hard for storage servers to directly support other

functions.

PROPOSED SYSTEM:
In our proposed system we address the problem of forwarding data to another
user by storage servers directly under the command of the data owner. We consider the
system model that consists of distributed storage servers and key servers. Since storing
cryptographic keys in a single device is risky, a user distributes his cryptographic key to key
servers that shall perform cryptographic functions on behalf of the user. These key servers are
highly protected by security mechanisms.
Here Storage system has allocates by different data container. Once owner
uploads the data with AES encryption mechanism, system again takes the data and makes
Secure Data segregation process. All the data pieces will be save in different location in cloud
storage. Here public distributor monitors all the data and corresponding positions where it is
saved. When a proper client asking the data, cloud system will provide the data in reversible
manner. So our system will prevent our data from both Inside and Outside attackers.

ADVANTAGES:

❖ Tight integration of encoding, encryption, and forwarding makes the storage system

efficiently meet the requirements of data robustness, data confidentiality, and data
forwarding.

❖ The storage servers independently perform encoding and re-encryption process and

the key servers independently perform partial decryption process.

❖ More flexible adjustment between the number of storage servers and robustness.
System architecture:

Admin login

Server1

File upload to the server Server2

Server3

Server4

Encrypt the data

File upload
Proxy re encryption
Download the data

HARDWARE SPECIFICATION

● Main Processor : 2GHz

● Ram : 512 MB (min)

● Hard Disk : 80 GB

SOFTWARE SPECIFICATION

● Language : Java

● Web Server : Tomcat 6

● Operating System : Windows 7 32 Bit

Technical Terms:

AES – Advanced Encryption Standard

Alternative title:
1. Exploring Task Parallelism in Erasure Coding for Enhanced
Bandwidth and Energy Efficiency.
2. An Innovative Parallel Cloud Storage System using proxy re encryption.

3. A Parallel and Scalable of erasure coding support in Cloud Object

Storage System.

4. A Parallel Reliable and Scalable Storage Software Infrastructure for

distributed storage system.

5. A proxy encryption repair mechanism for decentralized erasure code

based storage systems

Module

1. Registration
2. Sharing Data
3. Secure Cloud Storage
4. Proxy re-encryption
5. Data retrieval

Registration:
 For the registration of user with identity ID the group manager randomly selects
a number. Then the group manager adds into the group user list which will be used in
the traceability phase. After the registration, user obtains a private key which will be
used for group signature generation and file decryption.

Registration
Group Manager Group Members

Sharing Data:
The canonical application is data sharing. The public auditing property is especially
useful when we expect the delegation to be efficient and flexible. The schemes enable a
content provider to share her data in a confidential and selective way, with a fixed and small
ciphertext expansion, by distributing to each authorized user a single and small aggregate
key.

Secure Cloud Storage:

Data robustness is a major requirement for storage systems. There have been many proposals
of storing data over storage servers. One way to provide data robustness is to replicate a
message such that each storage server stores a copy of the message. A decentralized erasure
code is suitable for use in a distributed storage system.

Proxy re-encryption:

Proxy re-encryption schemes are crypto systems which allow third parties (proxies) to
alter a cipher text which has been encrypted for one user, so that it may be decrypted by
another user. By using proxy re-encryption technique the encrypted data (cipher text) in the
cloud is again altered by the user. It provides highly secured information stored in the cloud.
Every user will have a public key and private key. Public key of every user is known to
everyone but private key is known only the particular user.

Data retrieval:
Reports and data are the two primary forms of the retrieved data from servers. There are
some overlaps between them, but queries generally select a relatively small portion of the
server, while reports show larger amounts of data. Queries also present the data in a standard
format and usually display it on the monitor; whereas reports allow formatting of the output
however you like and is normally retrieved.

Data flow Diagram:

Level 0:

Registration

Database SQL

Login Compare

File upload
Level 1

Key

Choose file AES

Cipher text

Plain text

Encryption

Cloud Storage

Encrypted File
Level 2:

Encrypted File Proxy-Re-Encryption

MD5 File Splitting

Hash Distributed Cloud Storage

value

SQL
USECASE:-

Net
wor

End
user

Data
encryption/encoding

No of
S
Server
C er
li

Proxy
Reencryption

Provid
ekey

Upload/
Download

Description:
Use case diagrams gives a graphic overview of the actors involved in a system, different
functions needed by those actors and how these different functions are interacted.

Here the sender and receiver are the actors and select video, select file, encryption key,
decrypt data, extract data and view data are the functions

CLASS DIAGRAM:-
S
Data dividing
Serv Security provider
User Serv
er 1
Serv
er 2
Encryp
Log
tion
er 3
Login ffile
Erasure Secur
Application
User name() code() ity()

Password()

Manipulatio Datab
n up ase
downl
se
dat
up
oad de
le
de
dat
let
let manipulat
e()
Update_file()

Select_file()

Delete_file()

Description:
It is the main building block of any object oriented solution. It shows the classes in a system,
attributes and operations of each class and the relationship between each class.

A class has three parts, name at the top, attributes in the middle and operations or methods at
the bottom. In large systems with many related classes, classes are grouped together to create
class diagrams. Different relationships between classes are shown by different types of
arrows.

Here sender, embed data, receiver, encrypt and decrypt are the classes, each class contains its
own attribute and functions, they are related by arrows.

SEQUENCE DIAGRAM:-

Net W encry s
wor e ption er

1.send cover video with

data

Description:
Sequence diagrams in UML shows how object interact with each other and the order those
interactions occur. It’s important to note that they show the interactions for a particular
scenario. The processes are represented vertically and interactions are show as arrows.

Here sender, receiver, embedding data and room are objects they interact each other. The
arrow shows interaction like send cover video and data, reserving room etc.

COLLABORATION DIAGRAM:-

Description:
collaboration diagram, is an interaction diagram that shows similar information to sequence
diagrams but its primary focus is on object relationships.

On collaboration diagrams, objects are shown with association connectors between them.
Messages are added to the associations and show as short arrows pointing in the direction of
the message flow. The sequence of messages is shown through a numbering scheme

Here the objects like sender, receiver, room and Embed data are connected each other and
messages are added to the associations
ACTIVITY DIAGRAM:-
Description:

Activity diagrams represent workflows in an graphical way. They can be used to describe
business workflow or the operational workflow of any component in a system

● rounded rectangles represent actions;

● diamonds represent decisions;
● bars represent the start (split) or end (join) of concurrent activities;
● a black circle represents the start (initial state) of the workflow;
● an encircled black circle represents the end (final state).

Advanced Encryption Standard (AES)

Definition

The Advanced Encryption Standard (AES) is an encryption algorithm for securing sensitive
but unclassified material by U.S. Government agencies and, as a likely consequence, may
eventually become the de facto encryption standard for commercial transactions in the
private sector. (Encryption for the US military and other classified communications is
handled by separate, secret algorithms.)In January of 1997, a process was initiated by the
National Institute of Standards and Technology (NIST), a unit of the U.S. Commerce
Department, to find a more robust replacement for the Data Encryption Standard (DES) and
to a lesser degree Triple DES. The specification called for a symmetric algorithm
(same key for encryption and decryption) using block encryption (see block cipher) of 128
bits in size, supporting key sizes of 128, 192 and 256 bits, as a minimum. The algorithm was
required to be royalty-free for use worldwide and offer security of a sufficient level to
protect data for the next 20 to 30 years. It was to be easy to implement in hardware and
software, as well as in restricted environments (for example, in a smart card) and offer good
defenses against various attack techniques.The entire selection process was fully open to
public scrutiny and comment, it being decided that full visibility would ensure the best
possible analysis of the designs. In 1998, the NIST selected 15 candidates for the AES, which
were then subject to preliminary analysis by the world cryptographic community, including
the National Security Agency. On the basis of this, in August 1999, NIST selected five
algorithms for more extensive analysis. These were:

● MARS, submitted by a large team from IBM Research

● RC6, submitted by RSA Security

● Rijndael, submitted by two Belgian cryptographers, Joan Daemen and Vincent Rijmen

● Serpent, submitted by Ross Andersen, Eli Biham and Lars Knudsen

● Twofish, submitted by a large team of researchers including Counterpane's respected

cryptographer, Bruce Schneier

Implementations of all of the above were tested extensively in ANSI C and Java languages
for speed and reliability in such measures as encryption and decryption speeds, key and
algorithm set-up time and resistance to various attacks, both in hardware- and software-
centric systems. Once again, detailed analysis was provided by the global cryptographic
community (including some teams trying to break their own submissions). The end result
was that on October 2, 2000, NIST announced that Rijndael had been selected as the
proposed standard. On December 6, 2001, the Secretary of Commerce officially approved
Federal Information Processing Standard (FIPS) 197, which specifies that all sensitive,
unclassified documents will use Rijndael as the Advanced Encryption Standard.Also
see cryptography, data recovery agent (DRA)RELATED GLOSSARY TERMS: RSA algorithm
(Rivest-Shamir-Adleman), data key, greynet (or graynet), spam cocktail (or anti-spam
cocktail), fingerscanning (fingerprint scanning),munging, insider threat, authentication
server, defense in depth, nonrepudiation

Explanations
AES is based on a design principle known as a Substitution permutation network. It is fast in
both software and hardware. Unlike its predecessor, DES, AES does not use a Feistel
network.AES has a fixed block size of 128 bits and a key size of 128, 192, or 256 bits,
whereas Rijndael can be specified with block and key sizes in any multiple of 32 bits, with a
minimum of 128 bits. The blocksize has a maximum of 256 bits, but the keysize has no
theoretical maximum.AES operates on a 4×4 column-major order matrix of bytes, termed
the state (versions of Rijndael with a larger block size have additional columns in the state).
Most AES calculations are done in a special finite field.The AES cipher is specified as a
number of repetitions of transformation rounds that convert the input plaintext into the
final output of ciphertext. Each round consists of several processing steps, including one
that depends on the encryption key. A set of reverse rounds are applied to transform
ciphertext back into the original plaintext using the same encryption key.

High-level description of the algorithm

1. KeyExpansion—round keys are derived from the cipher key using Rijndael's key
schedule
2. Initial Round
1. AddRoundKey—each byte of the state is combined with the round key
using bitwise xor
3. Rounds
1. SubBytes—a non-linear substitution step where each byte is replaced
with another according to lookup.
2. ShiftRows—a transposition step where each row of the state is shifted
cyclically a certain number of steps.
3. MixColumns—a mixing operation which operates on the columns of the
state, combining the four bytes in each column.
4. AddRoundKey
4. Final Round (no MixColumns)
1. SubBytes
2. ShiftRows
3. AddRoundKey

Diagrams

Key Register FSM Control Data Register

File block File
 Ciphering &
Deciphering block

Examples
In this appendix, twenty examples are provided for the MAC generation process. The
underlying block cipher is either the AES algorithm or TDEA. A block cipher key is fixed for
each of the currently allowed key sizes, i.e., AES-128, AES-192, AES-256, two key TDEA, and
three key TDEA. For each key, the generation of the associated subkeys is given, followed by
four examples of MAC generation with the key. The messages in each set of examples are
derived by truncating a common fixed string of 64 bytes. All strings are represented in
hexadecimal notation, with a space (or a new line) inserted every 8 symbols, for readability.
As in the body of the Recommendation, K1 and K2denote the subkeys, M denotes the
message, and T denotes the MAC. For the AES algorithm examples, Tlen is 128, i.e., 32
hexadecimal symbols, and K denotes the key. For the TDEA examples, Tlen is 64, i.e., 16
hexadecimal symbols, and the key, K, is the ordered triple of strings, (Key1, Key2, Key3). For
two key TDEA, Key1 = Key3. D.1 AES-128

For Examples 1–4 below, the block cipher is the AES algorithm with the following 128 bit
key:

K 2b7e1516 28aed2a6 abf71588 09cf4f3c.

Subkey Generation

CIPHK(0

128

) 7df76b0c 1ab899b3 3e42f047 b91b546f

K1 fbeed618 35713366 7c85e08f 7236a8de

K2 f7ddac30 6ae266cc f90bc11e e46d513b

Example Explanations
The Advanced Encryption Standard (AES) specifies a FIPS-approved cryptographic algorithm
that can be used to protect electronic data. The AES algorithm is a symmetric block cipher
that can encrypt (encipher) and decrypt (decipher) information. Encryption converts data to
an unintelligible form called ciphertext; decrypting the ciphertext converts the data back
into its original form, called plaintext. The AES algorithm is capable of using cryptographic
keys of 128, 192, and 256 bits to encrypt and decrypt data in blocks of 128 bits.

Definition

MD5 is an algorithm that is used to verify data integrity through the creation of a 128-bit
message digest from data input (which may be a message of any length) that is claimed to
be as unique to that specific data as a fingerprint is to the specific individual. MD5, which
was developed by Professor Ronald L. Rivest of MIT, is intended for use with digital
signature applications, which require that large files must be compressed by a secure
method before being encrypted with a secret key, under a public key cryptosystem. MD5 is
currently a standard, Internet Engineering Task Force (IETF) Request for Comments (RFC)
1321. According to the standard, it is "computationally infeasible" that any two messages
that have been input to the MD5 algorithm could have as the output the same message
digest, or that a false message could be created through apprehension of the message
digest. MD5 is the third message digest algorithm created by Rivest. All three (the others are
MD2 and MD4) have similar structures, but MD2 was optimized for 8-bit machines, in
comparison with the two later formulas, which are optimized for 32-bit machines. The MD5
algorithm is an extension of MD4, which the critical review found to be fast, but possibly not
absolutely secure. In comparison, MD5 is not quite as fast as the MD4 algorithm, but offers
much more assurance of data security.

Explanations
The MD5 Message-Digest Algorithm is a widely used cryptographic hash function that
produces a 128-bit (16-byte) hash value. Specified in RFC 1321, MD5 has been employed in
a wide variety of security applications, and is also commonly used to check data integrity.
However, it has been shown that MD5 is not collision resistant; as such, MD5 is not suitable
for applications like SSL certificates or digital signatures that rely on this property. An MD5
hash is typically expressed as a 32-digit hexadecimal number.MD5 was designed by Ron
Rivest in 1991 to replace an earlier hash function, MD4. In 1996, a flaw was found with the
design of MD5. While it was not a clearly fatal weakness, cryptographers began
recommending the use of other algorithms, such as SHA-1 (which has since been found also
to be vulnerable). In 2004, more serious flaws were discovered, making further use of the
algorithm for security purposes questionable; specifically, a group of researchers described
how to create a pair of files that share the same MD5 checksum. Further advances were
made in breaking MD5 in 2005, 2006, and 2007. In an attack on MD5 published in December
2008, a group of researchers used this technique to fake SSL certificate validity.

MD5 Diagram

Data
Message Registers
Length
Counter

Destination
MD5 Round MAC Adress
Operations

Source MAC
Padding Adress
COunt

MIC Key

Example
MD5 (Message-Digest algorithm 5) is a widely used cryptographic hash function with a 128-
bit hash value. Specified in RFC 1321, MD5 is one in a series of message digest algorithms
designed by Professor Ronald Rivest of MIT (Rivest, 1994). Today MD5 has been employed
in a wide variety of security applications, and is also commonly used to check the integrity of
files. MD5 is perfectly fine solution for security thinking, As one Java developer, we usually
need to take over or coding to md5 encryption, the md5 encryption is very complicated and
not to easy implement. Ideally, The standard edition of Java has really came with MD5
support built in. according by Java specification class MessageDigest support applications
the functionality of a message digest algorithm, such as MD5 or SHA.. and it is defined in the
java.security package. firstly you need some string manipulation to turn the plain text into
byte array. This is going easy just use method getBytes() of class string. the digest is then
updated from the bytes from the byte array and a hash computation is conducted upon
them.

import java.io.FileInputStream;

import java.io.UnsupportedEncodingException;

import java.math.BigInteger;

import java.security.MessageDigest;

import java.security.NoSuchAlgorithmException;

public class MD5 {

public static String getMD5(String input) {

try {

MessageDigest md = MessageDigest.getInstance("MD5");

byte[] messageDigest = md.digest(input.getBytes());

 BigInteger number = new BigInteger(1, messageDigest);

String hashtext = number.toString(16);

// Now we need to zero pad it if you actually want the full 32 chars.

while (hashtext.length() < 32) {

hashtext = "0" + hashtext;

return hashtext;

catch (NoSuchAlgorithmException e) {

throw new RuntimeException(e);

public static void main(String[] args) throws NoSuchAlgorithmException {

System.out.println(getMD5("Javarmi.com"));

Example Explanations
 It is simply a one-way fingerprint of the message. It doesn't include the original message,
and you can't (generally) use the fingerprint (the md5sum) to 'figure out' the original
message.Okay, so you take a message - like a password - and generate an MD5sum from it..
Can't you brute-force that? Like any password system, you could attempt to brute force the
answer. However, MD5sum's are in a 128-bit space, meaning that to brute force it would
take 2^128 attempts - thats over 3 with 38 zeroes afterit.Neat! Thats a lot. Are there any
flaws in the algorithm that could speed it up?A birthday attack is based on the theory that
there *might* be *one* md5sum that matches multiple inputs. In theory, it is possible that
a "birthday" attack could be possible - two md5sum hashes could be the same. But even
then, the total number of brute forces is at 2^64 attempts - still a heck of a lot.Okay. But
couldn't (insert super-sneaky government agency here) build an md5 dictionary, and know
what the password was with the md5?Yes. Its entirely possible. However - it would take
some work to do so. For example, just for a dictionary consisting of Alphabet letters (upper
and lower), and numbers, there would be 46,656,000,000 entries - all at 32 characters each.
Thats over 1 terabyte of data to store and search! It could be done - absolutely. But is it
likely? So its hard to brute force, what about dictionary attacks? Dictionary attacks are a way
of attacking poor passwords - most people use words in their passwords. If you can guess
the word - for example, "love", then you can cut down the number of tries it would take. Of
course if you guess right, then your # of attacks = 1. However, in general, using common
computers as of the writing of this (2005), you can generally get roughly 5 million attacks
per second, or fast enough to guess all 8-character Alphanumericals within 497 days.

Proxy re-encryption

Proxy re-encryption (PRE) allows a proxy to convert a ciphertext encrypted under one key
into an encryption of the same message under another key. The main idea is to place as
little trust and reveal as little information to the proxy as necessary to allow it to perform its
translations. At the very least, the proxy should not be able to learn the keys of the
participants or the content of the messages it re-encrypts. However, in all prior PRE
schemes, it is easy for the proxy to determine between which participants a re-encryption
key can transform ciphertexts. This can be a problem in practice. For example, in a secure
distributed file system, content owners may want to use the proxy to help re-encrypt
sensitive information without revealing to the proxy the identity of the recipients.
In this work, we propose key-private (or anonymous) re-encryption keys as an additional
useful property of PRE schemes. We formulate a definition of what it means for a PRE
scheme to be secure and key-private. Surprisingly, we show that this property is not
captured by prior definitions or achieved by prior schemes, including even the secure
obfuscation of PRE by Hohenberger et al. Finally, we propose the first key-private PRE
construction and prove its CPA-security under a simple extension of Decisional Bilinear Diffie
Hellman assumption and its key-privacy under the Decision Linear assumption in the
standard model.

Erasure code technique

In information theory, an erasure code is a forward error correction (FEC) code for the
binary erasure channel, which transforms a message of k symbols into a longer message
(code word) with n symbols such that the original message can be recovered from a subset
of the n symbols. The fraction r = k/n is called the code rate, the fraction k’/k, where k’
denotes the number of symbols required for recovery, is called reception efficiency.

Optimal erasure codes

Optimal erasure codes have the property that any k out of the n code word symbols are
sufficient to recover the original message (i.e., they have optimal reception efficiency).
Optimal erasure codes are maximum distance separable codes (MDS codes).Optimal codes
are often costly (in terms of memory usage, CPU time, or both) when n is large. Except for
very simple schemes, practical solutions usually have quadratic encoding and decoding

complexity. In 2014, Lin et al. [1] gave an approach with operations.

Examples
In this appendix, twenty examples are provided for the MAC generation process. The
underlying block cipher is either the AES algorithm or TDEA. A block cipher key is fixed for
each of the currently allowed key sizes, i.e., AES-128, AES-192, AES-256, two key TDEA, and
three key TDEA. For each key, the generation of the associated subkeys is given, followed by
four examples of MAC generation with the key. The messages in each set of examples are
derived by truncating a common fixed string of 64 bytes. All strings are represented in
hexadecimal notation, with a space (or a new line) inserted every 8 symbols, for readability.
As in the body of the Recommendation, K1 and K2denote the subkeys, M denotes the
message, and T denotes the MAC. For the AES algorithm examples, Tlen is 128, i.e., 32
hexadecimal symbols, and K denotes the key. For the TDEA examples, Tlen is 64, i.e., 16
hexadecimal symbols, and the key, K, is the ordered triple of strings, (Key1, Key2, Key3). For
two key TDEA, Key1 = Key3. D.1 AES-128

For Examples 1–4 below, the block cipher is the AES algorithm with the following 128 bit
key:

K 2b7e1516 28aed2a6 abf71588 09cf4f3c.

Subkey Generation

CIPHK(0

128

) 7df76b0c 1ab899b3 3e42f047 b91b546f

K1 fbeed618 35713366 7c85e08f 7236a8de

K2 f7ddac30 6ae266cc f90bc11e e46d513b

Example Explanations
The Advanced Encryption Standard (AES) specifies a FIPS-approved cryptographic algorithm
that can be used to protect electronic data. The AES algorithm is a symmetric block cipher
that can encrypt (encipher) and decrypt (decipher) information. Encryption converts data to
an unintelligible form called ciphertext; decrypting the ciphertext converts the data back
into its original form, called plaintext. The AES algorithm is capable of using cryptographic
keys of 128, 192, and 256 bits to encrypt and decrypt data in blocks of 128 bits.

Java (programming language)

History

The JAVA language was created by James Gosling in June 1991 for use in a set top
box project. The language was initially called Oak, after an oak tree that stood outside
Gosling's office - and also went by the name Green - and ended up later being renamed to
Java, from a list of random words. Gosling's goals were to implement a virtual machine and a
language that had a familiar C/C++ style of notation. The first public implementation was
Java 1.0 in 1995. It promised "Write Once, Run Anywhere” (WORA), providing no-cost
runtimes on popular platforms. It was fairly secure and its security was configurable,
allowing network and file access to be restricted. Major web browsers soon incorporated the
ability to run secure Java applets within web pages. Java quickly became popular. With the
advent of Java 2, new versions had multiple configurations built for different types of
platforms. For example, J2EE was for enterprise applications and the greatly stripped down
version J2ME was for mobile applications. J2SE was the designation for the Standard
Edition. In 2006, for marketing purposes, new J2 versions were renamed Java EE, Java ME,
and Java SE, respectively.

In 1997, Sun Microsystems approached the ISO/IEC JTC1 standards bodyand later
the Ecma International to formalize Java, but it soon withdrew from the process. Java remains
a standard that is controlled through the Java Community Process. At one time, Sun made
most of its Java implementations available without charge although they were proprietary
software. Sun's revenue from Java was generated by the selling of licenses for specialized
products such as the Java Enterprise System. Sun distinguishes between its Software
Development Kit (SDK) and Runtime Environment (JRE)which is a subset of the SDK, the
primary distinction being that in the JRE, the compiler, utility programs, and many necessary
header files are not present.

On 13 Novmber2006, Sun released much of Java as free softwareunder the terms of

the GNU General Public License(GPL). On 8 May2007Sun finished the process, making all
of Java's core code open source, aside from a small portion of code to which Sun did not hold
the copyright.

Primary goals

There were five primary goals in the creation of the Java language:

● It should use the object-oriented programming methodology.

● It should allow the same program to be executed on multiple operating

systems.

● It should contain built-in support for using computer networks.

● It should be designed to execute code from remote sources securely.

● It should be easy to use by selecting what were considered the good parts of

other object-oriented languages

The Java Programming Language:

The Java programming language is a high-level language that can be characterized by

all of the following buzzwords:

● Simple

● Architecture neutral

● Object oriented

● Portable
 ● Distributed

● High performance

Each of the preceding buzzwords is explained in The Java Language Environment , a

white paper written by James Gosling and Henry McGilton.

In the Java programming language, all source code is first written in plain text files
ending with the .java extension. Those source files are then compiled into .class files by
the javac compiler.

A .class file does not contain code that is native to your processor; it instead
contains byte codes — the machine language of the Java Virtual Machine 1 (Java VM). The
java launcher tool then runs your application with an instance of the Java Virtual Machine.

An overview of the software development process.

Because the Java VM is available on many different operating systems, the same
TM
.class files are capable of running on Microsoft Windows, the Solaris Operating System
(Solaris OS), Linux, or Mac OS. Some virtual machines, such as the Java Hot Spot virtual
machineperform additional steps at runtime to give your application a performance boost.
This include various tasks such as finding performance bottlenecks and recompiling (to
native code) frequently used sections of code.
 Through the Java VM, the same application is capable of running on
multiple platforms.

The Java Platform

A platform is the hardware or software environment in which a program runs. We've already
mentioned some of the most popular platforms like Microsoft Windows, Linux, Solaris OS, and Mac
OS. Most platforms can be described as a combination of the operating system and underlying
hardware. The Java platform differs from most other platforms in that it's a software-only platform
that runs on top of other hardware-based platforms.

The Java platform has two components:

The Java Virtual Machine

The Java Application Programming Interface (API)

You've already been introduced to the Java Virtual Machine; it's the base for the Java
platform and is ported onto various hardware-based platforms.

The API is a large collection of ready-made software components that provide many
useful capabilities. It is grouped into libraries of related classes and interfaces; these libraries
are known as packages. The next section, What CanJavaTechnologyDo?Highlights some of
the functionality provided by the API.
 The API and Java Virtual Machine insulate the program from the
underlying hardware.

As a platform-independent environment, the Java platform can be a bit slower than native
code. However, advances in compiler and virtual machine technologies are bringing performance
close to that of native code without threatening portability.

Java Runtime Environment

The Java Runtime Environment, or JRE, is the software required to run any
application deployed on the Java Platform. End-users commonly use a JRE in software
packages and Web browser plug-in. Sun also distributes a superset of the JRE called the Java
2 SDK(more commonly known as the JDK), which includes development tools such as the
Javacompiler,Javadoc, Jarand debugger.

One of the unique advantages of the concept of a runtime engine is that errors
(exceptions) should not 'crash' the system. Moreover, in runtime engine environments such as
Java there exist tools that attach to the runtime engine and every time that an exception of
interest occurs they record debugging information that existed in memory at the time the
exception was thrown (stack and heap values). These Automated Exception Handling tools
provide 'root-cause' information for exceptions in Java programs that run in production,
testing or development environments.

Uses OF JAVA

Blue is a smart card enabled with the secure, cross-platform, object-oriented Java
Card API and technology. Blue contains an actual on-card processing chip, allowing for
enhance able and multiple functionality within a single card. Applets that comply with the
Java Card API specification can run on any third-party vendor card that provides the
necessary Java Card Application Environment (JCAE). Not only can multiple applet
programs run on a single card, but new applets and functionality can be added after the card
is issued to the customer

● Java Can be used in Chemistry.

● In NASA also Java is used.

● In 2D and 3D applications java is used.

● In Graphics Programming also Java is used.

● In Animations Java is used.

● In Online and Web Applications Java is used.

JSP :

JavaServer Pages (JSP) is a Java technology that allows software developers to

dynamically generate HTML, XML or other types of documents in response to a Web client
request. The technology allows Java code and certain pre-defined actions to be embedded
into static content.

The JSP syntax adds additional XML-like tags, called JSP actions, to be used to
invoke built-in functionality. Additionally, the technology allows for the creation of JSP tag
libraries that act as extensions to the standard HTML or XML tags. Tag libraries provide a
platform independent way of extending the capabilities of a Web server.

JSPs are compiled into Java Servlet by a JSP compiler. A JSP compiler may generate
a servlet in Java code that is then compiled by the Java compiler, or it may generate byte code
for the servlet directly. JSPs can also be interpreted on-the-fly reducing the time taken to
reload changes
 JavaServer Pages (JSP) technology provides a simplified, fast way to create dynamic
web content. JSP technology enables rapid development of web-based applications that are
server and platform-independent.

Architecture OF JSP

The Advantages of JSP

Active Server Pages (ASP). ASP is a similar technology from Microsoft. The
advantages of JSP are twofold. First, the dynamic part is written in Java, not Visual Basic or
other MS-specific language, so it is more powerful and easier to use. Second, it is portable to
other operating systems and non-Microsoft Web servers. Pure Servlet. JSP doesn't give you
anything that you couldn't in principle do with a Servlet. But it is more convenient to write
(and to modify!) regular HTML than to have a zillion println statements that generate the
HTML. Plus, by separating the look from the content you can put different people on
different tasks: your Web page design experts can build the HTML, leaving places for your
Servlet programmers to insert the dynamic content.

Server-Side Includes (SSI). SSI is a widely-supported technology for including

externally-defined pieces into a static Web page. JSP is better because it lets you use Servlet
instead of a separate program to generate that dynamic part. Besides, SSI is really only
intended for simple inclusions, not for "real" programs that use form data, make database
connections, and the like. JavaScript. JavaScript can generate HTML dynamically on the
client. This is a useful capability, but only handles situations where the dynamic information
is based on the client's environment.

With the exception of cookies, HTTP and form submission data is not available to
JavaScript. And, since it runs on the client, JavaScript can't access server-side resources like
databases, catalogs, pricing information, and the like. Static HTML. Regular HTML, of
course, cannot contain dynamic information. JSP is so easy and convenient that it is quite
feasible to augment HTML pages that only benefit marginally by the insertion of small
amounts of dynamic data. Previously, the cost of using dynamic data would preclude its use
in all but the most valuable instances.

ARCHITECTURE OF JSP
 ● The browser sends a request to a JSP page.

● The JSP page communicates with a Java bean.

● The Java bean is connected to a database.

● The JSP page responds to the browser.

SERVLETS – FRONT END

The Java Servlet API allows a software developer to add dynamic content to a Web
server using the Java platform. The generated content is commonly HTML, but may be other
data such as XML. Servlet are the Java counterpart to non-Java dynamic Web content
technologies such as PHP, CGI and ASP.NET. Servlet can maintain state across many server
transactions by using HTTP cookies, session variables or URL rewriting.

The Servlet API, contained in the Java package hierarchy javax. Servlet, defines the
expected interactions of a Web container and a Servlet. A Web container is essentially the
component of a Web server that interacts with the Servlet. The Web container is responsible
for managing the lifecycle of Servlet, mapping a URL to a particular Servlet and ensuring
that the URL requester has the correct access rights.

A Servlet is an object that receives a request and generates a response based on that
request. The basic Servlet package defines Java objects to represent Servlet requests and
responses, as well as objects to reflect the Servlet configuration parameters and execution
environment. The package javax .Servlet. Http defines HTTP-specific subclasses of the
generic Servlet elements, including session management objects that track multiple requests
and responses between the Web server and a client. Servlet may be packaged in a WAR file
as a Web application.
 Servlet can be generated automatically by Java Server Pages(JSP), or alternately by
template engines such as Web Macro. Often Servlet are used in conjunction with JSPs in a
pattern called "Model 2”, which is a flavour of the model-view-controller pattern.

Servlet are Java technology's answer to CGI programming. They are programs that
run on a Web server and build Web pages. Building Web pages on the fly is useful (and
commonly done) for a number of reasons:.

The Web page is based on data submitted by the user. For example the results pages
from search engines are generated this way, and programs that process orders for e-commerce
sites do this as well. The data changes frequently. For example, a weather-report or news
headlines page might build the page dynamically, perhaps returning a previously built page if
it is still up to date. The Web page uses information from corporate databases or other such
sources. For example, you would use this for making a Web page at an on-line store that lists
current prices and number of items in stock.

The Servlet Run-time Environment

A Servlet is a Java class and therefore needs to be executed in a Java VM by a service
we call a Servlet engine. The Servlet engine loads the servlet class the first time the Servlet is
requested, or optionally already when the Servlet engine is started. The Servlet then stays
loaded to handle multiple requests until it is explicitly unloaded or the Servlet engine is shut
down.

Some Web servers, such as Sun's Java Web Server (JWS), W3C's Jigsaw and Gefion
Software's Lite Web Server (LWS) are implemented in Java and have a built-in Servlet
engine. Other Web servers, such as Netscape's Enterprise Server, Microsoft's Internet
Information Server (IIS) and the Apache Group's Apache, require a Servlet engine add-on
module. The add-on intercepts all requests for Servlet, executes them and returns the
response through the Web server to the client. Examples of Servlet engine add-ons are Gefion
Software's WAI Cool Runner, IBM's Web Sphere, Live Software's JRun and New Atlanta's
Servlet Exec.

All Servlet API classes and a simple Servlet-enabled Web server are combined into
the Java Servlet Development Kit (JSDK), available for download at Sun's official Servlet
site .To get started with Servlet I recommend that you download the JSDK and play around
with the sample Servlet.

Life Cycle OF Servlet

● The Servlet lifecycle consists of the following steps:

● The Servlet class is loaded by the container during start-up.

The container calls the init() method. This method initializes the Servlet and must be
called before the Servlet can service any requests. In the entire life of a Servlet, the init()
method is called only once. After initialization, the Servlet can service client-requests.

Each request is serviced in its own separate thread. The container calls the service()
method of the Servlet for every request.

The service() method determines the kind of request being made and dispatches it to
an appropriate method to handle the request. The developer of the Servlet must provide an
implementation for these methods. If a request for a method that is not implemented by the
Servlet is made, the method of the parent class is called, typically resulting in an error being
returned to the requester. Finally, the container calls the destroy() method which takes the
Servlet out of service. The destroy() method like init() is called only once in the lifecycle of a
Servlet.

● Request and Response Objects

The do Get method has two interesting parameters: HttpServletRequest and

HttpServletResponse. These two objects give you full access to all information about the
request and let you control the output sent to the client as the response to the request. With
CGI you read environment variables and stdin to get information about the request, but the
names of the environment variables may vary between implementations and some are not
provided by all Web servers.

The HttpServletRequest object provides the same information as the CGI environment
variables, plus more, in a standardized way. It also provides methods for extracting HTTP
parameters from the query string or the request body depending on the type of request (GET
or POST). As a Servlet developer you access parameters the same way for both types of
requests. Other methods give you access to all request headers and help you parse date and
cookie headers.

Instead of writing the response to stdout as you do with CGI, you get an
OutputStream or a PrintWriter from the HttpServletResponse. The OuputStream is intended
for binary data, such as a GIF or JPEG image, and the PrintWriter for text output. You can
also set all response headers and the status code, without having to rely on special Web server
CGI configurations such as Non Parsed Headers (NPH). This makes your Servlet easier to
install.

ServletConfig and Servlet Context:

There is only one Servlet Context in every application. This object can be used by all
the Servlet to obtain application level information or container details. Every Servlet, on the
other hand, gets its own ServletConfig object. This object provides initialization parameters
for a servlet. A developer can obtain the reference to Servlet Context using either the
ServletConfig object or Servlet Request object.

All servlets belong to one servlet context. In implementations of the 1.0 and 2.0
versions of the Servlet API all servlets on one host belongs to the same context, but with the
2.1 version of the API the context becomes more powerful and can be seen as the humble
beginnings of an Application concept. Future versions of the API will make this even more
pronounced.

Many servlet engines implementing the Servlet 2.1 API let you group a set of servlets
into one context and support more than one context on the same host. The Servlet Context in
the 2.1 API is responsible for the state of its servlets and knows about resources and attributes
available to the servlets in the context. Here we will only look at how Servlet Context
attributes can be used to share information among a group of servlets.

There are three Servlet Context methods dealing with context attributes: get Attribute,
set Attribute and remove Attribute. In addition the servlet engine may provide ways to
configure a servlet context with initial attribute values. This serves as a welcome addition to
the servlet initialization arguments for configuration information used by a group of servlets,
for instance the database identifier we talked about above, a style sheet URL for an
application, the name of a mail server, etc.

JDBC

Java Database Connectivity (JDBC) is a programming framework for Java developers

writing programs that access information stored in databases, spreadsheets, and flat files.
JDBC is commonly used to connect a user program to a "behind the scenes" database,
regardless of what database management software is used to control the database. In this way,
JDBC is cross-platform. This article will provide an introduction and sample code that
demonstrates database access from Java programs that use the classes of the JDBC API,
which is available for free download from Sun's site.

A database that another program links to is called a data source. Many data sources,
including products produced by Microsoft and Oracle, already use a standard called Open
Database Connectivity (ODBC). Many legacy C and Perl programs use ODBC to connect to
data sources. ODBC consolidated much of the commonality between database management
systems. JDBC builds on this feature, and increases the level of abstraction. JDBC-ODBC
bridges have been created to allow Java programs to connect to ODBC-enabled database
software.

JDBC Architecture
Two-tier and Three-tier Processing Models

The JDBC API supports both two-tier and three-tier processing models for database
access.
 In the two-tier model, a Java applet or application talks directly to the data source.
This requires a JDBC driver that can communicate with the particular data source being
accessed. A user's commands are delivered to the database or other data source, and the
results of those statements are sent back to the user. The data source 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
data source as the server. The network can be an intranet, which, for example, connects
employees within a corporation, or it can be the Internet.

In the three-tier model, commands are sent to a "middle tier" of services, which then
sends the commands to the data source. The data source processes the commands 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 it simplifies the deployment of applications.
Finally, in many cases, the three-tier architecture can provide performance advantages.

Until recently, the middle tier has often 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 and technologies such as
Enterprise JavaBeans™, the Java platform is fast becoming the standard platform for middle-
tier development. This is a big plus, making it possible to take advantage of Java's robustness,
multithreading, and security features.

With enterprises increasingly using the Java programming language for writing server
code, the JDBC API is being used more and more in the middle tier of a three-tier
architecture. Some of the features that make JDBC a server technology are its support for
connection pooling, distributed transactions, and disconnected rowsets. The JDBC API is also
what allows access to a data source from a Java middle tier.

Testing

The various levels of testing are

1. White Box Testing

2. Black Box Testing
3. Unit Testing
4. Functional Testing
5. Performance Testing
6. Integration Testing
7. Objective
8. Integration Testing
9. Validation Testing
10. System Testing
11. Structure Testing
12. Output Testing
13. User Acceptance Testing

White Box Testing

White-box testing (also known as clear box testing, glass box testing, transparent
box testing, and structural testing) is a method of testing software that tests internal
structures or workings of an application, as opposed to its functionality (i.e. black-box
testing). In white-box testing an internal perspective of the system, as well as programming
skills, are used to design test cases. The tester chooses inputs to exercise paths through the
code and determine the appropriate outputs. This is analogous to testing nodes in a circuit,
e.g. in-circuit testing (ICT).

While white-box testing can be applied at the unit, integration and system levels of
the software testing process, it is usually done at the unit level. It can test paths within a unit,
paths between units during integration, and between subsystems during a system–level test.
Though this method of test design can uncover many errors or problems, it might not detect
unimplemented parts of the specification or missing requirements.

White-box test design techniques include:

● Control flow testing

● Data flow testing

● Branch testing

● Path testing

● Statement coverage

● Decision coverage

White-box testing is a method of testing the application at the level of the source code.
The test cases are derived through the use of the design techniques mentioned above: control
flow testing, data flow testing, branch testing, path testing, statement coverage and decision
coverage as well as modified condition/decision coverage. White-box testing is the use of
these techniques as guidelines to create an error free environment by examining any fragile
code.

These White-box testing techniques are the building blocks of white-box testing, whose
essence is the careful testing of the application at the source code level to prevent any hidden
errors later on. These different techniques exercise every visible path of the source code to
minimize errors and create an error-free environment. The whole point of white-box testing is
the ability to know which line of the code is being executed and being able to identify what
the correct output should be.
Levels

1. Unit testing. White-box testing is done during unit testing to ensure that the code is
working as intended, before any integration happens with previously tested code.
White-box testing during unit testing catches any defects early on and aids in any
defects that happen later on after the code is integrated with the rest of the application
and therefore prevents any type of errors later on.
2. Integration testing. White-box testing at this level are written to test the interactions
of each interface with each other. The Unit level testing made sure that each code was
tested and working accordingly in an isolated environment and integration examines
the correctness of the behaviour in an open environment through the use of white-box
testing for any interactions of interfaces that are known to the programmer.
3. Regression testing. White-box testing during regression testing is the use of recycled
white-box test cases at the unit and integration testing levels.

White-box testing's basic procedures involve the understanding of the source code that
you are testing at a deep level to be able to test them. The programmer must have a deep
understanding of the application to know what kinds of test cases to create so that every
visible path is exercised for testing. Once the source code is understood then the source code
can be analysed for test cases to be created. These are the three basic steps that white-box
testing takes in order to create test cases:

1. Input, involves different types of requirements, functional specifications, detailed

designing of documents, proper source code, security specifications. This is the
preparation stage of white-box testing to layout all of the basic information.
2. Processing Unit, involves performing risk analysis to guide whole testing process,
proper test plan, execute test cases and communicate results. This is the phase of
building test cases to make sure they thoroughly test the application the given results
are recorded accordingly.
3. Output, prepare final report that encompasses all of the above preparations and
results.
Black Box Testing

Black-box testing is a method of software testing that examines the functionality of

an application (e.g. what the software does) without peering into its internal structures or
workings (see white-box testing). This method of test can be applied to virtually every level
of software testing: unit, integration,system and acceptance. It typically comprises most if not
all higher level testing, but can also dominate unit testing as well

Test procedures

Specific knowledge of the application's code/internal structure and programming

knowledge in general is not required. The tester is aware of what the software is supposed to
do but is not aware of how it does it. For instance, the tester is aware that a particular input
returns a certain, invariable output but is not aware of how the software produces the output
in the first place.

Test cases

Test cases are built around specifications and requirements, i.e., what the application
is supposed to do. Test cases are generally derived from external descriptions of the software,
including specifications, requirements and design parameters. Although the tests used are
primarily functional in nature, non-functional tests may also be used. The test designer selects
both valid and invalid inputs and determines the correct output without any knowledge of the
test object's internal structure.

Test design techniques

Typical black-box test design techniques include:

● Decision table testing

● All-pairs testing

● State transition tables

● Equivalence partitioning

● Boundary value analysis

Unit testing
 In computer programming, unit testing is a method by which individual units
of source code, sets of one or more computer program modules together with associated
control data, usage procedures, and operating procedures are tested to determine if they are fit
for use. Intuitively, one can view a unit as the smallest testable part of an application.
In procedural programming, a unit could be an entire module, but is more commonly an
individual function or procedure. In object-oriented programming, a unit is often an entire
interface, such as a class, but could be an individual method. Unit tests are created by
programmers or occasionally by white box testers during the development process.

Ideally, each test case is independent from the others. Substitutes such as method
stubs, mock objects, fakes, and test harnesses can be used to assist testing a module in
isolation. Unit tests are typically written and run by software developers to ensure that code
meets its design and behaves as intended. Its implementation can vary from being very
manual (pencil and paper)to being formalized as part of build automation.

Testing will not catch every error in the program, since it cannot evaluate every
execution path in any but the most trivial programs. The same is true for unit testing.
Additionally, unit testing by definition only tests the functionality of the units themselves.
Therefore, it will not catch integration errors or broader system-level errors (such as functions
performed across multiple units, or non-functional test areas such as performance).

Unit testing should be done in conjunction with other software testing activities, as
they can only show the presence or absence of particular errors; they cannot prove a complete
absence of errors. In order to guarantee correct behaviour for every execution path and every
possible input, and ensure the absence of errors, other techniques are required, namely the
application of formal methods to proving that a software component has no unexpected
behaviour.

Software testing is a combinatorial problem. For example, every Boolean decision statement
requires at least two tests: one with an outcome of "true" and one with an outcome of "false".
As a result, for every line of code written, programmers often need 3 to 5 lines of test code.

This obviously takes time and its investment may not be worth the effort. There are
also many problems that cannot easily be tested at all – for example those that
are nondeterministic or involve multiple threads. In addition, code for a unit test is likely to
be at least as buggy as the code it is testing. Fred Brooks in The Mythical Man-
Month quotes: never take two chronometers to sea. Always take one or three. Meaning, if
two chronometers contradict, how do you know which one is correct?

Another challenge related to writing the unit tests is the difficulty of setting up
realistic and useful tests. It is necessary to create relevant initial conditions so the part of the
application being tested behaves like part of the complete system. If these initial conditions
are not set correctly, the test will not be exercising the code in a realistic context, which
diminishes the value and accuracy of unit test results.

To obtain the intended benefits from unit testing, rigorous discipline is needed
throughout the software development process. It is essential to keep careful records not only
of the tests that have been performed, but also of all changes that have been made to the
source code of this or any other unit in the software. Use of a version control system is
essential. If a later version of the unit fails a particular test that it had previously passed, the
version-control software can provide a list of the source code changes (if any) that have been
applied to the unit since that time.

It is also essential to implement a sustainable process for ensuring that test case
failures are reviewed daily and addressed immediately if such a process is not implemented
and ingrained into the team's workflow, the application will evolve out of sync with the unit
test suite, increasing false positives and reducing the effectiveness of the test suite.

Unit testing embedded system software presents a unique challenge: Since the
software is being developed on a different platform than the one it will eventually run on, you
cannot readily run a test program in the actual deployment environment, as is possible with
desktop programs.[7]

Functional testing

Functional testing is a quality assurance (QA) process and a type of black box
testing that bases its test cases on the specifications of the software component under test.
Functions are tested by feeding them input and examining the output, and internal program
structure is rarely considered (not like in white-box testing). Functional Testing usually
describes what the system does.

Functional testing differs from system testing in that functional testing "verifies a program by
checking it against ... design document(s) or specification(s)", while system testing
"validate a program by checking it against the published user or system requirements" (Kane,
Falk, Nguyen 1999, p. 52).

Functional testing typically involves five steps .The identification of functions that the
software is expected to perform

1. The creation of input data based on the function's specifications

2. The determination of output based on the function's specifications
3. The execution of the test case
4. The comparison of actual and expected outputs

Performance testing

In software engineering, performance testing is in general testing performed to

determine how a system performs in terms of responsiveness and stability under a particular
workload. It can also serve to investigate, measure, validate or verify
other quality attributes of the system, such as scalability, reliability and resource usage.

Performance testing is a subset of performance engineering, an emerging computer

science practice which strives to build performance into the implementation, design and
architecture of a system.

Testing types

Load testing

Load testing is the simplest form of performance testing. A load test is usually
conducted to understand the behaviour of the system under a specific expected load. This
load can be the expected concurrent number of users on the application performing a specific
number of transactions within the set duration. This test will give out the response times of all
the important business critical transactions. If the database, application server, etc. are also
monitored, then this simple test can itself point towards bottlenecks in the application
software.

Stress testing

Stress testing is normally used to understand the upper limits of capacity within the
system. This kind of test is done to determine the system's robustness in terms of extreme
load and helps application administrators to determine if the system will perform sufficiently
if the current load goes well above the expected maximum.

Soak testing

Soak testing, also known as endurance testing, is usually done to determine if the
system can sustain the continuous expected load. During soak tests, memory utilization is
monitored to detect potential leaks. Also important, but often overlooked is performance
degradation. That is, to ensure that the throughput and/or response times after some long
period of sustained activity are as good as or better than at the beginning of the test. It
essentially involves applying a significant load to a system for an extended, significant period
of time. The goal is to discover how the system behaves under sustained use.

Spike testing

Spike testing is done by suddenly increasing the number of or load generated by,
users by a very large amount and observing the behaviour of the system. The goal is to
determine whether performance will suffer, the system will fail, or it will be able to handle
dramatic changes in load.

Configuration testing

Rather than testing for performance from the perspective of load, tests are created to
determine the effects of configuration changes to the system's components on the system's
performance and behaviour. A common example would be experimenting with different
methods of load-balancing.

Isolation testing

Isolation testing is not unique to performance testing but involves repeating a test
execution that resulted in a system problem. Often used to isolate and confirm the fault
domain.

Integration testing
 Integration testing (sometimes called integration and testing, abbreviated I&T) is
the phase in software testing in which individual software modules are combined and tested
as a group. It occurs after unit testing and before validation testing. Integration testing takes
as its input modules that have been unit tested, groups them in larger aggregates, applies tests
defined in an integration test plan to those aggregates, and delivers as its output the integrated
system ready for system testing.

Purpose

The purpose of integration testing is to verify functional, performance, and

reliability requirements placed on major design items. These "design items", i.e. assemblages
(or groups of units), are exercised through their interfaces using black box testing, success
and error cases being simulated via appropriate parameter and data inputs. Simulated usage of
shared data areas and inter-process communication is tested and individual subsystems are
exercised through their input interface.

Test cases are constructed to test whether all the components within assemblages
interact correctly, for example across procedure calls or process activations, and this is done
after testing individual modules, i.e. unit testing. The overall idea is a "building block"
approach, in which verified assemblages are added to a verified base which is then used to
support the integration testing of further assemblages.

Some different types of integration testing are big bang, top-down, and bottom-up.
Other Integration Patterns are: Collaboration Integration, Backbone Integration, Layer
Integration, Client/Server Integration, Distributed Services Integration and High-frequency
Integration.

Big Bang

In this approach, all or most of the developed modules are coupled together to form a
complete software system or major part of the system and then used for integration testing.
The Big Bang method is very effective for saving time in the integration testing process.
However, if the test cases and their results are not recorded properly, the entire integration
process will be more complicated and may prevent the testing team from achieving the goal
of integration testing.

A type of Big Bang Integration testing is called Usage Model testing. Usage Model
Testing can be used in both software and hardware integration testing. The basis behind this
type of integration testing is to run user-like workloads in integrated user-like environments.
In doing the testing in this manner, the environment is proofed, while the individual
components are proofed indirectly through their use.

Usage Model testing takes an optimistic approach to testing, because it expects to

have few problems with the individual components. The strategy relies heavily on the
component developers to do the isolated unit testing for their product. The goal of the
strategy is to avoid redoing the testing done by the developers, and instead flesh-out problems
caused by the interaction of the components in the environment.

For integration testing, Usage Model testing can be more efficient and provides better
test coverage than traditional focused functional integration testing. To be more efficient and
accurate, care must be used in defining the user-like workloads for creating realistic scenarios
in exercising the environment. This gives confidence that the integrated environment will
work as expected for the target customers.

Top-down and Bottom-up

Bottom Up Testing is an approach to integrated testing where the lowest level

components are tested first, then used to facilitate the testing of higher level components. The
process is repeated until the component at the top of the hierarchy is tested.

All the bottom or low-level modules, procedures or functions are integrated and then
tested. After the integration testing of lower level integrated modules, the next level of
modules will be formed and can be used for integration testing. This approach is helpful only
when all or most of the modules of the same development level are ready. This method also
helps to determine the levels of software developed and makes it easier to report testing
progress in the form of a percentage.

Top Down Testing is an approach to integrated testing where the top integrated
modules are tested and the branch of the module is tested step by step until the end of the
related module.

Sandwich Testing is an approach to combine top down testing with bottom up

testing.

The main advantage of the Bottom-Up approach is that bugs are more easily found. With
Top-Down, it is easier to find a missing branch link

Verification and validation

 Verification and Validation are independent procedures that are used together for
checking that a product, service, or system meets requirements and specifications and that it
full fills its intended purpose. These are critical components of a quality management
system such as ISO 9000. The words "verification" and "validation" are sometimes preceded
with "Independent" (or IV&V), indicating that the verification and validation is to be
performed by a disinterested third party.

It is sometimes said that validation can be expressed by the query "Are you building
the right thing?" and verification by "Are you building it right?"In practice, the usage of these
terms varies. Sometimes they are even used interchangeably.

The PMBOK guide, an IEEE standard, defines them as follows in its 4th edition

● "Validation. The assurance that a product, service, or system meets the needs of the
customer and other identified stakeholders. It often involves acceptance and suitability
with external customers. Contrast with verification."

● "Verification. The evaluation of whether or not a product, service, or system complies

with a regulation, requirement, specification, or imposed condition. It is often an internal
process. Contrast with validation."

● Verification is intended to check that a product, service, or system (or portion thereof,
or set thereof) meets a set of initial design specifications. In the development phase,
verification procedures involve performing special tests to model or simulate a
portion, or the entirety, of a product, service or system, then performing a review or
analysis of the modelling results. In the post-development phase, verification
procedures involve regularly repeating tests devised specifically to ensure that the
product, service, or system continues to meet the initial design requirements,
specifications, and regulations as time progresses. It is a process that is used to
evaluate whether a product, service, or system complies with
regulations, specifications, or conditions imposed at the start of a development phase.
Verification can be in development, scale-up, or production. This is often an internal
process.

● Validation is intended to check that development and verification procedures for a

product, service, or system (or portion thereof, or set thereof) result in a product,
 service, or system (or portion thereof, or set thereof) that meets initial
requirements. For a new development flow or verification flow, validation procedures
may involve modelling either flow and using simulations to predict faults or gaps that
might lead to invalid or incomplete verification or development of a product, service,
or system (or portion thereof, or set thereof). A set of validation requirements,
specifications, and regulations may then be used as a basis for qualifying a
development flow or verification flow for a product, service, or system (or portion
thereof, or set thereof). Additional validation procedures also include those that are
designed specifically to ensure that modifications made to an existing qualified
development flow or verification flow will have the effect of producing a product,
service, or system (or portion thereof, or set thereof) that meets the initial design
requirements, specifications, and regulations; these validations help to keep the flow
qualified. It is a process of establishing evidence that provides a high degree of
assurance that a product, service, or system accomplishes its intended requirements.
This often involves acceptance of fitness for purpose with end users and other product
stakeholders. This is often an external process.

● It is sometimes said that validation can be expressed by the query "Are you building
the right thing?" and verification by "Are you building it right?". "Building the right
thing" refers back to the user's needs, while "building it right" checks that the
specifications are correctly implemented by the system. In some contexts, it is
required to have written requirements for both as well as formal procedures or
protocols for determining compliance.

● It is entirely possible that a product passes when verified but fails when validated.
This can happen when, say, a product is built as per the specifications but the
specifications themselves fail to address the user’s needs.

Activities

Verification of machinery and equipment usually consists of design qualification

(DQ), installation qualification (IQ), operational qualification (OQ), and performance
qualification (PQ). DQ is usually a vendor's job. However, DQ can also be performed by the
user, by confirming through review and testing that the equipment meets the written
acquisition specification. If the relevant document or manuals of machinery/equipment are
provided by vendors, the later 3Q needs to be thoroughly performed by the users who work in
an industrial regulatory environment. Otherwise, the process of IQ, OQ and PQ is the task of
validation. The typical example of such a case could be the loss or absence of vendor's
documentation for legacy equipment or do-it-yourself (DIY) assemblies (e.g., cars, computers
etc.) and, therefore, users should endeavour to acquire DQ document beforehand. Each
template of DQ, IQ, OQ and PQ usually can be found on the internet respectively, whereas
the DIY qualifications of machinery/equipment can be assisted either by the vendor's training
course materials and tutorials, or by the published guidance books, such as step-by-step series
if the acquisition of machinery/equipment is not bundled with on- site qualification services.
This kind of the DIY approach is also applicable to the qualifications of software, computer
operating systems and a manufacturing process. The most important and critical task as the
last step of the activity is to generating and archiving machinery/equipment qualification
reports for auditing purposes, if regulatory compliances are mandatory.

Qualification of machinery/equipment is venue dependent, in particular items that are

shock sensitive and require balancing or calibration, and re-qualification needs to be
conducted once the objects are relocated. The full scales of some equipment qualifications are
even time dependent as consumables are used up (i.e. filters) or springs stretch out,
requiring recalibration, and hence re-certification is necessary when a specified due time
lapse Re-qualification of machinery/equipment should also be conducted when replacement
of parts, or coupling with another device, or installing a new application software and
restructuring of the computer which affects especially the pre-settings, such as
on BIOS, registry, disk drive partition table, dynamically-linked (shared) libraries, or an ini
file etc., have been necessary. In such a situation, the specifications of the
parts/devices/software and restructuring proposals should be appended to the qualification
document whether the parts/devices/software are genuine or not.

Torres and Hyman have discussed the suitability of non-genuine parts for clinical use
and provided guidelines for equipment users to select appropriate substitutes which are
capable to avoid adverse effects. In the case when genuine parts/devices/software are
demanded by some of regulatory requirements, then re-qualification does not need to be
conducted on the non-genuine assemblies. Instead, the asset has to be recycled for non-
regulatory purposes.

When machinery/equipment qualification is conducted by a standard endorsed third

party such as by an ISO standard accredited company for a particular division, the process is
called certification. Currently, the coverage of ISO/IEC 15408 certification by an ISO/IEC
27001 accredited organization is limited; the scheme requires a fair amount of efforts to get
popularized.

System testing

System testing of software or hardware is testing conducted on a complete, integrated

system to evaluate the system's compliance with its specified requirements. System testing
falls within the scope of black box testing, and as such, should require no knowledge of the
inner design of the code or logic.

As a rule, system testing takes, as its input, all of the "integrated" software
components that have passed integration testing and also the software system itself integrated
with any applicable hardware system(s). The purpose of integration testing is to detect any
inconsistencies between the software units that are integrated together (called assemblages)
or between any of the assemblages and the hardware. System testing is a more limited type of
testing; it seeks to detect defects both within the "inter-assemblages" and also within the
system as a whole.

System testing is performed on the entire system in the context of a Functional

Requirement Specification(s) (FRS) and/or a System Requirement Specification (SRS).
System testing tests not only the design, but also the behavior and even the believed
expectations of the customer. It is also intended to test up to and beyond the bounds defined
in the software/hardware requirements specification

Types of tests to include in system testing

The following examples are different types of testing that should be considered during
System testing:

● Graphical user interface testing

● Usability testing

● Software performance testing

● Compatibility testing

● Exception handling

● Load testing
● Volume testing

● Stress testing

● Security testing

● Scalability testing

● Sanity testing

● Smoke testing

● Exploratory testing

● Ad hoc testing

● Regression testing

● Installation testing

● Maintenance testing Recovery testing and failover testing.

● Accessibility testing, including compliance with:

● Americans with Disabilities Act of 1990

● Section 508 Amendment to the Rehabilitation Act of 1973

● Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C)

Although different testing organizations may prescribe different tests as part of System
testing, this list serves as a general framework or foundation to begin with.

Structure Testing:

It is concerned with exercising the internal logic of a program and traversing

particular execution paths.
Output Testing:

● Output of test cases compared with the expected results created during design of test

cases.
 ● Asking the user about the format required by them tests the output generated or

displayed by the system under consideration.

● Here, the output format is considered into two was, one is on screen and another one

is printed format.

● The output on the screen is found to be correct as the format was designed in the

system design phase according to user needs.

● The output comes out as the specified requirements as the user’s hard copy.

User acceptance Testing:

● Final Stage, before handling over to the customer which is usually carried out by the

customer where the test cases are executed with actual data.

● The system under consideration is tested for user acceptance and constantly keeping

touch with the prospective system user at the time of developing and making changes
whenever required.

● It involves planning and execution of various types of test in order to demonstrate that

the implemented software system satisfies the requirements stated in the requirement
document.
Two set of acceptance test to be run:

1. Those developed by quality assurance group.

2. Those developed by customer.
Future work:

As a response, erasure coding as an alternative to backup has emerged as a method of

protecting against drive failure.Raid just does not cut it in the age of high-capacity HDDs.
The larger a disk's capacity, the greater the chance of bit error.And when a disk fails, the Raid
rebuild process begins, during which there is no protection against a second (or third)
mechanism failure. So not only has the risk of failure during normal operation grown with
capacity, it is much higher during Raid rebuild, too. Also, rebuild times were once measured
in minutes or hours, but disk transfer rates have not kept pace with the rate of disk capacity
expansion, so large Raid rebuilds can now take days or even longer.

Coding:

Database

/*

SQLyog - Free MySQL GUI v5.13

Host - 5.0.22-community-nt : Database - erasurecode

*********************************************************************

Server version : 5.0.22-community-nt

*/
SET NAMES utf8;

SET SQL_MODE='';

create database if not exists `erasurecode`;

USE `erasurecode`;

SET@OLD_SQL_MODE=@@SQL_MODE,
SQL_MODE='NO_AUTO_VALUE_ON_ZERO';

/*Table structure for table `admin` */

DROP TABLE IF EXISTS `admin`;

CREATE TABLE `admin` (

`username` varchar(30) default NULL,

`password` varchar(30) default NULL

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

/*Data for the table `admin` */

insert into `admin` (`username`,`password`) values ('deva','deva');

/*Table structure for table `gender` */

DROP TABLE IF EXISTS `gender`;

CREATE TABLE `gender` (

`Gender` varchar(20) default NULL

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

/*Data for the table `gender` */

insert into `gender` (`Gender`) values ('Male');

insert into `gender` (`Gender`) values ('Female');

/*Table structure for table `ownerprofile` */

DROP TABLE IF EXISTS `ownerprofile`;

CREATE TABLE `ownerprofile` (

`UserName` varchar(35) default NULL,

`groupname` varchar(35) default NULL,

 `filename` varchar(700) NOT NULL,

`server1` varchar(100) default NULL,

`server2` varchar(100) default NULL,

`server3` varchar(100) default NULL,

`server4` varchar(100) default NULL,

PRIMARY KEY (`filename`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

/*Data for the table `ownerprofile` */

Insert into `ownerprofile`

(`UserName`,`groupname`,`filename`,`server1`,`server2`,`server3`,`server4`) values
('ram','ram','3.jpg','ef3cad6eee251f670014365fde992889e73f1a8e','ef3cad6eee251f67001436
5fde992889e73f1a8ekey1','ef3cad6eee251f670014365fde992889e73f1a8ekey2','ef3cad6eee2
51f670014365fde992889e73f1a8ekey3');

/*Table structure for table `registration` */

DROP TABLE IF EXISTS `registration`;

CREATE TABLE `registration` (

`username` varchar(30) default NULL,

`password` varchar(30) default NULL,

`gender` varchar(20) default NULL,

`email` varchar(50) default NULL,

 `phoneno` varchar(50) default NULL,

`userproductkey` varchar(50) default NULL

) ENGINE=InnoDB DEFAULT CHARSET=latin1;

/*Data for the table `registration` */

insert into `registration`

(`username`,`password`,`gender`,`email`,`phoneno`,`userproductkey`) values
('ram','ram','male','deva@gamil.com','1234','asdfasdfasdfasdf');

insert into `registration`

(`username`,`password`,`gender`,`email`,`phoneno`,`userproductkey`) values ('deva
',NULL,NULL,NULL,NULL,NULL);

insert into `registration`

(`username`,`password`,`gender`,`email`,`phoneno`,`userproductkey`) values
('kumar',NULL,NULL,NULL,NULL,NULL);

SET SQL_MODE=@OLD_SQL_MODE;

Admin Servlet Code:

*/

package com.ErasureCode;

import java.io.IOException;

import java.io.PrintWriter;

import java.sql.Connection;
import java.sql.DriverManager;

import java.sql.ResultSet;

import java.sql.Statement;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import javax.servlet.http.HttpSession;

import java.io.*;

import javax.servlet.*;

import javax.servlet.http.*;

/**

* @author Admin

*/

public class AdminServlet extends HttpServlet {

private Object out;

/**

* Processes requests for both HTTP <code>GET</code> and <code>POST</code>

* methods.
*

* @param request servlet request

* @param response servlet response

* @throws ServletException if a servlet-specific error occurs

* @throws IOException if an I/O error occurs

*/

protected void processRequest(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

response.setContentType("text/html;charset=UTF-8");

try (PrintWriter out = response.getWriter()) {

/* TODO output your page here. You may use following sample code. */

out.println("<!DOCTYPE html>");

out.println("<html>");

out.println("<head>");

out.println("<title>Servlet AdminServlet</title>");

out.println("</head>");

out.println("<body>");

out.println("<h1>Servlet AdminServlet at " + request.getContextPath() + "</h1>");

out.println("</body>");

out.println("</html>");
}

// <editor-fold defaultstate="collapsed" desc="HttpServlet methods. Click on the + sign on

the left to edit the code.">

/**

* Handles the HTTP <code>GET</code> method.

* @param request servlet request

* @param response servlet response

* @throws ServletException if a servlet-specific error occurs

* @throws IOException if an I/O error occurs

*/

@Override

protected void doGet(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

processRequest(request, response);

}
/**

* Handles the HTTP <code>POST</code> method.

* @param request servlet request

* @param response servlet response

* @throws ServletException if a servlet-specific error occurs

* @throws IOException if an I/O error occurs

*/

@Override

protected void doPost(HttpServletRequest request, HttpServletResponse response)

throws ServletException, IOException {

HttpSession session1=request.getSession();

Connection con=null;

Statement st=null;

ResultSet rs=null;

try(PrintWriter out = response.getWriter())

{

String Username=request.getParameter("username");

String Password=request.getParameter("password");

System.out.println("this line my cheking======="+Username);

System.out.println("this line my cheking======="+Password);

Class.forName("com.mysql.jdbc.Driver");

con=DriverManager.getConnection("jdbc:mysql://localhost:3306/
imageselectionerasurecode","root","password");

st=con.createStatement();

rs=st.executeQuery("select * from admin where username='"+Username+"' and

password='"+Password+"'");

if(rs.next())

response.sendRedirect("UserReg.jsp");

else

{
// out.print("Sorry UserName or Password Error!");

RequestDispatcher rd=request.getRequestDispatcher("Admin1.jsp");

rd.include(request, response);

out.print("<br><br><br><h1><center>Sorry UserName or Password Error!"+"</h1>");

catch(Exception ex)

ex.printStackTrace();

Screenshot:
Conclusion:
Erasure codes are promising for improving the reliability of the storage system due to
its space efficiency compared to the replication methods. Traditional erasure codes split data
into equalsized data blocks and encode strips in different data blocks. This brings heavy
repairing traffic when clients read parts of the data, since most strips read for repairing are
not in the expected blocks. This paper proposes a novel discrete data dividing method to
completely avoid this problem. The key idea is to encode strips from the same data block. We
could see that for repairing failed blocks, the strips to be read are either in the same data
block with corrupted strips or from the encoded strips. Therefore, no data is wasted. We
design and implement this data layout into a HDFS-like storage system. Experiments over a
small-scale testbed shows that the proposed discrete data divided method avoids downloading
data blocks that are not needed for clients during the repairing operations.

REFERENCES
[1] James S. Plank, Erasure Codes for Storage Systems A Brief
Primer, USENIX .login, Vol. 38 No. 6, 2013.
[2] Hsing-bung Chen, Ben McClelland, et al., An Innovative
Parallel Cloud Storage System using OpenStack’s Swift Object
Store and Transformative Parallel I/O Approach, Los Alamos
National Lab Science Highlights, 2013.
[3] Corentin Debains, Gael Alloyer, Evaluzation, Evaluation of
Erasure-coding libraries on Parallel Systems, 2010.
[4] Peter Sobe, Parallel Reed/Solomon Coding on Multicore
Processors, in Proceedings of International Workshop on
Storage Network Architecture and parallel I/O, 2010.
[5] Babak Behzad, Improving parallel I/O auto tuning with
performance modeling, in Proceedings of ACM International
Symposium on High-performance Parallel and Distributed
Computing (HPDC), 2014.
[6] Hsing-bung Chen, parEC – A Parallel and Scalable of erasure
coding support in Cloud Object Storage Systems, Los Alamos
National Lab.
[7] A. Varbanescu , On the Effective Parallel Programming of
Multi-core Processors, Ph.D Thesis, Technische Universiteit
Delft , 2010.
[8] William Gropp Ewing Lusk, Anthony Skjellum, Using MPI:
Portable Parallel Programming with the Message-Passing
Interface, The MIT Press, 2014.
[9] Hsing-bung Chen, Parallel Workload Benchmark on Hybrid
Storage EcoSystem, Los Alamos national Lab.