Implementation Of Runtime Web Service Discovery

Abstract' During the execution of service based application there is an important issue for replacing the service in them which fails to satisfy the current requirement or is no longer present. Identification of services based on different service parameters such as structural, quality, behavioral and contextual leads to effective runtime discovery of service. So in this paper, we are introducing a framework that support runtime services discovery. The framework supports two modes of execution of query for service discovery namely pull and push mode. In pull mode (reactive way), queries are executed when a need for finding a replacement service arises (for example: unavailability or malfunctioning of service, emergence of new service, changes in structure functionality etc.).In push mode (proactive way), execution of query is carried out in parallel to the service-based system execution. Hence, if there is a need to replace a service in service based application, push mode of execution of query makes it possible to avoid interruptions in the operation of application. Both types (i.e., pull and push) of queries are specified in a XML based query language called SerDiQueL. SerDiQueL is the language that allows the representation of behavioral (functionality), structural (interface),quality, and contextual conditions of services to be identified. So in this paper, we are going to discuss the runtime service discovery framework.
.

Index Terms' Web Service Discovery, Web Services, XML, Dynamic Service Discovery.

I. INTRODUCTION
Services are nothing but entities that are owned by a third party in a service based application. Such services are helpful in creating the dynamic business processes. Due to various changes in market, it is necessary to identify the services that will directly fulfill the need of user by providing the appropriate quality and functional features of service based application .The process of identifying such services is called as service discovery. Several researches and approaches has been developed to support service discovery, classified as static[1], [2], [3], [4] and dynamic [5], [6], [7], [8] approaches. The services which are identified during the application development and prior to execution comes under static approach while the services that are identified during the execution of the application comes under dynamic approach. There are various scenarios where we need to replace the service during the execution of application.
Following are the scenarios due to which we need to replace the services:
1) Due to service unavailability , service malfunctioning.
2) Changes in the interface, behavioral, quality, service context in the application due to the service which no longer fulfill its task.
3) The emergence of new services that which fulfill the task in better way than the existing service.
4) Changes in the application context due to services which is used no longer fulfill its task.

The above scenarios give rise to a question, i.e, how to support the application when the service which is being used is not working properly or stop functioning as desired, as well as changing the application and their services continuously at runtime .To address such questions we require a flexible and dynamic service identification at the runtime of service based application.

Currently most of the approaches uses pull mode of query execution for dynamic service discovery. This mode of query execution is often not effective because the discovery process starts only if the requirement for a new service arises (as in case 1 above) and it may also consume more time to complete, which will affect the application performance and its capability to produce acceptable or
appropriate services (as in case 3 above). Similarly, for cases 2 and 4 above, pull mode discovery would need to wait until the changes that made used services become inadequate arise at runtime, as in case 1. Alternatively, the pull mode of query execution would need to be enhanced for
polling service registries regularly and/or context information resources to identify changes that can create subsequent problems. Such polling would consume resources as even if there is no need to do so it would need to be executed at regular intervals (i.e., in case of emergence of new services ,application environment, in the absence of service context changes or context changes).

Furthermore, existing approaches to service discovery (with the exception of [8]) do not consider different characteristics of the application at the same time when attempting to identify services such as interface(structural), functional (behavioral), quality, and contextual aspects .
To address the existing approaches limitations, we present a web service discovery framework that supports runtime service discovery based on complex queries that can express flexible combinations of structural, quality, contextual and behavioral parameters. These complex queries are specified in an XML-based query language, called SerDiQueL. The framework assumes services that have different descriptions including service behavioral, interface, quality, and context descriptions.

To support entire cases 1 to 4 above and avoid the limitations of traditional mechanisms for polling, our frame-work allows
service discovery based on both push and pull query execution modes. Pull mode query execution is triggered in cases 1 like scenarios above. In push mode, query execution is performed in parallel to the execution of the application using queries. These queries maintain up-to-date sets of candidate replacement services for these services and are associated with specific services in an application . In both pull and push modes, execution of query is based on matching and the computation of service specifications and distances between query.

2. OVERVIEW

In this section, we will be presenting some scenarios for runtime web service discovery and give an overall description of how our framework will be useful to address these scenarios.

2.1 Runtime Web Service Discovery Scenarios

Various scenarios regarding runtime service discovery can be identified in reference to a mobile service based application called On-the-go-News[10] .

On-the-go-News allows its users to request and receive news from different sites from their mobile phone. To do so, the application offers services allowing users to:

1. search for news topics and choose the source from where they want to receive the news,

2. display news about a topic from different sources,

3. create customized on-the-fly 'magazines' or with data from several different news sites,

4. flip through articles in a customized magazine from several sources,

5. obtain and pay for the nonfreely available information, charging the amount in the user's phone bill at the end of the month, and

6. see the new balance of their phone bill after using the application for 5.

On-the-go-News uses an external service, called SService, which searches different news sites to identify news about specific topics, and another service, called SCustMag, which enables the amalgamation of news and their appearance in an on-the-fly magazine.

After receiving a request for news on a specific topic one runtime service discovery scenario can arise , on-the-go-News is not able to contact SService due to which the latter service is unavailable (Case 1). In this case, the application will need to identify a new service to replace SService. After the new service is identified and bound to on-the-go-News,the user who issued the request will start receiving the requested information from various sites.

A second scenario may arise if a user who wants an on-the-fly magazine about climate change on his/her mobile phone and created such a magazine using SCustMag starts getting a slow response from SCustMag as the service is used by many different users simultaneously (Case 2). In such cases, an alternative service for SCustMag with acceptable response time will need to be identified and bound to on-the-go-News.

A third scenario arises when, while a user of on-the-go-News is traveling by train, he loses access to the service that displays and supports flipping through news (i.e., a service
called SDisFlip) since SDisFlip cannot be accessed at his current location. This change in the location of on-the-go-News

(Case 3) requires searching for an alternative service that could be used in the user's current location.

A fourth scenario arises when a new service that allows payments by debiting the user's bank account and credit card payments instead of charging the user's phone bill becomes available (Case 4). If flexibility in payment is desirable in on-the-go-News, the new service should be bound to the application.

2.2 Framework Support

Fig.1 Architecture of various components in runtime service discovery framework
Runtime service discovery consists of web service user interface, application data server, service data server, service analyzer, request web service, match finder, service catalog system, external service catalogs.
The web service user interface is used by the user to query for a web service which provides access to framework. It represent request entry point and response exit point.
The request web service block offers various functionalities. It instantiates the service queries to be executed by the matchfinder based on the various situations, receives responses from matchfinder, collect, organize the result and send it to the web service interface etc.
The matchfinder is responsible to parse the constraints of a query and evaluate these constraints against service specifications in the various service registries. The matchfinder
consists of two stages filtering and ranking.
The service catalog system provides the use of different service registries. Its main aim is to provide an interface, which allows the matchfinder to access services from various different type registries.
The service data server and application data server enable context information is to be subscribed. They also allow to spread context information of the services and application environment.
The service analyzer provides the information about the new service available or information about changes in structural, behavioural, quality characteristics of existing services of an application.


3.WEB SERVICE DISCOVERY QUERY LANGUAGE
A runtime service discovery query may contain different criteria, namely: 1) constraints, specifying additional conditions for the service to be discovered; 2) structural criteria, specifying the interface of the required service; 3) behavioral criteria, specifying the functionality of the required service; and. The latter conditions may refer to quality aspects of the required service or interface characteristics of services that cannot be represented by the standardized forms of structural descriptions used in the framework. Examples of constraints referring to quality characteristics of services may concern the maximum response time or cost to execute a certain operation in a service.
The constraints in a query can be contextual or non-contextual. A non-contextual constraint is concerned with static information, while a contextual constraint is mostly concerned with information that changes dynamically during the operation of the service-based application or the services that the application deploys. The constraints can be hard or soft. A hard constraint must be satisfied by all discovered services for a query and is used to filter services that do not comply with them. Soft constraints do not need to be satisfied by all discovered services, but are used to rank candidate services.
To specify runtime service discovery queries, we have developed an XML-based language,called SerDiQueL.
SerDiQueL allows the specification of all the structural, behavioral, quality, and contextual characteristics required from the services to be discovered. An earlier version of SerDiQueL was presented in [9]. The new version of the language that we present in this paper enables the specification of the required behavior of a service using behavioral conditions rather than a full BPEL model of service behavior as in the original version.

3.1 Structural Subquery

The structural subquery describes the interface of the required service. Structural subqueries in SerDiQueL are specified using WSDL [16]. The use of WSDL in this case is due to its wide acceptance as a service interface description
language. In addition, during runtime service discovery, any replacement service that might be identified for an existing service in a service-based application will need to conform to the interface of the existing service. A structural subquery in SerDiQueL is specified as the WSDL specification of the service to be replaced.

3.2 Behavioral Subquery

Behavioral subqueries in SerDiQueL support the specification of
1. the existence of required functionalities in a service specification,
2. the order in which the required functionalities should be executed by the service,
3. dependencies between functionalities (e.g., a functionality realized by an operation always requires the existence of a functionality of another operation),
4. preconditions, and
5. loops concerning execution of certain functionalities. Behavioral subqueries are expressed by elements that are similar to temporal logic operators.

3.3 Constraint Subquery

A constraint subquery in SerDiQueL is defined as a single logical expression, or a conjunction/ disjunction of two or more logical expressions, combined by logical operators AND and OR, or a negated logical expression. Query constraints have four attributes:
1. name, specifying the name of the constraint;
2. type, indicating whether the constraint is hard or soft;
3. weight, specifying the significance of the constraint as a real number in the range [1.0, 0.0]; and
4. contextual, indicating whether the constraint refers to a noncontextual or contextual feature of a service.
The weight of a constraint is used to prioritize it against other soft constraints when inexact matches are found in query evaluation. A constraint subquery whose contextual attribute is true contains ContextOperand elements. When this attribute is set to false, the query may only contain NonContextOperand elements.

A logical expression is defined as a condition, or logical combination of conditions, over elements or attributes of service specifications or context aspects of operations.

Conditions are defined as relational operations expres- sing comparisons between the values of two operands (operand1 and operand2). The supported comparisons are specified by elements expressing the relational operations equalTo, notEqualTo, lessThan, greaterThan, lessThanEqualTo, greaterThanEqualTo, and notEqualTo. These operations have the normal respective meanings for comparisons between their operands. The operands can be noncontextual operands, contextual operands, arithmetic expressions, or constants. A noncontextual operand (i.e., an element of type Non- ContextOperand) has information about the name and the type of the service specification facet from which the operand's value will be retrieved during the constraint evaluation, and an XPath expression indicating elements and attributes in the service specification facet. The evaluation of this XPath expression will provide the value of the noncontextual operand during the evaluation of the enclosing constraint. Hence, constraints can be specified against any element or attribute of any facet in the description of a service in a registry.

4. WEB SERVICE DISCOVERY PROCESS

Service Discovery process contains following Process:

4.1 Query Matching Process

Matching between queries and services is executed in two stages: the filtering stage and the ranking stage. In the filtering stage, only the hard non contextual constraints of a query are evaluated against service specifications and the candidate services that comply with these constraints are identified.

The ranking stage has three sub stages.
In the first of these sub stages, the structural and behavioral parts of a query are evaluated against the services maintained by the filtering stage and a structural-behavioral partial distance between each of these services and the query is computed.
In the second sub stage, the soft non contextual constraints of the query are evaluated against each candidate service and a soft non contextual partial distance is computed for each such service.
Finally, in the third sub stage, the contextual constraints of the query are evaluated against the candidate services and a contextual partial distance is computed for each candidate service.
At the end of the ranking stage, the partial distances computed for each service are aggregated into an overall distance and only services whose distance to the query is below a certain threshold are maintained.

4.2 Pull and Push Query Execution

In the pull mode of query execution, the service requester of RSDF (see Section 2.2) invokes the service matchmaker to execute a query. The service matchmaker executes the query and maintains services whose distance from the query does not exceed a specific threshold. The set of maintained services is sorted in ascending distance order and returned to the client application for further action. In the push mode of query execution, the client application subscribes to RSDF the services it deploys and a query Q for each of them. Based on the subscribed query for each service S, RSDF initially retrieves a set of services Set S that could replace S (if necessary) by executing the query as in the pull mode and, subsequently, maintains an up-to-date version of Set S as changes in the descriptions and context of the services and/or their application's environment are notified to it. Set S includes only services whose overall distance from the query subscribed for S does not exceed a given threshold and is sorted in ascending distance order. It should be noted, however, that although Set S includes candidates that could replace S, the replacement of S in the application does not take place right after the first or subsequent modifications of Set S. This is because an immediate replacement might be inappropriate. In cases, for example, where the service S is executing some transaction on behalf of the application at the time when a new better service is found, no replacement should take place. In RSDF, the decision to stop the execution of the application to replace a service for which a better alternative service has been found is based on replacement policies. Policies are associated with the different functional roles that are assumed by services in the application and specify if the service that is currently bound to a role should be replaced immediately when a better service is found, after the termination of a specified computation, or after the application terminates. The push mode service discovery process that maintains the set Set S of candidate replacement service for a given service S covers four different cases. These are cases where:
1. S becomes malfunctioning or unavailable (Case A),
2. there are changes in the structure, functionality, quality,or context of any service in Set S or S(CaseB),
3. there are changes in the context of the application environment (Case C), or
4. new services become available or existing services have their characteristics modified (Case D). In the following, we discuss the push execution mode for each of these cases.

Case A: In this case, the service S is replaced by the first service S0 in Set S. By virtue of the process of maintaining this set, S0 is guaranteed to have the smallest distance to query Q associated with S. Following the replacement, S0 is removed from Set S.
Case B: Suppose S0 is a service that is currently bound to the application or another service in its associate replacement Set S. This case arises when new versions of the structural, functional, quality, or context facets of S0 become available in a service registry. When a change in some characteristic of S0 occurs, the new versions of the changed facets or service context information are evaluated against query Q to verify if S0 still matches the query. The new overall distance between Q and S0 is also calculated. If S0 is a candidate replacement service in Set S, it remains in it only if the new distance between S0 and Q is below the threshold distance. Also, the relevant position of S0 in Set S might change due to the new distance. Following this, if S0 becomes the best replacement service in Set S, S0 will replace S when the relevant replacement policy allows it. If S0 is the service currently deployed by the application but is no longer the best option according to its new distance from Q, it will be replaced by the first service in Set S as soon as the replacement policy permits the change. Furthermore, if the new distance between S0 and Q makes S0 a noneligible member of Set S, S0 will be removed from Set S and its subscription will be removed from RSDF. Also, a new replacement service for S0 in Set S will be located.

Case C: In this case, a value in a context constraint in query Q is modified and a new query Q0 needs to be created to reflect the new context value. The service S that is currently bound to the application needs to be evaluated against the new context constraint in Q0. IfS does not match the new query Q0, the services in Set S will be evaluated against Q0 and a new version of Set S may be generated. This is necessary for identifying the service S0 in Set S with the best fit to Q0 and bind it to the application so that it can continue its execution while trying to find new services that match Q0 from the service registries. Note that S0 might not have the best fit with Q0 given all available services in the registry. However, the use of the best service S0 in the current Set S in this case is acceptable as it will allow the application to continue. Moreover, the context constraints are soft constraints used for ranking services with respect to queries, rather than filtering them out. Following the use of S0, RSDF will do an exhaustive search in registries (pull mode) to update Set S based on Q0. The same exhaustive search will be used if no service in the current Set_S matches Q0. Following the update of Set S, if a new service in it is better than S0, it will replace S0 subject to the replacement policy.

Case D: This case arises when new services appear in registries for the first time or descriptions of existing services in registries that were not matching a query Q before change (the latter services are not covered by Case C since, as they are not members of Set S, the changes in their characteristics will not be notified to RSDF through the existing subscriptions for Set S). Once RSDF is notified of new or updated service descriptions, it evaluates them against query Q for each service S deployed in the application. Depending on the result of this evaluation, the new/updated service may become member of Set S or even replace S in the application, subject to the criteria of the replacement policy for S. In the approach, the replacement policy used in CasesA-D described above takes into consideration the position of a service S that may need to be replaced with respect to the current execution point of the service-based application. More specifically, the replacement policy considers the cases in which changes need to be performed so that the application can continue its operations, changes can wait to be performed after the current execution of the application, and no changes are required. For a replace- ment policy, the approach considers three different positions, namely:
1. not in path: when service S is not in the current execution path of the application, S appears in a different branch of the application's execution path or before the current point in the execution path; 2. current: when service S is in the current execution point of the application; 3. next in path: when service S is in the current execution path of the application and will be invoked some time in the future. When the position of a service S to be replaced is not in path, S is marked for replacement when S is accessed in a future execution of the application; when the position of S is current, S needs to be replaced; when the position of S is next in path, S is marked to be replaced when S is accessed in the current execution. It should be noted that notifications about changes in services S0 falling in case B are dealt with according to their priority. More specifically, the service matchmaker main- tains three notification queues'a high-, medium-, and low- priority queue'and notifications for services bound to the application are placed at the end of the high-priority queue, notifications for services in some replacement set (Set_S) are placed in the medium priority queue, and notifications for other services are placed in the low-priority queue (i.e., the queue of new services). Also, the services with notifications in the high- and medium-priority queues are marked as 'unsafe' to prevent the application from using them before the notifications that have arrived for them are processed. Furthermore, if a notification N0 arrives for a service for which there is already an earlier notification N in the same queue which has not been processed yet, the facets identified in N0 are added to those of N in the queue rather than appending N0 to the end of the queue. Hence, all the unprocessed notifications of a service are merged. Matchmaker processes notifications from lower priority queues only if there are no notifications in higher priority queues. This heuristic ordering of processing ensures that: 1) Notifications regarding the services which are currently bound to the application and are the most critical for it are processed first, 2) notifications for candidate replacement services which enable timely operational replacement of services will be processed next, and 3) notifications for new services that can only lead to optimizations will be processed last. This is a measure for dealing with high- frequency service emergence and/or update rates, which can stress the resources of RSDF.
An approach for executing changes in a service-based application can be performed by stopping the system, making the necessary changes, and resuming the system [15]. Other approaches use binding partner links during execution time of the system [11]; proxy services as placeholders for the services in a composition, instead of having concrete services referenced in the system [13], [12]; or even an adaptation layer based on aspect-oriented programming with information about alternative services [14]. In this framework, we use proxy services to support changes in the service-based application during execution time, therefore avoiding changes in the original application specification. More specifically, RSDF maintains a record associating the logical references to services within an application with pointers to the actual services used and when a call is made by the application the logical reference is resolved to the actual endpoint where the service can be called.

4.3 Module Information

Module1:
Design the Graphical User Interface (GUI) and database for our system. Login and registration of user.

Module2:
Registration of new services and initialization of data.
Register to the framework a list of service endpoints that it wishes to use along with one query for each such service that should be used for discovering alternatives to it.

Module3:
On The Go News Application.
On-the-go-News allows its users to request and receive news.
To do so, the application offers services allowing users to:
1. Search for certain news.
2. Display news about a topic from various sources.
3. Pay for news if it is 'paid news'.

Module4:
Runtime Service Discovery Framework (RSDF):
Building various components of Runtime Service Discovery Framework (RSDF) such as Service Requester, Service Listener, Execution Engine, service Matchmaker, Service registry intermediately etc.

5. RESULTS

Below are the web services that we have retrieved when we search for it by considering the structural , behavioural, quality, location parameters. The user can also subscribe for the web service and update the same.


6. CONCLUSION
In this paper, we have seen a framework for dynamic service discovery in which candidate services are used to replace the existing services of service based application. This framework also overcome the problem of various scenarios for eg. Malfunctioning or unavailability of services, etc. In both pull and push query execution modes, a service is matched against a query based on computation of distances between query and service specifications. The framework uses complex queries expressed in an XML-based query language named SerDiQueL. The language allows the representation of structural, behavioral, quality, and contextual characteristics of services and applications.
REFERENCES
'
Implementation of Runtime Web Service Discovery

Abstract' During the execution of service based application there is an important issue for replacing the service in them which fails to satisfy the current requirement or is no longer present. Identification of services based on different service parameters such as structural, quality, behavioral and contextual leads to effective runtime discovery of service. So in this paper, we are introducing a framework that support runtime services discovery. The framework supports two modes of execution of query for service discovery namely pull and push mode. In pull mode (reactive way), queries are executed when a need for finding a replacement service arises (for example: unavailability or malfunctioning of service, emergence of new service, changes in structure functionality etc.).In push mode (proactive way), execution of query is carried out in parallel to the service-based system execution. Hence, if there is a need to replace a service in service based application, push mode of execution of query makes it possible to avoid interruptions in the operation of application. Both types (i.e., pull and push) of queries are specified in a XML based query language called SerDiQueL. SerDiQueL is the language that allows the representation of behavioral (functionality), structural (interface),quality, and contextual conditions of services to be identified. So in this paper, we are going to discuss the runtime service discovery framework.
.

Index Terms' Web Service Discovery, Web Services, XML, Dynamic Service Discovery.

I. INTRODUCTION
Services are nothing but entities that are owned by a third party in a service based application. Such services are helpful in creating the dynamic business processes. Due to various changes in market, it is necessary to identify the services that will directly fulfill the need of user by providing the appropriate quality and functional features of service based application .The process of identifying such services is called as service discovery. Several researches and approaches has been developed to support service discovery, classified as static[1], [2], [3], [4] and dynamic [5], [6], [7], [8] approaches. The services which are identified during the application development and prior to execution comes under static approach while the services that are identified during the execution of the application comes under dynamic approach. There are various scenarios where we need to replace the service during the execution of application.
Following are the scenarios due to which we need to replace the services:
1) Due to service unavailability , service malfunctioning.
2) Changes in the interface, behavioral, quality, service context in the application due to the service which no longer fulfill its task.
3) The emergence of new services that which fulfill the task in better way than the existing service.
4) Changes in the application context due to services which is used no longer fulfill its task.

The above scenarios give rise to a question, i.e, how to support the application when the service which is being used is not working properly or stop functioning as desired, as well as changing the application and their services continuously at runtime .To address such questions we require a flexible and dynamic service identification at the runtime of service based application.

Currently most of the approaches uses pull mode of query execution for dynamic service discovery. This mode of query execution is often not effective because the discovery process starts only if the requirement for a new service arises (as in case 1 above) and it may also consume more time to complete, which will affect the application performance and its capability to produce acceptable or
appropriate services (as in case 3 above). Similarly, for cases 2 and 4 above, pull mode discovery would need to wait until the changes that made used services become inadequate arise at runtime, as in case 1. Alternatively, the pull mode of query execution would need to be enhanced for
polling service registries regularly and/or context information resources to identify changes that can create subsequent problems. Such polling would consume resources as even if there is no need to do so it would need to be executed at regular intervals (i.e., in case of emergence of new services ,application environment, in the absence of service context changes or context changes).

Furthermore, existing approaches to service discovery (with the exception of [8]) do not consider different characteristics of the application at the same time when attempting to identify services such as interface(structural), functional (behavioral), quality, and contextual aspects .
To address the existing approaches limitations, we present a web service discovery framework that supports runtime service discovery based on complex queries that can express flexible combinations of structural, quality, contextual and behavioral parameters. These complex queries are specified in an XML-based query language, called SerDiQueL. The framework assumes services that have different descriptions including service behavioral, interface, quality, and context descriptions.

To support entire cases 1 to 4 above and avoid the limitations of traditional mechanisms for polling, our frame-work allows
service discovery based on both push and pull query execution modes. Pull mode query execution is triggered in cases 1 like scenarios above. In push mode, query execution is performed in parallel to the execution of the application using queries. These queries maintain up-to-date sets of candidate replacement services for these services and are associated with specific services in an application . In both pull and push modes, execution of query is based on matching and the computation of service specifications and distances between query.

2. OVERVIEW

In this section, we will be presenting some scenarios for runtime web service discovery and give an overall description of how our framework will be useful to address these scenarios.

2.1 Runtime Web Service Discovery Scenarios

Various scenarios regarding runtime service discovery can be identified in reference to a mobile service based application called On-the-go-News[10] .

On-the-go-News allows its users to request and receive news from different sites from their mobile phone. To do so, the application offers services allowing users to:

7. search for news topics and choose the source from where they want to receive the news,

8. display news about a topic from different sources,

9. create customized on-the-fly 'magazines' or with data from several different news sites,

10. flip through articles in a customized magazine from several sources,

11. obtain and pay for the nonfreely available information, charging the amount in the user's phone bill at the end of the month, and

12. see the new balance of their phone bill after using the application for 5.

On-the-go-News uses an external service, called SService, which searches different news sites to identify news about specific topics, and another service, called SCustMag, which enables the amalgamation of news and their appearance in an on-the-fly magazine.

After receiving a request for news on a specific topic one runtime service discovery scenario can arise , on-the-go-News is not able to contact SService due to which the latter service is unavailable (Case 1). In this case, the application will need to identify a new service to replace SService. After the new service is identified and bound to on-the-go-News,the user who issued the request will start receiving the requested information from various sites.

A second scenario may arise if a user who wants an on-the-fly magazine about climate change on his/her mobile phone and created such a magazine using SCustMag starts getting a slow response from SCustMag as the service is used by many different users simultaneously (Case 2). In such cases, an alternative service for SCustMag with acceptable response time will need to be identified and bound to on-the-go-News.

A third scenario arises when, while a user of on-the-go-News is traveling by train, he loses access to the service that displays and supports flipping through news (i.e., a service
called SDisFlip) since SDisFlip cannot be accessed at his current location. This change in the location of on-the-go-News

(Case 3) requires searching for an alternative service that could be used in the user's current location.

A fourth scenario arises when a new service that allows payments by debiting the user's bank account and credit card payments instead of charging the user's phone bill becomes available (Case 4). If flexibility in payment is desirable in on-the-go-News, the new service should be bound to the application.

2.2 Framework Support

Fig.1 Architecture of various components in runtime service discovery framework
Runtime service discovery consists of web service user interface, application data server, service data server, service analyzer, request web service, match finder, service catalog system, external service catalogs.
The web service user interface is used by the user to query for a web service which provides access to framework. It represent request entry point and response exit point.
The request web service block offers various functionalities. It instantiates the service queries to be executed by the matchfinder based on the various situations, receives responses from matchfinder, collect, organize the result and send it to the web service interface etc.
The matchfinder is responsible to parse the constraints of a query and evaluate these constraints against service specifications in the various service registries. The matchfinder
consists of two stages filtering and ranking.
The service catalog system provides the use of different service registries. Its main aim is to provide an interface, which allows the matchfinder to access services from various different type registries.
The service data server and application data server enable context information is to be subscribed. They also allow to spread context information of the services and application environment.
The service analyzer provides the information about the new service available or information about changes in structural, behavioural, quality characteristics of existing services of an application.


3.WEB SERVICE DISCOVERY QUERY LANGUAGE
A runtime service discovery query may contain different criteria, namely: 1) constraints, specifying additional conditions for the service to be discovered; 2) structural criteria, specifying the interface of the required service; 3) behavioral criteria, specifying the functionality of the required service; and. The latter conditions may refer to quality aspects of the required service or interface characteristics of services that cannot be represented by the standardized forms of structural descriptions used in the framework. Examples of constraints referring to quality characteristics of services may concern the maximum response time or cost to execute a certain operation in a service.
The constraints in a query can be contextual or non-contextual. A non-contextual constraint is concerned with static information, while a contextual constraint is mostly concerned with information that changes dynamically during the operation of the service-based application or the services that the application deploys. The constraints can be hard or soft. A hard constraint must be satisfied by all discovered services for a query and is used to filter services that do not comply with them. Soft constraints do not need to be satisfied by all discovered services, but are used to rank candidate services.
To specify runtime service discovery queries, we have developed an XML-based language,called SerDiQueL.
SerDiQueL allows the specification of all the structural, behavioral, quality, and contextual characteristics required from the services to be discovered. An earlier version of SerDiQueL was presented in [9]. The new version of the language that we present in this paper enables the specification of the required behavior of a service using behavioral conditions rather than a full BPEL model of service behavior as in the original version.

3.1 Structural Subquery

The structural subquery describes the interface of the required service. Structural subqueries in SerDiQueL are specified using WSDL [16]. The use of WSDL in this case is due to its wide acceptance as a service interface description
language. In addition, during runtime service discovery, any replacement service that might be identified for an existing service in a service-based application will need to conform to the interface of the existing service. A structural subquery in SerDiQueL is specified as the WSDL specification of the service to be replaced.

3.2 Behavioral Subquery

Behavioral subqueries in SerDiQueL support the specification of
1. the existence of required functionalities in a service specification,
2. the order in which the required functionalities should be executed by the service,
3. dependencies between functionalities (e.g., a functionality realized by an operation always requires the existence of a functionality of another operation),
4. preconditions, and
5. loops concerning execution of certain functionalities. Behavioral subqueries are expressed by elements that are similar to temporal logic operators.

3.3 Constraint Subquery

A constraint subquery in SerDiQueL is defined as a single logical expression, or a conjunction/ disjunction of two or more logical expressions, combined by logical operators AND and OR, or a negated logical expression. Query constraints have four attributes:
1. name, specifying the name of the constraint;
2. type, indicating whether the constraint is hard or soft;
3. weight, specifying the significance of the constraint as a real number in the range [1.0, 0.0]; and
4. contextual, indicating whether the constraint refers to a noncontextual or contextual feature of a service.
The weight of a constraint is used to prioritize it against other soft constraints when inexact matches are found in query evaluation. A constraint subquery whose contextual attribute is true contains ContextOperand elements. When this attribute is set to false, the query may only contain NonContextOperand elements.

A logical expression is defined as a condition, or logical combination of conditions, over elements or attributes of service specifications or context aspects of operations.

Conditions are defined as relational operations expres- sing comparisons between the values of two operands (operand1 and operand2). The supported comparisons are specified by elements expressing the relational operations equalTo, notEqualTo, lessThan, greaterThan, lessThanEqualTo, greaterThanEqualTo, and notEqualTo. These operations have the normal respective meanings for comparisons between their operands. The operands can be noncontextual operands, contextual operands, arithmetic expressions, or constants. A noncontextual operand (i.e., an element of type Non- ContextOperand) has information about the name and the type of the service specification facet from which the operand's value will be retrieved during the constraint evaluation, and an XPath expression indicating elements and attributes in the service specification facet. The evaluation of this XPath expression will provide the value of the noncontextual operand during the evaluation of the enclosing constraint. Hence, constraints can be specified against any element or attribute of any facet in the description of a service in a registry.

4. WEB SERVICE DISCOVERY PROCESS

Service Discovery process contains following Process:

4.1 Query Matching Process

Matching between queries and services is executed in two stages: the filtering stage and the ranking stage. In the filtering stage, only the hard non contextual constraints of a query are evaluated against service specifications and the candidate services that comply with these constraints are identified.

The ranking stage has three sub stages.
In the first of these sub stages, the structural and behavioral parts of a query are evaluated against the services maintained by the filtering stage and a structural-behavioral partial distance between each of these services and the query is computed.
In the second sub stage, the soft non contextual constraints of the query are evaluated against each candidate service and a soft non contextual partial distance is computed for each such service.
Finally, in the third sub stage, the contextual constraints of the query are evaluated against the candidate services and a contextual partial distance is computed for each candidate service.
At the end of the ranking stage, the partial distances computed for each service are aggregated into an overall distance and only services whose distance to the query is below a certain threshold are maintained.

4.2 Pull and Push Query Execution

In the pull mode of query execution, the service requester of RSDF (see Section 2.2) invokes the service matchmaker to execute a query. The service matchmaker executes the query and maintains services whose distance from the query does not exceed a specific threshold. The set of maintained services is sorted in ascending distance order and returned to the client application for further action. In the push mode of query execution, the client application subscribes to RSDF the services it deploys and a query Q for each of them. Based on the subscribed query for each service S, RSDF initially retrieves a set of services Set S that could replace S (if necessary) by executing the query as in the pull mode and, subsequently, maintains an up-to-date version of Set S as changes in the descriptions and context of the services and/or their application's environment are notified to it. Set S includes only services whose overall distance from the query subscribed for S does not exceed a given threshold and is sorted in ascending distance order. It should be noted, however, that although Set S includes candidates that could replace S, the replacement of S in the application does not take place right after the first or subsequent modifications of Set S. This is because an immediate replacement might be inappropriate. In cases, for example, where the service S is executing some transaction on behalf of the application at the time when a new better service is found, no replacement should take place. In RSDF, the decision to stop the execution of the application to replace a service for which a better alternative service has been found is based on replacement policies. Policies are associated with the different functional roles that are assumed by services in the application and specify if the service that is currently bound to a role should be replaced immediately when a better service is found, after the termination of a specified computation, or after the application terminates. The push mode service discovery process that maintains the set Set S of candidate replacement service for a given service S covers four different cases. These are cases where:
1. S becomes malfunctioning or unavailable (Case A),
2. there are changes in the structure, functionality, quality,or context of any service in Set S or S(CaseB),
3. there are changes in the context of the application environment (Case C), or
4. new services become available or existing services have their characteristics modified (Case D). In the following, we discuss the push execution mode for each of these cases.

Case A: In this case, the service S is replaced by the first service S0 in Set S. By virtue of the process of maintaining this set, S0 is guaranteed to have the smallest distance to query Q associated with S. Following the replacement, S0 is removed from Set S.
Case B: Suppose S0 is a service that is currently bound to the application or another service in its associate replacement Set S. This case arises when new versions of the structural, functional, quality, or context facets of S0 become available in a service registry. When a change in some characteristic of S0 occurs, the new versions of the changed facets or service context information are evaluated against query Q to verify if S0 still matches the query. The new overall distance between Q and S0 is also calculated. If S0 is a candidate replacement service in Set S, it remains in it only if the new distance between S0 and Q is below the threshold distance. Also, the relevant position of S0 in Set S might change due to the new distance. Following this, if S0 becomes the best replacement service in Set S, S0 will replace S when the relevant replacement policy allows it. If S0 is the service currently deployed by the application but is no longer the best option according to its new distance from Q, it will be replaced by the first service in Set S as soon as the replacement policy permits the change. Furthermore, if the new distance between S0 and Q makes S0 a noneligible member of Set S, S0 will be removed from Set S and its subscription will be removed from RSDF. Also, a new replacement service for S0 in Set S will be located.

Case C: In this case, a value in a context constraint in query Q is modified and a new query Q0 needs to be created to reflect the new context value. The service S that is currently bound to the application needs to be evaluated against the new context constraint in Q0. IfS does not match the new query Q0, the services in Set S will be evaluated against Q0 and a new version of Set S may be generated. This is necessary for identifying the service S0 in Set S with the best fit to Q0 and bind it to the application so that it can continue its execution while trying to find new services that match Q0 from the service registries. Note that S0 might not have the best fit with Q0 given all available services in the registry. However, the use of the best service S0 in the current Set S in this case is acceptable as it will allow the application to continue. Moreover, the context constraints are soft constraints used for ranking services with respect to queries, rather than filtering them out. Following the use of S0, RSDF will do an exhaustive search in registries (pull mode) to update Set S based on Q0. The same exhaustive search will be used if no service in the current Set_S matches Q0. Following the update of Set S, if a new service in it is better than S0, it will replace S0 subject to the replacement policy.

Case D: This case arises when new services appear in registries for the first time or descriptions of existing services in registries that were not matching a query Q before change (the latter services are not covered by Case C since, as they are not members of Set S, the changes in their characteristics will not be notified to RSDF through the existing subscriptions for Set S). Once RSDF is notified of new or updated service descriptions, it evaluates them against query Q for each service S deployed in the application. Depending on the result of this evaluation, the new/updated service may become member of Set S or even replace S in the application, subject to the criteria of the replacement policy for S. In the approach, the replacement policy used in CasesA-D described above takes into consideration the position of a service S that may need to be replaced with respect to the current execution point of the service-based application. More specifically, the replacement policy considers the cases in which changes need to be performed so that the application can continue its operations, changes can wait to be performed after the current execution of the application, and no changes are required. For a replace- ment policy, the approach considers three different positions, namely:
1. not in path: when service S is not in the current execution path of the application, S appears in a different branch of the application's execution path or before the current point in the execution path; 2. current: when service S is in the current execution point of the application; 3. next in path: when service S is in the current execution path of the application and will be invoked some time in the future. When the position of a service S to be replaced is not in path, S is marked for replacement when S is accessed in a future execution of the application; when the position of S is current, S needs to be replaced; when the position of S is next in path, S is marked to be replaced when S is accessed in the current execution. It should be noted that notifications about changes in services S0 falling in case B are dealt with according to their priority. More specifically, the service matchmaker main- tains three notification queues'a high-, medium-, and low- priority queue'and notifications for services bound to the application are placed at the end of the high-priority queue, notifications for services in some replacement set (Set_S) are placed in the medium priority queue, and notifications for other services are placed in the low-priority queue (i.e., the queue of new services). Also, the services with notifications in the high- and medium-priority queues are marked as 'unsafe' to prevent the application from using them before the notifications that have arrived for them are processed. Furthermore, if a notification N0 arrives for a service for which there is already an earlier notification N in the same queue which has not been processed yet, the facets identified in N0 are added to those of N in the queue rather than appending N0 to the end of the queue. Hence, all the unprocessed notifications of a service are merged. Matchmaker processes notifications from lower priority queues only if there are no notifications in higher priority queues. This heuristic ordering of processing ensures that: 1) Notifications regarding the services which are currently bound to the application and are the most critical for it are processed first, 2) notifications for candidate replacement services which enable timely operational replacement of services will be processed next, and 3) notifications for new services that can only lead to optimizations will be processed last. This is a measure for dealing with high- frequency service emergence and/or update rates, which can stress the resources of RSDF.
An approach for executing changes in a service-based application can be performed by stopping the system, making the necessary changes, and resuming the system [15]. Other approaches use binding partner links during execution time of the system [11]; proxy services as placeholders for the services in a composition, instead of having concrete services referenced in the system [13], [12]; or even an adaptation layer based on aspect-oriented programming with information about alternative services [14]. In this framework, we use proxy services to support changes in the service-based application during execution time, therefore avoiding changes in the original application specification. More specifically, RSDF maintains a record associating the logical references to services within an application with pointers to the actual services used and when a call is made by the application the logical reference is resolved to the actual endpoint where the service can be called.

4.3 Module Information

Module1:
Design the Graphical User Interface (GUI) and database for our system. Login and registration of user.

Module2:
Registration of new services and initialization of data.
Register to the framework a list of service endpoints that it wishes to use along with one query for each such service that should be used for discovering alternatives to it.

Module3:
On The Go News Application.
On-the-go-News allows its users to request and receive news.
To do so, the application offers services allowing users to:
1. Search for certain news.
2. Display news about a topic from various sources.
3. Pay for news if it is 'paid news'.

Module4:
Runtime Service Discovery Framework (RSDF):
Building various components of Runtime Service Discovery Framework (RSDF) such as Service Requester, Service Listener, Execution Engine, service Matchmaker, Service registry intermediately etc.

5. RESULTS

Below are the web services that we have retrieved when we search for it by considering the structural , behavioural, quality, location parameters. The user can also subscribe for the web service and update the same.


6. CONCLUSION
In this paper, we have seen a framework for dynamic service discovery in which candidate services are used to replace the existing services of service based application. This framework also overcome the problem of various scenarios for eg. Malfunctioning or unavailability of services, etc. In both pull and push query execution modes, a service is matched against a query based on computation of distances between query and service specifications. The framework uses complex queries expressed in an XML-based query language named SerDiQueL. The language allows the representation of structural, behavioral, quality, and contextual characteristics of services and applications.
REFERENCES
[1] D. Grirori, J.C. Corrales, and M. Bouzeghoub, 'Behavioral Matching for Service Retrieval,' Proc. Int'l Conf. Web Services, 2006.
[2] U. Keller, R. Lara, H. Lausen, A. Polleres, and D. Fensel, 'Automatic Location of Services,' Proc. European Semantic Web Conf., 2005.
[3] L. Li and I. Horrock, 'A Software Framework for Matchmaking Based on Semantic Web Technology,' Proc. Int'l Conf. World Wide Web, 2003.
[4] Z. Shen and J. Su, 'Web Service Discovery Based on Behavior Signatures,' Proc. Third Int'l Conf. Service Computing, 2005.
[5] S. Cuddy, M. Katchabaw, and H. Lutfiyya, 'Context-Aware Service Selection Based on Dynamic and Static Service Attributes,'

Proc. IEEE Int'l Conf. Wireless and Mobile Computing, Networking, and Comm., 2005.
[6] C. Doulkeridis, N. Loutas, and M. Vazirgiannis, 'A System Architecture for Context-Aware Service Discovery,' Electronic Notes of Theoretical Computer Science, vol. 146, no. 1, pp. 101-116, 2006
[7] H. Niu and Y. Park, 'An Execution-Based Retrieval of Object-Oriented Components,' Proc. 37th ACM Southeast Regional Conf.,1999
[8] S. Singh, J. Grundy, J. Hosking, and J. Sun, 'An Architecture for Developing Aspect-Oriented Web Services,' Proc. Third European Conf. Web Services, 2005.
[9] G. Spanoudakis, K. Mahbub, and A. Zisman, 'A Platform for Context-Aware RunTime Service Discovery,' Proc. IEEE Int'l Conf. Web Services, 2007.
[10] G. Spanoudakis, A. Zisman,James Dooley,Igor Siveroni 'Proactive and Reactive Runtime Service Discovery:Framework and its evaluation. '
[11] I. Horrocks, P.F. Patel-Schneider, and F. van Harmelen, 'From SHIQ and RDF to OWL: The Making of a Web Ontology Language,' J. Web Semantics, vol. 1, no. 1, pp. 7-26, 2003.
[12] J. Kim, J. Lee, and B. Lee, 'Runtime Service Discovery and Reconfiguration Using OWL-S Based Semantic Web Service,' Proc. Seventh IEEE Int'l Conf. Computer and Information Technology, 2007.
[13] L. Baresi, C. Ghezzi, and S. Guinea, 'Towards Self-Healing Compositions of Services,' Studies in Computational Intelligence, vol. 42, Springer, 2007
[14] O. Moser, F. Rosenberg, and S. Dustdar, 'Non-Intrusive Monitor- ing and Service Adaptation for WS-BPEL,' Proc. 17th Int'l World Wide Web Conf., 2008.
[15] D. Ardagna, M. Comussi, E. Musi, B. Pernici, and P. Plebani, 'PAWS: A Framework for Executing Adaptive Web-Service Processes,' IEEE Software, vol. 24, no. 6, pp. 39-46, Nov./Dec. 2007.
[16] 'WSDL,' http://www.w3.org/TR/wsdl, 2013.

Source: Essay UK - http://www.essay.uk.com/free-essays/information-technology/runtime-web-service.php



About this resource

This Information Technology essay was submitted to us by a student in order to help you with your studies.


Search our content:


  • Download this page
  • Print this page
  • Search again

  • Word count:

    This page has approximately words.


    Share:


    Cite:

    If you use part of this page in your own work, you need to provide a citation, as follows:

    Essay UK, Implementation Of Runtime Web Service Discovery. Available from: <https://www.essay.uk.com/free-essays/information-technology/runtime-web-service.php> [25-05-20].


    More information:

    If you are the original author of this content and no longer wish to have it published on our website then please click on the link below to request removal: