WSDATool : A Novel Web Service Developer Assistance Tool Using a New Complementary Service Publishing Method

Web service technology (WST) is a service-oriented architecture implementation framework that makes designing component-based internet applications possible. At present, many providers offer their services as web services. Current WST suffers from the lack of an integrated tool to assist web service developers. In WST, the services are published publicly, and their descriptions are stored in service directories. These descriptions contain valuable information about the work of different software teams throughout the world. However, with the increasing number of web services, searching for services is difficult and time-consuming. Furthermore, in current service directories, there is a little knowledge about the services, and extraction of useful information to be utilised by developers is not easy. In this paper, in order to increase the knowledge of what is available in service directories, a structure is presented by interlinking WST entities by using some defined semantic relations. The proposed structure provides a framework and a tool named WSDATool to develop new web services using information from published services or to refine current published web service descriptions. In experiments, services designed with the assistance of the WSDATool are more coherent and well designed.


Introduction
Software systems are currently very dependent on software components.Service-oriented architecture is one of the best practical architectures for component-based systems.In this architecture, service providers present some services to be utilised by users and applications.Web service technology (WST) is one of the solutions provided by this architecture.A web service is a software component that presents an API accessible via the web.Hoffmann et al. (2007) by investigating 15 million programmer queries from the MSN search engine, showed that 34.2 percent of programmers' queries involved finding suitable application program interfaces (APIs).By the same way, web service developers search the Internet to find the information they need.Anyway, one of the main problems with developing web services is the lack of an assistance tool to help developers create coherent and easy-to-discover web services.Furthermore, most service descriptions are provided by integrated development environment IDE tools automatically.The generated service description are full of anti-patterns and bad coding practices (Crasso, Mateos, Zunino, & Campo, 2010;Crasso, Rodriguez, Zunino, & Campo, 2010;Juan Manuel, Marco, Alejandro, & Marcelo, 2010; Juan Manuel Rodriguez, Zunino, & Campo, 2010;Lu et al., 2010;Mateos, Crasso, Zunino, & Campo, 2010;Rodriguez, Crasso, Zunino, & Campo, 2009, 2010;Sneed, 2010) that reduce the chance of a service being discovered correctly (Juan Manuel et al., 2010).This situation motivated the current study in which a tool for overcoming this problem is proposed.The idea is to utilise current published web services to assist web service developers.The published services stored in service directories contain valuable information that can be used to help developers develop more powerful and coherent web services.This information is the result of work done by different software teams throughout the world.
However, extracting useful information from service directories is a difficult and time-consuming process.With the increasing number of web services, searching for services is difficult and time-consuming.For example, at the time this paper was being written, Seekda (a web service crawler available at http://webservices.seekda.com/)had indexed 28,606 working web services from 7,739 providers.Furthermore, service directories only offer the simple similarity searching operation.Even the enhanced similarity matching operation is very time-consuming, and in the best situation, it returns services that are similar to the user's request.
To assist developers, we need to extract more information from service directories and organise them in a knowledge database.By querying these knowledge based service directories, developers can extract required information.Extraction of information cannot be accomplished using the simple searching APIs provided by traditional service directories or enhanced similarity matching operations.To date, efforts to enhance service directory search operations have mainly concentrated on the precision of the similarity matching operation.Examples include semantic descriptions of web services (Iqbal, Sbodio, Peristeras, & Giuliani, 2008), similarity matching algorithms based on semantic descriptions (Plebani & Pernici, 2009), and similarity calculation algorithms based on ontology (Klusch & Kapahnke, 2009).These efforts have not increased the knowledge about the contents of service directories and cannot assist web service developers.
In this paper, a method of publishing web services by interlinking web service entities based on the concept of semantic relations is introduced.Some semantic relations are defined and an interlinked graph of web service entities is constructed.A software tool is developed on top of this structure to assist web service developers and named WSDATool.Services designed with the assistance of the proposed system are more coherent, and free from anti-patterns.WSDATool can also be used to refine current service descriptions.
The main contributions of our work are as follows:  We present a structure for increasing the knowledge about the contents of service directories.In this structure, the WST entities are interlinked based on semantic relations that may exist between them.This part is an extension to our previous work in (Fardin, Naser, & Ali, 2012).


We present a method to extract knowledge from interlinked structure and an expert agent to assist developers using tis knowledge.


We present a novel tool to assist web service developers based on the presented structure.
The presented system is capable of presenting usable information at a lower cost to system developers, and it helps them develop web services.By lower cost, we mean that the speed of performing high-level queries can be increased by using the presented structure and that these queries are described by a user-friendly language.In this paper, real services were used for expressing the definitions and examples.

Related Work
Several researches (Crasso, Mateos, et al., 2010;Crasso, Rodriguez, et al., 2010;Juan Manuel Rodriguez et al., 2010;Lu et al., 2010;Mateos et al., 2010;Rodriguez et al., 2009Rodriguez et al., , 2010;;Sneed, 2010) are investigated the problems of current registered web service descriptions and the effect of these problems on service discovery and usability.The results of these researches are mainly list of anti-patterns that should be removed in order to improve service usability.
Several tools have been developed to assist in the annotation of web services.Dietze et al. (Dietze, Yu, Pedrinaci, Liu, & Domingue, 2011) created an editor to edit and search for linked-data based services.Linked-data based services are a method of describing web services by connection service descriptions to linked-data (Bizer, Heath, & Berners-Lee, 2009) cloud entities.Maleshkova et al. (2009) proposed an editor named SWEET to annotate semantic web services.This editor is useful for annotating web services, and it creates an HTML description of the service.Birukou et al. (2007) presented a method to assist system developers.In this method, for each user request, the invocation and performance of relevant services are monitored.By monitoring the performance of services, QoS can be achieved in the proposed system.At first, operational data are modelled.Then, by using the semantic similarity between the user request and the registered activities, the system makes recommendations.
Recommender systems have been attracting the attention of software researchers.Several methods based on recommender systems are presented for extracting information and for helping service developers.Robillard et al. (2010) provide an overview of available recommender systems that assist application developers.These methods can be divided into the following two types: 1) Recommender systems (Bhaskar, Claudia, Avare, Claudio, & J., 2004;Birukou et al., 2007;Blake & Nowlan, 2007;Ichii, Hayase, Yokomori, Yamamoto, & Inoue, 2009;Sellami, Tata, Maamar, & Defude, 2009;Shripad & V., 2005;Zheng, Ma, Lyu, & King, 2009): These systems try to discover the most likely web services based on the behaviour of other users and by preserving the system history.
2) Search engines (Dong, Halevy, Madhavan, Nemes, & Zhang, 2004;Vu, Hauswirth, Porto, & Aberer, 2006): These systems try to discover the best web service candidate based on the similarity of a user query to registered web services and the aid of a ranking algorithm.
The output of both methods is the most similar service corresponding to the user request.Although these methods were designed to assist service consumers, they can also be used by service developers.
These systems can be used by web service developers to create better services.Ichii et al. (2009) present a recommender system based on collaborative filtering to propose software components.However, Zheng et al. (2009) propose a collaborative filtering system for web service recommendations based on QoS.Both presented methods in (Ichii et al., 2009;Zheng et al., 2009) utilise the history of user activity and present a method for expressing the similarity between users.Blake and Nowlan (2007) present a method for web service discovery and candidate recommendation based on syntactical matching.For this purpose, search algorithms, service ranking and syntactical similarity matching are used.Fardin et al. (2012) construct an interlinked graph of WST entities named Semantic Interlinked Graph in the service directories in order to augment service directories with knowledge.In this graph, entities are interlinked using some sort of semantic relationships that may exist between them.They shows how these relations can be formally defined using ontology, implemented using RDF, and extracted using the SPARQL language.Furthermore, they show how some limitations of the current service directories such as service versioning and registering composition plans can be resolved.
Calculation of similarity between WST entities are one of the important task in service discovery operations.Plebani and Pernici (2009) presented a method to measure the similarity between two web services.This method is used for the replacement of services in case of failure.They propose a formula in which the similarities between web service operations are calculated based on the similarity between arguments name and their data types.Also they extend their method calculate the similarity between semantic web services too.Crasso et al. (2008) present a method to calculate similarity of user query and web services as the angle between two vectors of words.

Structures, Methods and Tool
The core element of this work is a Semantic interlinked graph (SIG) of WST entities.In this structure, a graph of web service entities is constructed based on some semantic relation between them.SIG is developed in previous work in (Fardin et al., 2012) and we enhance it in this paper make it usable for developers assistance tool.This structure is a complementary facility for service directories that increases the knowledge about the contents of service directories.By using this structure, high-level queries are possible.The following section presents the construction of SIG; its features are described in the following subsections.

Extraction of WST Entities
The first step in using the information stored in service directories is to present a way to extract, represent, and manage the knowledge in it.To assist service developers, the system must determine which web services are related to currently under developing web service and how other service providers develop, enrich and document their web services.
For this reason, this paper presents a structure that stores this type of knowledge by interlinking web service entities based on semantic relations that may exist between them.Therefore, we must first formally identify the involved entities.Second, the semantic relations between these entities must be defined and formulated.Third, the instances of these relations in service directories must be discovered, and a method of representation must be presented.
Each service description involves a brief piece of documentation about its related web service and specifies the operations that the web service offers.Web services present one or more functions that are called operations.
Operations may take some input from the user, create some process based on these input data, and produce some results as output.So, Four type of entities can be distinguished, namely, Web Service, Operation, InputArgument, and OutputArgument in web service descriptions.The ERD diagram of Figure 1 shows the relationships and cardinality between these entities.

Constructing the SIG
In the previous section, the related entities were identified, and a unique identifier was defined for them to prevent ambiguity.In this section, an extension of the semantic relations introduced in (Fardin et al., 2012) are defined.By "semantic relation", we mean a relationship that is defined formally by using semantic technology.
Based on the ERD diagram in Figure 1, Table 1 present the semantic relations between four entities, namely, Service, Operation, InputArgument and OutputArgument.The set of X shows the possible semantic relations between these entities.This set is given by: and is shown as the union of two sets to clear the reversal of each semantic relation.
Table 1 shows a graphical representation, a short explanation and a real-world example for each of the defined semantic relations.All of the real-world examples were extracted from Seekda, a web service crawler available at http://webservices.seekda.com/.Some sort of semantic relations may exist between the instances of each entity.For example, the semantic relations that may exist between web services are introduced in (Fardin et al., 2012) by some real examples.
Based on the findings in (Fardin et al., 2012), by investigating real-world web services, the set of  shows the possible semantic relations between web services, and is given by: ={is Similar To, is New Version Of, is Richer Than, is Composed Of } {is Similar To, is Old Version Of, is Weaker Than, is In Plan Of} Furthermore, each service presents one or more operations.Operations may have some sort of semantic relationship between them.Based on the findings in (Fardin et al., 2012), by investigating real-world web services, the set of shows the possible semantic relations between operations.We extend this set with two more relations shown in Finally, each operation may have some input and at least one output argument.The extracted semantic relations between arguments are shown in Table 3.
The set of  showing the possible semantic relations between arguments of service operations is described in

Assistant System Architecture
Suppose some web services have been published in the network.The description of these services is preserved in the service directory.In order to create, preserve and use the SIG, certain processes have been created in the service directory.Figure 3 shows the general architecture of the system.The components of the assistant system are Ontology, Inference Engine, SPARQL Endpoint, RDF Repository, Monitoring Service, Matching Service, and service descriptions.The assistant unit is the access point for developers and helps them develop new web services.
Figure 3. Architecture of the Assistant System Each component of the system has been explained individually below: Ontology: First, the semantic relations are defined formally by means of an ontology.With the aid of the ontology, the entities or concepts, the semantic relations, the cardinality constraints and the mutual exclusiveness of the semantic relations are defined.The following are examples of a cardinality constraint: "An Operation is presented by only one Service" or "A Service may present one or more Operation".For an example of a mutually exclusive constraint, isSimilarTo and isRicherThan cannot be established between two operations at the same time.For this porpose, we extend OWLS-SD (Fardin et al., 2012) and develop it with new relations introduced in this paper.OWLS-SD is a semantic language based on RDF.The goal of OWLS-SD is to create machine-readable ontologies.
Matching Service: finding the similarity between arguments, operations and services in order to extract relevant information in the service directory, is the responsibility of this service.This process extracts the semantic relations between WST entities.This service is implemented as described in (Plebani & Pernici, 2009).The matching service returns the degree of similarity between two entities as a number in the interval [0,1].

RDF Repository:
The relations founded by Matching Service are stored in RDF Repository.Similar to our previous work in (Fardin et al., 2012), this paper selects the RDF language as the language used to implement the SIG.RDF triples are simple but strong and efficient tools for encoding knowledge in semantic environments.
Each RDF triple connects two entities by specifying the relationship between them.The relationships between entities are semantic relations that are defined by the constructed OWLS-SD ontology.By using RDF triples, the SIG is implemented in this RDF store.
Monitoring Process: Providers publish their services and register the service descriptions in the directory.To make these newly added services usable by the assistant unit; they must be added to the semantic interlinked graph.Discovering new registered services and joining these services to the graph is the responsibility of this process.

SPARQL Endpoint:
In order to use constructed SIG in the presented tool and extract useful knowledge to assist developers, some functions should be defined and implemented in the proposed system.In these functions the RDF repository must be queried.A good choice to use for querying the RDF repository is the SPARQL language.SPARQL is a protocol and also a language to query RDF databases through the internet.In addition, SPARQL queries are human readable, and users can provide high-level queries in SPARQL to extract knowledge stored in the RDF repository.So in the SPARQL Endpoint, we define and implement the required functions as follows.
First, a mathematical relation is defined that retrieves a set of services for a given service and a semantic relation.This relation can be defined as follows: where  For this purpose, the following mathematical relation is defined to extract information about a given operation and semantic relation: where 1 2 { , ,..., } is the finite set of operations presented by the service and As an example, the statemen ' ' ( , ' ' ) GetWeatherData g isSimilarTo GetCityForecastByZip  declares that an operation called ' ' GetWeatherData has the isSimilarTo relation with an operation called ' ' GetCityForecastByZip .Figure 5 shows the graph representation of this instance.
is the set of the arguments of all the operations.The mathematical relation h is defined to extract information about a given argument and semantic relation: Inference Engine: This process is responsible for checking the constraints of the system based on the extended OWLS-SD ontology.Also, it tries to discover and establish new semantic relations based on the properties of them.
Assistant Unit: This component implements the procedures assisting developers by extracting and presenting useful information from the SIG.The assistant unit receives input from service developers by providing a web-based user interface.
The general activity of service directory is described in Algorithm 1 as follow: The start-up of the system and initialization of it is performed by this algorithm too.

WSDATool and Process of Assisting
The architecture of Assistant unit is depicted in figure 6.In general, Assistant unit mine the RDF repository to extract useful patterns and assist developers, based on these patterns and some guidance rules.
Figure 6.The WSDATool processes In the following, the components of assistant unit are described: Miner: this process mine the RDF triples stored in the RDF Repository to extract useful patterns of web service designing.Rules that generated by this unit store in the Knowledge DB.
Knowledge DB: design patterns generated by Mine process are stored in this database.An example of such pattern is: most weather services get city name as input, most airport services get 3 digit airport codes as input.
Expert Agent: This process utilise Knowledge DB to assist web service developers using some guidance rules.These rules answer to the following questions:  Which operations consume these defined inputs, and what is the output of these operations? Which operations generate these defined outputs, and what is the input of these operations? Which operations can be linked to this defined operation to make a composition plan? Which operations are similar to the developed operation?
For an example of using the semantic relations, the operations that have isRicherThan relations with a user-defined operation can be used to improve and enrich the written service.The canBeLinkedTo services can also be used to improve a being developed service to make it more contributable in composition plans.
GUI Agent: Service developers communicate to the GUI agent by means of a web-based GUI.This GUI consists of several tabs.In each tab, the developer obtains assistance from the assistant unit.In the proposed system, the process of assisting begins simultaneously with the process of developing a web service.There is no need to have an initial web service description file or documentation.Developers can start to write a new web service using the tool.
The assisting process for the developer takes place according to the following Algorithm and the sequence of operations is shown in Figure 7.
In each step, developers can see similar or richer entities extracted from SIG and are categorised by the tool in order to redefine them if necessary.Beside recommendation derived from SIG, the tool assist developers in some areas as follow: Clear Naming: Defining the arguments of a web service in an easy-to-understand way is very important to service discovery.For example, in [1], it was shown that 35.9 percent of users querying the MSN search engine to find APIs used queries based on the name of the APIs, the methods and the data types.Therefore, the naming strategy and API design can improve the discovery of services.In (Juan Manuel et al., 2010), investigating some published services showed that approximately 82 percent of services suffer from name ambiguity.
Documentation: Furthermore, Good documentation can facilitate better discovery of provided services.In (Juan Manuel et al., 2010), the effect of good documentation in better service discovery has been shown.This work, by investigating some published services, shows that approximately 68 percent of them are not well documented.
Failure: Defining suitable error message to handle failures helps service consumers understand the source of the error in case of any failures and improves data quality.
Furthermore, users can use the annotating tools, such as Maleshkova et al. (2009) or Dietze et al. (2011), to construct a semantic annotating description for their being developed services.Making a composition plan is another feature of the tool.The user can construct a composition plan by specifying the input parameters and the output parameters.If possible, the tool tries to find a chain of one or more web services consuming input parameters and producing output parameters.For each step in which the tool cannot proceed, it asks the developer to resolve the problem, if possible.The tool can also be used to assist service consumers in making queries.The output of the system can be used as a query to describe the consumer's needs.Table 4 shows aspects that the tool can assist developers.

Results and Discussion
In this section, some aspects of the implemented tool were examined through experimentation.To experiment with the tool, 558 web services were selected from Seekda.Services are chosen so that there exist some similarity between them in order to be able to construct a dense SIG graph.These services are divided into two sets named Directory_set, consisting of 538 services, and Experimental_set, consisting of the remainder of the services.Then, a semantic interlinked graph was constructed using Directory_set.To construct the framework, jUDDI is used as the service directory (downloadable at http://juddi.apache.org/)and Sesame as the SPARQL endpoint (downloadable at http://www.openrdf.org/),both with some modifications.
The monitoring process and the inference process were developed as a system process using the .Net framework.The monitoring process is an event-based process and is activated upon service insertion.
To experiment with the tool, the services in Experimental_set are redesigned using .Net web service developing IDE without considering the description of them.The service descriptions for the written services were gathered in a set called Re IDE sult .At the next step, the services are rewrite using the assistant tool.The service descriptions of the written services from this step were gathered in a second set called Re Tool sult .Therefore, we created three sets of service descriptions, as follows: We inspected different aspects of the usefulness of the tool: the size of the service description file, the amount of documentation included, the number of port types, and the number of failure-handling messages.More failure error handling messages, more documentation, a low number of port types, and a smaller size for the description file are desired for services.This is because these parameters influence service discovery precision and speed and also influence the readability of services.For each service, we calculated how the tool enhanced these parameters.Let us define the following measures:  CalculateSize(s): Get a service description file and return the size in bytes. DocumentationNumbers(s): Return the amount of documentation in the service description normalised by the number of defined entities inside the service according to the ERD diagram of Figure 1. PortNumbers(s): Return the number of defined port types of the service s.  FailureMessages(s): Return the number of defined failure-handling messages of the service s.
The enhancement made by using the tool for a service ses i could be normalised by the following formula: The number of port types, amount of documentation, and failure-handling messages are calculated in this way, and the results of using the tool are depicted in Figure 8.Each figure represents the enhancement made by the tool with respect to a given aspect.In each figure, the enhancements for all 20 web services are shown.The horizontal axes are web services and the vertical axes are the normalised values of the performance parameter.
As shown in Figure 8, in all aspects investigated, the tool was shown to be useful.In failure message enhancements, a zero value means that appropriate failure messages are embedded by the provider of the service.A zero value in port-type enhancements means the provider used the minimum required port-types, so developers could not minimise it.
We constructed several queries using the tool to evaluate the effect of the system on service discovery.For this purpose, the refined services in the Re Tool sult set were returned to the original data set that was collected from Seekda.The experiment shows that the degree of similarity between created queries and services in Re Tool sult is greater than the degree of similarity between created queries and services in Set Experimental .
Finally, in the worst case in which no similar arguments, operations or services exist for our being developed services, the system can be useful in developing a more unambiguous, well-documented, compact and anti-pattern-free web service.

Future Works
In this paper, a graph of WST entities is constructed.These entities are interlinked based on the semantic relations that are defined between them.This graph of entities is implemented by RDF triples that make it possible to interlink all WST entities around the world.The heart of the system is the ontology, which makes it possible for all processes to have the same understanding of the network.RDF triples use this ontology to express the relation between entities.
Using the presented knowledge and the provided method of knowledge management, an assistant system for web service developers was designed and implemented.By using this system, developers can use patterns that have previously been developed by providers from around the world to develop powerful and easy-to-discover services.Our experiments showed that the presented tool can help service and software developers enrich their work.By using this system, the developed services will have a high-quality description, and this will make it easier to discover them.
Although different description languages are presented so far such as SAWSDL (Iqbal et al., 2008), OWLS (Klusch & Kapahnke, 2009;Matthias, Benedikt, & Katia 2009), and WSMO (Maleshkova et al., 2009), and some methods that try to presents unified methods of presenting web services (Cardoso, Barros, May, & Kylau, 2010;Loutas, Peristeras, & Tarabanis, 2011;Pilioura & Tsalgatidou, 2009), we present our method by using WSDL 1.1 description language.But, our method can be applying to other description languages as well by slights modifications to implemented codes.WSDL 1.1 is selected because current web services developing IDE use this description language.
Automatic or semi-automatic integration with service repositories are main necessary feature that must be considered in future works.

Figure 2 .
Figure 2. Graphic view of the semantic relations S={s 1 ,s 2 ,s 3 ,…} is the set of published web services in the network.By considering the semantic relation    and a service s S  , the relation f returns a set of services that have a semantic relation  with s.For example, the statement ' Weather  declares that a service called ' ' Weather has the is Similar To relation with a service called ' ' Weatherservive .A graphical representation of this statement is illustrated in Figure 4.

Figure
Figure 4. Graphical representation of ' ' ( , ' ' ) Weatherservive f isSimilarTo Weather  of all operations presented in the network.For example, by considering    and an operation o O  , the relation g returns a set of operations that have a semantic relation  with o.

Figure 7 .
Figure 7. Overall process of the tool

Figure 8 .
Figure 8. Normalised enhancements of the tool for the description file size, amount of documentations, number of failure messages, and number of port types

Table 1 .
Relation between WST entities Table 2, and is given by: ={is Similar To, has Same Result As, has Same Input As, is Richer Than, can Be Linked To, can Assist, complement} {is Similar To, has Same Result As, has Same Input As, is Weaker Than, can Get Input F

Table 3
and is given by: ={is Similar To, is Replacement Of, is Related To, is Richer Than} {is Similar To, is Replacement Of, is Related To, is Richer Than}

Table 2 .
Extension of semantic relations between operations