You are on page 1of 11

ABSTRACT

Searching through the keywords in an image database require a lot of Meta data (information
about the image) to be stored for each image in a separate database. This does not lead to an
effective search mechanism. Also the currently available search query results do not involve the
resultant images that are content related i.e. images whose contents are similar. The similarity in
the context of the content is measured by as many features like Color, Texture, Shape, Dominant
Color, Correlation Matching heuristic, Many new features are being proposed day by day, many
of which like entropy, smoothness, skewness, etc.
In this research I am proposing an approach to model content based meta-search engine which
search all the content related images present in the dataset. The result based on the above features
from the images is filtered using the correlation matching heuristic. The overall matching scores
will decide on the basis of the sum of all of these individual feature scores. The proposed scheme
will be used to retrieve all the images having related contents to the query image. On the basis of
the scores ranking of the match will be provided. The simulation results of combined approach
suggest the effectiveness of the approach. This proposed model will increase the accuracy of
search results.
This research model is quite interactive and familiar like the other meta-data models present on
web for searching the images from huge database and data sources. In advance this model also
contains many good features to improve the accuracy and efficiency. Although this model has
some small riddles those have to solve afterwards.

Chapter-1
INTRODUCTION
1.1 Information:
There are two Web Services protocols standards, SOAP WS and RESTful WS.

SOAP Web Services is having well-adopted standards. Following is a typical scenario of


consuming SOAP Web Services.
a. The provider of service who publishes services to the
service registry follows the UDDI standard.
b. Customers too follow UDDI standard to innovate the service they want.
c. Customers make out the code for a particular SOAP Web
Services from the WSDL.
d. Customers interchange SOAP messages with services which uses the Hyper Text
Transfer Protocol.
Another solution to SOAP Web Services is Restful Web Services. Restful Web Services
were first time introduced by Fielding in his doctoral dissertation in the year 2002. They
followed a resource-orientation computing procedure. Restful Web Ser ices were
presented as resources which were identified by a Uniform Resource Identifier (URI).
Customers interact with the Restful Web-Services through the Hyper Text Transfer
Protocol, but not only this, the message/information body can follow any formats/path,
such as Extensible Markup Language and JSON structure, as long as the customers and
the providers who provides services mutually agree upon it. Restful Web Services also
take profit of the meaning of the Hyper Text Transfer Protocol. Such as for example,
HTTP GET request is for taking a resource and HTTP POST.
and the quality of services. To ensure and to make it confirm about the correctness of user
data in the cloud. We propose and we make a suitable and flexible and easy distribution
scheme for the two way handshake based on token management. By using and enhancing
the homomorphic token with distributed verification/ authorization of erasure-coded data,
our scheme achieves and touches the integration of the storage and its correct insurance
and data error localization i.e., the finding of misbehaving server(s).

1.2 Data Storage:


Cloud Computerization has been developed as the next generation architecture of
Information Technology Enterprise Edition. Various trends and techniques are opening up
the world of Cloud Computing, and one of the questions which are arising in the mind of
experts is that which is an Internet-based development and use of computer technology?
If we Consider and accept various/ different kinds and types of data for each of our user
stored in the cloud and the need of everlasting term continuous assurance of their data
safety and security, the problem of verifying and authorizing correctness and error free of
data storage in the cloud comes out to be even more challenging and difficult. Despite
this, the Cloud Computerization is not only another party data warehouse. The storage of
the data in the cloud may be frequently updated by the users or the clients or the
customers, including various methods like inserting, deleting, modification, appending,
reordering, etc. To ensure and to make it clear about the storage correctness and ensures
its safety under the dynamic and modified data to update is hence of great and necessary
importance.
These techniques, however can be useful for both clients and service providers to ensure
the storage correctness without having clients possessing data, but in another case it
cannot address all the security threats and thefts in cloud data storage, since they are all
determining on single and alone server scenario and most of them do not consider
dynamic data operations.
Our work and effort is among the first few ones in this field and scenarios to consider the
distributed data storage in the Cloud Computing environment. Our contribution can be
summarized and followed as the following three aspects:

a) Equalizing or just comparing to many of its predecessors, which only provide the
binary (two way) results or binary outcome about the storage state across the distributed
servers, the challenge-response protocol or the rules in our work in future provides the
localization of data error.
b) Unlike most prior works or the previous work for ensuring and to make it confirm
about the remote data integrity, the new scheme, new study and new work supports
secure, clear and efficient dynamic operations on data blocks, including: update, delete
and append.
c) Extensive security, enlarged performance and performance analysis shows that the
proposed scheme is highly efficient and resilient against Byzantine failure, malicious data
modification attack, and even server colluding attacks.

1.3 Ensuring Cloud Data Storage:


In cloud data storage system, users store their data in the cloud and no longer possess the
data locally. Thus, the correctness and availability of the data files being stored on the
distributed cloud servers must be guaranteed. Our main scheme for ensuring cloud data
storage is presented in this section. The first part of the section is devoted to a review of
basic tools from coding theory that is needed in our scheme for file distribution across
cloud servers.

1.4 Correctness:
Our scheme outperforms those by integrating the correctness verification and error
localization in our challenge-response protocol: the response values from servers for each
challenge not only determine the correctness of the distributed storage, but also contain
information to locate potential data error.
Cloud Computing has been envisioned as the next generation architecture of IT
Enterprise. In contrast to traditional solutions, where the IT services are under proper
physical, logical and personnel controls, Cloud Computing moves the application
software and databases to the large data centers, where the management of the data and
services may not be fully trustworthy. This unique attribute, however, poses many new
security challenges which have not been well understood. In this article, we focus on
cloud data storage security, which has always been an important aspect of quality of
service. To ensure the correctness of users data in the cloud, we propose an effective and
flexible distributed scheme with two salient features, opposing to its predecessors. By
utilizing the homomorphic token with distributed verification of erasure-coded data, our
scheme achieves the integration of storage correctness insurance and data error
4

localization, i.e., the identification of misbehaving server(s). Unlike most prior works, the
new scheme further supports secure and efficient dynamic operations on data blocks,
including: data update, delete and append. Extensive security and performance analysis
shows that the proposed scheme is highly efficient and resilient against Byzantine failure,
malicious data modification attack, and even server colluding attacks.

1.5 Design & Architecture:


The aim of the Mobile Cloud Computing (MCC) architecture is to provide a proxy for
mobile clients connecting to Cloud services. The architecture include three parts, the
mobile clients, the middleware and the Cloud services. Since Cloud services are generally
controlled by service providers, the middleware performs all the necessary adaptation to
the mobile clients. Some services require real-time updates, for example, news, Blog, and
Twitter service.
The middleware also pushes updates of service results to mobile clients via HTTP or
email immediately after it receives the updates.
The middleware is responsible for consuming the Cloud Services whether they are SOAP
or RESTful WS and delivers the service result to the mobile client. On the mobile client,
users can define WS or mashup services and later execute the pre-defined WS on the
fly. The middleware provide RESTful WS interface for the mobile clients. When WS are
executed through the middleware, the follow steps are involved in the middleware.
1. The mobile client sends a HTTP GET request with an identifier of a WS to the
middleware.
2. The middleware deals with interactions to the WS (and generates SOAP WS client).
3. The middleware extracts (JSON or XML parsing) the required service results from the
original service result and form a new service results in JSON format.
5

4. The middleware stores a copy of result with the service ID in the database and
returns the optimized result to the mobile client
The middleware is also a Personal Service Mashup Platform (PSMP) that is based on a
novel data structure which represents WS as objects. The next section talks about the
middleware design and how these functions are achieved. Section 3 describes the design
of PSMP. The rest of the sections present implementations of mobile client and Cloud
middleware.

1.6 Middleware Architecture:


It has a RESTful service interface for mobile clients. By the management interface,
users can define and manage user profile, Mashup Services, Service Actions, and their
parameters and results. All the requests through the management interface are passed to
the service repository which reads and write data from and into the storage. The execution
requests of Service Actions go through the service execution interface. These requests
are primarily mapped to read operations in the service repository. The service executer
composes service requests and passes them to the HTTP client which sends outgoing
request to Cloud services. In short, the middleware provides the following features to
improve the interaction between mobile clients and Cloud Services.
Middleware pushing: Mobile clients can subscribe to service resources and explicitly
update service results cached on the middleware through the management interface.
When the middleware receives an update of service results, it sends the update to all the
mobile clients that subscribed to this service result. The update is pushed to the clients
(e.g. via email).

1.7 Personal Service Mashup Platform:


On the mobile client side, the middleware has a user interface which lets users define
mashup services. The middleware has a service storage which stores user defined service
data and an execution engine which executes WS and pipes input and output of WS. In
order to support a service mashup, the middleware must first support consuming existing
WSs. Specific WS calls are pre-defined by users using the mobile client and stored in the
service storage for future execution. The following gives a user scenario of how to
consume a WS from the mobile client through the middleware.

1.8 Service Entities:


User defined WS calls are stored in the service storage as service entities. A WS
essentially includes two parts of information: service configuration describing the
properties of the WS (meta-data) and how to consume the service (parameters), and the
user-specific parameter values needed to be passed to the WS. There is a format
describing a RESTful WS (WADL), but it is not adopted. In the middleware, service
entities abstract the essential elements of RESTful WS. In the future, service entities will
also be compatible for both SOAP and RESTful WS.
System storage is a database implementation. Each kind of entity is presented as a table.
there are four kinds of entity: Mashup Service (MS), Service Action (SA), parameter,
result and result value.
Mashup Service (MS): It is a container for service actions. It provides users with
a conceptual grouping of similar service actions as well as a boundary for preventing
outside access. Users can also share their MS with others.
Service Action (SA): It is the primary entity on which the service mashup is based. It
defines all the necessary attributes to consume a WS: the URL to find the WS, the
interaction protocol, the parameters required by the WS, the desired results and so on.
Parameter: It is not only a name-value pair, but also consists of meta-data, for
example, the source of a value and how they are passed to the WS
Result: It describes how the proxy processes the WS response and how the clients
present the result. Only data interesting to the user will be extracted from the response.
Result value: The reason for separating result and result value is that a result can have
multiple copies of values depending on targeted clients. The proxy keeps copies of results
in local database for different clients, for example HTML for browser, JSON for native
application.

Literature Review
2.1 SECURITY:
Data confidentiality is a desired property when users outsource their data storage to
public cloud service providers. To protect users data, encryption is used to secure the
data in the cloud. Recently, Cipher text Policy Attribute- Based Encryption (CP-ABE)
schemes were proposed to facilitate key management and cryptographic access control in
an expressive and efficient way. Under the construction of CP-ABE, an attribute is a
descriptive string assigned to (or associated with) a user and each user may be tagged
with multiple attributes. Multiple users may share common attributes, which allow
message encryptors to specify a data access policy by composing multiple attributes
through logical operators such as AND, OR, etc. To decrypt the message, the
decryptors attributes need to satisfy the access policy. These unique features of CP-ABE
solutions make them appealing in the cloud data storage system that requires an efficient
data access control for a large number of users
belonging to different organizations.
With the fast development of wireless technology, mobile cloud has become an emerging
cloud service model, in which mobile devices and sensors are used as the information
collecting and processing nodes for the cloud infrastructure. This new trend demands
researchers and practitioners to construct a trustworthy architecture for mobile cloud
computing, which includes a large numbers.
8

With the CP-ABE enabled cloud storage service, a new challenge is how to incorporate
wireless mobile devices, especially lightweight devices such as cell phones and sensors
into the cloud system. This new challenge is originated from the fact that CP-ABE
schemes always require intensive computing resources to run the encryption and
decryption algorithms. To address this issue, an effective solution is to outsource the
heavy encryption and decryption computation without exposing the sensitive data
contents or keys to the cloud service providers. Our research described in this paper
proposes such a solution for CP-ABE. Another research challenge is how to share
encrypted data with a large number of users, in which the data sharing group can be
changed frequently. For example, when a user is revoked from accessing a file, he/she is
not authorized to access any future updates of the file, i.e., the local copy (if exists) will
get outdated. To this end, the updated data need to be encrypted by a new encryption key.
Furthermore, the third research challenge is how to upload/ download and update
encrypted data stored in the cloud system. For example, when changing certain data
fields of an encrypted database, the encrypted data needs to be downloaded from cloud
and then be decrypted. Upon finishing the updates, the files need to be re-encrypted and
uploaded to the cloud system. Frequent upload/download operations will cause
tremendous overhead for resource constrained wireless devices. Thus, it is desirable to
design a secure and efficient cloud data management scheme to balance the
communication and storage operational overhead incurred by managing the encrypted
data.
To address the above described research challenges, in this paper, we present a holistic
secure mobile cloud data management framework that includes two major components:
1) A Privacy Preserving CP-ABE (PP-CP-ABE) scheme;
2) An Attribute-Based Data Storage (ABDS) scheme that achieves information
theoretical optimality.
Using PP-CP-ABE, users can securely outsource computation
Intensive CP-ABE encryption and decryption operations to the cloud without revealing
data content and secret keys. In this way, lightweight and resource constrained devices
can access and manage data stored in the cloud data store. The ABDS system achieves
scalable and fine-grained data access control, using public cloud services. Based on
ABDS, users attributes are organized in a carefully constructed hierarchy so that the cost
of membership revocation can be minimized. Moreover, ABDS is suitable for mobile
computing to balance communication and storage overhead, and thus reduces the cost of
data management operations (such as upload, updates, etc.) for both the mobile cloud
nodes and storage service providers.
A. Notations:
The notation used in this paper is listed in Table II-A:

TABLE I
NOTATIONS USED IN THIS PAPER.
Acronym Descriptions
DO Data Owner
ESP Encryption Service Provider
DSP Decryption Service Provider
SSP Storage Service Provider
TA Trust Authority
T Access Policy Tree

2.2 System Model:


In our proposed system, we denote the Data Owner as DO. A DO can be a mobile
wireless device or a sensor that can request and/or store information from/in the Cloud.
The data are secured by using our proposed PP-CP-ABE scheme. Other than DO, there
are many data receivers who subscribe to the data owned by DO. The presented system
model has the following properties:
1) The data must be encrypted before sending to storage service provider (SSP).
2) The encryption service provider (ESP) provides encryption service to the data owner
without knowing the actual data encryption key (DEK).
3) The decryption service provider (DSP) provides decryption service to users without
knowing the data content.
4) Even ESP, DSP and SSP collude, the data content cannot be revealed;
The SSP, ESP, and DSP form the core components of the proposed system. ESP and DSP
provide PPCP-ABE services and SSP, e.g., Amazon S3, provides storage services. The
cloud I semi-trusted, in which the cloud only provides computing and storage services
with the assistance on data security; however, the data is blinded to the cloud. In
particular, more powerful PCs and Mobile Phones can works as communication proxy for
sensors that collect information.

10

4.5 SUMMARY AND CONTRIBUTION:


As service consumers, mobile devices have unique properties. They are small and
portable. They are personal devices with various sensors. However, mobile devices have
limitations, for example, small bandwidth, loss connectivity and less process power. On
the another hand, the existing services are normally designed for stationary clients. For
example, SOAP is a verbose protocol which involves a lot of XML parsing. To overcome
the limitations, this research presents the Mobile Cloud Computing architecture for
connecting mobile device to
the existing Cloud Services.
The proposed mobile client design is mobile platform independent. The mobile client
provides an interface for users to define mashup services and consume them through the
middleware. It interacts with the middleware through RESTful WS interface. The mobile
client has been implemented on two major mobile platforms, Android and Blackberry.
The mobile client design involves both native application and embedded browser.
GAE is highly scalable, because the applications share Google's infrastructure. However,
because resources are shared, the Quality of Service (QoS) is hard to control. EC2 is very
stable but hard to scale, since users have the complete control of the Virtual Machines.
The experiments proved the following design of the mobile client and middleware. The
mobile client is able to consume both SOAP and RESTful WS through the middleware.
The mobile client can be implemented on different mobile platforms. The mobile client
can be implemented as a native as well as embedded browser Application.

11

You might also like