Added On Web Service Discovery section provinding theoretic background.

AFMS2011.bib

@@ -26,6 +26,18 @@ @article{SemanticWeb
   description = {EBSCOhost}
 }
 
+@inproceedings{WSIL,
+    author = {Ballinger, Keith and Brittenham, Peter and Malhotra, Ashok and Nagy, William A. and Pharies, Stefan},
+    citeulike-article-id = {327709},
+    citeulike-linkout-0 = {http://www-106.ibm.com/developerworks/webservices/library/ws-wsilspec.html},
+    keywords = {bibtex-import},
+    posted-at = {2005-09-21 06:42:21},
+    priority = {2},
+    title = {{Web Services Inspection Language (WS-Inspection) 1.0} , {\em http://www-106.ibm.com/developerworks/webservices/library/ws-wsilspec.html}},
+    url = {http://www-106.ibm.com/developerworks/webservices/library/ws-wsilspec.html},
+    year = {2001}
+}
+
 @misc{xmlschema11-1,
   author = {Shudi Gao and C. Michael Sperberg-McQueen and Henry S. Thompson and Noah Mendelsohn and David Beech and Murray Maloney},
   howpublished = {World Wide Web Consortium, Working Draft WD-xmlschema11-1-20080620},

AFMS2011.tex

@@ -456,7 +456,10 @@ \subsection{Compatibility and automatic translation}
 \section{RESTdesc Service Discovery} \label{sec:restdesc-discovery}
 In this section we will show with the help of the concrete example of a face detection and recognition API introduced before how starting from a single URI one can follow ones nose to explore the capabilities of an API.
 
-\subsection{Learning About Ones OPTIONS}
+\subsection{On Web Service Discovery}
+Web Service discovery can be seen as the process of locating a suitable Web service for a given task. Typically in classic WS-* architectures there are several options for this process, which can involve Web services registering themselves with a central registry (as in Section~\ref{sec:uddi} with UDDI), or Web services exposing their capabilities using the Web Service Description Language~(WSDL, \cite{WSDL1, WSDL2}). On a related note the Web Services Inspection Language~(WSIL, \cite{WSIL}) has been proposed to list groups of Web services and their endpoints. When we say Web service discovery, we currently limit ourselves to enable discovery of Web services by following ones nose from a given start URI by resolving links and making sense of Notation3 service invocation descriptions. 
+
+\subsection{Learning About Ones OPTIONS} \label{MainStory}
 A concrete execution plan can be dynamically discovered by a user agent that is given the task to identify all persons in a certain photo. The user agent first starts to check out its options on the Web service's base URI \url{/}, as shown in Listing~\ref{lst:BaseOPTIONS}. From there, the user agent discovers that there is a link of type ``index" to \url{/photos}, which in turn it checks its options on. As can be seen in Listing~\ref{lst:PhotosOPTIONS}, the user agent has indicated that it accepts responses of type ``text/n3; charset=utf-8", and therefore is given instructions that new items can be added to the index by means of a POST request. Next, the user agent uploads the photo to the server, and is notified that the photo has been stored at the location \url{/photos/1}, as given in the Location header. The user agent then executes an OPTIONS call to that location in order to find out what it can do with the uploaded photo. The response contains Notation3 instructions on how to detect potentially contained faces in the photo by performing a GET request to \url{/photos/1/faces}.  Each of the detected faces has its own URI, for example \url{/photos/1/faces/1}, where a cropped image region of just that face is available, as extracted from the Link header. In addition to that, a different Link header reveals that the persons behind each of the faces can be recognized by navigating to the particular person's URI, for example \url{/photos/1/persons/1}.
 
 \begin{figure}[float=t!]
@@ -569,8 +572,7 @@ \subsection{Learning About Ones OPTIONS}
 \end{lstlisting}
 \end{figure}
 
-\subsection{\todo{Google Docs story 1}}
-\label{MainStory}
+
 \todo{The details of the service composition will have been handled in \ref{Composition}.}
 
 \begin{comment}
@@ -595,7 +597,6 @@ \subsection{Adaptive error handling}
 The REST practice of correctly using HTTP status codes forms the corner stone of error detection. They can precisely identify the source of the problem (client, request, or server), its temporal scope (temporary or or permanent), and offer additional information (even in case of success). What we suggest is that the service should supply hyperlinks that can help the client to remedy the problem, similar to service discovery in \autoref{sec:restdesc-discovery}. For example, depending on the error, the server lists photo uploading (image does not exist), an alternative algorithm (no faces detected), or another server (server unavailable) as solutions.
 % voorbeeld: herkenning faalt? => alternatieven
 
-
 \section{Conclusion and Future Work} \label{sec:conclusion-and-future-work}
 %%%% Responsible: Thomas %%%%