This document describes a project that aims to consolidate access policies for event processing systems. It discusses existing systems that lack privacy for event streams processed across multiple domains. The proposed system allows fine-grained access management through access policies specified for each incoming event stream. Key modules include event processing, manufacturer, shipping company, and customer, which interact via the consolidated access policies.

1. ACCESS POLICY CONSOLIDATION FOR
EVENT PROCESSING SYSTEMS
Student Name:- V.SATISH (312275715036)

2. CONTENTS
 Introduction
 Existing System
 Proposed System
 System Requirements Specification
 Modules
 Algorithm
 System Design
 Screen Shots
 Test Cases
 Conclusion

3. 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.

4. 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.

5. 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.

6. DISADVANTAGES OF EXISTING SYSTEM:
 Its take lot of time
 Delivery problem in customer and manufacturer

7. 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.

8. ADVANTAGES OF PROPOSED SYSTEM:
 Clear content based public or subscribe systems.
 Time saving.
 Clear communication system between user and
manufacture.

9. 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.

10. 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

11. MODULES
Modules in this project are:
 Event Processing
 Manufacturer
 Shipping Company
 Customer

12. 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.

13. 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.

14. 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

15.  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}))}

16. SYSTEM DESIGN
E-R DIAGRAM

17. USE-CASE DIAGRAM

18. CLASS DIAGRAM

19. SEQUENCE DIAGRAM

20. SCREEN SHOT
Login Page

21. SCREEN SHOTS
Registration Page

22. SCREEN SHOTS
Customer’s Homepage

23. SCREEN SHOTS
Product Details Page

24. SCREEN SHOTS
Booking Order Page

25. SCREEN SHOTS
Shipping Company’s Homepage

26. SCREEN SHOTS
Product Request Page

27. SCREEN SHOTS
Send Order to Manufacturer

28. SCREEN SHOTS
Manufacturer’s Homepage

29. SCREEN SHOTS
Insert Product Details

30. SCREEN SHOTS
Product Request Details

31. SCREEN SHOTS
Status of Requested Product

32. TEST CASES
Input Input
Description
Excepted
Value
Actual
Result
Pass
/Fail
Remarks
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

33. 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.