- This paper aims at analyzing the state of the art of Web services to understand how they can now play a crucial role in the landscape of agent systems, after several years of uncertainty. The study is first outlined by illustrating the main interfaces and protocols that are now emerging and by providing a list of the main repositories of Web services that are really available in the network. The results of the study clearly show that Representational State Transfer (RESTful) services are overtaking Simple Object Access Protocol (SOAP) services. Moreover, the results emphasize the lack of really effective repositories. The study also highlights the almost total absence of semantics in surveyed repositories, thus severely limiting the accurate rating of Web services. The overall judgment on the situation of Web service repositories is that it is surprisingly still immature, especially in the Italian and European landscapes. This is the reason why we decided to propose a novel Web portal meant to become an active and maintained collector of semantic Web services accessible to users (especially in Italy) and able to create a solid base for developing agent-based service systems.
INTRODUCTION
The enormous potential of combining agent technology and
Web Services became a certainty some years ago (see, e.g.,
[
Unfortunately the results of our study reveals a still too immature situation that severely limits the wide use of semantic Web services at a business level. For this reasons, our research has led (i) to create a novel portal of Web services, which is useful as a collector of Web services (with or without explicit semantics) and (ii) to introduce a Semantic Web Services Register (SWSR) available through a FIPA-based Matchmaker Agent.
II.
It is known that the purely syntactic description of a Web service strongly limits its use both for search and for automatically combining atomic services into complex services. In particular, an agent that provides a search tool on purely syntactic services cannot customize the search according to user needs and it must also depend on a specific service and on its actual availability. For these reasons, it is of paramount importance to have explicit semantics to be published at the stage of discovery. Moreover, RESTful Web services, in comparison with traditional semantic annotations, are problematic with this regard since most Web APIs are described in free text in Web sites and they do not have machine-understandable documentation.
Nowadays the literature provides numerous studies that deal with the issue of semantic matchmaking and that accomplish important results. Our research, however, puts emphasis on the entire business semantics that the agent will perform. In particular, it stresses the importance of the phase of Testing and Select, immediately following the matchmaking phase as described in detail below, through which the agent is able to overcome problems of a specific Web service.
Generally speaking, the publication and use of semantic
Web services follows a common scheme:
1. Given the services and the syntactic domain of
interest, the developer chooses an ontology (e.g., in
OWL [
The idea behind semantic Web services is about the use of formal descriptions of the characteristics of services to facilitate the reuse and to automate some of the most common processes, such as discovery, composition and invocation. In order to have such a scenario ready for adoption, there are nowadays two different approaches that are used to semantically describe Web Services: 1. Bottom-up: an incremental approach that adds semantics to existing Web services by linking semantic annotation to available WSDL annotations; 2. Top-down: an approach that makes extensive use of high-level ontology to semantically describe the characteristics of Web services.
The top-down approach uses the OWL-S, which derives
from OWL ontologies and, in particular, it uses the
ServiceProfile [
Please note that the whole process is asynchronous and transparent to the user. In details:
MATCHMAKING. It is a way to identify the best match available to fulfill a request (even in part), and to provide a list of tenders ordered on their degree of match. In our case we are talking about the Semantic Matchmaking as requests and offers are expressed in an appropriately structured knowledge domain, i.e., a proper ontology. The input of this step is therefore a query (commonly expressed via OWL-S) while the output is a list of found Web services ordered from the most interesting to the least interesting. 2. TESTING and SELECT. Once we get the ranking of available Web services, it is deemed necessary to carry out a test phase before we hand it for invocation and, in the likely event of positive test results, we can actually move on to the next step. 3. INVOKING. Once the previous phase concretized the details of the service for its successful invocation(e.g., the physical address of the service and the names of operations), we pass to the invocation phase. This is not a simple static call; rather the adopted approach is that of a classic DII (Dynamic Invocation Interface). 4. PARSING. The last phase is meant to extrapolate from the (XML) response obtained the much anticipated output and to transform it into the desired shape for our purposes.
As anticipated earlier, the provision of semantics to
RESTful Web Services is still undertaking slightly
difficulties (see, e.g., [
III.
It is nowadays clear that the technology of Web services
ensures a uniform method for accessing software
components located in different platforms and written in
different programming languages. At the technological level,
it is not instead clear what is the best protocol stack to use
and, in fact, today there are still two main types of Web
services: WSDL/SOAP Web services and Web APIs [
Glancing to the market trend until the end of 2010 and in
particular considering the Web Services collected by
seekda.com portal, we can say that, while classic Web
services are still more numerous (around 28,000 1 ), the
number of RESTful Services is growing quickly (around
1,9002) and above all they are quite clearly the choice of the
software giants such as Google and Yahoo [
Moreover, since the last two years, several important companies have been developing tools for mash-up creation that require no programming knowledge and therefore they are pushing the use of simpler and lighter Web APIs against more rigorous, yet complex, classic approach. Such tools, through a simple interface, allow selecting a number of RESTful Web services and chaining them together by piping one service’s output into the next service’s input while filtering content and making (slight) format changes.
The two most promising specifications that emerged in recent years have the main objective of providing machineprocessable interfaces: Web Service Description Language (WSDL 2.0) for the classic services and Web Application Description Language (WADL) for Web APIs. While WSDL 2.0 (released by the W3C as a Recommendation on June 26th, 2007) is a formal standardization of WSDL 1.1, WADL (submitted to the W3C as a member submission two years ago) is designed to provide a machine processable protocol description format for use with HTTP-based Web applications, especially those using XML.
The two specifications may appear similar but, in reality, the differences that distinguish them are essential. In general WADL is simpler yet somewhat more limited, while WSDL 2.0 is more feature rich but complex. Coming into more technical detail, the following is a list of the most important differences: Resources vs interfaces: WADL is a resourcecentric description language where documents are composed of a set of resource descriptions. On the other hand, WSDL is an interface-centric description language where documents are composed of a set of interface definitions.
B. WSDL/SOAP Services: Strengths and Weaknesses As mentioned above, WSDL/SOAP Web services are mainly characterized by the complexity of their descriptions, yet they stand out for their wide dissemination because of their ability to provide a valuable tool for interoperability between heterogeneous systems. Another strong point of such services is the protocol transparency and independence, i.e., their ability to deliver the same message, in the same format, not only via HTTP but also via any other suitable transport protocol. Moreover WSDL description provides finegrained, machine-processable details of request and response message syntax.
Looking for important weaknesses, SOAP is typically
slower than other middleware technologies, e.g., CORBA,
because it is based on XML format. Moreover, there is also a
characteristic that at first sight might seem an advantage:
SOAP was designed to slip through firewalls as HTTP using
port 80 and people now sees that this might be a danger as
“SOAP goes through firewalls like a knife through
butter” [
Despite the clear advantages listed above, RESTful Web Services have several important weaknesses. First, we lack a unique method for building this type of Web services. In fact, we can choose between Hi-REST, using all of the 4 available verbs (GET, POST, PUT, and DELETE) and the use of “nice URIs” and Lo-REST, in which only 2 of the 4 verbs are used (GET, POST). The latter type of RESTful Web services born to (i) cope with the fact that firewalls may not allow HTTP connections that use other verbs than GET and POST, and (ii) support the method attribute of an XHTML form. Such limitations have led to several workarounds but these may not be understood by all Web services, thus requiring additional development and testing efforts. Comparative analysis revealed substantial differences between the two schools of thought. In general we can say that the most appropriate use heavily depends on the context of use. So, if the context of use is, e.g., a data center where you need interoperability between different servers and performance is of crucial importance, then the SOAP/WSDL approach is still the best choice. On the contrary, the use of the RESTful architectural style becomes an important choice if you need a simpler client side.
It is not accidental that the features that characterize the
RESTful style services coincide with the first three principles
of simplicity in software engineering: reduction, organization
and time [
Finally, we must consider that such a simpler and high level approach is proving a huge success in the world so that most of new public services from large vendors (see, e.g., Google, Yahoo!, Microsoft, and Amazon) invest on RESTful Web services to share information.
One of the first activities of our research was to look for a large group of Web services primarily by linking research institutions in the attempt to select a set of efficient and accessible services, especially in Europe and particular in Italy.Despite that the possibility to search for the right Web service is an essential prerequisite for their composition and reuse, search and discovery has become very problematic with the ever increasing number of services. Moreover, we experienced frequent discontinuity from the most important service providers: many repositories, working until a few years ago, are now off-line and those that are still running do not have efficient and effective search engines. In addition, today we have a very low availability of semantically described, working and accessible Web services. Given that such a premise is not encouraging, we decided to focus initially on the selection of purely syntactic Web services and then leave semantic annotations at a later stage.
In recent years the landscape of the Web Service
repositories has changed substantially [
The first result of our research is a prioritized list of service repositories that are now available and that offer good expectations for the near future. The following list discusses the repositories we found in our research, in relative order of importance: 1. IServe3: it can be considered as a hybrid provider that supports both service types . Although for what concerns the search it makes available a small number of service of type WSDL/SOAP, it was extremely interesting for finding many Web services described semantically. IService can be considered the first true global provider of Semantic Web Services. 2. Seekda! Services4: the largest, it has about 28,500
Web Services. It is active and very helpful. 3. Service-Finder 5 : the second largest and busiest, with about 20,000 Web Services assets. Also very active. 4. WebserviceX.NET 6 : it provides about 70 Web services grouped into seven categories. This provider was established about six years ago but since then it has never been updated. Many Web services tested were faulty and inefficient. 5. Xmethods7: it provides hundreds of services but it also stalled frequently and it has no search engine.
On the one hand the large and almost vain effort made to catalog a series of useful Web services, and on the other the need of a folder of active Web services, pushed for an independent solution: to create a portal to host fully usable Italian (syntactic) Web services and hopefully, in the near future, an Italian community centered around the exchange of useful semantic Web services.
Moreover, in addition to providing a collection point for Web services in Italy, offering a Web interface for their search, our goal is primarily to provide an interface for
4 http://webservices.seekda.com/
5 http://demo.service-finder.eu/index
6 http://www.webservicex.net
7 http://www.xmethods.com
FIPA agents. In particular we would like to offer clients the
opportunity to communicate with a matchmaker agent that,
by using a shared ontology and the FIPA standard, returns
the most suitable Web Services after the appropriate
matchmaking task. We have short term and long term goals.
The long term goal is to create a collection of thousands of
Web services described by semantic standards (e.g.,
OWLS) and to make them searchable by full semantics-aware
techniques through any agent capable to formalizing a
request in the form of IOPEs. In particular, we will make
available to any agent, a Semantic Web Services Register
(SWSR) containing all the semantically described Web
Services. Our idea is to use the well-know OWLS-MX
Semantic Matchmaker [
However, the successful provision of semantics to Web services has already been a difficult undertaking: all the attempts carried out so far, despite some relevant positive results, have led to final negative results. The difficulty lies trivially in still not having a large group of semantically described services. For this reason, our first short term goal is to create a portal for bringing together a set of syntactically described Web services, that are meant to be useful and immediately effective for the Italian market. For example, the portal is expected to publish interesting Web services targeting concrete problems like the discovery of opened pharmacies of a certain Italian city in a certain day, or secretarial service for a student of an Italian University. Thanks to our novel Web services folder it will be possible to create an interface through which FIPA agents could seek and discover Web services. Up to this point, the beneficial results of the proposed portal would be essentially the availability of services for the Italian market and their ease of access.
Before entering the big issue of semantics, we will then
consider hybrid approaches intended to empower the pure
syntactic search, as follows:
1. To give the possibility of using so-called social
tagging of Web Services, to make them searchable
via different, yet related, keywords than those used
in descriptions;
2. To use the Italian WordNet Ontology API [
Starting by these two intermediate steps, toward the heavier and true semantic approach, we can have both a folder Web services ready to use, and the opportunity to carry out interesting research on hybrid syntactic/semantic search approaches. In this paper we intended to make a reality check on the overall status of the Web service technology and we also aimed at better understanding the relationship between agents and Web services today. Thus, the research presented here has led to ask ourselves a number of interesting questions and to observe that the Web service technology is still far from its full maturity.
Glancing at the current trends, we can certainly say that the RESTful Web services standard is quickly taking place over other approaches mainly because of its lightweight nature. Furthermore, it is equally clear that the advent of the Semantic Web would accelerate the rise of semantic Web services and, in particular it would boost the need of agents to effectively use semantic Web services.
For all these reasons, we have recently created the WebServices4Agents Portal (www.webservices4agents.com) in the intent to provide both an up-to-date repository for (even RESTful) Web services and to open an access to such services to FIPA agents. We hope that the portal will be an important and useful meeting point for all agentswho want to discover and invoke useful Web services.
Our first goal is to set up a large repository of Web Services and to have an agent capable of providing a matchmaking service on such a repository.After that we immediately want to match with the reality of semantic Web services landscape: first by trying with semi-semantic approaches, e.g., using social tagging, and finally going to the full power of the Semantic Web.
We conclude this paper with a list of questions that arose during our work and that are still open and demanding for discussions.
What are the results of efforts made so far to make semantics to Web services available? Are there “less invasive” ways capable to bring (softer) semantic to Web services?
The issues about the Semantic Web have been subjects of extensive discussions since about ten years. However, even today, especially from the point of view of Web services, there is not a great use of semantics. The lowering of performances and the difficulties for service providers to offer semantically annotated Web services are just two of the problems hindering the rise of semantic Web services. In order to avoid this bottleneck, our idea is to propose softer approaches: (i) the use of keywords by exploiting the power of WordNet, and (ii) the adoption of ordinary social tagging to make richer and more effective searches.
Taking now formal semantics into account and noting the sudden growth of RESTful Web Services, can we use OWL-S descriptions for this kind of Web services?
As briefly discussed in earlier, we can say that, starting from a good description of a syntactic RESTful Web service, we can get a semantic description by means of OWL-S because it has been recently extended to exploit the semantics of RESTful Web services. In particular, the recent introduction of the RESTfulGrounding should provide the possibility of using OWL 2 for semantically annotating RESTful Web services.
Will service developers be encouraged to advertise their services syntactically and also semantically?
First, please remember that in Italy the development of truly efficient and free Web services is still far from reality and we do not have yet a means to expose them and to make the effectively available. Through the WebServices4Agents portal producers of Web services and their respective consumers would finally meet through an interface capable of selecting the best service for a consumer’s needs. The portal would give the possibility to query a JADE matchmaker agent which would then return the best service.
Under the assumption that we have a folder of semantically described services in the portal and a matchmaker agent for searching, what would the implications be from the point of view of agent systems?
This is definitely one of the most interesting points
emerged during our research. Our vision is to have a large
number of accessible Web services and to have the
possibility of composing such services with the help of a
semantic infrastructure. In recent years, Telecom Italia
S.p.A. and the University of Parma have already
implemented WADE (Workflow Agent Development
Environment) [
This research project has been supported by Working Capital Initiative of Telecom Italia S.p.A.