Cost-Based Optimization of Service Compositions
Abstract:
For providers of composite services, preventing cases of SLA
violations is crucial. Previous work has established runtime adaptation of
compositions as a promising tool to achieve SLA conformance. However, to get
a realistic and complete view of the decision process of service providers, the
costs of adaptation need to be taken into account. In this paper, we formalize the
problem of finding the optimal set of adaptations, which minimizes the total
costs arising from SLA violations and the adaptations to prevent them. We
present possible ideas to solve this complex optimization problem, and detail an
end-to-end system based on our earlier work on the PREvent (prediction and
prevention based on event monitoring) framework, which clearly indicates the
usefulness of our model. We discuss experimental results that show how the
application of our approach leads to reduced costs for the service provider, and
explain the circumstances in which different lead to more or less satisfactory
results.
Architecture:
Existing System:
Instead, the open and distributed process includes tasks that are
performed by services that are not centrally controlled, and hence, can be
unpredictable. As a result, service outcomes themselves tend to be uncertain.
Generally, the idea of PREVENT is to use event-based monitoring of
composition data to generate runtime predictions of SLA violations before they
have happened. Based on these predicted violations, adaptation actions are
triggered with the goal of preventing the violation.
Disadvantages:
In our previous work, we have already shown how such
adaptations can technically be applied. However, in these previous papers, the
question of how the service provider can actually select these actions has not
been discussed.
Proposed System:
The goal of this research is to develop a framework for monitoring such
service systems. To establishes its feasibility, and evaluates it with scenarios
and comparisons against existing proposals.
It monitoring the software systems is closely tied to the monitoring of
requirements and how they are realized in software.
If observes and analyzes the behaviour of another (target) system, that
determining qualities of interest, such as satisfaction of the target system’s
requirements.
Similarly, techniques to optimize application servers in a way to maximize the
provider profit in distributed systems have been proposed.
Advantage:
 Where well-specified business processes with service to perform tasks are
advanced changes such as stability, feasibility, predictability.
The main advantage that we see in using learning is that it is very easy to
incorporate data (composition instance data, such as customer identifiers or
ordered products) without the need to explicitly specify aggregation rules
describing how this data influence the composition performance.
ALGORITHM:
IT CAN BE USED TO PROVE PROPERTIES WHEN THE SET OF STATES REACHABLE FROM AN INITIAL STATE IN A
SYSTEM MODULE IS FINITE.
WE CAN DISTINGUISH TWO LEVELS OF SPECIFICATION:

A SYSTEM SPECIFICATION LEVEL, PROVIDED BY THE REWRITE THEORY SPECIFIED BY THAT SYSTEM
MODULE WHICH DEFINES THE BEHAVIOR OF THE SYSTEM, AND

A PROPERTY SPECIFICATION LEVEL, GIVEN BY SOME PROPERTY (OR PROPERTIES) Φ THAT WE WANT TO
STATE AND PROVE ABOUT OUR MODULE.
AN INTERACTION PROTOCOL IS DEFINED AS THE “RULES OF ENGAGEMENT” AMONG INTERACTING
PARTICIPANTS. THEREFORE, INCLUDE:
1)
SPECIFICITY
2)
SEMANTIC
3)
COMPOSABILITY
IN SPECIFICITY REPRESENT INTERACTIONS AMONG SERVICES. THAT IS DOMAIN INDEPENDENT.
(E.G. FOR SHIPMENT , MAY BE DOMAIN-DEPENDENT.)
IN SEMANTIC CONCERN IS SEMANTIC CONTENT. I.E., THE NATURE OF THE INTERACTIONS. (REQUEST – REPLY
MECHANISM).
(E.G., DESTINATION, PAYMENT INFO) TO CAPTURE CONTENT. THE MESSAGE ITSELF MAY CAPTURE THE
SEMANTICS TO DISTINGUISH ACTIONS, SUCH AS DIRECT, INFORM, CANCEL, AND OTHERS.
FINALLY, COMPOSABILITY IS CONCERNED WITH HOW A DESIGNER MIGHT SPECIFY THE PROCESS BY COMBINING
PROTOCOLS.
MODULES:
 Customer Details
 Manufacturer Details
 Loan Approved
 Shipping Process
 Payment Gateway
Customer Details:
In this module the details about various customers are maintained
and each has a unique id. And includes about various Manufacturers are
maintained and each has a unique id. The customer selects best Manufacturer
and then send quote to that Manufacturer mail account. And send his purchasing
order details with some conditions. After that receive amount quote, customer
check the conditions and then he take decision. If he satisfies means approach
the Manufacturer.
Manufacturer Details:
As same as, in this module the details about various Manufacturers
are maintained and each has a unique id. The Manufacturers receives item id, &
consults the policy order and sends the quote to customer, and receives either
accept-quote or reject-quote. When Manufacturer satisfies the condition from
the customer then only he able to transact the materials to customer with help of
shipper. He sends the quotation to customer. After that the customer transacts
money to Manufacturer account. Manufacturer checks the account details then
he giving order to shipper. Otherwise, he rejected the customer order.
Loan Transaction:
In this module the authentication of the customer’s to be checked
their quotation and items are monitored. Then, loan approver confirms his
account and quotation to be authorized/unauthorized. If, the customer to be
authorized person the loan to be sanction to that specific customer. When
unauthorized customer loan to be rejected.
Shipping Process:
The shipper who transports the physical items to the customer from
Manufacturer within the given date. He receives the details about the product
order and customer. Finally he check the account to be credit of not. And they
know the conditions and commitments of both customer and Manufacturers. If
account to be credit means he gets the orders from Manufacturers and send to
that particular customer. Otherwise, reject the order.
Payment Gateway:
Manufacturers who authorize the customer payments for his purchase
order. The customer who pays the money to his account. After payer sends
payment information, eventually payer receives receipt. After payer commits to
order, payer pays for order.
System Specification
System Requirements:
Hardware Required:
 System
: Pentium IV 2.4 GHz
 Hard Disk
: 40 GB
 Floppy Drive
: 1.44 MB
 Monitor
: 15 VGA color
 Mouse
: Logitech.
 Keyboard
: 110 keys enhanced
 RAM
: 256 MB
Software Required:
 O/S
: Windows 08.
 Language
: Asp.Net, c#.
 Data Base
: Sql Server 2008.