Introduction

The basic relationship between a web service provider and the service requesters is request and response. The service requesters usually send the request to a service provider, which responds with a solution to the request or an error message if the request cannot be processed. When multiple web services are involved in a specific application, service aggregation or integration has to be considered. It is expected that web services can be dynamically and automatically discovered, composed, and invoked in a specific order to fulfill particular tasks. The crux of the research and development of semantic web services has been the modeling and description of the semantics of service aggregation processes.

The ever-more complicated framework of semantic web services reveals a significant limitation of web services technology. Compared to the popularity of the World Wide Web, which can be used by any person who can connect to the Internet, web services at present are a tool specifically for computer science professionals rather than users in broader domains. Mazzocchi observes, "even XML people don't understand semantic Web languages" in RDF/OWL (Please see Resources for more information). However, service requesters have no interest in how the service providers process their request and it should not be the requester's responsibility to understand how the service is provided through logical modeling. Much research in semantic web services focuses not on describing the meaning of services, but rather emphasizes the process of service aggregation, which is of no interest to the service requester.

This paper first reviews the recent development of semantic web service technology. Next it will discuss how to transform the composite web services into an atomic process -- and how to describe the service semantics of such atomic web service that actually integrate multiple web services in different service domains in a single request-response relation. Then, this paper demonstrates how Internet/distributed computing or semantic/intelligent web services can be implemented using HTTP/POST by the proposed approach and, finally, discusses challenges for future developments.

Back to top

SOAP web services

Web services promise a new level of interoperability for applications developed in heterogeneous platforms and programming languages. Each service encapsulates specific business functionality that can be invoked through a Web Services Description Language (WSDL) interface by using Simple Object Access Protocol (SOAP) over HyperText Transfer Protocol (HTTP) to transfer the message between the service requester and service provider. SOAP uses serializers and deserializers to translate from the native language of a software application to the SOAP protocols that transfer the request and response over the network. Deem (2002) notes, "The most useful functionality offered by SOAP is the ability to convert data between platform-specific formats and the XML format used in SOAP messages. It is this functionality that allows an application running on one platform to convey information to an application running on another platform." Please see Resources for more information.

SOAP resolves the interoperability problem at the syntactic level but the semantic problems remain unsolved. While web services encapsulate specific business functionality, this hides the information required by requesters to understand the data and service semantics. Users have to follow the object and data flow diagrams to learn the implementation details so as to deploy the services (Shi, 2004). In reality, WSDL interfaces only reflect the naming systems and the hierarchical relationship of the objects, data types, functions, and variables; which are used when programmers develop the web services, rather than the meaning -- or, rather -- the semantics of the data and services. The syntactic architecture of web services cannot clearly express the meaning of the data and the service; nevertheless they are full of redundant information.

Figure 1 (Shi, 2004) illustrates these problems. This diagram shows how to understand and invoke the findAddress function of the Address Finder web services provided by ESRI, the world-leading vendor of Geographic Information Systems (GIS) software. We can find the Address Finder Web Service's WSDL file at http://arcweb.esri.com/services/v2/AddressFinder.wsdl.

We can use the findAddress function to find the location (longitude and latitude) of a given street address. For the semantics of this paid web service, the service requester has to:

1. Provide a valid user name, a password to invoke an Authentication Web Service to get the authentication token
2. Specify the data source to be used in this application
3. Use this dynamically generated token and specified data source with the address to invoke the findAddress function.

The result is that this web service will return the longitude and latitude of the input address.

To summarize:

• The input requirements are user name, password, data source, street address, city, state, zip code
• The outcome will either be a list of longitude and latitude that matches the input address or an error message.

However we cannot find such straightforward information from either Figure 1 or the WSDL file. Furthermore, the service requesters cannot understand from the diagram that they have to use two web services to get the expected result. Some of the string data types look meaningful, such as: street, intersection, city, state, province, zone, and country. However, WSDL is full of redundant information that is unnecessary to the novice or layperson. Regarding the WSDL content for the most part we have to guess the meaning. For example, LocationInfo, ArrayOfLocation, Location[], description1, description2, addressFinderOptions, token, matchType, are the names of various objects, data types, functions, variables, but don't represent their true meaning. Who knows the meaning of description1, description2, addressFinderOptions, token, matchType, etc. within WSDL? To conclude, the names contained in WSDL are not the meaning of web services and the semantics of web services are not within the WSDL file.

Back to top

Semantic web services

According to W3C, WSDL defines the service description of message formats, data types, transport protocols, and transport serialization formats as a machine-processable specification of the web service's interface. The semantics of a web service is the shared expectation about the behavior of the service and is the "contract" between the service requester and the service provider regarding the purpose and consequences of the interaction. "While the service description represents a contract governing the mechanics of interacting with a particular service, the semantics represents a contract governing the meaning and purpose of that interaction" (please see Resources for more information). It has been defined as "a service description is a machine-processable description of a service" that "contains a machine-processable description of the messages that are exchanged by the service" and "may include a description of the service's semantics," while it has been expected that "a service semantics is about the service tasks that constitute the service" and "should be identified in a service description" and "may be described in a formal, machine-processable language" (please see Resources for more information).

The communication between service requester and service provider sets up the basic relationship in a web service: request and response. The purpose of the semantic description of the service is to help the service requester to understand the content, scope, requirements, outcomes and effects before the service is invoked. The service description functions as an advertisement for service discovery and matchmaking to help the requester find the correct service and further to enable the automatic or semi-automatic service composition and invocation. For this reason, the so-called shared expectation should be requester-oriented, which is to say, the service provider's advertisement should focus on the requester's needs and provide a solution to help the service requester. Given a typical and practical case, if a client uses www.expedia.com to buy airline tickets, reserve a rental car, and a hotel for a trip to NewYork in a certain period, www.expedia.com will do the search on the server side and then return back to the client a list of all possible solutions to the request, a combination of relevant information about the available airlines, car rental companies, and hotels, such as price, time schedule, etc. Thus it can be concluded that, what a service requester expects is to send out the request and get an answer back from the service provider, rather than to figure out the framework and logical routines of how the service provider processes the request.

Service aggregation is a vital function. Currently many approaches are proposed for semantic web services, for example: Ontology Web Language (OWL)-based web service ontology (OWL-S), (W3C, 2004a), Web Service Modeling Ontology (WSMO) (W3C, 2005), and Web Service Semantics (WSDL-S) (Akkiraju, et al. 2005). OWL-S and WSMO have a root relationship with the semantic Web technology by using different kinds of logic to model the service processes (Description Logic for OWL-S, Frame Logic for WSMO). Such approaches build up complex frameworks chaining different web services into composite processes and describe how the processes are composed by using logical statements to associate unknown services, functions, input variables and output results. For example, OWL-S has a Process Model while WSMO has varied Mediators for service aggregation.

Given the requester-oriented shared expectation in mind, OWL-S, WSMO, and others emphasize the process model for service aggregation rather than provide an answer to the request. What service aggregators provide are complex frameworks that require interpretation. If such processes and models are removed from OWL-S and WSMO, all that would remain would be just the service description (Profile for OWL-S vs. Goals for WSMO) and web services themselves. In conclusion, the service aggregation process does not provide the semantic meaning of the services and such aggregations should not be exposed to the service requesters who are waiting for an answer to their request rather than a framework.

WSDL-S is also a problematic approach for semantic web services. Since WSDL is the outcome of object-oriented programming (OOP), the WSDL document can only reflect the content of OOP other than the meaning of the data and services. Many WSDL documents are redundant and irrelevant to the service requesters as shown in Figure 1 since such documentation contains many intermediate objects and data used in the programming without direct significance for the data and services (please see Resources for more information).

In the example shown in Figure 1, ESRI's ArcWeb service provides address finder web services. The requester sends the address information to the services provider who will then return the location information (longitude and latitude) back to the requester. By OOP, the service provider will return a LocationInfo object to the requester. Since it is possible that multiple locations might be identified that may match the input address if the input address is not uniquely and completely described, LocationInfo object then contains an array of Location objects. For each Location object, besides multiple attributes within it, Location object contains the Point object, which eventually contains the value of longitude and latitude.

When the requester sends the request to the server, the expected answer is all possible location information (longitude and latitude) that match the input address rather than the other objects, data types, attributes, etc. that are used in the programming process. Since the semantics of web services are not within WSDL file, WSDL-S is not the correct approach to describe the service semantics, but on the contrary, it describes the details in the programming process rather than the meaning of the service. Since not all the content in WSDL is meaningful, adding semantics into WSDL is an obvious challenge as it is difficult to describe the intermediate objects used in OOP. Although service providers can add semantics onto all elements in a WSDL file, it is not worthwhile since many elements in a WSDL file are irrelevant to the request as described in Figure 1. Especially if one service is based on the result of another service, adding semantics into individual services cannot help requesters to understand the internal relationships among the different services and providers. However, adding semantics into WSDL selectively will make the document difficult to interpret if only a small part of the document is described, which eventually increases the difficulty that requesters have in understanding the meaning of the data and services.

Back to top

Rebuilding the semantic web service architecture

Semantic web service development should focus on the basic request-response relationship in the communication process. The Semantic Request and Response (SRR) approach (please see Resources for more information) can transform all composite web services into an atomic one to provide service aggregation without those logic frameworks. SRR focuses on the service requester's expectation to send out the request and get the answer back from the service provider. Service requesters should not care about how the service providers process the request, but only require an answer from the service provider. In this way, semantic web service research and development can focus on the service semantics in describing the request and response, but ignore the process, which has no significance to the requester.

Web service aggregation can be classified into three categories:

1. The parallel processes in which each web service is independent from the others
2. The ordered processes in which one service might depend on the result of other web services
3. A hybrid process containing the previous two types

SRR can transform such composite web services into an atomic one as described in Figure 2. This approach requires that the service provider handle all aggregation processes before it provides integrated services to the requester so that the requester has no need to understand how the provider processes the request.

As for the parallel service process, such as one service provider chain the airline ticketing, hotel and rental car reservation services, these are independent from each other, while those logical models try to determine the relationship among different servers, functions and variables. The SRR approach, however, provides a direct service description to the service requesters. In Figure 2, function F1 identifies one input variable as object x1 that contains two attributes a1, and a2. While programmers know how to create a function for different approaches, SRR will generate a request XML document to specify the input requirements as (a1, a2, y1, x2, x3, y3) while the response XML document includes the output as (z1, z2, z3).

In the example of the ordered process, in Table 1, the request XML document contains the input variables (x1, y1, x2) while the response XML document can include all possible attributes of object z2, that is to say, the output is an array of object z2, and then the XML documents can be sampled as the follows:

The hybrid process example has inputs (x1, y1, x2, y2) and an output (z3) that are defined in the request and response XML documents.

An ontology-enhanced SRR (OSRR) approach (please see Resources for more information) was proposed to rebuild the semantic Web Services architecture. The OSRR approach suggested that semantic web services could be:

• Self-describing
• Document based rather than object based
• Meaning or semantics oriented rather than name or syntax oriented
• Service-domain and functional-purpose independent
• Human semantics and behavior simulated
• Standardized web service with one interface with proven efficiency
• Obviating the need for WSDL for semantic description
• With simplified implementation for the discovery, matchmaking, composition and invocation of web service within its current infrastructure (UDDI, WSDL, SOAP)

The proposed new approach suggested that each web service has two components: one a XML document (ServiceDescription.xml) and the other standardized interface - function getService(String request): String response. The service provider has to supply detailed information and guidance within ServiceDescription.xml that should contain at least five building blocks (please see Resources for more information):

1. Service domain and function category description
2. Format of the service request input XML document
3. Format of the service response output XML document
4. Service request input requirements: defines the template for service request
5. Service response output prototype: defines the template for service response

Web services can be meaningfully classified by service domains and functional categories. On the one hand, the service description file (ServiceDescription.xml) is marked-up semantically so that anyone can understand the meaning of the provided service, while at the same time, such XML documents are machine-processable. In this way, a series of web services can be identified and automated, and intelligent service discovery and matchmaking can be easily and efficiently performed (0-10 milliseconds per service varied based on the details the requester supplies, such as service domain and subdomain, function category and subcategory, input variable specifications, expected outcome formulations). On the other hand, the service description file provides detailed guidance for users and machines to understand how to use and process the service and what can be expected to get the service outcome. In this way, service composition is almost a copy-and-paste process and service invocation is simplified through one standardized interface.

As for the service providers, if they build web services in the proposed new approach, they can develop such web services in the traditional OOP approach. The only requirement is that all input variables should be transferred and derived from the XML documents as the service request sent by the requesters. It is the service provider's full responsibility to aggregate all related web services in the service chain, while such processes should not be exposed to the service requesters. When the server receives the service request from the users, the main task is to first, process the XML document, then determine which services and functions are requested. Then the server must check if the input variables are qualified, then invoke the corresponding service and function, get the result and put the result in a cache or queue. Ultimately, it must loop though all involved services in the same way, and finally, generate the response XML document, and send it back to the requesters. To invoke the web service function, the proposed new approach advocates exchanging a meaningful XML document rather than passing the encapsulated objects between the service providers and service requesters. Only in this way can web services be meaningful to the broad general public other than the computer science professionals.

To implement this approach, domain-specific standards on service description (what should be described in the service request and what can be in the service response) should be formulated. Figure 3 shows an example of creating a service domain ontology framework. Those service providers who provide services to book airline tickets, reserve hotel and rental cars will share the same service description. Normally such services include a search function and a reservation function. The service requester searches the appropriate information first and once a specific service is identified, the requester sends a reservation request. The example shows only the template of service description for the search functions in those three services.

If one service provider (SP) wants to provide an integrated service that aggregates all three kinds of services, it will do so in the service registration that is specified in the first building block as "Service domain and function category description." In the template of service request description, SP will specify the conditional input requirements. That is to say, SP has to specify such requirements in the service description in advance so that a service requester can either use only a part of SP's service to book ticket, reserve hotel, or, use all of the services. Therefore, the service request will be conditional (OWL-S and WSMO have conditional output and effect but not conditional input). When the SP receives the service request, it will process the request XML document to identify the requested service then process the corresponding requests and reply to the requester. In this process, the SP may contact multiple web services offered by airline companies, hotels and other companies, but the original requester is never made aware of these processes in detail. In this way, the service description can be separated from the service implementation. Developers can develop the service description file first before the project implementation, which will be directly developed upon completion of the service description file.

When the service request is transferred to the service provider, the only element(s) that have a direct relationship with provider's implementation is the Function element(s) specified in the request. The service provider will check which function(s) will be processed accordingly, based on the specific request (actually the function element(s) may not be a real name of the function(s) that are used in the programming code). Given the following example, all service providers for hotel reservations should understand how to process such a request if they can share such an agreement while they can develop their own applications, however necessary:

<Service Request>
 <Service Name="SearchHotelInformation">
  <Function Name="WebService.Hotel.SearchInformation">
   <InputVariables>
    <City></City>
     <State></State>
   </Location>
   <CheckInDate></CheckInDate>
   <CheckOutDate></CheckOutDate>
   <NumberOfCustomer></NumberOfCustomer>
   <RoomType></RoomType>
  </InputVariables>
 </Service>
<ServiceRequest>
 

Shi and Jagannathan (2005) have provided a detailed sample service description file formulated in the OSRR approach. Figure 4 shows a pilot project that is designed and implemented by the OSRR approach. By clicking the button Classify Services, this pilot project will demonstrate how Web services can be categorized based on the ServiceDescription.xml XML documents which enable automatic service discovery and matchmaking. Through this approach, this demo system possesses certain intelligence to "understand" whether necessary services and functions can be identified from a list of Web services. By adding or removing the Web services in the textbox on the Web page, after a user types in a place name in West Virginia, such as Morgantown, he then clicks either of the two buttons on the page, Get Longitude/Latitude or Convert to UTM X,Y. The computer can then understand whether the request can be processed or not. If the computer is able to find the necessary services, it will compose the service request, invoke the service(s) in order and show the result. If certain required services cannot be identified, the computer will not process the request, but will respond to inform the requester what is missing. In fact, the location service will call a Web service offered by ESRI via its ArcWeb Service interface, while the data conversion service will call the Web service offered by Microsoft's TerraService. In using the OSRR approach the requesters do not need to know the process details, but are able to understand what the service can offer and how to implement the service.

Uschold (2003) proposed the law of the semantic Web as "the more agreement there is, the less it is necessary to have machine-processable semantics" (that is, semantics derived by machine-processable logics). Invoking the same law to create semantic Web services, we need a greater number of standards rather than logics. Web services within a single domain, like hotel reservation services, should have at least an industrial agreement and standard to specify the required input variables and the possible output format. Implementing OSRR requires these kinds of agreements and standards. On the other hand, it is argued that it is difficult to get such kind of agreements and in consequence OSRR is not possible. However, for each specific service domain, if such a simple agreement cannot be achieved, how are users able to decode the unlimited possibilities created when using logics to match or guess the relationships among different service providers? Programmers designed logic models to chain and process the aggregated services because each service has no information about other available services. The problem for the unknown service lies in the development process as each developer gives different names to the service, functions, input variables and output results that are used in the OOP. As a result, each WSDL file is different for each service provider although the content of the service can be exactly the same. In this situation, we need logical deduction to understand the relationships among different elements used in the programming process. However, since any logic models cannot enumerate all possibilities, such a model will fail once any developer defined a system using a different approach. Even a small difference will result in a non-match result. If all developers follow the same rule as specified by the logical models, then they are following an agreement or standard to keep the framework running.

Uschold (2003) asked "How can a machine (that is, software agent) learn something about the meaning of a term that it has never encountered before enough to accomplish its task?" While "the semantics (whether implicit, informal, or formal) can be hardwired into the web applications," the goal to allow the machine to process the semantics to dynamically discover what the content means and how to use it "might be impossible to achieve in its full generality." If such statements are true for the semantic Web, it is true for semantic Web services. We need more agreements and standards rather than logic models because, if services developers can reach an agreement beforehand, such logic for service integration is not necessary since everything can be specified by agreements and standards. This is especially true when considering that the requesters have no interest, relationship, or responsibility to understand the process of service aggregation.

Back to top

Internet/distributed computing via HTTP/POST

When a Web service can be invoked by exchanging an XML document, WSDL/SOAP is no longer a necessary component because we can perform the same task via HTTP/POST, although both protocols can exist without conflict. The advantage for HTTP/POST is that to deploy this type of semantic Web service, people do not need to get any specific software to write the code to invoke SOAP Web services via the single functional interface as function getService (String request): String response since the same service and function can be performed via a Web page by "cut-copy-paste." However, to perform more complicated system integration for specific tasks, professional programmers have to use certain software to integrate the input and output together via either WSDL/SOAP or HTTP/POST by processing the request and response XML documents for different Web services without knowing the details within the composite processes.

This is a natural advance for this cutting-edge technology. Initially, computer scientists created the Web service technology to resolve interoperability problems among different operating systems and programming languages by exchanging various business logic, object data types and functionalities through the serialization process and via the SOAP protocol. In reality, the message exchanged in SOAP is just an XML document that contains the serialization information for computing without the semantic significance. For now, when service request and response can be described and defined explicitly in XML documents, such requests and responses can be transferred directly over HTTP by a POST method in a Web page as described in Figure 5.

Demonstration

To demonstrate that Internet/distributed computing can be implemented via HTTP/POST to perform exactly the same functionality provided by WSDL/SOAP, an HTTP Server was created using .NET. This HTTP Server accepts a POSTed message via HTTP to perform a geospatial data processing function to create a new buffer polygon feature that are within 1000 meters for the input geospatial point features. ESRI ArcGIS Server 9.0 is used to process the buffer function.

This service is designed to accept an XML document via the HTTP POST request. When the server gets the request, it will invoke the ArcGIS Server to process the input data and generate the result as an XML document and send it back to the requester.

The client-side interfaces were developed using .NET, Java servlet/JSP, and CGI/Python to communicate with the .NET HTTP server. All three client-applications received exactly the same result without any interoperability problem.

1. GIS HTTP Servers
   When the HTTP server is waiting for a POSTed message to invoke the same function as bufferPoint, and you put the link in the Address box, you can only see the error message:
.ArgumentOutOfRangeException: Length cannot be less than zero. Parameter name:
at System.String.Substring(Int32 startIndex,Int32 length) ad MSDNHandlers.getService.createBuffer

   
   
2. .NET client
   Figure 6 shows the Web interface of a .NET client for interaction with the GIS HTTP server:
   
   Figure 6. Web interface of a .NET client for interaction with the GIS HTTP server
   
   
   
3. CGI/Python client
   Figure 7 shows the Web interface of a CGI/Python client for interaction with the GIS HTTP server, before service invocation:
   
   Figure 7. the Web interface of a CGI/Python client for interaction with the GIS HTTP server, before service invocation
   
   
   Figure 8 shows the Web interface of a CGI/Python client for interaction with the GIS HTTP server, after service invocation:
   
   Figure 8. the Web interface of a CGI/Python client for interaction with the GIS HTTP server, after service invocation
   
   
   
   Listing 2 shows the source code for SendHTTPRequest.py:
   
   Listing 2. Python Source Code: SendHTTPRequest.py
   

   import urllib import cgi, string, sys form = cgi.FieldStorage() inputURL = form["ServerURL"].value inputRequest = form["request"].value f = urllib.urlopen(inputURL, inputRequest) s = f.read() print print 'Status: 200 OK' print 'Content-type: text/html' print print '<html><head><title>Web Service via Http/Post by Python</title></head>' print '<body>' print '<br><br><center><b>Here is your request (left) and response (right)</b></center><br><br>' print '<center>' print '<div><TEXTAREA name=\"request\" COLS=60 ROWS=40>' + inputRequest + '</TEXTAREA>' print '<TEXTAREA name=\'request\' COLS=60 ROWS=40>' + s print '</TEXTAREA>' print '</center>' print '</body></html>'

   
   
   
4. SP/Java Servlet client
   Figure 9 shows the Web interface of a JSP/Java Servlet client for interaction with the GIS HTTP server before service invocation:
   
   Figure 9. Web interface of a JSP/Java Servlet client for interaction with the GIS HTTP server before service invocation
   
   
   
   Listing 3 is the source code for the Semantic Web service invoked through HTTP/POST by the JSP/Java servlet:
   
   Listing 3. Semantic Web service invoked through HTTP/POST by JSP/Java servlet
   

   <html> <head> <title>HTTP POST vs. WSDL SOAP Web Services </title> </head> <body> <br> <center> <h2><P>Semantic Web Service invoked via HTTP/POST by JSP/Java Servlet</h2></P> <FORM action= "http://157.182.136.51:8080/HttpApp/servlet/SendHTTPRequest" method="post"> <P><b><font color="blue">Simple Server URL: </font> http://157.182.136.76/xshi/httpPost/demo1/VBHandler.aspx </b></P> <P><b><font color="blue">GIS Server URL: </font> http://157.182.136.51/agswsprojs/HttpService/getService.aspx </b></P> <P><b>(--The GIS Server will create a new buffer feature for any input point features at your specified distance, e.g. 560 meters.--)</b></P> <P><b>(--Sample source data can be copied from <font color="red"> http://157.182.136.51/agswsprojs/HttpService/WebForm2.aspx</font>--)</b></P> <div><b>Server Requested: </b> <input name="ServerURL" type="text" size="80"/></div> <br> <div><TEXTAREA NAME="request" COLS=60 ROWS=25></TEXTAREA> <TEXTAREA NAME="response" COLS=60 ROWS=25></TEXTAREA></div> <br> <b>Request</b> <INPUT TYPE=SUBMIT VALUE="Submit Request"> <b>Response</b> </FORM> <b><P><font color="red">Before click the button, specify the distance in the BufferDistance tags to c reate the new buffer feature of the input dataset </font></P></b> </center> </body> </html>

   
   
   
   Figure 10 shows the Web interface of a JSP/Java Servlet client for interaction with the GIS HTTP server after service invocation:
   
   Figure 10. Web interface of a JSP/Java Servlet client for interaction with the GIS HTTP server after service invocation
   
   
   
   Listing 4 is the Java source code for SendRequestServlet.java:
   
   Listing 4. Java source code: SendRequestServlet.java
   

   import java.io.*; import javax.servlet.*; import java.util.*; import java.net.*; import java.io.IOException; import java.io.PrintWriter; import javax.servlet.RequestDispatcher; import javax.servlet.ServletException; import javax.servlet.http.*; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class SendRequestServlet extends HttpServlet { public void doPost(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { String strRequest = request.getParameter("request"); String strURL = request.getParameter("ServerURL"); PrintWriter writer = response.getWriter(); response.setContentType("text/html"); writer.println("<html>"); writer.println("<head>"); writer.println("<title>Your requested service is returned</title>"); writer.println("</head>"); writer.println("<body bgcolor=\"white\">"); String newRequest1, newRequest2, newRequest3; newRequest1 = strRequest.replaceAll("<","<"); newRequest2 = newRequest1.replaceAll(">",">"); newRequest3 = newRequest2.replaceAll("\"","""); writer.println("<br><br><center><b>Here is your request (left) and response (right) </b></center><br><br>" ); writer.println("<center>"); writer.println("<div><TEXTAREA name=\"request\" COLS=60 ROWS=40>" + newRequest3 + "</TEXTAREA>"); String outPut; outPut=""; try { URL url; URLConnection urlConn; DataOutputStream printout; DataInputStream input; url = new URL (strURL); urlConn = url.openConnection(); urlConn.setDoInput (true); urlConn.setDoOutput (true); urlConn.setUseCaches (false); urlConn.setRequestProperty ("Content-Type", "application/x-www-form-urlencoded"); printout = new DataOutputStream (urlConn.getOutputStream ()); String content = strRequest; printout.writeBytes (content); printout.flush (); printout.close (); input = new DataInputStream (urlConn.getInputStream ()); String str; while (null != ((str = input.readLine()))) { System.out.println (str); outPut = outPut + str + "\n"; } input.close (); } catch (MalformedURLException me) { System.err.println("MalformedURLException: " + me); } catch (IOException ioe) { System.err.println("IOException: " + ioe.getMessage()); } String newResponse1, newResponse2, newResponse3; newResponse1 = outPut.replaceAll("<","<"); newResponse2 = newResponse1.replaceAll(">",">"); newResponse3 = newResponse2.replaceAll("\"","""); writer.println("<TEXTAREA name=\"request\" COLS=60 ROWS=40>" + newResponse3 + "</TEXTAREA> </div>"); writer.println("</center>"); writer.println("</body>"); writer.println("</html>"); } }

   
   
5. .NET Studio
   Figure 11 shows a normal Web service developed in .NET Studio. It provides a WSDL interface to accept two input variables, a String data type strPoint and a Double data type dblDistance. The output result is a String data type. This function will create a new buffer feature data layer around the input point features at user specified distance. In practice, this function can be used in such case in which a company may want to know the service coverage within 5000 (or any other number) meters of its business centers (point features).
   
   Figure 11. Web service developed in .NET Studio
   
   
   
   
6. bufferPoint Web service
   Listing 5 provides the code for the WSDL document for the bufferPoint Web service:
   
   Listing 5. The WSDL document for the bufferPoint Web service
   

   <?xml version="1.0" encoding="utf-8" ?> - <wsdl:definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://tempuri.org/geoWebService/Service1" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://tempuri.org/geoWebService/Service1" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> - <wsdl:types> - <s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/geoWebService/Service1"> - <s:element name="bufferPoint"> - <s:complexType> - <s:sequence> <s:element minOccurs="0" maxOccurs="1" name="strPoint" type="s:string" /> <s:element minOccurs="1" maxOccurs="1" name="dblDistance" type="s:double" /> </s:sequence> </s:complexType> </s:element> - <s:element name="bufferPointResponse"> - <s:complexType> - <s:sequence> <s:element minOccurs="0" maxOccurs="1" name="bufferPointResult" type="s:string" /> </s:sequence> </s:complexType> </s:element> <s:element name="string" nillable="true" type="s:string" /> </s:schema> </wsdl:types> - <wsdl:message name="bufferPointSoapIn"> <wsdl:part name="parameters" element="tns:bufferPoint" /> </wsdl:message> - <wsdl:message name="bufferPointSoapOut"> <wsdl:part name="parameters" element="tns:bufferPointResponse" /> </wsdl:message> - <wsdl:message name="bufferPointHttpGetIn"> <wsdl:part name="strPoint" type="s:string" /> <wsdl:part name="dblDistance" type="s:string" /> </wsdl:message> - <wsdl:message name="bufferPointHttpGetOut"> <wsdl:part name="Body" element="tns:string" /> </wsdl:message> - <wsdl:message name="bufferPointHttpPostIn"> <wsdl:part name="strPoint" type="s:string" /> <wsdl:part name="dblDistance" type="s:string" /> </wsdl:message> - <wsdl:message name="bufferPointHttpPostOut"> <wsdl:part name="Body" element="tns:string" /> </wsdl:message> - <wsdl:portType name="Service1Soap"> - <wsdl:operation name="bufferPoint"> <wsdl:input message="tns:bufferPointSoapIn" /> <wsdl:output message="tns:bufferPointSoapOut" /> </wsdl:operation> </wsdl:portType> - <wsdl:portType name="Service1HttpGet"> - <wsdl:operation name="bufferPoint"> <wsdl:input message="tns:bufferPointHttpGetIn" /> <wsdl:output message="tns:bufferPointHttpGetOut" /> </wsdl:operation> </wsdl:portType> - <wsdl:portType name="Service1HttpPost"> - <wsdl:operation name="bufferPoint"> <wsdl:input message="tns:bufferPointHttpPostIn" /> <wsdl:output message="tns:bufferPointHttpPostOut" /> </wsdl:operation> </wsdl:portType> - <wsdl:binding name="Service1Soap" type="tns:Service1Soap"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> - <wsdl:operation name="bufferPoint"> <soap:operation soapAction= "http://tempuri.org/geoWebService/Service1/bufferPoint" style="document" /> - <wsdl:input> <soap:body use="literal" /> </wsdl:input> - <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> - <wsdl:binding name="Service1HttpGet" type="tns:Service1HttpGet"> <http:binding verb="GET" /> - <wsdl:operation name="bufferPoint"> <http:operation location="/bufferPoint" /> - <wsdl:input> <http:urlEncoded /> </wsdl:input> - <wsdl:output> <mime:mimeXml part="Body" /> </wsdl:output> </wsdl:operation> </wsdl:binding> - <wsdl:binding name="Service1HttpPost" type="tns:Service1HttpPost"> <http:binding verb="POST" /> - <wsdl:operation name="bufferPoint"> <http:operation location="/bufferPoint" /> - <wsdl:input> <mime:content type="application/x-www-form-urlencoded" /> </wsdl:input> - <wsdl:output> <mime:mimeXml part="Body" /> </wsdl:output> </wsdl:operation> </wsdl:binding> - <wsdl:service name="Service1"> <documentation xmlns="http://schemas.xmlsoap.org/wsdl/" /> - <wsdl:port name="Service1Soap" binding="tns:Service1Soap"> <soap:address location="http://157.182.136.51/agswsprojs/geoWebService/Service1.asmx" /> </wsdl:port> - <wsdl:port name="Service1HttpGet" binding="tns:Service1HttpGet"> <http:address location="http://157.182.136.51/agswsprojs/geoWebService/Service1.asmx" /> </wsdl:port> - <wsdl:port name="Service1HttpPost" binding="tns:Service1HttpPost"> <http:address location="http://157.182.136.51/agswsprojs/geoWebService/Service1.asmx" /> </wsdl:port> </wsdl:service> </wsdl:definitions>

   
   

If the service description can be composed by the proposed new approach, people without a background in computer science will be able to easily understand and find the specific service they wanted as such services are classified by service domains, functional categories, and with detailed specifications on both input and output templates.

Back to top

Challenges and conclusion

When Tim Berners-Lee defined the semantic Web, the word "semantic" meant "machine processable." Now that Web services are designed for machine-processable, WSDL is criticized as not semantic. While many people claimed that the definition of semantic Web services could be semantic Web plus Web Services, Veltman (2004) concluded that "a semantic Web which deals only tangentially with meaning might more accurately be called the transactions web or the logic web," since people who designed semantic Web regards that "logical meaning is the only objective dimension of meaning; that all other meaning is subjective and therefore unimportant. In this view, the semantic Web rightfully limits itself to the realms of logic. In science, technology and business this claim leads to pragmatic results" (Veltman, 2004).

Uschold (2003) wrote a paper entitled "Where Are the Semantics in Semantic Web?" Now the question is "Where Are the Semantics in Semantic Web Services?" If the goal of the semantic Web is to allow machine processing of the semantics, to discover dynamically the content meaning, and how to use it in a logic approach, it "might be impossible to achieve in its full generality" (Uschold, 2003). The same impossibility might be to develop semantic Web services using the logical modeling approach.

McCool (2005) concluded that "Logic, which forms the basis of OWL, suffers from an inability to represent exceptions to rules and the contexts in which they are valid." "Because it's a complex format and requires users to sacrifice expressivity and pay enormous costs in translation and maintenance, the Semantic Web will never achieve widespread public adoption." "New representations must be easy to translate to and from natural language. Any other approach ignores the representation problem, assumes that context-free facts and logical rules are sufficient, and will fail. The Semantic Web will fail because it inherits these problems and then couples them to the Web, which represents the breadth of human knowledge. It will fail." If the so-called semantic Web technology failed and will fail, then researchers and developers should explore alternative ways to realize the goal of semantic Web services.

As demonstrated, data and service semantics cannot be identified in a WSDL file, which contains the names of service, functions, input and output, as well as the relationships among the various objects that are used in the OOP. While the content of WSDL is not the meaning of the service, the aggregated process of service integration is also not the meaning of the service. Approaches built upon logical models to chain the services involved do not provide a solution and answer to the service requesters, but on the contrary such logic-based approaches increase the difficulty and burden to service requesters with the necessity to understand and deploy a complicated framework to derive the result. Such a complex system means only a few computer science professionals with such expertise can use the system while all others are unable to understand the terminologies and the logics used in those frameworks. If most people cannot use this technology, it is not a successful advancement but on the contrary, it aggravates the "digital divide" crisis in the world.

Transforming all composite Web services into atomic processes can be the short-term goal for developing semantic Web services. The ontology-enhanced semantic request and response approach focuses on the basic relationship between service requester and provider and embeds the data and service semantics into one single description document. Requesters can just follow the detailed semantic template of service request and response to deploy the services without the needs to handle the composite processes of service aggregation. Where are the Semantics in Semantic Web services? By now it can be concluded that the Semantics in Semantic Web services can be all defined and identified in the ServiceDescription.xml XML document. By parsing such XML, it's easy for machines to classify Web services by different service domains/sub-domains and function categories and sub-categories, while all requirements for service invocation can be predefined and released at the variable-level. Such advantages will help requesters to identify the required services more efficiently and accurately. While the UDDI framework should be changed accordingly, service registration and identification will be an easy process since once the service is registered, the UDDI system can process the ServiceDescription.xml XML document easily for detailed classification and initial matchmaking so that the requesters can easily locate specific services

It is suggested that the ontology definition of service domains and sub-domains needs to be classified by a standards body like the W3C or ISO, while each of the domain-specific service semantics have to be determined and developed through the bottom-up approach in real practice and application. The challenge lies in the negotiation and communication among different service domains to generate agreements and standards to describe domain-specific Web services. Describing service processes is not the right way to illustrate the service semantics since the requester only wants to know the answer to their request instead of receiving a complex framework from which to derive the answer by them. Creating semantic Web services via a logic deduction is almost impossible, as we discussed in this paper. Researchers should pay more attention to the standardization on domain-specific service description. For each specific service domain, if such a simple agreement cannot be achieved, then it's more difficult or impossible for people to figure out the unlimited unknown possibilities when using logics to figure out, or match, or guess, the relationships among different service providers. Today, all successful interoperable applications and developments are based on such standards or protocols like HTTP, HTML, WSDL, etc. rather than any logics. To realize semantic Web services, more standards and agreements have to be formulated with top-down and bottom-up approaches as the long-term goal.

Acknowledgement

The author gratefully acknowledges Dr. Greg Elmes' kind review and advice to this paper.

Resources

Learn

• Web Service Semantics - WSDL-S.
  
  
• Microsoft SOAP Toolkit Type Mappers
  
  
• Potential Modeling And Simulation Applications Of The Web Ontology Language - OWL from the proceedings of the 2004 Winter Simulation Conference
  
  
• Semantic Web Road map (developerWorks, Novem ber 2004) discussese the semantic communication that is necessary when developing and using geospatial Web services.
  
  
• Semantic request and response for standardized Web services.
  
  
• Removing Syntactic Barriers for Semantic Geospatial Web Services
  
  
• Rebuilding the Semantic Web Service Architecture (PDF) Proceedings of the ICWS 2005 Second International Workshop on Semantic and Dynamic Web Processes.
  
  
• Removing Syntactic Barriers for Semantic Geospatial Web Services
  
  
• Planning for Semantic Web Services
  
  
• Semantic Web Services Tutorial
  
  
• Towards a Semantic Web for Culture, from the Journal of Digital Information, Volume 4 Issue 4. Article No. 255, 2004-03-15.
  
  
• OWL-S: Semantic Markup for Web Services
  
  
• Web Services Architecture on W3C
  
  
• Web Service Modeling Ontology (WSMO)
  
  
• SOA and Web services -- hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  

Discuss

• Participate in the discussion forum.
  
  
• developerWorks blogs -- get involved in the developerWorks community.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• SOAP web services
• Semantic web services
• Rebuilding the semantic web service architecture
• Internet/distributed computing via HTTP/POST
• Challenges and conclusion
• Acknowledgement
• Resources
• About the author
• Comments

Next steps from IBM

WebSphere Application Server can leverage its built in Web Services support to expose services to remote consumers in an industry-standard way.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and includes built in Web Services support.
• Article: Learn how to use of the JAX-WS programming model to create dispatch and dynamic proxy clients and how to create an asynchronous Web service client.
• Tutorial: This tutorial takes you through the steps to deploy Data Web Services to the WebSphere Application Server Community Edition.
• Demo: This demo shows how to extract and install the IBM Java Platform, Java EE 5 SDK with WebSphere Application Server.
• Buy: WebSphere Application Server - Express

Dig deeper into SOA and Web services on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers