Introduction

Web services technology provides the foundation for the dynamic binding of distributed computing systems to enable the exchange and interaction of data and functions among heterogeneous computer networks through the Web Services Description Language (WSDL) interface. Since WSDL may contain embedded Web services or share the common object data types within more than one Web service, while the meaning and content of the data and services cannot be described, WSDL is a puzzle to the application developers who deploy Web services into their own applications. Anticipating the enormous growth of Web services by different service providers in the near future, it is difficult for application developers to track and understand the different routines for invoking Web services, even though Object Model and Flow diagrams and supplementary information materials about the services may be provided.

By standardizing the service request and response into an XML-based document that will be exchanged among service providers and service requesters instead of data objects and functions, the proposed approach for developing and using geospatial Web services will significantly improve the communication and implementation process for geospatial Web services. Such an approach will expose the hidden information encapsulated by the Object-Oriented techniques, while hiding the implementation details; a simplification of the development process that will lead to more robust geospatial Web services with potential for the artificially intelligent integration into the distributed computing systems. It is suggested that new standards and specifications on the service description for Web services in general, and on defining symbology and label in geospatial Web Services in particular, should be formulated to enable the building of a new generation of geospatial Web services for integrated mapping and geoprocessing that otherwise would be a great challenge to the Geographic Information Systems (GIS) professionals and the GIS community.

Back to top

The WSDL puzzle

WSDL is the key concept in developing and deploying Web services as WSDL sets up the contract between the service provider and service requester. WSDL describes the data types of the input-output variables, the name of the set of operations in each service, the format that the client must follow to invoke a service, and so on. However, the WSDL contract does not contain all the necessary information for requesting services. To understand how to invoke the Web service, the service requesters must do at least one of the following:

• Know the implementation details about how the Web service is constructed.
• Manipulate the WSDL files.
• Find the necessary information beyond the contract.
• Trace the object Diagram of the service.
• Learn from the samples.

This paper uses the example of ArcWeb Services from ESRI, a leading company in GIS software and technology. Given the example of ESRI's ArcWeb Services, its Address Finder Web Service has a function findAddress to find the location (longitude and latitude) of a given address. You can find the Address Finder Web Service's WSDL file at: http://arcweb.esri.com/services/v2/AddressFinder.wsdl. Since the WSDL is the contract between the service provider and service requester, the service requester first has to figure out how to invoke this service by studying the content of this contract.

The following section of the WSDL file, shown in Listing 1, describes how to invoke the function findAddress as the <portType> element identifies a set of operations and the messages involved with each of those operations.

<portType name="IAddressFinder">  
	<operation name="findAddress" parameterOrder=
	"address addressFinderOptions token">
	  <documentation>Returns an x,y-coordinate from an address.</documentation>
	  <input name="findAddress1In" message="tns:findAddress1In" />
	  <output name="findAddress1Out" message="tns:findAddress1Out" />
	</operation>
</portType>

Here, the <message> element describes the messages to be communicated -- the input message is named as findAddress1In, and the output message is named as findAddress1out. You can trace the details of the <message> element in the following segment of the WSDL file.

<message name="findAddress1In">
	<part name="address" type="ns13:Address">
		<documentation>the address find x,y-coordinates for.</documentation>
	</part>	
	<part name="addressFinderOptions" type="ns13:AddressFinderOptions">
		<documentation>options object.</documentation>
	</part>	
	<part name="token" type="xsd:string">
		<documentation>the authentication token.</documentation>
	</part></message><message name="findAddress1Out"></message>

	<message name="findAddress1Out">
	<part name="Result" type="ns12:LocationInfo">
		<documentation>LocationInfo location information object.</documentation>
	</part>
</message>

The <message> element describes the logical parts by the <part> child element. Each <part> element has both a name and type attribute that specify the message part name and its corresponding data type. To invoke the function findAddress, three data types are needed as address, AddressFinderOptions, and a string data type named as token. The order of the input variables is described in the <portType> element as parameterOrder="address addressFinderOptions token." The output data type is a LocationInfo object named as result.

The <types> element in the WSDL file defines the various data types to be used in exchanging the messages. Below is the description of each of the data types to be used as the input variables to invoke the findAddress service.

<xsd:complexType name="Address">
	<xsd:sequence>
		<xsd:element name="houseNumber" nillable="true" type="xsd:string" />
		<xsd:element name="street" nillable="true" type="xsd:string" />
		<xsd:element name="intersection" nillable="true" type="xsd:string" /> 
		<xsd:element name="city" nillable="true" type="xsd:string" />
		<xsd:element name="state_prov" nillable="true" type="xsd:string" /> 
		<xsd:element name="zone" nillable="true" type="xsd:string" />
		<xsd:element name="country" nillable="true" type="xsd:string" />
	</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="AddressFinderOptions">
	<xsd:sequence>
		<xsd:element name="dataSource" nillable="true" type="xsd:string" /> 
	</xsd:sequence>
</xsd:complexType>

For now, the service requester can understand what he needs to invoke the service: a series of string data types with different names that consist of the Address object data type and a string data type that describes the datasource. However, this WSDL file, or the contract, does not declare which element(s) may be a required or optional variable for the invocation. The contract declares neither how many nor what kind of data sources are available for invocation of the service. The service requester has to check the Web site of ArcWeb Services on "Data sources and credits" to understand available data sources that are not contained inside the contract. Although the <enumeration> data type in Web service development can partially resolve the problem to give out the options of data sources, WSDL itself is still a problematic guidance to the service requesters.

What about the string data type named as token? token is required as the input variable to invoke the findAddress service. However, the only clue that you can find in the WSDL file of Address Finder Web Service is the <documentation> element inside the <message> as the authentication token. After checking and tracing the ArcWeb Services, authentication is found as another Web service -- the Authentication Web Service that validates if the service requester can access ArcWeb Services. This means that the service requester has to sign another contract with the service provider to invoke the Address Finder Web Service.

Eventually, the output that the service requester obtains after invoking the service is an object data type -- LocationInfo. To find the location (longitude and latitude) of a given address, the service requester has to trace this object data type described as the follows:

<xsd:complexType name="LocationInfo">
	<xsd:sequence>
		<xsd:element name="matchType" nillable="true" type="xsd:string" /> 
		<xsd:element name="candidates" nillable="true" type=
		"ns12:ArrayOfLocation" /> 
		<xsd:element name="hasMore" type="xsd:boolean" /> 
		<xsd:element name="errorCode" nillable="true" type="xsd:string" /> 
	</xsd:sequence>
</xsd:complexType>

One of the elements in the LocationInfo is ArrayOfLocation data type that contains an array of the location datatype as described below. Given the example that only Morgantown is placed in the input variables to invoke the Address Finder Web Service, 15 locations of Morgantown in different counties and States will be returned as the output that consists of an array of candidate locations for final decision.

<xsd:complexType name="ArrayOfLocation">
	<xsd:complexContent>
		<xsd:restriction base="soapenc:Array">
			<xsd:attribute ref="soapenc:arrayType" wsdl:arrayType=
			"ns12:Location[]" /> 
		</xsd:restriction>
	</xsd:complexContent>
</xsd:complexType>

The location data type contains the point data type that finally provides the location information (longitude and latitude) as described below.

<xsd:complexType name="Location">
	<xsd:sequence>
		<xsd:element name="point" nillable="true" type="ns11:Point" /> 
		<xsd:element name="description1" nillable="true" type="xsd:string" /> 
		<xsd:element name="description2" nillable="true" type="xsd:string" /> 
		<xsd:element name="score" type="xsd:double" /> 
		<xsd:element name="matchType" nillable="true" type="xsd:string" /> 
		<xsd:element name="type" nillable="true" type="xsd:string" /> 
		<xsd:element name="locationExtent" nillable="true" type=
		"ns11:Envelope" /> 
	</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="Point">
	<xsd:sequence>         
		<xsd:element name="x" type="xsd:double" />          
		<xsd:element name="y" type="xsd:double" />          
		<xsd:element name="coordinateSystem" nillable="true" type=
		"ns11:CoordinateSystem" /> 
	</xsd:sequence>
</xsd:complexType>

Figure 1 summarizes the invocation process of Address Finder Web Service. Although WSDL is the contract between the service provider and service requester, it is a problem for application developers to understand the invocation details. In Web Service development, since many functions share the same object data types or one Web Service can be shared by the other Services, service providers reasonably develop the Service using the Object-Oriented techniques and the UML models.

However in practice, it is difficult for the service requesters to understand which Web service is embedded into the other services, or which component of certain object data types is used in the Web service or not. Once the service provider upgrades the services, the service requesters have to update their applications accordingly. For example, in the version 1 of ArcWeb Services, however, there was no point data type. The location data type contains the x, y value directly. Service requesters have to update their Address Finder Web Service applications to accept responses that include Point objects to retrieve the x and y coordinates. Otherwise, the application fails. This is one of the reasons for why Web service is not robust and stable.

The goal of this research is how to standardize and simplify the implementation process of geospatial Web services in particular, and Web services in the general domain, to enable the service requesters to get the appropriate result without needing to know how service providers have developed the Web services. Vogels (2003) claimed that the "XML document is the Web service's keystone because it contains all the application-specific information that a service consumer sends to the service for processing." Communication between the service providers and service requesters can be based on the exchange of such XML document that can explicitly describe the details of the services rather than the encapsulated or embedded data objects and functions.

Back to top

Exposing the hidden information through semantic request and response

The WSDL puzzle originates from the development of Web services based on the Object-Oriented technology in software engineering. In Object-Oriented programming (Schach, 2002), an object is a self-contained programming unit, consisting of both data and functionality to manipulate the data. Since objects encapsulate data and functional implementation, the object is a black box to the application developers in Web services. The hidden information contained in the object makes it difficult for application developers to understand how to invoke the services.

A WSDL file only describes the data types, as well as the name of data types and the operations or functions and so on, but does not describe the meaning of the data type. Some of the data types describe the content of the data through the name of the element, for example, the element of street as a string data type in the address data type in the WSDL file of the Address Finder Web Service. However, in the Address Finder Web Service, the location data type in the WSDL file contains the elements named as <description1> and <description2> without any meaning.

What are <description1>; and <description2>? ESRI (2004) explains these elements in the online document of ArcWeb Services as the follows:

• description1 contains the long description of the place (for example, Redlands, California, United States).
• description2 contains the short description of the place (for example, Redlands). Not used in Address Finder.

<description2> is not used in the Address Finder Web Service but is a part of the WSDL contract of the Address Finder Web Service. It seems that the WSDL contract is not self-validated and is not explicitly composed when the computer programs generate the WSDL file. It can be concluded that Object-Oriented techniques are advantageous for developing Web services, but the WSDL file derived from the encapsulated object data types in Object-Oriented programming is not good for the communication between the service providers and service requesters.

While Web services technology resolves the technical problems of non-interoperability among distributed computing systems, it should also remove the obstacles of semantic non-interoperability among the computers and developers. To expose the hidden information inside the encapsulated black boxes to deploy the services, examine how to invoke the Address Finder Web Service and understand the whole implementation process as described in Listing 7. Visual Basic .NET is used to demonstrate the coding examples in this paper, although you can describe the same idea using Java programming and C#.

	Dim myAddress As New Address()
	myAddress.houseNumber = "888"
	myAddress.street = "Willey St"
	myAddress.city = "Morgantown"
	myAddress.state_prov = "WV"
	myAddress.zone = "26505"
	
	Dim myAddressFinderOptions As New AddressFinderOptions() 
	myAddressFinderOptions.dataSource = "GDT.Streets.US"
	
	Dim myAuthentication As New Authentication()
	Dim token as Stringtoken = 
	myAuthentication.getToken("[username]","[password]", 5)
	Dim myAddressFinder As New com.esri.arcwebservices.AddressFinder ()
	Dim myLocationInfo As New LocationInfo()
	
	myLocationInfo = 
	myAddressFinder.findAddress(myAddress,myAddressFinderOptions,token)

In this process, some of the variables are primary elements that are necessary for input, while others are optional. For example, besides house number and street name, the Address object has one more optional property as Cross Street which is not shown in the above code segment. All others are obligatory in the invocation process. How can you know such details in the black box? Considering the huge number of Web services to be developed and utilized in the near future, it is difficult for application developers to trace and understand the different routines for invoking the Web services generated by different service providers, even though the object model and flow diagrams or descriptions are provided.

Semantic invocation of Web services will focus on the standardization of service request and response to simplify the programming routine and make the invocation machine readable and understandable. The whole process is described in Listing 8, being in contrast with the above coding section in Listing 7 for invoking the Address Finder Web Service.

	Dim myService As New com.esri.arcwebservices ()
	Dim request as String
	Dim response As String
	request = getRequestXMLDoc()
	response = myService.getService(request)

Here, both the request and response are XML documents that describe the details and procedures of the routine of invocation that contain the requirements for the input variables and output product. First the service requester needs to edit the XML document described in Listing 9 and then create a function getRequestXMLDoc to read the XML document as a string or as a URL that refers to this document, depending on the specification from the service provider.

Traditionally, the service name is the object name for functional invocation, such as AddressFinder, that has a function as findAddress. However, the semantic request and response exposes the development routines by standardizing the whole coding process into an XML document. In this way, all kinds of Web services can share the same functional interface just as getService(request).

Given the example of the Address Finder Web Service, its invocation can be based on the following XML document as the input request, as shown in Listing 9. In this way, the hidden information in Object-Oriented programming can be exposed to the service requesters.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<ServiceRequest>  
	<Service Name="AddressFinder">    
		<Function Name="findAddress">       
			<InputVariables>    
				<address>    
					<houseNumber>888</houseNumber>    
					<street>Willey St</street>    
					<city>Morgantown</city>    
					<state_prov>WV</state_prov>    
					<zone>26505</zone>    
				</address>    
				<datasource>GDT.Streets.US</datasource>    
				<username>[username]</username>    
				<password>[password]</password>       
			</InputVariables>    
		</Function>  
	</Service>
</ServiceRequest>

Back to top

Hiding the implementation details through semantic request and response

The output of the Address Finder Web Service is a LocationInfo object that contains such information as Number of Candidates, Match Type, and so on, as well as an array of Location object types, as discussed earlier. To retrieve the location (longitude and latitude) information, the following highlighted code segment has to be used in Visual Basic .NET, as described in Listing 10.

Dim myAddress As New Address()
myAddress.houseNumber = "888"
myAddress.street = "Willey St"
myAddress.city = "Morgantown"
myAddress.state_prov = "WV"
myAddress.zone = "26505"
	
Dim myAddressFinderOptions As New AddressFinderOptions() 
myAddressFinderOptions.dataSource = "GDT.Streets.US"
	
Dim myAuthentication As New Authentication()
Dim token as Stringtoken = myAuthentication.getToken("[username]","[password]", 5)
Dim myAddressFinder As New com.esri.arcwebservices.AddressFinder ()
Dim myLocationInfo As New LocationInfo()
	
myLocationInfo = myAddressFinder.findAddress(myAddress,myAddressFinderOptions,token)
	
Dim loc As New com.esri.arcwebservices.Location()
loc = locInfo.candidates(0) 'just retrieve the first record
Dim strLocation As String
strLocation = loc.description1 + " is located at: " + 
" Longitude: " + loc.point.x + ", Latitude: " + loc.point.y
	

Again, the hidden information can be exposed explicitly through semantic response as described in Listing 11. For example, the meaning of the <description1> element in the WSDL file can be exposed explicitly in the <LocationDescription> element in the semantic response retrieved from the service provider.

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<ServiceResponse>  
	<Service Name="AddressFinder">    
		<Function Name="findAddress">       
			<InputVariables>    
				<address>    
					<houseNumber>888</houseNumber>    
					<street>Willey St</street>    
					<city>Morgantown</city>    
					<state_prov>WV</state_prov>    
					<zone>26505</zone>    
				</address>    
				<datasource>GDT.Streets.US</datasource>    
				<username>[username]</username>    
				<password>[password]</password>       
			</InputVariables>    
			
			<OutputResult>        
				<NumberOfCandidates>1</NumberOfCandidates>
				<Location>             
				  <LocationDescription>888 Willey 
				  St, Morgantown, WV 26505</LocationDescription>
				  <longitude>-79.946623</longitude>             
				  <latitude>39.635351 </latitude>        
				</location>   
			</OutputResult>
			
		</Function>  
	</Service>
</ServiceResponse>

Meanwhile, and most importantly, semantic request and response can hide the implementation details for invoking the Web services, as shown in Listings 10 and 11. In the traditional way of invocation as shown in Listing 10, service requesters have to invoke another ArcWeb Service named Authentication by passing the required variables (username, password, and minutes to expiration) to retrieve the token as the authentication to get access to the Address Finder Web Service. To retrieve the location information (longitude and latitude), the service requester first has to retrieve a LocationInfo object by invoking Address Finder Web Service then create a location object to retrieve the value of longitude and latitude from the candidates of the LocationInfo object. Through semantic response, as described in Listing 11, service requesters can ignore all such implementation details to make the implementation more compact and efficient.

One of the main weaknesses of Web services is that a Web service is not stable or robust because if the service provider changes the architecture design in the Object-Oriented program, the service requesters have to make the same change accordingly to update and then invoke the service. Otherwise, the provided service will not work. As for the Address Finder Web Service applications, you have to make the changes as the service provider upgrade its service from version 1 to version 2, as described in Table 1:

Table 1: Parameter changes

However, through semantic response, service requesters don't need to make any changes in coding as described in Listing 8 because what service requesters need to know is the location information (longitude and latitude), which is not changed in the XML document of semantic response as described in Listing 11. Unless the service provider makes fundamental changes in the system design and implementation, the service requesters don't need to care about such changes due to the changes in object design. In this way, you hide the implementation details and simplify the whole process to invoke the service.

Back to top

Standardized semantic Web services

Invocation of Web services can be standardized into the following format, as described in Listing 12.

	Dim myService As New com.esri.arcwebservices ()
	Dim request as String
	Dim response As String
	
	Dim description as String
	description = myService.getServiceDescription()
	request = getRequestXMLDoc()
	response = myService.getService(request)

Service providers need to provide two functional interfaces as getService and getServiceDescription. getServiceDescription offers an XML document that contains all necessary information and guidance to invoke the function of getService. All hidden information should be exposed in getServiceDescription, such as the information about which input and output variables are necessary or optional, and so on, through the XML schema of the template documents of service request and response.

Given the example of Address Finder Web Service, a template of semantic request and response can be included in the XML document that is retrieved by requesting the getServiceDescription function. This template can be described as shown in Listing 13 (sidefile).

The template in Listing 13 is self-explanatory. To invoke the Address Finder Web Service, the requester needs to edit an XML document that includes the necessary elements described in the <description> section of the template, such as:

• XML declaration
• ServiceRequest
• Service with the name of the service
• Function with the name of the function
• Sets of InputVariables as described in the element ServiceRequestTemplate that define which input variables are optional, what options can be used as the data sources, and so on.

The template also tells the requester that, in order to send the request for a Web Service using the functional call response = myService.getService(request) (See details in Listing 13), the acceptable content of the string data type for request input should be a URL that refers to the XML document of the service request template. Thus the requester has to save the XML template for request as an XML document that can be placed in a Web server directory. The URL can be retrieved using the functional call request = getRequestXMLDoc() (See details in Listing 13).

Before the service requester sends the request to invoke the service, the XML template of the service request can be validated in the function getRequestXMLDoc, based on the XML schema provided by the service provider. If the service request cannot pass the validation process, the service requester understands that the service provider makes updates in the provided services. In this case, the service requester only needs to check the template XML document of service description to see if there are any new requirements for the invocation.

For example, the ArcWeb Service added the dataSource parameter to some of it services that did not already have it. The data source is now required in all such requests listed in Table 2:

Table 2: ArcWeb Service that contains dataSource object data type

The service requester needs to insert necessary new nodes into the XML template of the service request, rather than change the coding segment as shown in Listings 7 and 10. While Object-Oriented techniques can continuously be used in developing Web services, semantic request and response will be superior in the communication among service providers and service requesters. Semantic invocation will standardize and simplify the development and utilization of Web services meaningfully and significantly to make it more stable and robust. In this way, the content of the Web service contract between the service provider and service requester will be more meaningful and explicit.

Since Web services can be standardized through semantic request and response, the role of WSDL and UDDI needs to be reconsidered, as everything can now be described in the XML template including:

• The content
• Meaning and specification of the input/output variables
• Functional capabilities
• How to use such semantic request and response to invoke Web services.

This means that all WSDL files can have the same syntax and content, except for the name and location of the Web services. In this case, WSDL will only be the interface for service requesters to identify and invoke Web services without any other meaning, because all Web services can have the same two functional interfaces: getServiceDescription:string and getService(request:string):string.

Back to top

Conclusion

WSDL itself cannot explicitly describe the content and meaning of a Web service. It is difficult for service requesters to trace the object diagrams or the supplementary descriptions to figure out the implementation details of the services, the hidden services, and the shared common object data types used in multiple services. How to enable service requesters to deploy Web services in a simple, stable, and efficient way should be a main concern and task for service providers. It has been demonstrated by this research that Web services, including geospatial Web services, can be standardized through the semantic request and response approach that can explicitly expose all hidden and required information inside the WSDL and the corresponding Web services and hide the implementation details to the service requesters to make the Web services more robust and stable. The main difference between the traditional Web service implementation and the new approach, as described in Figure 2, is that the new approach exchanges the XML document rather than the data and functions between the service provider and service requester.

Semantic templates for Web services request and response will establish an explicit contract between the service provider and the service requester. The semantic template of service description will make a fundamental contribution to the artificially intelligent integration of distributed computing systems to automatically match and chain Web services capabilities. As a result, the meaning of the data and function and the request for services are made explicitly machine-readable and understandable. Artificial intelligence refers to the ability of the computer to simulate human behavior. To invoke the Web services, such human behavior is described in Figure 1 in which red, dashed arrows indicate the obstacles to computers to simulate human behavior, since computer can only "understand" the Web services through WSDL rather than automatically find the supplementary information beyond the WSDL. However, if the invocation of Web services needs only to exchange the XML document, which explicitly contains all required information and direction, it is possible for computers to do it automatically without any human intervention. Such an approach is also different from the current research of ontology-based semantic Web services that still deals with the exchange of object data types and functions rather than the exchange of XML documents containing the meaning and content description of the data and services, for example complexTypes (the collection of elements in WSDL schema) is modeled in ontology-based specifications as a class-subclass hierarchy with properties as shown in Figure 1. Such hierarchy is not necessary and can be ignored in the exchange of XML documents, as the service requester just wants to know the x, y values rather than the implementation details on the server side.

Developers and consumers of geospatial Web services are facing new challenges on how to describe the content and functionalities in the new generation of geospatial Web services for mapping, geoprocessing, and integration. Given the example of building interactive mapping services in which service requesters can define the symbology and label styles for certain geospatial features in the map, how the syntax and content can be mutually comprehensible will depend on the creation of standards and specifications in the GIS domain. Object-Oriented techniques will not be a good approach again in such a situation, because, for example, to create a shield label for an Interstate road feature, more than 60 lines of code have to be generated using ArcObjects in Vb.NET. However, if such a shield label can be defined explicitly, it can be just a line of text element in the XML template of a service request. Such power has already been demonstrated by the standards and specifications on the Spatial Reference System (SRS). Many Open GIS Consortium (OGC) Web Map Service (WMS) servers use the pre-defined European Petroleum Survey Group (EPSG) projections, such as EPSG:4326 refers to WGS84 (World Geodesic Datum), EPSG:26917 refers to NAD83 / UTM zone 17N, and EPSG:26717 refers to NAD27 / UTM zone 17N, etc. Standardized specifications on the symbology and labeling can follow the same mechanism as EPSG and will be one of the most challenging tasks in the following days. OGC is expected to start working on new initiatives in this domain. The next great challenge will be to standardize the service template into the XML document in order to build a new generation of Web services in the general domain with self-describable data and service semantics.

Back to top

References

1. ESRI. 2004. ArcWeb Services. http://arcweb.esri.com/arcwebonline/ (last accessed August 23, 2004)

2. Schach, S. R. 2002. Object-Oriented and Classical Software Engineering. McGraw-Hill.

3. TerraServer. 2004. http://terraserver.microsoft.com/ (last accessed August 23, 2004)

4. Vogels, W. 2003. Web Services Are Not Distributed Objects. IEEE Internet Computing. Vol. 7, No. 6

Resources

• Get a history and overview of Eclipse, including details on how to install Eclipse and plug-ins in the article Getting started with the Eclipse Platform (developerWorks, November 2002).
  
  
• If you are a Java developer using Eclipse, then Eclipse In Action: A Guide for Java Developers (Independent Pub Group, 2003) is a must-read.
  
  
• Browse all of the Charming Python columns on developerWorks.
  
  
• Get the latest version of Netbeans, an open source IDE for Java application development, at the Netbeans Web site.
  
  
• Access Web services knowledge, tools, and skills with Speed-start Web services, which offers the latest Java-based software development tools and middleware from IBM (trial editions), plus online tutorials and articles, and an online technical forum.
  
  
• Browse for books on these and other technical topics.
  
  
• Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• Introduction
• The WSDL puzzle
• Exposing the hidden information through semantic request and response
• Hiding the implementation details through semantic request and response
• Standardized semantic Web services
• Conclusion
• References
• Resources
• About the author
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into SOA and Web services on developerWorks

Discover knowledge paths

Skill-building guides for Linux, open source, cloud, Java, business analytics, and more.

Special offers