In any organization where SOA has been implemented, all of the web services are registered in UDDI and users’ needs are served by using appropriate web services. So in this paper, we will try to discover a service from repository first that can provide the required output to the user. The process becomes difficult when a single service is not able to fulfill a user’s need and we need a combination of services to answer complex needs of users. In our paper, we will suggest a simpler approach for dynamic service composition using a graph based methodology. This will be a design time service composition. This approach uses the functional and non-functional parameters of the services to select the most suitable services for composition as per user’s need. This approach involves “service classification” on the basis of functional parameters, “service discovery” on the basis of user’s need and then “service composition” using the selected services on the basis of non-functional parameters like response time, cost, security and availability. Another challenge in SOA implementation is that, once the composition has performed, some services may become faulty at runtime and may stop the entire process of serving a user’s need. So, we will also describe a way of “dynamic service reconfiguration” in our approach that will enable us to identify and replace a faulty service that is violating the SLA or is not accessible anymore. This service reconfiguration is done without redoing or reconfiguring the entire composition. In the end, to simulate the proposed approach, we will represent a prototype application built on php 5.4 using My SQL database at backend.
Section 1 gives the introduction of Service Oriented Architecture and the basic terminologies related to SOA. We are also going to discuss the service discovery, composition and reconfiguration along with the use of SLA in SOA in this section. In section 2, we will discuss the related work. In section 3, we will discuss the methodology used for services composition in our research and will show the services dependencies in form of Directed Acyclic Graph. In section 4, we will discuss the methodology used for services reconfiguration in our research. We will also discuss the role of SLA in service composition and service reconfiguration along with the related research work for services composition and reconfiguration. Section 5 presents a simulated system to demonstrate the methodology used in our research. Conclusion and future work will be presented in the next section.
Service Oriented Architecture (SOA) is a services based software integration solution for most of the systems. It is a loosely-coupled architecture designed to meet the business needs of the organization.
Key features of service oriented architecture are to:
Divide our code in reusable modules and encapsulate design decisions in modules.
Combine modules with each other following loose coupling for different purposes.
Easily respond to changes and make maintainability easier.
Improve productivity, agility, and speed for both business and IT.
Align IT services to business and deliver faster services.
Reusability, flexibility and maintainability are the main powers of service oriented architecture.
SOA can provide following benefits to business.
Efficiency: Transform business processes from replicated processes into highly leveraged shared services that cost less to maintain.
Responsiveness: Rapid adaptation and delivery of key business services are to meet market demands for increased service levels to customers, employees, and partners.
Adaptability: More effectively rollout changes throughput the business with minimal complexity and effort, saving time and money.
Some web services standards discussed in different research are: WSDL, SOAP, UDDI, ESB, and BPEL.
WSDL: Web service description language is an XML file used to define what service is and how to interact with it.
SOAP: Simple Object Access Protocol provides a framework that manages the interaction between requester and responder through message passing.
UDDI: Universal Description, Discovery and Integration is used to register web services.
ESB: ESB serves as a middleware in SOA. Service provider publishes services on ESB and service users can invoke the services on the ESB according to their business requirements. ESB provides a set of infrastructure capabilities, implemented by middleware technology, which enable the integration of services in SOA.
BPEL: Business Process Execution Language is an XML based standard for defining business processes. It supports processes which exchange information by using web service interfaces.
SLA: Service Level Agreement is an agreement between consumer and service provider that is used to verify the QoS of services.
We can classify services based on any similarity found among them like similar functional parameters, similar non-functional parameters, similar complexity level, etc. For example, when some or all of the input and output parameters are common between two services, then these services can become a part of the same class on the basis of functional parameters. Another example is when two services can provide the same level of security or can complete process in similar response time or cost of the services is the same, then we can say that these services are in the same class based on non-functional parameter. Services can also be classified on the basis of complexity level, for example, if two or more services have the same complexity class like n (O) then we can say that these services are in the same class.
When a service can fulfill any pre conditions of another service then we can say that the second service is dependent on the first service. But this dependency should not be cyclic; it means the first service should not be dependent on the second service in this case. Acyclic dependency among services leads us to the path of required service composition based on the provided input and required output of the user.
A directed acyclic graph helps us to map service dependencies in the form of graph. Services names can be represented as nodes and input and output parameters can be represented on edges of the graph. The direction of the graph represents which service is dependent on which another service exactly. There is no backward or feedback path in this graph so the graph will always be acyclic. Because the services are already classified on the basis of the similarities found among them, so the services of the same class cannot be dependent on each other thus graph complexity will be minimized and each service has to be represented only once in the form of a node using all possible edges for the input and output dependencies with other services except the services of the same class.
Service Discovery means to find the desired service to fulfill the customer’s need or to find a service for the appropriate service composition to serve the user’s requirement. Service Discovery is performed to answer the following questions:
Does the requested service exist?
Is the service accessible or is service instance available to fulfill the request?
A Service Level Agreement (SLA) is a contract between a service provider and its customers that document what services the provider will furnish. It is used to measure the performance of the service provider and to measure and maintain the QoS parameters like response time, cost, security, availability which are agreed by the provider for that particular service.
When a single service cannot serve a request for any user independently then we use a service composition. A service composition is a collection of existing services that is used to automate a particular task or business process. We cannot get benefits of SOA if we cannot compose service conveniently and appropriately. We can save the mostly used compositions for later use and to further reduce the response time for the end user.
Service Reconfiguration is the process of identifying a faulty service from a composite service and then replacing that service with another but similar type of service without reconfiguring the entire process. When “identification and replacement of a faulty service” is more feasible then “re-composition of the services”, then we go with reconfiguration approach.
Hajar Elmaghraoui et al. proposed a framework in [
Yang Bo et al. discussed the design time and deploy time service binding issues in [
Dmytro Pukhkaiev et al. discussed the dynamic composition of services in [
Services in dynamic service composition may be from different service providers. A faulty service in this composition may violate end-to-end QoS of a service process. Kwei-Jay Lin et al. proposed an effective approach for service replacement of faulty service in [
Pavankumar Guluru et al. in [
Saurabh Shrivastava and Ashish Sharma suggested an approach in [
Philipp Leitner et al. developed a framework PREvent in [
Hui LIU et al. discussed in [
Karthikeyan and Kumar discussed in [
Vallidevi Krishnamurty et al. discussed in [
A web services based system is configured by using a simple life cycle of service composition discussed in [
Service Request Phase defines the properties and goals of the desired service. These properties and goals are the inputs for the Service Discovery and Service Composition phases. Service Discovery Phase finds the service by analyzing the service request to fulfill user’s requirements. If the desired service is not found then the service are automatically composed in Service Composition Phase. Service Execution Phase translates the service composition into an executable representation and deploys it to the service composition execution engine.
Some of the problems discussed in [
Services had been selected at design time but after that selection, services offering better results have been deployed.
Services had been selected at design time but have removed now and not accessible at runtime.
Error occurs in service execution that interrupts the process and there is no recovery process now.
Service composition at runtime can solve these problems but it is a time consuming process that usually increase the throughput and response time to complete the user request.
We preferred the design time service composition in our research. We are using a Directed Graph Approach to compose services based on the dependencies exist among them and possible compositions will be saved in a Directed Graph Repository. The entire process is completed at design time and to overcome the shortcomings of the service binding at design time, we will use the approach to automatically update the Directed Graph Repository whenever a new service is published or an existing service is changed or removed.
Our approach is, find a service from Service Repository that fulfills the user requirement. If there is no any service that can fulfill all of the parts of the user requirement then find a composite service from Composite Service Repository where previously created composite service plans are stored and if not succeed then find a composite service from Directed Graph Repository.
A service can be defined by its inputs, pre-conditions, outputs and effects. Set of Inputs for a service describes what the service required to produce the required output? Set of outputs of a service describes what the service produce as an answer to a request? Set of pre-conditions for a service describes what are the expectations for a
web service to provide required output? Set of effects of a service describes what is the result of a web service with respect to the inputs and conditions on it? In service composition process, we must know about the values of the functional parameters.
There is more than one method to perform web services composition. For example, static service composition, dynamic service composition, manual service composition and automated service composition.
We have selected a graph based approach for service composition because we can easily map services composition into a graph structure [
Based on the functional parameters of the services defined in WSDL document of each service, we can classify them in service classes. All of the services in a class should provide the same functionality having same input/output types, but they differ on the basis of non-functional parameters thus providing different QoS value with same functionality [
Class SC1 includes services S1and S2 both providing the same functionality to user request. S3, S4 and S5 are similar type of services thus enclosed in a class SC2. Class SC3 contains services S6 and S7. For the desired web service composition, we may select one service from each class having QoS values better than other services of the same class. Some ways of service composition are discussed and compared in [
When an output parameter of a service in a class can fulfill completely or partially the input parameter requirement of a service in another class then there exist a dependency between two services.
Service S1 takes I1 and I2 as input and computes the requested functionality if pre-conditions P1 and P2 are satisfied for I1 and I2 respectively. S1 generates the output as O1 and O2 with effects E1 and E2 respectively. Similarly I1 and I2 are inputs for service S3 with pre-conditions P1 and P2 and S3 generates output O1 and O2 with effects E1 and E2. Here one of the outputs of service S1 fulfills the input requirement of service S3 either partially or completely hence there exist a dependency between services S1 and S2 and both services can execute sequentially in any service composition.
We are constructing a directed acyclic graph to show the dependencies among services of different classes shown in
Now, If the request is to find a service composition that takes {A, B} as input and gives {J, K} as output then possible service compositions with their aggregated values of QoS parameters are shown in
S No. | Service Composition | Total Response Time | Total Cost | Security | Availability |
---|---|---|---|---|---|
1 | S1 −> S3 −> S6 −> S8 | 18 | 27 | H, M, H, L | H, M, H, L |
2 | S1 −> S3 −> S6 −> S9 | 17 | 28 | H, M, H, L | H, M, H, L |
3 | S1 −> S3 −> S6 −> S10 | 15 | 30 | H, M, H, M | H, M, H, M |
4 | S1 −> S3 −> S7 −> S8 | 22 | 22 | H, M, M, L | H, M, M, L |
5 | S1 −> S3 −> S7 −> S9 | 21 | 23 | H, M, M, L | H, M, M, L |
6 | S1 −> S3 −> S7 −> S10 | 19 | 25 | H, M, M, M | H, M, M, M |
7 | S1 −> S4 −> S6 −> S8 | 20 | 27 | H, M, H, L | H, M, H, L |
8 | S1 −> S4 −> S6 −> S9 | 19 | 28 | H, M, H, L | H, M, H, L |
9 | S1 −> S4 −> S6 −> S10 | 17 | 30 | H, M, H, M | H, M, H, M |
10 | S1 −> S4 −> S7 −> S8 | 24 | 22 | H, M, M, L | H, M, M, L |
Service | Input | Output | Response Time | Cost | Security | Availability |
---|---|---|---|---|---|---|
1 | A, B | C, D | 2 | 10 | High | High |
2 | A, B | C, D | 3 | 5 | Med | Med |
3 | C, D | F | 3 | 5 | Med | Med |
4 | C, D | F | 5 | 5 | Med | Med |
5 | C, D | F | 4 | 5 | Med | Med |
6 | F | H, I | 6 | 10 | High | High |
7 | F | H | 10 | 5 | Med | Med |
8 | H | J, K | 7 | 2 | Low | Low |
9 | H | J, K | 6 | 3 | Low | Low |
10 | H | J, K | 4 | 5 | Med | Med |
Based on this repository, one can select a service composition according to the required QoS values. When security and availability are the most critical requirements then the composition with services having low security should not be selected. When cost is the major issue and a user can compromise with security and availability then the composition having low cost should be selected. When a user requirement is time critical then a composition having low response time can be selected along with the acceptable values of cost, availability, and security.
We not only need accurate results from a service composition but also need the desirable QoS to maintain [
Response Time of a service in milliseconds.
Cost of a service on a scale of 1 to 10.
Security of a service on a scale of Low, Medium, High.
Availability of a service on a scale of Low, Medium, High.
We will select services for service composition on the basis of these four parameters.
Based on the functional and non functional parameters, service composition can be defined as:
where SC represents service composition, I is the set of input values, O is the set of output values, F represents the required functionality and NF is for the non-functional parameters.
Based on the non functional parameters, service composition can be defined as:
where P is the performance, RI is the reliability, RB is the Robustness, AC is the Accessibility, AV is the Availability, C is the Cost, S is the Scalability, CA is the Capacity, and AR is the Accuracy.
Service level agreement SLA is an agreement between consumer and service provider that is used to verify the QoS of services. In web services composition process, services can be selected on the basis of the QoS parameters defined in Service Level Agreement by service provider while publishing a service. Composed services can also be monitored on the basis of SLA to detect any violation of agreed parameters by a service [
SLA represents the Service Level Objectives (SLOs) i.e. QoS that the service needs to fulfill and the monitoring is performed on the basis of agreed upon QoS in SLA. Philipp Leitner et al. presented a PREvent framework that predicts the SLA violation at runtime and suggests a adaptation action to improve the overall performance in a composition instance [
Hui LIU et al. presented a framework for the SLA based service composition where they suggest that service provider should also register the service quality information along with the functional details of a service in repository [
Karthikeyan and Kumar presented a framework for the quality based dynamic composition [
Dmytro Pukhkaiev et al. proposed a SLA aware approach for web service composition [
At runtime, services may violate pre-defined QoS levels due to many factors like host overload, network congestion etc. In this situation, we need to repair a service process to continue the business process function effectively [
Replacing the entire service process will not be efficient and will be time consuming and costly. Reconfiguration is the optimal service selection process that allows the system to work continuously and there is no need of the migration of system and services [
Saurabh et al. discussed two approaches of service reconfiguration: i) Finding an optional path of services from its predecessor services to the completion of service process; ii) Finding an alternate service path from the start to the end of the service process [
In our approach, we have first classified all of the services on the basis of functional dependencies and have created the directed dependency graph to know all of the possible compositions of the available service at design time. When any composition executed and a service violates the agreed QoS values then we suggest the alternative composition by replacing the faulty service with a service having same input and output dependencies. We can get familiar about the violation of agreed QoS values from the side of any service by using a service monitoring engine or the response getting executing a service composition. One of the service monitoring engines based on monitoring of SLA is discussed by Vallidevi et al. in [
Discussion of the service monitoring engine is not included in our scope. We are assume some scenarios like a service is violating the QoS values or service is not responding at all and are suggesting an approach to replace that faulty service with another service having better QoS values. In chapter 6, we will discuss a prototype system used to demonstrate the suggested approach of service composition and reconfiguration.
We are assuming that we have a list of available services along with the details of functional and non-functional parameters of the services. We have created a web based system using Yii framework of php. MySQL database is in use at backend. We can insert the information of services in our system to find out the dependencies among services and to compose service as per user needs.
1This simulator is available online. URL: http://asharali.com/scr_system/index.php. Email: visitor@hotmail.com. PWD: 9A@1c$qrf.
The web based application is not publicly accessible so a login screen will appear first to allow only authenticated users to access the system.
After a successful login, user can view the home screen to know the details about how to use the system.
Service discovery screen lists all of the services which exist in repository along with the information of services about input, output, response time, cost, availability and security parameters. User can find a service by providing some parameter values as filter of the list.
Service composition screen finds and list all of the atomic or composite services based on provided values of the input and output required by the user. All of the aggregated values of the QoS parameters are also listed along with the services map on this screen.
Service reconfiguration screen shows the effect of executing any service composition.
Graph in
Graph in
This graphical analysis clearly depicts that the methodology we are using will become complex with the increased number of services and we have to find a way to optimize the process. One possible way of this optimization can be “sort the list of compositions based on the number of times a composition is used and then show top 10 compositions to user”.
In this paper, we proposed a graph based approach for dynamic service discovery, service composition and service reconfiguration. The first step is to classify the services based on input/output parameters of the services. The second step is to identify the service dependencies based on their input and output requirements. The third step is to identify the services. We called this step as service discovery phase. Service discovery also includes the description of the input/output parameters and QoS parameters of the identified services. We then list all of the possible combinations of the services based on the user’s needs of input/output parameters as well as the QoS parameters like response time, security, cost and availability. A most suitable composition can then be selected from this list on the basis of required QoS parameters. One may prefer minimum response time and low cost and others may prefer high security and availability. A service that is a part of the selected composition may become faulty or may violate the SLA terms. To solve this problem, we have suggested a way in our approach to identify and replace the faulty service without reconfiguring the entire composition. We have also developed a prototype application to simulate the suggested approach.
In the future, we will work on the aggregated SLA of the composite application to make the composition and reconfiguration process more efficient.
I would like to pay special thanks to Allah (SWT) who gave me the opportunity to complete this paper. At last, I am also thankful to my family, friends, fellows, and colleagues who supported me in their best.
Zulqarnain Abdul Jabbar,Asia Samreen, (2016) Dynamic Service Discovery, Composition and Reconfiguration in a Model Mapping Business Process to Web Services. Journal of Computer and Communications,04,24-39. doi: 10.4236/jcc.2016.49004