The composition of the web service is a common technique to attain the best results of complex web tasks. The selection of appropriate web services, linking those services in the action flow and attaining the actual functionality of the task are the important factors to be considered. Even though different frameworks and methods have been proposed to dynamically compose web services, each method has its advantage and disadvantage over the other. Most of the methods give much importance to the Quality of Service (QoS) but fail to achieve the actual functionality after composition. This paper proposes a functionality-oriented composition technique for composing web services. Moreover, this method helps reach the extreme functionality of each web service in the composition towards customer satisfaction. Apart from considering the overall QoS of every single service, the non-functional parameters associated with these services are also considered for achieving the expected functionality. Each of these non-functional parameters has a vital role in the functional performance of the web service. The web services that satisfy the non-functional requirements are chosen to form the composition to attain the best performance. The list of services in the proposed composition method is different from the conventional one, which is composed based on the overall QoS. The non-functional parametric values, the QoS of each web service and the overall QoS after composition are evaluated for the proposed method and experimentally analyzed to prove their advantage over the others.
The increased interest in cloud-based web application leads to the use of web services more effectively. To achieve a solution for complex web task through web applications lead to dynamic composition of web services. But it is difficult to select an appropriate web service that is to be included in the composition to satisfy a task. Currently, different techniques are used for the composition of web services for better performance. The objective is to reach the actual functionality of the intended task. The functionality of a web service is defined by the provider while publishing it, but in some cases, it will not be the same in the real-time usage. So, the quality of a web service comes into effect to address the situation. The QoS is always evaluated based on the functional and non-functional parametric values of the web services. The functional parameters are evaluated based on customer feedback, third-party evaluation surveys and other similar methods [
The entire paper has organized as follows. Section 2 reviews the related works about the frameworks and methodologies used for the composition of web services. Section 3 explains the method used for the dynamic composition of web services and the related experimental results discussed in Section 4. The advantages of this proposed architecture are concluded in Section 5 and followed by references.
Web services are ideal choices to implement customer’s web-based tasks. Web service composition is achieved through automatic discovery, selection and binding of web services with a variety of functionalities. But it is a challenging task in terms of time limits, correctness, transactional and other related features. Several composition techniques are used to compose web services for the best results. Surveys are conducted to study the advantage of one composition method over the other [
D’Mello et al. [
These approaches follow different frameworks and architectures for composing web services, but the aim is to reach the best QoS. The QoS of composition is calculated based on the functional and non-functional parameters guaranteed by the providers of the service [
The proposed service composition architecture has shown in
The service requester describes the complex web task to be completed along with its functional requirements. This task may contain a series of sub-tasks that may have dependent or independent functionalities. The level of fulfillment of this task is mentioned along with its description. The description of the task from the service requester must be clear and unambiguous with its functional level of satisfaction. This description is forwarded to the broker to assign the best composition of services to activate the task.
For example,
Task | Functionality | Overall level of satisfaction |
---|---|---|
T1 | User accounts—Registration and creation of user profile/login as guest | Reliability – 90% |
T2 | Checking availability—Making reservations/Blocking/Confirmation | Response time—98% |
T3 | Confirm ticket | Response time and Reliability—100% |
T4 | Reschedule ticket | Response time and Reliability—100% |
T5 | Cancellation ticket | Response time—85% |
T6 | Update profile | Usability—60% |
T7 | View ticket status | Response time—80% |
T8 | Query flight details | Response time—80% |
T9 | Telephone access | Reliability, Response time—95% |
Let us consider the web task T3, which is used to confirm a ticket that involves various subtasks to complete its process. Several web services are involved in the composition and the requester must have to describe the expected level of satisfaction in terms of functional and non-functional parameters.
Task | Functionality | Level of satisfaction |
---|---|---|
T3F1 | Checking the availability | Reliability—95% |
T3F2 | Booking the Ticket | Response—98% |
T3F3 | Finance Service | Response and Reliability—100% |
T3F4 | Confirmation Services (Email & SMS) | Response time and Reliability—95% |
The remaining steps in this proposed composition framework will be carried out by the broker and the respective feedback will be given to the service requester to evaluate the performance. This process involves the following steps: Describing the complex web task with overall expected QoS. Defining, classifying the complex web task into subtasks so that each subtask will be carried out by the atomic web service. Fixing the non-functional limits and individual QoS of services.
The services needed to compose are selected based on their functionality. This combination is a group of services from different providers and the local web services used within the environment.
Let T1, T2……Tn are the web tasks that the web application needs to be solved by composing suitable web services.
The composition of web service is an important step because the formation and success of the compositions are mainly based on understanding the functionality of each sub-tasks involved in the main task. The process of defining a composite service involves fixing the interaction between the service components, representing the flow of data among the services, supporting the transactional features and its correctness [
The main non-functional parameters P1, P2, P3, P4 and P5 that influence the functionality of the web service are considered to evaluate the QoS for individual services are as follows:
P1—Response time, P2—Availability, P3—Throughput, P4—Successibility, P5—Reliability
The equations for defining the task, web services, QoS and composition of web services are as follows
The task to accomplish the user requirement is defined as:
Here, each WSi is a web service that satisfies a functionality in the flow of the web tasks described by the service requester.
Each atomic web service involved in the combination is a tuple and will be defined as
Here, the ‘Id’ is the identification number of the service. The QoS is evaluated from the non-functional parameter guaranteed by the providers.
The web services with similar functionality are grouped based on QoS and the non-functional minimum expected values. Only those services satisfy these two criteria are ranked and maintained in groups.
The Quality of Service (QoS) related to the task in each group is defined as:
where pj is the non-functional parametric values.
The QoS of each web service in these categories can be calculated as follows:
where, 1 ≤ j ≤ m and Wj weight assigned to each non-functional parameter.
After evaluating the QoS, the services are ranked categorically and stored in the service repository.
The composition of services to satisfy the complex task can be defined as:
The overall QoS of the composition is
for all j (1 ≤ j ≤ m)
Here Ck evaluated for all possible ‘n’ compositions. Gj is the categorized group of services for the subtasks.
After defining the composite service, the next task is to identify the set of web services that need to include the flow of composition based on its functionality. There may be several services are available that satisfy the specific functionality. The minimum expected QoS and level of non-functional parameters are fixed based on the functional requirements of the web service in the composition. These values above the minimum threshold can satisfy the functionality of the web service involved in the composition.
Task | Service category & function | Expected QoS |
Expected values of non-functional |
---|---|---|---|
TF1 | 0.817 | P2 = 0.915 |
|
TF2 | 0.955 | P2 = 0.945 |
|
TF3 | 0.975 | P1 = 0.955 |
|
TF4 | 0.935 | P1 = 0.925 |
After defining the composite service, it is necessary to discover the appropriate services to compose. The discovery is based on the matching between the requirement and description of the service. Here semantic matching is proposed to improve the automation of service discovery. Normally, the discovered services are identical in functionality and with different QoS. The QoS of individual web services is evaluated as in
{
for each task
{
If (Overall QoS > fixed QoS & non-functional parametric values > fixed values)
{
Add the web service in the stack of the task
}
Sort the stack based on QoS
if (stack(top) available)
{
Add this service in the composition chain
Record the QoS up to this composition
}
else
{
Move to the next topmost element in the stack
}
}
In this dynamic composition framework, the services that satisfy the expected measures are ranked and grouped into a specific category based on their functionality. For example, an airline reservation tasks may contain functionalities such as user registration, booking, payment and confirmation. The number of services considered in each group is the broker’s choice; here top four services are taken into consideration for composition.
Task | Service category | Services | Provider | QoS |
Non-functional expected value |
---|---|---|---|---|---|
T3F1 | User Registration | T3F1WS1—Act-On Account | Act on software | 0.898 | P2 = 0.917, P5 = 0.938 |
T3F1WS2—GoSquared Account | GoSquared | 0.866 | P2 = 0.934, P5 = 0.922 | ||
T3F1WS3—Spredfast Account | Spredfast | 0.855 | P2 = 0.945, P5 = 0.936 | ||
T3F1WS4—Amazon Cloud Drive Account | Amazon | 0.832 | P2 = 0.92, P5 = 0.937 | ||
T3F2 | Booking | T3F2WS1—Max Booking | Max Booking | 0.977 | P2 = 0.952, P4 = 0.965 |
T3F2WS2—OnSched Online Booking | OnSched Online Booking | 0.975 | P2 = 0.964, P4 = 0.952 | ||
T3F2WS3—Bookeo | Bookeo | 0.965 | P2 = 0.955, P4 = 0.956 | ||
T3F2WS4—DotTransfers | DotTransfers | 0.964 | P2 = 0.951, P4 = 0.957 | ||
T3F3 | Payment | T3F2WS1—Max Booking | Max Booking | 0.977 | P2 = 0.952, P4 = 0.965 |
T3F2WS2—OnSched Online Booking | OnSched Online Booking | 0.975 | P2 = 0.964, P4 = 0.952 | ||
T3F2WS3—Bookeo | Bookeo | 0.965 | P2 = 0.955, P4 = 0.956 | ||
T3F2WS4—DotTransfers | DotTransfers | 0.964 | P2 = 0.951, P4 = 0.957 | ||
T3F4 | Confirmation | T3F4WS1—Sinch Messaging | Sinch | 0.962 | P2 = 0.932, P5 = 0.955 |
T3F4WS2—TeleSign SMS Verify | TeleSign | 0.961 | P2 = 0.934, P5 = 0.952 | ||
T3F4WS3—Bandwidth | Bandwidth | 0.953 | P2 = 0.945, P5 = 0.946 | ||
T3F4WS4—Papa Texts | Papa | 0.952 | P2 = 0.931, P5 = 0.947 |
The proposed composition algorithm generates all possible combinations of these web services from each group that can be used to develop the composition chains. The QoS of these compositions is evaluated based on
Task | Services involved in the composition flow | Overall QoS of the composition |
---|---|---|
C1 | T3F1WS1 → T3F2WS1 → T3F3WS1 → T3F4WS1 | 0.9575 |
C2 | T3F1WS1 → T3F2WS1 → T3F3WS1 → T3F4WS2 | 0.95725 |
C3 | T3F1WS1 → T3F2WS2 → T3F3WS1 → T3F4WS1 | 0.957 |
C4 | T3F1WS1 → T3F2WS2 → T3F3WS1 → T3F4WS2 | 0.95675 |
C5 | T3F1WS1 → T3F2WS1 → T3F3WS2 → T3F4WS1 | 0.95575 |
C6 | T3F1WS1 → T3F2WS1 → T3F3WS2 → T3F4WS2 | 0.9555 |
C7 | T3F1WS1 → T3F2WS1 → T3F3WS1 → T3F4WS3 | 0.95525 |
C8 | T3F1WS1 → T3F2WS2 → T3F3WS2 → T3F4WS1 | 0.95525 |
C9 | T3F1WS1 → T3F2WS1 → T3F3WS3 → T3F4WS1 | 0.955 |
C10 | T3F1WS1 → T3F2WS1 → T3F3WS1 → T3F4WS4 | 0.955 |
The following
The following
Compositions | QoS-proposed method | QoS-general method |
---|---|---|
C1 | 0.9575 | 0.957 |
C2 | 0.95725 | 0.94925 |
C3 | 0.957 | 0.95525 |
C4 | 0.95675 | 0.949 |
C5 | 0.95575 | 0.9475 |
C6 | 0.9555 | 0.95575 |
C7 | 0.95525 | 0.95225 |
C8 | 0.95525 | 0.967 |
C9 | 0.955 | 0.95475 |
C10 | 0.955 | 0.95675 |
These results are also graphically shown in
The composition of web service is an important technique to satisfy the customer’s complex web tasks. Choosing a suitable service for composition is vital to achieving the real functionality of the web task. A low-performance service may collapse the entire workflow of the composition. To reach the actual functionality of the web service, apart from considering the QoS, the non-functional parameters that are most needed for the functionality also used in this research. Based on the request from the customer, the broker considers the QoS and non-functional parametric values for the desired functionality to select the web service. These services are selected from the pool of similar services and ranked based on the proposed criteria. This method supports the dynamic composition of web services and helps to achieve the best result during real-time usage. The performance measures of non-functional parameters of the web services are recorded in real-time and the web service that satisfies the expectations will be included in the group so that it will be added to the composition in the future. In a cloud-based setup, the composition of services is more common and available monitoring and management tools from cloud providers can enhance the quality of web service composition.
The authors M. Sha and A. Alameen are thankful to the Deanship of Scientific Research, Prince Sattam Bin Abdulaziz University, KSA for supporting this work.