M.

Tech( CSE ) IV th SEM

PROJECT
Table of Contents
1. Introduction
1.1 Introduction
1.2 Aim of the Project
1.3 Literature Survey
1.4 Methodology ( Hardware and Software Requirements )
1.5 Motivation
2. System Description
2.1 Problem Statement
2.2 Study of the System
2.3 Existing System
2.4 Disadvantages of existing system
2.5 Proposed system
2.6 Advantages of proposed system
2.7 Modules description
3. Algorithms & Techniques
3.1 Analyzing Techniques
3.2 Method Description
3.2.1 Algorithm 1
3.2.2 Algorithm 2
3.3 System Design
4. Experimental Results
5. Conclusions
6. References



-----------------------------------------------------------------------------------------------------




1. INTRODUCTION

1.1 INTRODUCTION
WEB Services (WSs) are the most famous implementation of service-oriented architectures allowing the
construction and the sharing of independent and autonomous softwares. Web service composition consists
in combining Web services, developed by different organizations and offering diverse functional, ticket
purchase, payment), behavioral, and nonfunctional properties i.e., Quality of Service values, to offer more
complex services. The Web service composition can be viewed as a three step process: composite Web
service specification, selection of the component Web services, and execution of the composite Web
services. At the first step, the user submits the goal he/she wants the composite service achieves, along with
some constraints and preferences that need to be satisfied. Workflows can be used to model the composite
Web service specification. During the second step, component Web services fulfilling the users goal are
selected among a set of available services. This WS selection could be done by hand or could be
automatically decided by the system. When component WSs are selected at design time, the third step of
the composition process consists in executing the selected component WS. At runtime, selection and
execution of component WS are integrated and the selection is described as dynamic. In this paper, we
focus on design-time WS selection, and particularly, on automatic selection, where the user is relieved as
much as possible from the composition process. We do not focus on the execution step or on the recovery
or re-planning problems. While many works have been done for Web service selection, designing a
composite Web service to ensure not only correct and reliable execution but also optimal QoS remains an
important challenge. Indeed, WSs composition based on transactional properties ensures a reliable
execution, however, an optimal QoS composite Web service is not guaranteed. Moreover, composing
optimal QoS Web services does not guarantee a reliable execution of the resulting composite Web service.
Thus, QoS-aware and transactional-aware should be integrated. However, the problem is generally
addressed from the QoS side or from the transactional side separately. The conventional QoS aware
composition approaches do not consider the transactional constraints during the composition process,
likewise transactional-aware ones do not consider QoS.

1.2 AIM OF THE PROJECT
Quality of Service (QoS) is a major concern in the design and management of a composite
service.In this project, a systematic approach is proposed to calculate QoS for composite services
with complex structures, taking into consideration of the probability and conditions of each
execution path. Four types of basic composition patterns for composite services are discussed:
sequential, parallel, loop, and conditional patterns. In particular, QoS solutions are provided for
unstructured conditional and loop patterns.

1.3 LITERATURE SURVEY
In service oriented environments, complex applications can be described as processes invoking
services selected at runtime. In this scenario, applications are defined as flexible processes
composed of abstract Web services. Web services are selected from a set of functionally
equivalent services, that is, services which implement the same functionality but differ for
nonfunctional characteristics, i.e., Quality of Service (QoS) parameters. The goal is to select the
best set of services available at runtime, taking into consideration process constraints, but also end-
user preferences and the execution context.

1.4 METHODOLOGY(HARDWARE AND SOFTWARE
REQUIREMENTS )
Software requirement
1. Operating
System
Windows 2000 / XP, Linux based systems
2. Languages/
Software
Java Runtime Environment,
Java Software Development Kit 1.6
Apache Tomcat Server
Java NetBeans IDE

Hardware requirement
1 Pentium-4 PC with 20 GB
hard-disk and 256 MB RAM,
Keyboard, Mouse





1.5 MOTIVATION
Techniques in web services create the opportunity for building composite services by combining
existing elementary or complex services (referred to as component services) within or from
different enterprises and in turn offering them as value-added services (referred to as composite
services). QoS analysis becomes increasingly challenging and important when complex and
mission critical applications are built upon services with different QoS. Thus, solid model and
method to support for QoS predication in service composition become crucial and will lay a
foundation for further analysis of complexity and reliability in developing service-oriented
distributed applications. It is important to estimate the QoS of a composite service at design time
based on the quality of component web services to make sure that the composition can satisfy the
expectations of end users. A web service may need to be replaced with functionally equivalent
services at runtime if it becomes unavailable or its performance degrades too much. A comparison
is, therefore, necessary by analyzing the QoS of the composite service with different service
combination options.



















2. SYSTEM DESCRIPTION
2.1 PROBLEM STATEMENT
The Web service selection problem has been studied for business processes and e-science.
Dynamic Web service selection for composed Web services focused in particular on context aware
business processes. Context awareness may be needed both when considering Web service
personalization, where a generic process is personalized choosing services according to user
preferences, and in mobile composed services, to provide ubiquitous services where selection and
execution depend on the available services and their QoS. An interesting application area of
service selection optimization is e-science. Complex processes, defined as workflows in this
research context, based on grid technology are being developed, reaching the dimension of
thousands of tasks in in silico experiments. Each task is performed selecting and invoking a
service.

Web service selection results in an optimization problem that has been studied both in the research
areas of service oriented computing for business processes and of grid environments. The literature
has provided two generations of solutions. First generation solutions implemented local
approaches, which select Web services one at the time by associating the running abstract activity
to the best candidate service which supports its execution. Local approches can guarantee only
local QoS constraints, i.e., candidate Web services are selected according to a desired
characteristic, e.g., the price of a single Web service invocation is lower than a given threshold.
Second generation solutions proposed global approaches. The set of services that satisfy the
process constraints and user preferences for the whole application are identified before executing
the process. In this way, QoS constraints can predicate at a global level, i.e., constraints posing
restrictions over the whole composed service execution can be introduced. In order to guarantee
the fulfillment of global QoS constraints, second generation optimization techniques consider the
worst case execution scenario for the composed service. For cyclic processes, loops are unfolded,
i.e., unrolled according to their maximum number of iterations. These approaches could be very
conservative and constitutes the main limitation of second generation techniques.

Furthermore, global approaches introduce an increased complexity with respect to local solutions.
The main issue for the fulfillment of global constraints is Web service performance variability.
Indeed, the QoS of a Web Service may evolve relatively frequently, either because of internal
changes or because of workload fluctuations. If a business process has a long duration, the set of
services identified by the optimization may change their QoS properties during the process
execution or some services can become unavailable or others may emerge. In order to guarantee
global constraints Web service selection and execution are interleaved:

Optimization is performed when the business process is instantiated and its execution is started,
and is iterated during the process execution performing re-optimization at runtime. To reduce
optimization/re-optimization complexity, a number of solution have been proposed that guarantee
global constraints only for the critical path (i.e., the path which corresponds to the highest
execution time), or reduce loops to a single task, satisfying global constraints only statistically, by
applying the reduction formula proposed.

Another drawback of second generation solutions is that, if the end-user introduces severe QoS
constraints for the composed service execution, i.e., limited resources which set the problem close
to unfeasibility conditions (e.g., limited budget or stringent execution time limit), no solutions can
be identified and the composed service execution fails.

2.2 STUDY OF THE SYSTEM
Composed Service Model
A Web service is modeled as a software component that implements a set of operations. A
composed service is specified at an abstract level as a high-level business process. We assume that
a composed service is characterized by a single initial task and a single end task and that task
composition follows a block structure so that, in particular, only structured loops can be specified,
i.e., loops with only one entry and exit point. In the remainder of the paper, we represent
composed services by UML activity diagrams, where activities represent tasks to be executed by
Web services. The operational language we use for process implementation is BPEL.

In the following, we refer to component abstract Web services operations to be executed in the
process with the term task (ti), while Web services selected to be executed are called concrete Web
services (wsj). To support adaptive concretization, a set of semantic annotations are associated to
the process specification to specify either intrinsic characteristics of the process, or requirements
by the user of the composed service.

The probability of execution of conditional branches and distribution of loops number of iterations
can be evaluated from past executions by inspecting system logs or can be specified by the
composed service designer. Assuming that for every loop l, an upper bound NIl for the loop
number of iterations is determined. Otherwise, if an upper bound does not exist, the process cannot
be optimized since infinite resources might be needed for its execution and global constraints
cannot be guaranteed. Local constraints can be specified by the composed service designer. Vice
versa, the user can specify only global constraints since we assume the user has no knowledge of
the structure of the composed process. For the same reason, Web service dependency constraints
are specified by the composed service designer. User preferences may be either specified explicitly
by the user requesting the service, or can be implicit in the user profile and, therefore, the same for
all service requests, or not specified at all. In the last case, all quality dimensions are considered at
the same level of preference giving each dimension a weight 1=N.[1]

The ability to rapidly and effectively build new services by composing existing services a practice
known as service composition is one of the key pillars of Service-Oriented Computing (SOC).
Service orchestration is a popular approach for service composition. The idea of service
orchestration is to assign the responsibility for coordinating the execution of a composite service to
a single entity (the orchestrator). The orchestrator is responsible for handling incoming requests
for the composite service and to interact with the services participating in the composition (the
component services) in order to fulfill these requests. The interactions between the orchestrator
and the component services are governed by a orchestration model that usually takes the form of a
process model in which each task represents either an internal action (e.g. a data transformation) or
an interaction with a component service.

In practice, these process models are specified using a specialized language such as the Business
Process Execution Language (WS-BPEL) or the Business Process Modeling Notation (BPMN).
One of the key issues in service composition is that of predicting and managing the Quality-of-
Service (QoS) of composite services. If we assume that each component service advertises its
QoS, or that this QoS information can be derived based on past observations, we can estimate the
QoS of the composite service by aggregating the available information about the component
services' QoS. This estimation can then be used to detect undesirable QoS variance as early as
possible and to trigger corrective actions when such variance is detected. In this setting, this paper
addresses the following problem: How to compute the expected QoS of a composite service, given
an orchestration specified in a language such as WS-BPEL or BPMN, and a binding that assigns
each task in the orchestration to a concrete service? We assume that QoS is captured in terms of
numerical attributes (e.g. time, cost and reputation) and that the QoS attribute values for each
component service are given. Gathering QoS attribute values for non-composite services is a
separate problem addressed in previous work.
Orchestration Model
We consider service compositions whose internal logic is specified in terms of orchestration
models. An orchestration model is essentially a process graph in which the tasks are mapped to
interactions with the client of the composite service and with services drawn from a service
repository (the component services).

Figure : Composite Service

A composite service is a tuple (Orc, Binding), where Orc is a service orchestration model and
Binding is a function that maps tasks in the orchestration model to component services or to a
predefined Client role. An orchestration model is a directed graph consisting of edges (n1; p; n2)
such that n1 and n2 are process nodes (the source and the target of the edge) and p is the
probability of taking the edge assuming that the execution of the orchestration has reached node
n1. Process nodes are of two types: tasks and gateways. Tasks represent units of work that are
delegated to component services, while gateways represent control flow routing points. There are
two types of gateways: XOR gateways represent conditional branching (XOR-split) or merging of
exclusive branches (XOR-join), whereas AND gateways represent parallel forking (AND-split) or
synchronization points (AND-join). Split gateways are gateways with multiple outgoing edges,
while join gateways are gateways with multiple incoming edges.

The binding of a composite service is not necessarily a total function some tasks might not be
bound to any service. A task in a composite service that is not bound to a service is called an
empty task. We impose the following well-formdness conditions: (i) an orchestration model has a
single source node (i.e., a node with no incoming edges), and a single sink node (i.e., a node with
no outgoing edges), and every node is on a path from the source to the sink; (ii) every task node
has a single incoming and a single outgoing edge, and every gateway is either a split or a join. If
these latter conditions are not satisfied, the orchestration model can be trivially restructured into
one that satisfies these conditions; (iii) the sum of the probabilities attached to the outgoing edges
of an XOR-split gateway is 1; (iv) an edge whose source is not an XOR-split gateway has a
probability of 1, meaning that such edges are always traversed when their source node is reached.

Quality of Service Model
QoS computations on composite services are performed with respect to a fixed set of QoS
attributes such as execution time, cost and reliability. The assumption of a fixed set of attributes is
made for presentation purposes and does not constitute a limitation since we can make this set as
large as required. We further postulate the existence of a function that given a service, returns its
QoS. This function is initially given for pre-existing (non-composite) services. Our goal is to lift
this function so that it can also be applied to composite services. With respect to the method for
computing QoS attribute values for composite services, we classify existing QoS attributes into
three categories:

1. Critical path The value of the QoS attribute for the composite service is determined by the
critical path of the orchestration. Examples include execution time (longest critical path)
and fault-tolerance (weakest path).
2. Additive The value of the QoS attribute for the composite service is a sum of the QoS
values of the component services taking into account how often each service is invoked.
Examples include cost and carbon footprint.
3. Multiplication The QoS attribute value for the composite service is a product of the QoS
values of the component services taking into account how often each service is invoked.
Examples include reliability and availability.

The control flow of a business process can often be modeled as a workflow graph. Workflow
graphs capture the core of many business process languages such as UML activity diagrams,
BPMN and EPCs. We study the problem of parsing a workflow graph, that is, decomposing the
workflow graph into a hierarchy of sub-workflows that have a single entry and a single exit of
control, often also called blocks, and labeling these blocks with a syntactical category they belong
to. Such categories are sequence, if, repeat-until, etc., see Figure below. Such a decomposition is
also called a parse of the workflow graph. It can also be shown as a parse tree, see Figure below.


Figure : Work Flow Graph

The parsing problem occurs when we want to translate a graph-based process description (e.g. a
BPMN diagram) into a block-based process description (e.g. BPEL process), but there are also
other use cases for workflow graph parsing. We believe that parsing also helps in understanding
large processes and in finding reusable sub-processes.

For a round tripping between a BPMN diagram and a BPEL process, it is desirable that the
decomposition be unique, i.e., the same BPMN diagram always translates to the same BPEL
process. Consider, for example, the workflow graph in Figure above. The translation algorithm
proposed by Ouyang et al. is nondeterministic. It may produce one of the two parses shown in
Figure above, depending on whether the if-block or the repeat-until-block is found first by the
parsing algorithm.

One idea to resolve some of this non-determinism is to define priorities on the syntactic categories
to be found. For example, if in each step the parsing algorithm tries to find sequences first, then if-
blocks and then repeat-until blocks, we can only obtain the parse in Figure above in our example.
However, this can introduce another problem. If we change a single block, say, the repeat-until
block by replacing it, e.g. by a single task, we obtain the workflow graph shown in Figure above.
Figure above also shows the parse we obtain with the particular priorities mentioned above. The
corresponding parse tree is shown in Figure above. It cannot be derived from the tree in Figure
above by just a local change, viz., by replacing the Repeat-Until subtree. For a round tripping
between a BPMN diagram and a BPEL process, it would be much more desirable that a local
change in the BPMN diagram also result in only a local change in the BPEL process. Replacing a
block in the BPMN diagram would therefore only require replacing the corresponding block in the
BPEL process. We then call a such decomposition modular. The existing approach to the BPMN
to BPEL translation problem is not modular. Furthermore, it does not provide, because of the
above problems, a specification of the translation that is independent of the actual translation
algorithm. [3]

Service oriented computing is emerging as a new computing paradigm for efficient deployment
and access of the exponentially growing plethora of Web applications. The development of
enabling technologies for such an infrastructure is expected to change the way of conducting
business on the Web. Web services have become de facto the most significant technological by-
product. Simply put, a Web service is a piece of software application whose interface and binding
can be defined, described, and discovered as XML artifacts. It supports direct interactions with
other software agents using XML-based messages exchanged via Internet-based protocols.
Examples of Web services include online reservation, ticket purchase, stock trading, and auction.

The ability to efficiently access Web services is necessary, in light of the large and widely
geographically disparate space of services. Using Web services would typically consist of
invoking their operations by sending and receiving messages. However, complex applications, for
example, a travel package that accesses multiple Web services, would need an integrated
framework to efficiently access and manipulate Web services functionalities. The increasing
adoption of Web services requires a systematic support of query facilities. The service oriented
queries would enable users to access multiple Web services in a transparent and efficient manner.
In addition, as Web services with similar functionality are expected to be provided by competing
providers, a major challenge is devising optimization strategies for finding the best Web services
or composition thereof with respect to the expected user-supplied quality.

However, service oriented queries are inherently different from data queries partially because of
the rich semantics embodied in Web services. This poses several new research challenges:

1. Web services have been so far mainly driven by standards. This is historically similar to
the progress of DBMSs. The DBMS technology has a tremendous progress with the advent
of the relational model which was instrumental in giving databases a solid theoretical
foundation. Web services have yet to have such a solid theoretical underpinning.

2. Web services are usually modeled as function calls, with focus on their input and output
types. However, services with the same input-output types may provide totally different
functionalities. For example, assume services Si and Sj take a string as the input and output
a float number. Also assume that Si is a book price checking service, which takes the book
title as its input and returns the book price. On the other hand, assume Sj is a stock
checking service, which takes the stock name as its input and returns the stock price.
Querying Web services based on such limited syntactic information may result in
erroneous results. Necessary semantics need to be defined to extend the current service
models.

3. Web service operations may not be invoked in arbitrary orders. There may be dependency
constraints between different service operations. The constraints may require that the
invocation of some service operations occur only after their dependent operations have
been successfully invoked. A simple example is that an online transaction service may
require a login operation before making an order. Therefore, a service query should be
answered by considering all the dependency constraints of the retrieved Web services.

4. The proliferation of Web services is expected to introduce competition among multiple
Web service providers. Querying services only based on functionality may result in large
numbers of candidate services. Users may also have special requirements on the service
qualities. In this case, the service query optimizer should not generate efficient query plans
based only on performance but also differentiate competing Web services based on user
expected Quality of Web Service (QoWS).[4]

5. The nature of services creates the opportunity for building composite services by
combining existing elementary or complex services (referred to as component services)
from different enterprises and in turn offering them as value added services. QoS analysis
becomes increasingly challenging and important when complex and mission critical
applications are built upon services with different QoSs. Thus solid model and method to
support for QoS predication in service composition become crucial and will lay a
foundation for further analysis of complexity and reliability in developing service oriented
distributed applications.

It is important to estimate the QoS of a composite service at design time based on the quality of
component Web services to make sure that the composition can satisfy the expectations of end
users. A Web service may need to be replaced with functionally equivalent services at run time if
it becomes unavailable or its performance degrades too much. A comparison is therefore necessary
by analyzing the QoSs of the composite service with different service combination options.

Selecting service components for the composite service and making sure that the QoS of the
composite service fulfill the users QoS requirements is an optimization problem. QoS calculation
is of great importance in the QoS-based service selection. A good QoS calculation method should:

1. calculate the QoS for the composite service as a whole as well as the QoSs for alternative
execution paths. User requirements are usually specified as the mean, the maximum, or the
minimum of the QoS value. For example, the user requirement could be: the cost of the
composite service A should not be over 5000 dollars and the cost of each execution should
not exceed 7000 dollars. The former is a constraint on the mean cost while the latter is a
constraint on the cost of individual paths. But current QoS calculation approach either
computes QoS for the composite service or QoS for the paths, but not for both.

2. be able to deal with complex structures. A composite service can be constructed based on
basic patterns, such as sequential pattern, parallel pattern, and etc., which is referred to as
Composition Pattern in this paper. Therefore, the QoS of a composite service can be seen
as the aggregation of the QoS of these composition patterns. Existing QoS calculation
approaches only deal with simple basic patterns. They cannot handle the situation when
basic patterns are combined in an arbitrary way. For example, a composite service has a
parallel pattern nested in a loop pattern or a loop pattern nested in a parallel pattern.
Therefore, we need a mechanism which can identify patterns from the composite service
even if they are nested in each other and be able to get the composition information for
each execution path, such as its QoS and execution probability.

We will first look into the existing QoS aggregation approaches, then discuss calculation methods
used in QoS based service selection approaches. In work, a composite service is seen as being
composed of basic composition patterns, such as sequential, parallel, loop, and conditional
patterns. The QoS for a composite service can be treated as the aggregation of the QoSs of these
patterns. These approaches have two major problems due to the way in which conditional patterns
are handled:
1. Only the mean QoS value is obtained and the probability information is lost. For example, if
there are two services with the same mean QoS value, then the one with smaller deviation is
better. This information cannot be obtained;
2. In general, conditional patterns can be represented in two ways: structured way and
unstructured way.

Structured way: in which exclusive tasks are split from the same task and join together to another
task. An example of structured conditional pattern can be seen in Figure 1(a). The QoS of it can be
calculated as the probability weighted sum of the QoS of the service in each conditional branch.
Unstructured way: in which two or more paths can share the same tasks before they join together.
For example, in Figure below, task PaybyCash is shared by one branch splitting from task
PlaceOrder and another branch splitting from task CheckCredit. All the branches finally join to
task Charging.



Figure : Service Processes of Conditional Patterns

How to calculate the unstructured conditional patterns is still an open problem. When there are
more of the unstructured conditional patterns, the QoS calculation for the composite service
becomes very difficult. [5]

Recently, there has been a growing trend for businesses to outsource parts of their processes, so as
to focus more on their core activities. In addition, Web users often need to compose different
services to achieve a more complex task that cannot be fulfilled by an individual service. Web
services provide the means for such seamless integration of business processes across
organizational boundaries. Industry standards, namely WSDL, UDDI, WS-BPEL, exist for
describing, locating and composing web services. Following the Service-oriented Architecture
paradigm, composite applications are specified as abstract processes composed of a set of abstract
services. Then, at run time, for each abstract service, a concrete web service is selected and used.
This ensures loose coupling and flexibility of the design. Quality of Service (QoS) parameters (e.g.
responsiveness, availability, throughput) play a major role in determining the success or failure of
the composed application. Therefore, a Service Level Agreement (SLA) is often used as a
contractual basis between service consumers and service providers on the expected QoS level.
QoS-based service composition aims at finding the best combination of web services that satisfy a
set of end-to-end QoS constraints in order to fulfill a given SLA.

Example. Figure below shows an example of a web application for finding the best used car
offers. The users submit their requests to the system, specifying some criteria for selecting the cars
(e.g. brand, type, model). The system then returns a list of the best offers along with a credit and
an insurance offer for each car on the list. The composed application can be exposed to users as a
web service, API or widget, programmatically accessible or directly integrated into their web
applications using a Mashup tool.

Figure : Service Composition

In this example, some tasks like UsedCarSearch or CreditOffer are outsourced and integrated via
web service calls. For these outsourced tasks, multiple services may be available providing the
required functionality but with different QoS values. Users are typically unaware of the involved
services, and they specify their QoS requirements in the SLA in terms of end-to-end QoS
constraints (e.g. average end-to-end response time, minimum overall throughput, maximum total
cost). The goal of QoS-based service composition is to select one service or service configuration
for each outsourced task such that the aggregated QoS values satisfy all the application level QoS
constraints. This problem becomes especially important and challenging as the number of
functionally-equivalent services offered on the web at different QoS levels increases. According,
there has been a more than 130% growth in the number of published web services in the period
from October 2006 to October 2007. The statistics published by the web services search engine
Seekda!1 also indicate an exponential increase in the number of web services over the last three
years. Moreover, it is expected that with the proliferation of the Cloud Computing and Software as
a Service (SaaS) concepts, more and more web services will be offered on the web at different
levels of quality. The pay-per-use business model promoted by the cloud computing paradigm will
enable service providers to offer their (software) services to their customers in different
configurations with respect to QoS properties. Therefore, it is expected that service requesters will
be soon faced with a huge number of variation of the same services offered at different QoS levels
and prices, and the need for an automatic service selection method will increase.

Hence, performing an exhaustive search to find the best combination that satisfy a certain
composition level SLA (i.e. end-to-end QoS constraints) is not practical in this scenario, as the
number of possible combinations can be very huge, based on the number of subtasks comprising
the composite process and the number of alternative services for each subtask. Already with few
hundreds of candidate services (or service configurations) the required time for finding the best
combination will exceed the constraints for real-time execution (e.g., with 100 alternative options
for each subtask in our example, we have 1005 possible combinations). This problem can be
modeled as a combinatorial problem, which is known to be NP-hard in the strong sense, i.e. it is
expected that any exact solution to this problem has an exponential cost. Therefore, reducing the
search space by focusing only on interesting service offers is crucial for reducing the
computation cost. [6]

The service-oriented computing paradigm and its realization through standardized web service
technologies provide a promising solution for the seamless integration of business applications to
create new value-added services. Industrial practice witnesses a growing interest in the ad-hoc
service composition in the areas of supply chain management, ac- counting, finances, eScience as
well as in multimedia applications. With the growing number of alternative web services that
provide the same functionality but differ in quality parameters, the composition problem becomes
a decision problem on the selection of component services with regards to functional and non-
functional requirements.


Figure : Web Service Composition

Consider for example the personalized multimedia delivery scenario. A smartphone user requests
the latest news from a service provider. Available multimedia content includes a news ticker and
topical videos available in MPEG 2 only. The news provider has no adaptation capabilities, so
additional services are required to serve the users request: a transcoding service for the
multimedia content to fit the target format, a compression service to adapt the content to the
wireless link, a text translation service for the ticker, and also a merging service to integrate the
ticker with the video stream for the limited smart- phone display. The user request can be
associated with some end-to-end QoS requirements (like bandwidth, latency and price). The
service composer has to ensure that the aggregated QoS values of the selected services match the
user requirements at the start of the execution as well as during the execution.

However, dynamic changes due to changes in the QoS requirements (e.g. the user switched to a
net- work with lower bandwidth) or failure of some services (e.g. some of the selected services
become unavailable) can occur at run-time. Therefore, a quick response to adaptation re- quests is
important in such applications. The performance of the service selection middleware can have a
great impact on the overall performance of the composition system.

Figure below gives a conceptual overview of the QoS-aware ser-vice composition problem. Given
an abstract composition request, which can be stated in a workflow-like language the discovery
engine uses existing infrastructure (e.g. UDDI) to locate available web services for each task in the
workflow using syntactic (and probably semantic) functional matching between the tasks and
service descriptions. As a result, a list of candidate web services is obtained for each task. The goal
of QoS-aware service selection middleware is to select one component service from each list such
that the aggregated QoS values satisfy the users end-to-end QoS requirements.


Figure : Conceptual Overview

In service oriented environments, where deviations from the QoS estimates occur and decisions
upon replacing some services has to be taken at run-time (e.g. in the multimedia application
above), the efficiency of the applied selection mechanism becomes crucial. The focus of this paper
is on the selection of web services based on their non-functional properties and the performance of
the ap- plied techniques. [7]

In recent years, Web service technologies have demonstrated usefulness and promising capabilities
in deploying understandable applications used for business-to-business integration. However,
Web services adoption rate is still slow due to many challenges. Some of these challenges
include: (1) inexistence of reliable approaches for computing and monitoring QoS properties in a
fair and transparent manner to both service requesters and providers, and (2) inability to associate
QoS parameters into the discovery process.

In addition, standards such as UDDI have enabled service providers and requesters to publish and
find services of interest through UDDI Business Registries (UBRs), respectively. However, UBRs
are not adequate enough for enabling clients to effectively find relevant Web services due to a
variety of reasons. As Web services proliferate, size and magnitude of UBRs are likely to increase
significantly, and hence searching multiple UBRs will become very time consuming and
inefficient using simple keyword-based search operations.
The UDDI specification V3 does not include QoS as part of its publication or inquiry APIs. In
addition, it does not provide the ability to associate QoS information within the registry through
tModels, or binding Templates in a standardized manner. Unfortunately, this major design
deficiency hinders service requesters from being able to define any search criteria based on QoS
parameters or differentiate and compare between services prior to any invocations or bindings
during the discovery process.

To address the above issues, this work introduces a mechanism that extends our Web Service
Repository Builder (WSRB) architecture by offering QoS support for Web services and uses a
combination of service parameters as constraints when searching for relevant Web services. Our
solution has been tested and results show high success rate in providing the correct or most
relevant Web service of interest within top results.

Web Service QoS Manager
The main focus of our approach is to design an intelligent system that has the potential of
examining Web services QoS properties in an open and transparent manner, and enabling clients
to select the best available Web service by taking advantage of client QoS preferences, Web
service capabilities, and service provider features. This is achieved through the WS-QoSMan
service broker. The architecture of the proposed WS-QoSMan solution is shown on Figure below.


Figure : Web Service Quality of Service Manager Architecture
The WS-QoSMan applies an external resource approach in which it uses a tModel called
QoSMetrics that contains information to an external reference. This is very similar to the tModel
used for pointing to WSDL files. QoSMetrics uses overview URL to point to an XML-based file
generated by WS-QoS Man and that contains QoS metrics for a specific Web service.
Service Oriented architecture (SOA) is emerging as a paradigm for the design of complex software
systems, which encourages the realization of new software systems by composing network-
accessible loosely-coupled services. According to this paradigm, the development focus shifts
from activities concerning the in-house custom design and implementation of the system
components, to activities concerning the identification, selection, and composition of services
offered by third parties. These activities are driven by the goal of fulfilling both the functional
requirements concerning the overall business logic that must be implemented and the non-
functional requirements concerning the quality of service (QoS) levels that should be guaranteed
by the system.

Achieving this goal in a SOA environment is a challenging task, mainly because of its dynamic
and unpredictable nature. To cope with this problem, a generally accepted idea is that a SOA
system should be able to dynamically self-adapt to the changing conditions of its operating
environment. Several methodologies have been proposed in the literature for this purpose,
concerning the fulfillment of functional or non-functional requirements. In this paper, we present
MOSES (MOdel-based SElf-adaptation of SOA systems), a methodology and a prototype tool
aimed at driving the self-adaptation of a SOA system to fulfill non-functional QoS requirements
such as system performance, reliability, and cost.

Devising QoS-driven adaptation methodologies of SOA systems is of utmost importance in the
envisaged service marketplace, where different services may co-exist implementing the same
functionality (we refer to the former as concrete services and the latter as abstract service). These
competing services are differentiated by their QoS, thus allowing a prospective user to choose the
services that best suit his/her QoS requirements. Hence, being able to deliver and guarantee the
QoS level required by a given class of users may bring competitive advantage to a service provider
over other providers. In this respect, it is generally assumed in the SOA environment that the
service provider and user engage in a negotiation process, which culminates in the definition of a
Service Level Agreement concerning their respective obligations and expectations about QoS.
Most of the proposed methodologies for QoS-driven adaptation of SOA systems address this
problem as a question concerning which services should be used (service selection problem): given
the set of abstract services needed to compose a new added value service, the goal is to identify for
each abstract service a corresponding single concrete service, selecting it from a set of candidates.
When the operating conditions change (e.g., a selected concrete service is no longer available, or
its delivered QoS has changed, or the user QoS requirements have changed), a new selection can
be calculated and the abstract services which compose the SOA system are dynamically bound to a
new set of concrete services. However, it may happen that, under a specific operating condition,
no selection exists of single concrete services allowing the fulfillment of the QoS requirements. In
this case, adaptation methodologies based only on service selection fail to meet their objective,
which could cause a loss of income and/or reputation for a service provider.

To overcome this problem, with MOSES we propose to broaden the range of the considered
adaptation mechanisms, by exploiting the availability in a SOA environment of multiple
independent implementations of the same functionality. Rather than considering only the binding
of each abstract service to one single concrete service that implements it, MOSES can more
generally bind each abstract service to a set of functionally equivalent concrete services,
coordinated according to some spatial redundancy pattern. In this way, MOSES may achieve QoS
levels concerning reliability and, in some cases, performance that could not be achieved otherwise,
thus increasing the flexibility of a provider in facing a broader range of QoS requirements and
volatile operating conditions. The service selection mechanism considered in other papers thus
becomes a special case of this more general mechanism, when the cardinality of the identified set
of concrete services is equal to one. Of course the advantage achieved in this way should be
weighed against the higher cost caused by the use of multiple concrete services.

Service-oriented architecture (SOA) provides a flexible and dynamic paradigm for integrating
distributed services into business processes. SOA allows enterprises to, statically or dynamically,
compose service processes by integrating services deployed by different service operators using
some process description language, such as WS-BPEL. As SOA becomes more popular, there are
now many Web services with rich functionalities available. Services from different providers can
be used to perform similar functionalities. One thus can compose a service process by selecting
services from competing service providers. Enterprises and their clients are free to pick and choose
services from service providers that best suit their needs. With SOA now adopted in real-time
enterprises (such as Fedex, UPS, and Twitter), it has become increasingly important for enterprises
to build service processes that not only provide accurate results, but also deliver a desirable quality
of service (QoS), including but not limited to response time, availability, and security. Customers
at different application domains may have different concerns. For example, some may have very
strict end-to-end response time requirements, while others may be more concerned about the end-
to-end security. Some may have a tight budget constraint, while others only care about the
reliability of the service process. In we have studied the pre-run-time service process composition
problem with end-to-end QoS constraints. We presented algorithms to select services and their
service levels for a business process according to a users functional and QoS needs.

Other projects for service selection in SOA have also been reported in literature. However, the
QoS delivered by individual services at runtime may not meet their pre-defined QoS levels. Many
factors, such as host overload, network congestion, unexpectedly large number of requests, can
affect the QoS delivered by services. When that happens, a service process must be repaired
immediately in order to continue serving the business process functions effectively. Providing a
QoS consistent SOA system is a big challenge. In self-healing has been identified as one of the
leading edge challenges in SOA.In the event of QoS violation at run-time, it is not desirable to
always stop and recompose the entire process. Re composition is time-consuming since the
optimal service selection problem is NP-hard. Moreover, most enterprises would like to have a
stable business environment and minimize the number of system shutdown and reconfiguration, so
that customers may not experience unexpected service migration too often.

Increasingly, organizations try to automate their business processes using coarse-grained services
that implement specific parts of their business functionality. Services are self describing, platform-
agnostic computational elements that support rapid low-cost composition of distributed
applications. Recently, Web services are one popular technology for implementing such services.
Composing different services into a structured process can be done by using an orchestration
language (also called composition language) such as WS-BPEL, the Web Service Business
Process Execution Language (BPEL for short). It is an XML-based language that provides the user
with variables, conditionals, loops, asynchronous messages, process correlation and facilities for
transaction and exception handling. The language itself was originally designed by BEA,
Microsoft and IBM. Finally, WS-BPEL 2.0 is now standardized by OASIS. When leveraging
BPEL as a process execution language, there are some major concerns that have to be considered
when using it in high-availability environments. As a motivating scenario, consider an online store
where the back-end business logic is implemented using a BPEL based solution, and the front-end
for the customers is a Web application which gathers data and hands it over to the BPEL engine
for processing the order. The order processing requires some communication with the local back-
end services (such as stock services) or partner services offered by other organizations (e.g., credit
card verification and payment). A failure or downtime of one of these services in the process can
cause a downtime in the overall process execution. This may result in a considerable loss of
money due to the fact that the front-end is relying on a fully operational back-end system.

In this work, we address two issues we identified when using BPEL in enterprise systems where
monitoring and high availability play a crucial role: Firstly, one major drawback of BPEL is its
inherently static nature. Basically, if a process definition is deployed into a BPEL environment the
BPEL engine it cannot be changed dynamically at runtime. Every information is hard-wired after a
process is deployed, for example, references to other services (called partner links) used in the
BPEL process cannot be changed and exchanged without editing and redeploying the process
which implies a downtime of the overall system. Although it is possible for the process to bind to
partner links at runtime, the process definition would contain a tremendous amount of code that is
not related to the business process. A dynamic replacement of partner Web services in the process
is, therefore, a necessary approach when the service provider quality in terms of response time (or
other QoS) aspects is not good enough and affects the overall quality of the process. Secondly, the
BPEL standard does not provide any means for monitoring a running process. Nevertheless,
monitoring of business processes is a very important issue in enterprise systems as they are a key
factor for running a business. Currently, it is up to the BPEL engine to provide monitoring
interfaces. However, to the best of our knowledge, available BPEL engines lack this ability. The
monitoring of QoS is a necessary foundation to decide whether a replacement of a service should
be performed and also what kind of QoS based selection criteria should be used.

2.3 EXISTING SYSTEM
Existing QoS calculation methods for a composite service can be classified into two categories:
The first one being the aggregation method in which a composite service is seen as an integration
of composition patterns. By recursively removing these patterns, one single task is reached. The
QoS for this single task is the QoS of the composite service. While the second method calculates
the QoS for every possible execution path of a composite service. In these systems probability of
the QoS is not taken into consideration. Although, in the first method individual QoS of tasks is
not considered, the second method takes each possible execution path of composite service. Now
for each path the probability has not been considered.

2.4 LIMITATIONS OF EXISTING SYSTEM
The existing QoS calculation methods do not provide probability for each execution path of a
composite service in the results. The limitations of the methods that calculate QoS for each
execution path without considering the probability is that each execution path must satisfy the
requirements on QoS of the composite service. There are ups and downs in the QoS of a composite
service to execute different paths. Adding QoS constraints on every execution path without
considering the probability makes the user-specified requirements too difficult to be satisfied.
Second, most existing QoS calculation approaches deal only with basic patterns or simple cases.
They cannot handle complicated patterns such as unstructured conditional or unstructured loop
patterns. But because of the lack of computation approach for general loops (loops with any
number of entry and exit points), these works are still incomplete.

2.5 PROPOSED SYSTEM
In this project, a systematic QoS calculation approach is proposed to overcome the above
limitations. The proposed approach has the following features: Compared with existing work, the
proposed QoS analysis approach can generate richer QoS information including not only the QoS
of a web service composition but also the QoS and probability for each execution path of the web
service composition. This feature provides a foundation for considering a range of user
requirements on the QoS of paths, which can help select better composition plans to execute goal
services. Furthermore, most complex structures can be covered by the proposed method. The QoS
calculation for loop patterns with multiple entry and multiple exit (MEME) points has not been
discussed by any existing work.

2.6 ADVANTAGES OF PROPOSED SYSTEM
A systematic QoS calculation approach is proposed to overcome the above limitations. The
proposed approach takes into consideration the probability of each QoS path. Thus along with
other parameters to calculate the QoS of composite web service the probability for successful
completion. Compared with existing work, the proposed QoS analysis approach can generate
richer QoS information including not only the QoS of a web service composition but also the QoS
and probability for each execution path of the web service composition. Furthermore, most
complex structures can be covered by the proposed method. Thus this system allows selection of
the most appropriate task for the completion of the composite web services.

2.7 SYSTEM ARCHITECTURE
2.7.1 Composite Service Modelling
Workflow control patterns in real-life business scenarios have been identified in [12]. We choose
from [12] the basic patterns that are supported by business process execution language for web
services (BPEL4WS) [13]. These basic patterns include sequential pattern, parallel pattern,
conditional pattern, and loop pattern. In this paper, the process of a web service composition is
assumed to be built upon these four patterns.
We use the service graph to represent the process of a web service composition to compute the
QoS. In the following sections, we will introduce how composite services and composition
patterns can be specified by the service graph.
Service Graph
In the graph, vertices represent component services, and arcs denote the transitions from one
component service to another. Formally:
Let S be the set of component services, T be the set of transitions in a composite service, P be the
set of transition probabilities between two services linked by a transition, and Q be the set of
QoS values of component services. A service graph is G =(V ,A) where



Sequential Pattern
In a sequential pattern, one service is enabled after the completion of another one. Formally:
A sequential pattern composed of vertices v
x
and v
y
will be recorded as v
x
v
y
in its replacing
vertex with the symbol representing the sequential relation between vertex v
x
and v
y
.
Parallel Pattern
In a composite service, if two or more services split from the same service, execute
simultaneously, and converge into a service in synchronization (referred to as parallel pattern with
synchronized merge) or the first finished branch triggers the following service (referred to as
parallel pattern with single merge), then this kind of structure is named parallel pattern. Formally:
Definition 3 shows the probability values of the arcs v
x
k
split
v
yi
;p of the parallel pattern splitting
from the start vertex v
x
are the same, which is p. p is the probability that the parallel

Fig. 5. A structured conditional pattern.
pattern will be executed. If there is only one parallel pattern at vertex v
x
, p 1. If there are
multiple parallel patterns starting at vertex v
x
, we assume the execution probabilities for these
patterns are different so that different parallel patterns can be distinguished.
For a parallel pattern without a start and end points (this could happen in the flow activities of WS-
BPEL), i.e., there are only concurrent running web services v
yi
in the pattern, empty actions need
to be added as the start and end points for the parallel pattern. The QoS, such as cost and execution
time, of the empty action is zero. The QoS, such as reliability, of the empty action is one.
In Fig. 4, the parallel pattern is composed of vertices v
y1
;...;v
yn
. The connection between the start
point v
x
and v
yi
is concurrent split k
split
and between v
yi
and the end point v
z
is synchronized
merge for symbol k
synjoin
or single merge for symbol k
sngjoin
.
Structured Conditional Pattern
In structured conditional patterns, exclusive tasks split from the same task and merge into another
task.
Definition 4 (Structured Conditional Pattern (see Fig. 5)). In G V ;A, G
0
V
0
;A
0
is a
structured conditional pattern with n exclusively executing paths (i.e., only one path can be run
at a time), where V
0
fv
yi
j i 2 1;ng and A
0
fv
x
v
yi
;p
i
j i 2 1;ng.
Loop Pattern
Definition 5 (Loop Pattern (see Fig. 6)). In G V ;A, G
0
V
0
;A
0
is an arbitrary loop pattern
with n vertices in the loop, where V
0
fv
i
j i 2 1;ng;A
0
fv
i
v
i mod n1
;p
i
j P
i 2 1;ng, and P fpi;pIik;pOij j pi jmi1 pOij 1g (pi is the transition probability for an
arc within the loop pattern, p
Iik
is the transition probability for an incoming arc of the loop
pattern, p
Oij
is the transition probability for an outgoing arc of the loop pattern). A loop pattern
composed of n vertices v
1
;..., and v
n
starting at v
1
will be recorded as v
1
!v
2
v
i
v
n
!v
1
in its
replacing vertex.
Definition 5 defines a general loop, i.e., a loop with any number of entry and exit points.
Symbol ! symbol helps distinguish the label of a loop pattern from the label of a sequential
pattern. For example, v
1
!v
2
v
i
v
n
!v
1
is for a loop pattern while v
1
v
2
v
i
v
n
is for a
sequential pattern.
So far, four symbols have been introduced to record the relations between the vertices in a pattern.
They are: , k
synjoin
, k
sngjoin
, and !. Symbol has the lowest priority level. Symbols
k
synjoin
, k
sngjoin
, and ! have the same priority level, which are higher than .

Fig. 6. Loop pattern.


2.8 FEASIBILITY STUDY
A Feasibility Study is a preliminary study undertaken before the real work of a project starts to
ascertain the likely hood of the projects success. It is an analysis of possible alternative solutions
to a problem and a recommendation on the best alternative.
1. Economic Feasibility
2. Technical Feasibility
3. Operational Feasibility

Economic Feasibility: It is defined as the process of assessing the benefits and costs associated
with the development of project. A proposed system, which is both operationally and technically
feasible, must be a good investment for the organization.

With the proposed system the users are greatly benefited as it provides Quality of service to the
web service users. This proposed system does not need any additional software and high system
configuration. Hence the proposed system is economically feasible.

Technical Feasibility: The technical feasibility infers whether the proposed system can be
developed considering the technical issues like availability of the necessary technology, technical
capacity, adequate response and extensibility.

The project is decided to build using java. Java Environment is designed for use in distributed
environment of the internet and for the professional programmer it is easy to learn and use
effectively. As the developing organization has all the resources available to build the system
therefore the proposed system is technically feasible.

Operational Feasibility: Operational feasibility is defined as the process of assessing the degree to
which a proposed system solves business problems or takes advantage of business opportunities.

The system is self-explanatory and doesnt need any extra sophisticated training. The system has
been built by concentrating on the graphical user interface concepts. The application can be
handled very easily with a novice user. The overall time that a user needs to get trained is less than
one hour. As the software that is used for developing this application is very economical and is
readily available in the market. Therefore the proposed system is operationally feasible.

2.9 MODULES DESCRIPTION
2.9.1 Create Service Graph
In the graph, vertices represent component services, and arcs denote the transitions from one
component service to another. Let S be the set of component services, T be the set of transitions in
a composite service, P be the set of transition probabilities between two services linked by a
transition, and Q be the set of QoS values of component services. A service graph is G = (V,A)
where v are the vertices and A is the arcs of the Graph; delta represents the connections methods in
the graph such as, Sequential connection, split connection, synchronized merge connection, single
merge connection.

2.9.2 Sequential Pattern
For a sequential pattern the transition probability of the incoming arcs be Px and the transition
probability of the outgoing arcs be Py. The QoS of vx and vy are cx and cy for cost, tx and ty for
execution time, and ax and ay for availability. Then the incoming transition probability, the
outgoing transition probability, cost, execution time, and availability for the vertex replacing the
sequential pattern are calculated. When a sequential pattern is replaced by a vertex, the incoming
arc/arcs of the start vertex of the sequential pattern become the incoming arc/arcs of the replacing
vertex, and the outgoing arc/arcs of the end vertex of the sequential pattern become the outgoing
arc/arcs of the replacing vertex. The transition probabilities for the incoming and outgoing arcs of
the replacing vertex are the same as the original incoming and outgoing arcs of the sequential
pattern. The sequential processing is designed to process a sequential pattern. The input of the
sequential processing is vertices v1 and v2 in a sequential pattern. The QoS of the pattern is
calculated.

2.9.3 Parallel Pattern
For a parallel pattern the transition probabilities of the arcs splitting from vx be p, the QoS of vy
be cy ,ty , and ay for cost, time, and availability, respectively. The incoming transition probability,
the outgoing transition probability, cost, execution time and availability for the vertex replacing
the parallel pattern are calculated. In a parallel pattern with single merge, the first finished branch
will trigger the subsequent task of the parallel pattern and the results of other branches are ignored.
All the tasks in the pattern are executed; therefore, the cost should be the sum of the cost of each
branch. The execution time of the pattern is the execution time of the first finished branch, i.e., the
shortest execution time. The circumstance when the pattern being unavailable will only happen
when all the branches are unavailable. When a parallel pattern is replaced by a vertex, the
incoming arc of the vertex is from the vertex where the parallel pattern splits (i.e., the start point)
and the outgoing arc of the vertex goes to the vertex where the parallel pattern merges (i.e., the end
point). The processing of a parallel pattern is done through the input of the function is a list of
vertices in a parallel pattern. The QoS of the pattern is calculated.

2.9.4 Conditional Pattern
In general, there are two types of conditional patterns: structured and unstructured. The QoS of a
structured conditional pattern can be calculated. In unstructured conditional patterns, two or more
paths can share the same tasks before they join together. In this project, conditional structures will
be processed along with the processing of the service graph. Specifically, sequential, parallel, and
loop patterns will be removed from a service graph first. There are only conditional patterns left in
the service graph. We transform the service graph into a rooted tree. The QoS of the web service
composition is the QoS of the tree, which can be calculated as the probability weighted sum of the
QoS of the branches. By the above-mentioned method, the problem of the existence of
unstructured conditional patterns can be solved and the QoS of the web service composition can be
computed.

2.9.5 Loop Pattern
In this module the QoS calculation method is the same when other vertices are the entry points.
We only use one incoming arc to indicate the entry point of the loop and ignore all the other
incoming arcs. Doing this does not affect the QoS computation result. This is because the QoS of a
loop pattern is affected by the position of an entry point, i.e., the point where a loop starts, but not
by the transition probabilities of the incoming arcs of the entry point, which indicates the
possibility of entering the loop and has nothing to do with the repeating of the loop or the jumping
out of the loop. That is also to say that only the transition probabilities within a loop and the
transition probabilities of jumping out of a loop are needed to compute the probability for each
possible execution branch of a loop pattern. Through the function LoopProcessing which takes
input of the function is the vertices of a loop pattern. The QoS of the pattern is calculated.




















3. ALGORITHMS & TECHNIQUES

3.1 QoS ANALYSIS FOR COMPOSITION PATTERNS

3.1.1 SEQUENTIAL PATTERN
QoS Calculation for a Sequential Pattern
For a sequential pattern in Fig. 3, let the transition probability of the incoming arcs be P
x
={p
x
| i
[1,m]} and the transition probability of the outgoing arcs be P
y
={p
y
| j [1,n]}. The QoS of v
x and

v
y
are c
x
and c
y
for cost, t
x
and t
y
for execution time, and a
x
and a
y
for availability. The incoming
transition probability (P'
in
), the outgoing transition probability (P'
out
), cost (c'), execution time (t'),
and availability (a') for the vertex replacing the sequential pattern are calculated as follows:

P'
in
= P
x
= {p
xi
| i [1,m]},
P'
out
= P
y
= {p
yj
| j [1,n]},
c' = c
x
+ c
y
,
t' = t
x
+ t
y ,

a' = a
x
+ a
x ,

When a sequential pattern is replaced by a vertex, the incoming arc/arcs of the start vertex of the
sequential pattern become the incoming arc/arcs of the replacing vertex, and the outgoing arc/arcs
of the end vertex of the sequential pattern become the outgoing arc/arcs of the replacing vertex.
The transition probabilities for the incoming and outgoing arcs of the replacing vertex are the same
as the original incoming and outgoing arcs of the sequential pattern.

Processing of a Sequential Pattern
Function SeqProcessing(v
1
,v
2
) is designed to process a sequential pattern. The input of the
function is vertices v
1
and v
2
in a sequential pattern. The QoS of the pattern is calculated based on
(5), (6), and (7). The ID of the pattern is v'
1
- v'
2
. Vertex v
1
is applied to capture the QoS and IDs
of the pattern. After the outgoing arcs of v
1
are replaced by the outgoing arcs of v
2
, vertex v
2
is
removed from the service graph. In this way, the input sequential pattern is replaced by a single
vertex.

3.1.2 PARALLEL PATTERN
QoS Calculation for a Parallel Pattern
For a parallel pattern in, let the transition probabilities of the arcs splitting from v
x
be p, the QoS of
v
yi
be c
yi
, t
yi
, and a
yi
for cost, time, and availability, respectively. The incoming transition
probability (P'
in
), the outgoing transition probability (P'
out
), cost (c'), execution time (t'), and
availability (a') for the vertex replacing the parallel pattern are calculated as follows:
P'
in
= p,
P'
out
= 1,

,
t' ={max (t
yi
) (f or synchronized merge)
min (t
yi
) (f or single merge)

a' = {

, (f or synchronized merge)
1 -

(f or single merge)

Since these formulas are straightforward for a parallel pattern with synchronized merge, we will
only explain how these formulas are generated for a parallel pattern with single merge. In a
parallel pattern with single merge (1 out of n pattern in [12]), the first finished branch will trigger
the subsequent task of the parallel pattern and the results of other branches are ignored [12]. All
the tasks in the pattern are executed; therefore, the cost should be the sum of the cost of each
branch. The execution time of the pattern is the execution time of the first finished branch,
i.e., the shortest execution time. The circumstance when the pattern being unavailable will only
happen when all the branches are unavailable, the probability of which is

, . Therefore, the
availability of the pattern should be 1 -

.
When a parallel pattern is replaced by a vertex, the incoming arc of the vertex is from the vertex
where the parallel pattern splits (i.e., the start point) and the outgoing arc of the vertex goes to the
vertex where the parallel pattern merges (i.e., the end point). The connection ways of both the
incoming arc and the outgoing arc are sequential connections.
Processing of a Parallel Pattern
The processing of a parallel pattern is through function ParaProcessing (para_list). The input of the
function is a list of vertices (v
1
. . . v
n
) in a parallel pattern. The QoS of the pattern is calculated
based on (10), (11), and (12). The QoS and ID information of the pattern are stored in vertex v1.
The connection ways are changed to sequential for both the incoming arc and the outgoing arc of
v
1
. Then, vertices v
2
. . . v
n
are removed from the service graph.

3.1.3 CONDITIONAL PATTERN
In general, there are two types of conditional patterns: structured and unstructured. The QoS of a
structured conditional pattern can be calculated according to (1) and (2). In unstructured
conditional patterns, two or more paths can share the same tasks before they join together.
The conditional structures will be processed along with the processing of the service graph.
Specifically, sequential, parallel, and loop patterns will be removed from a service graph first.
There are only conditional patterns left in the service graph. We transform the service graph into a
rooted tree. The QoS of the web service composition is the QoS of the tree, which can be
calculated as the probability weighted sum of the QoS of the branches. By the above-mentioned
method, the problem of the existence of unstructured conditional patterns can be solved and the
QoS of the web service composition can be computed.

3.1.4 LOOP PATTERN
QoS Calculation for a Loop Pattern
We will study how the QoS of the loop pattern is computed when vertex v
1
is the entry point. The
QoS calculation method is the same when other vertices are the entry points. We only use one
incoming arc to indicate the entry point of the loop and ignore all the other incoming arcs.
Doing this does not affect the QoS computation result. This is because the QoS of a loop pattern is
affected by the position of an entry point, i.e., the point where a loop starts, but not by the
transition probabilities of the incoming arcs of the entry point, i.e., p
I
, which indicates the
possibility of entering the loop and has nothing to do with the repeating of the loop (which is
determined by p
i
) or the jumping out of the loop (which is determined by p'). That is also to say
that only the transition probabilities within a loop (i.e., p
i
) and the transition probabilities of
jumping out of a loop (i.e., p') are needed to compute the probability for each possible execution
branch of a loop pattern.
Based on the discussion above, the loop pattern is QoS equivalent to the loop pattern in Fig. 6
when vertex v
1
is the entry point. Next, we will discuss the QoS calculation for it.
The transition probability from v
i
to v
i+1
is p
i
. The loop is left from v
i
at a probability pO
ij
. There
is

(i [1,n]),.If vertex v
i
(i [1,n]),. is just an internal vertex of the loop, i.e.,
deg
+
v
i
= 1, then pO
ij
= 0 (j [1,m]) , The cost, execution time, and availability of v
i
is c
i
, t
i
, and a
i
,
respectively.
After it has been executed for l (l [0,+oo)) times, the loop will be left from v
i
(i [1, n]) to its
adjacent vertex that does not belong to the loop. Based on this description, the loop pattern can be
transformed into an equivalent graph but without the loop. The combination of vertices v
1
; v
2
; . . . ;
and v
n
, (the part within the dashed ellipse) is equivalent to one time of execution of the loop in Fig.
8. After the combination of vertices has been executed for l (l [0,+oo)) times, finally, the loop
will transfer from vertex v
i
(i [1, n]) to its adjacent vertex according to the probability pO
ij
(j
[1,m
i
]). The probability for the combination of vertices to be executed for l (l [0,+oo)) times and
transferring from vertex v
1
to its adjacent vertex is transferring from vertex v
k
(k [2, n]) to its
adjacent vertex . Therefore, statistically, the cost (c0), the execution time (t0), and availability (a0)
generated by all the vertices within the loop pattern are as follows:



The loop pattern in Fig. 8 can be replaced by one vertex v
0
in Fig. 10. The calculation for the
transition probability, cost, execution time, and availability of vertex v0 is based on (13),
(14), (15), and (16), respectively. Formulas (13), (14), (15), and (16) are general formulas
for all types of loop patterns.

Processing of a Loop Pattern
At each entry point v
i
, a loop pattern is replaced by a vertex v
'
i
through function LoopProcessing
(loop_list). The input of the function is the vertices of a loop pattern. The QoS of the pattern is
calculated based on (14), (15), and (16). The QoS and ID information of the pattern are stored in
v'
i
. The incoming arc for v'
i
is the incoming arc for v
i
. The outgoing arcs for v0i are the outgoing
arcs of the loop pattern. The transition probabilities are recalculated according to (13) for all the
outgoing arcs of v'
i
. Then, the incoming arc of v
i
is removed from the service graph. The vertices
in the loop will be removed after there is no incoming arc for the loop.

3.2 METHOD DESCRIPTION
The method in is adopted to detect single entry single exit (SESE) regions in a graph. Since
sequential, parallel patterns, structured conditional patterns, and structured loop patterns are all
SESE regions, they can be detected and removed by the methods.
In an SESE region containing MEME loops, depth-first search (DFS) method is used to explore
the region. An entry of a loop can be discovered by finding the back edge, the tail of which is an
entry point of the loop. At each entry point of a loop, the processing method for loop patterns in
Section 3.1.4 is applied. By doing so, MEME loops can be removed. After all the basic
composition patterns are removed, the service graph contains only unstructured conditional
patterns. Algorithm 1 is designed to transform the acyclic service graph into a tree, the branches of
which are the paths of the service graph. By computing the QoS and probability of each branch of
the tree, the QoS and probability of the web service composition can be obtained,
and consequently, the QoS of the web service composition can be computed (which is the
probability weighted sum of the QoS of the paths).







3.2.1 Algorithm 1. Algorithm for Transforming an Acyclic Graph into a Rooted Tree.



Algorithm Description
Function DfsVstAcyclcGrph transforms an acyclic graph into a tree. To distinguish nodes in a
graph with nodes in a tree, node is called vertex in a graph and is stilled called node in a tree.
DfsVstAcyclcGrph is recursively run for each UNVISITED vertex (line 14). First, a tree node will
be generated for the current vertex and added to the tree (lines 2 to 3). If it is the last vertex of the
graph, then one path is generated by backtracking from the leaf node (the tree node for current
vertex) to the root of the tree (lines 4 to 6). During the exploration of the successors of current
vertex (lines 7 to 14), if the successor is a joint vertex of two conditional branches (line 8), the
subtree rooted at the tree node of this successor vertex will be copied as the subtree rooted at the
tree node of the current vertex (line 9). If an original node is a leaf node of the tree, a copy of it
will also be a leaf node. Therefore, another path is obtained by backtracking the copied leaf node
through to the root of the tree (lines 10 to 12). When all the paths of the input graph are generated,
the QoS of the composite service will be calculated (lines 15 to 16).


3.2.2 Algorithm 2. Algorithm for Decreasing Deviation.



3.3 SYSTEM DESIGN

3.3.1 Introduction
The Unified Modeling Language (UML) is a visual modeling language used to specify, visualize,
construct and document a software intensive system. The embedded real-time software systems
encountered in applications such as telecommunications, school systems, aerospace, and defense
typically tends to be large and extremely complex. It is crucial in such systems that the software is
designed with a sound architecture. A good architecture not only simplifies construction of the
initial system, but also, readily accommodates changes forced by a steady stream of new
requirements.

The UML represents a collection of best engineering practices that have proven successful in the
modeling of large and complex systems. The UML is a very important part of developing object
oriented software and the software development process. The UML uses mostly graphical
notations to express the design of software projects. Using the UML helps project teams
communicate, explore potential designs, and validate the architectural design of the software.
The primary goals in the design of the UML are: Provide users with a ready-to-use, expressive
visual modeling language so they can develop and exchange meaningful models. Provide
extensibility and specialization mechanisms to extend the core concepts. Be independent of
particular programming languages and development processes. Provide a formal basis for
understanding the modeling language. Encourage the growth of the OO tools market. Support
higher-level development concepts such as collaborations, frameworks, patterns and components.
Integrate best practices.

3.3.2 Use Case Diagram







Create Service Graph
Sequential Pattern
Parallel Pattern
Conditional Pattern
User
Loop Pattern
3.3.3 Activity Diagram


Activity Diagram for Create Service Graph

Retrieve S as set of
component services
Retrieve T as set of transitions
in a composite service
Retrieve P set of transition
probabilities between two services
Compute V set
of vertices
Compute A is the
arcs of the Graph
Compute delta
representing connections


Activity Diagram for Sequential Pattern

Retrieve transition probability
of the incoming arcs
Retrieve transition probability
of the outgoing arcs
Calculate incoming and outgoing
transition probability
Calculate cost, execution
time, and availability
Process the
sequential pattern

Activity Diagram for Parallel Pattern



Split arcs for transition
probabilities
Compute parallel incoming and
outgoing transition probability
Compute cost, execution time and
availability for parallel pattern
Process parallel
pattern

Activity Diagram for Conditional Pattern


Compute QoS of a structured
conditional pattern
Process the
service graph
Remove sequential,
parallel, and loop patterns
Transform the service
graph into a rooted tree
Calculate probability weighted
sum of the branches

Activity Diagram for Loop Pattern

Retrieve vertices
which are entry points
Compute only one incoming arc to
indicate the entry point of the loop
Compute transition
probabilities within a loop
Compute transition probabilities
of jumping out of a loop
Process Loop with input
as vertices of loop pattern
3.3.4 Sequence Diagrams



Sequence Diagram for Create Service Graph


: User
: ServiceGraph
1: RetrieveS( )
2: RetrieveT( )
3: RetrieveP( )
4: ComputeV( )
5: ComputeA( )
6: ComputeDelta( )


Sequence Diagram for Sequential Pattern

: User
: SequentialPattern
1: RetrieveTPIncomingArcs( )
2: RetrieveTPOutgoingArcs( )
3: CalculateIOTP( )
4: CalculateCostTimeAvailability( )
5: ProcessSequential( )


Sequence Diagram for Parallel Pattern

: User
: ParallelPattern
1: SplitArcs( )
2: ComputParellelIOTP( )
3: ComputeCostTimeAvailabilityParallel( )
4: ProcessParallelPattern( )


Sequence Diagram for Conditional Pattern

: User
: ConditionalPattern
1: ComputeStructuredPattern( )
2: ProcessServiceGraph( )
3: RemoveSequentialParallelLoopPatterns( )
4: TransformServiceGraph( )
5: CalculateProbabilityWeightedSum( )

Sequence Diagram for Loop Pattern



: User
: LoopPattern
1: RetrieveEntryPoints( )
2: ComputeIncomingArc( )
3: ComputeTPLoop( )
4: ComputeTPJumpingLoop( )
5: ProcessLoopPattern( )
3.3.5 Collaboration Diagrams





Collaboration Diagram for Create Service Graph








Collaboration Diagram for Sequential Pattern



: User
: ServiceGraph
1: RetrieveS( )
2: RetrieveT( )
3: RetrieveP( )
4: ComputeV( )
5: ComputeA( )
6: ComputeDelta( )
: User
: SequentialPattern
1: RetrieveTPIncomingArcs( )
2: RetrieveTPOutgoingArcs( )
3: CalculateIOTP( )
4: CalculateCostTimeAvailability( )
5: ProcessSequential( )

Collaboration Diagram for Parallel Pattern




Collaboration Diagram for Conditional Pattern




Collaboration Diagram for Loop Pattern


: User : ParallelPattern
1: SplitArcs( )
2: ComputParellelIOTP( )
3: ComputeCostTimeAvailabilityParallel( )
4: ProcessParallelPattern( )
: User
: ConditionalPattern
1: ComputeStructuredPattern( )
2: ProcessServiceGraph( )
3: RemoveSequentialParallelLoopPatterns( )
4: TransformServiceGraph( )
5: CalculateProbabilityWeightedSum( )
: User
: LoopPattern
1: RetrieveEntryPoints( )
2: ComputeIncomingArc( )
3: ComputeTPLoop( )
4: ComputeTPJumpingLoop( )
5: ProcessLoopPattern( )
3.3.6 Class Diagram
















4. EXPERIMENTAL RESULTS


























5. CONCLUSION
In this project, we present a systematic QoS analysis approachthat is able to provide
comprehensive QoS information for acomposite service even with the existence of
complexcomposition structures such as unstructured conditionalpatterns and MEME loop patterns.
The QoS informationgenerated by the proposed QoS analysis approach includesnot only the QoS
of the web service composition but also theQoS and probability of the execution paths.In this
work, the QoS of a web service composition iscalculated based on the assumption that each task
has afixed QoS. The QoS of each task is more likely to be aprobability distribution in reality. For
future research, wewill study QoS calculation method for a composite servicewith component QoS
modeled as general QoS probabilitydistributions. It would be even challenging to estimate
theprobability distributions for services with short life cycle orless frequent use.





















6. BIBLIOGRAPHY

[1] D. Ardagna and B. Pernici, Adaptive Service Composition in Flexible Processes, IEEE
Trans. Software Eng., vol. 33, no. 6, pp. 369-384, June 2007.

[2] M. Dumas, L. Garca-Ban uelos, A. Polyvyanyy, Y. Yang, and L. Zhang, Aggregate Quality
of Service Computation for Composite Services, Proc. Intl Conf. Service Oriented Computing
(ICSOC 10), pp. 213-227, 2010.

[3] J. Vanhatalo, H. Vo lzer, and J. Koehler, The Refined Process Structure Tree, Proc. Sixth
Intl Conf. Business Process Management (BPM 08), 2008.

[4] Q. Yu and A. Bouguettaya, Framework for Web Service Query Algebra and Optimization,
ACM Trans. Web, vol. 2, no. 1, pp. 1- 35, 2008.

[5] H. Zheng, J. Yang, and W. Zhao, QoS Analysis and Service Selection for Composite
Services, Proc. IEEE Intl Conf. Services Computing (SCC 10), pp. 122-129, 2010.

[6] M. Alrifai, D. Skoutas, and T. Risse, Selecting Skyline Services for QoS-Based Web Service
Composition, Proc. 19th Intl Conf. World Wide Web (WWW 10), pp. 11-20, 2010.

[7] M. Alrifai and T. Risse, Combining Global Optimization with Local Selection for Efficient
QoS-Aware Service Composition, Proc. 18th Intl Conf. World Wide Web (WWW 09), pp. 881-
890, 2009.

[8] A.D. Belegundu and T.R. Chandrupatla, Optimization Concepts and Applications in
Engineering, second ed. Cambridge Univ. Press, 2011.

[9] E. Al-Masri and Q.H. Mahmoud, Discovering the Best Web Service, Proc. 16th Intl Conf.
World Wide Web (WWW 07), pp. 1257-1258, 2007.

[10] V. Cardellini, E. Casalicchio, V. Grassi, F.L. Presti, and R. Mirandola, QoS-Driven Runtime
Adaptation of Service Oriented Architectures, Proc. Seventh Joint Meeting European Software
Eng. Conf. and ACM SIGSOFT Symp. Foundations of Software Eng. (ESEC/ SIGSOFT FSE
09), pp. 131-140, 2009.

[11] K.-J. Lin, J. Zhang, Y. Zhai, and B. Xu, The Design and Implementation of Service Process
Reconfiguration with End-to- End QoS Constraints in SOA, Service Oriented Computing and
Applications, vol. 4, no. 3, pp. 157-168, 2010.

[12] O. Moser, F. Rosenberg, and S. Dustdar, Non-Intrusive Monitoring and Service Adaptation
for WS-BPEL, Proc. 17th Intl Conf. World Wide Web (WWW 08), pp. 815-824, 2008.