Over the years a large number of technologies have been devised in order to describe service interfaces, e.g., WSDL (Booth & Liu, 2007), combine services in a process-oriented way, e.g., WS-BPEL (OASIS Web Services Business Process Execution Language (WSBPEL) TC, 2007), provide support for transactions, e.g., WS-Transaction, and cover non-functional properties (NFP) of services such as security aspects and the like, see for instance WS-Security and WS-Policy to name just a few (Erl, 2007). There is in an overwhelming stack of technologies and specifications dubbed WS-*, covering most aspects researchers have faced thus far. There remain nonetheless a number of outstanding issues (Papazoglou, Traverso, Dustdar, & Leymann, 2007) some of which are of a general technical nature, and some, indeed, are specifically related to NFPs. The latter will be dealt with in more detail in the next section.
TopOn The Evolution And Recent Trends Around Services
Despite the initial expectations, in reality, however, Web Services have hardly been adopted beyond the boundaries of enterprises (Davies, et al., 2009). Today, Seekda.com provides one of the largest indexes of publicly available Web Services which currently accounts for 28,500 with their corresponding documentation. The number of Web Services publicly available contrasts significantly with the billions of Web pages available, and interestingly is not significantly bigger than the 4,000 Web Services estimated to be deployed internally within Verizon (Stollberg, Hepp, & Hoffmann, 2007). Other academic efforts in crawling and indexing Web Services on the Web have found far lower numbers of services (Al-Masri & Mahmoud, 2008).
A number of technical limitations have been argued to be at the core of this lack of uptake (Pilioura & Tsalgatidou, 2009), some of which have been addressed by additional specifications, like the WS-* stack, as well as by the Semantic Web Services community (Erl, 2007) (Pedrinaci, Domingue, & Sheth, Semantic Web Services, 2011). However, recent trends driven by the Web 2.0 phenomenon have highlighted that socio-economic aspects have been as much an impediment as technological drawbacks. In fact, the major revolution behind Web 2.0 is not on the use of particular technologies such as AJAX as initially believed, but rather on realising that, on the Web, value largely resides on the data about and the communication between people and this value is subject to the network effect (Hendler & Golbeck, 2008). On the Web, Web Services never reached the critical mass that would justify the additional efforts and investment.
Stirred by the Web 2.0 phenomenon, the world around services on the Web, thus far limited to “classical” Web Services based on SOAP and WSDL, has significantly evolved with the proliferation of Web APIs, also called RESTful services (Richardson & Ruby, 2007; Schreiber, et al., 1999) when they conform to the REST architectural style (Fielding, 2000). This more recent breed of services is characterised by the simplicity of the technology stack they build upon, i.e., URIs, HTTP, XML and JSON, and their natural suitability for the Web. Nowadays, an increasingly large quantity of Web sites offer (controlled) access to part of the data they hold through simple Web APIs, see for instance Flickr1, Last.fm2, and Facebook3. This trend towards opening access to previously closed data silos has generated a new wave of Web applications, called mashups, which obtain data from diverse Web sites and combine it to create novel solutions (Benslimane, Dustdar, & Sheth, 2008).
At the time of this writing, ProgrammableWeb.com lists about 3,250 Web APIs, and 5,800 mashups and this number has been increasing steadily during the last years. Those APIs and mashups listed are in most cases used on a daily basis by a growing number of applications and mobile devices which exploit the data and functionality provided by enterprises on a world-wide basis over the Internet, precisely what was initially hoped and predicted for Web services. Talking about services thus nowadays necessarily needs to contemplate this new increasingly popular type of services whose development is, interestingly, not guided by standards, patterns, or guidelines. It is more an art than a science whereby Web APIs are more often than not solely described in HTML as part of a webpage rather than using an interface description language that could better support software development.
In the remainder of this chapter we analyse the main outstanding issues concerning non-functional properties for services in the light of the state of the art and the main trends we have just identified.