ACCESS POLICY CONSOLIDATION FOR

EVENT PROCESSING SYSTEMS

Student Name:- V.SATISH (312275715036)

CONTENTS

Introduction

Existing System

Proposed System

System Requirements Specification

Modules

Algorithm

System Design

Screen Shots

Test Cases

Conclusion

INTRODUCTION

The project ACCESS POLICY CONSOLIDATION FOR

EVENT PROCESSING SYSTEMS deals with the

manufacturer, shipping company and customers about the

product’s buy or sale of establishments online.

Event processing systems respond to events in the system’s

environment or user interface.

The key characteristic of event processing systems is that the

timing of events is unpredictable and the system must be able

to Scope with these events when they occur.

INTRODUCTION CONT…

In business processes, it is necessary to detect inconsistencies

or failures early. For example, in manufacturing and logistics

processes, items are tracked continuously to detect loss or to

reroute them during transport. To answer this need complex

event processing (CEP) systems have evolved as a key

paradigm for business and industrial applications.

CEP systems allow to detect situations by performing

operations on event streams which emerge from sensors all

over the world, e.g. from packet tracking devices.

EXISTING SYSTEMS

Current event processing systems lack methods to preserve

privacy constraints of incoming event streams in a chain of

subsequently applied stream operations.

This is a problem in large-scale distributed applications like a

logistic chain where event processing operators may be spread

over multiple security domains.

An adversary can guess from legally received outgoing event

streams confidential input streams of the event processing

system.

DISADVANTAGES OF EXISTING SYSTEM:

Its take lot of time

Delivery problem in customer and manufacturer

PROPOSED SYSTEM

This project presents a fine-grained access management for

complex event processing.

Each incoming event stream can be protected by the

specification of an access policy.

The utility of the event processing system is increased by

providing and computing in a scalable manner.

ADVANTAGES OF PROPOSED SYSTEM:

Clear content based public or subscribe systems.

Time saving.

Clear communication system between user and

manufacture.

HARDWARE-SOFTWARE REQUIREMENT

SPECIFICATION

Software Requirements

Operating System - Windows XP /7/8

Application Server - Apache Tomcat 6.0

Front End - HTML, Java

Server side Script - Java Server Pages.

Database - MySQL

Software Tools - Eclipse IDE

Database Connectivity - JDBC.

HARDWARE-SOFTWARE REQUIREMENT

SPECIFICATION

Hardware Requirements

• Processor - Pentium IV or above

• Speed - 1.1 GHz

• RAM - 512 MB or above

• Hard Disk - 20 GB or above

• Key Board - Standard Windows Keyboard

• Mouse - Two or Three Button Mouse

MODULES

Modules in this project are:

Event Processing

Manufacturer

Shipping Company

Customer

MODULES DESCRIPTION

Event Processing:- Event processing systems respond to events in

the system’s environment or user interface. The key characteristic of

event processing systems is that the timing of events is unpredictable

and the system must be able to cope with these events when they

occur.

Manufacturer:- In this module manufacturer, insert the product

details. The shipping company will forward the request to

manufacturer sent by customer. So manufacturer can view product

request from shipping company. The manufacturer will send the

product details to shipping company to delivery date and pickup time

means the manufacturer will send the export details.

MODULE DESCRIPTION CONT…

Shipping Company:- The customer can request a product

from shipping company. So, in this module shipping company,

view product request from customer. Then the shipping

company forwards the request to manufacturer or rejects the

request. So as per the product details sent by manufacturer the

shipping company delivers the product.

Customer:- In this module customer, views the product

details. If the customer likes to purchase any product then the

customer order the product from Ship Company. The

customer can also view the order from Ship Company.

Customer views the import details.

ALGORITHM : LOCAL OBFUSCATION CALCULATION:

1. procedure INITIALIZE(ω)

2. for all operator ω do

3. Dω ← FINDMULTIPATHOPERATORS(ω)

4. end for

5. for all ω ∈ Dω do

6. relAtts ←FINDRELATEDATTRIBUTES

7. for all (attnew, attold) ∈ relAtts do

8. TRANSMIT P(attnew|attold) TO ω

9. end for

10. end for

11. end procedure

12. procedure UPONRECEIVEEVENT(e)

13. for all att ∈ e do

14. if ∃ multPathDependency(att) then

15. CALCULATEWORSTCASEOBFUSCATION(ATT)

16. else

17. CALCULATELOCALOBFUSCATION(ATT)

18. end if

19. end for

20. end procedure

Access control allows to specify access rights of subjects(operators) for the set

of available objects (event attributes).These access rights are provided by the

owner of an object (e.g. the producer of an event stream) and maybe granted to

operators based on an access requirement.

we specify the access rights within an access policy AP for an operator ω as a

set of (attribute,access requirement)

Pairs: APω = {(att1, ar1), ..., (attn, arn)} .

An access requirement is a tuple of a property p, a mathematical operator op and

a value set

val: ar = (p, op, val),

ar1 = (domain, ∈, {domainA, domainB}).

APmmanufacturer =

{(destination,(domain,∈,{shippingComp,customer})),

(pickup time, (domain,=,shippingComp)),

(production place, (domain,=,shippingComp))}

APshipping =(warehouse,

(domain,∈,{shippingComp,customer})),(estArrivalTime,

(domain,=,{shippingComp}))}

SYSTEM DESIGN

E-R DIAGRAM

USE-CASE DIAGRAM

CLASS DIAGRAM

SEQUENCE DIAGRAM

SCREEN SHOT

Login Page

SCREEN SHOTS

Registration Page

SCREEN SHOTS

Customer’s Homepage

SCREEN SHOTS

Product Details Page

SCREEN SHOTS

Booking Order Page

SCREEN SHOTS

Shipping Company’s Homepage

SCREEN SHOTS

Product Request Page

SCREEN SHOTS

Send Order to Manufacturer

SCREEN SHOTS

Manufacturer’s Homepage

SCREEN SHOTS

Insert Product Details

SCREEN SHOTS

Product Request Details

SCREEN SHOTS

Status of Requested Product

TEST CASES

Input Input

Description

Excepted

Value

Actual

Result

Pass

/FailRemarks

Positive

Input

user name:

manufacturer

It should be accepted Accepted P Login

(Next Page)

Negative

Input

user name: user It shouldn’t be accepted Not

Accepted

P Invalid

username or

password

Negative

Input

user name:

“Empty”

It shouldn’t be accepted Not

Accepted

P Invalid

username or

password

Positive

Input

password:

********

It should be accepted Accepted P Hidden

password

Negative

Input

password:

“Empty”

It shouldn’t be accepted Not

Accepted

P Invalid

username or

password

CONCLUSION

This project addressed the inheritance and consolidation of

access policies in heterogeneous CEP systems.

We identified a lack of security in multi-hop event processing

networks and proposed a solution to close this gap.

More specific, we presented an approach that allows the

inheritance of access requirements, when events are correlated

to complex events.