Anatomy Of A Web Service

ANATOMY OF A WEB SERVICE*

STUDENT PAPER

Kamalsinh F Chavda
Kennesaw State University
Kennesaw, GA

ABSTRACT
One of the newest innovations for the use of the Internet is Web services. Web
services allow applications and Internet-enabled devices to easily communicate with
one another and combine their functionality to provide services to each other,
independent of platform or language. Web services are characterized by SOAP
messages used to talk to a Web service, WSDL files that describe a Web service,
and the UDDI used to find Web services. Conceptually, Web services are very
understandable. They eliminate many of the complexities that have been required
when there is a need for computer applications to interact with each other. The
question then becomes, is the development of Web services substantially less
complex than the prior options available for creating interoperable components?
That question is assessed in this paper through the development and annotation of
a basic Web service. Software applications like Visual Studio .NET have greatly
simplified the creation of Web service and consequently Web services are the
future.

INTRODUCTION
The twentieth century saw unprecedented advancement in technology. The 1990s fostered
growth in communications and information technology as never seen before. The Internet, which
had started as an effort to facilitate research and development for educational and military
purposes, became the backbone for businesses and communication media for people all over

___________________________________________

*
Copyright © 2003 by the Consortium for Computing Sciences in Colleges. Permission to copy
without fee all or part of this material is granted provided that the copies are not made or
distributed for direct commercial advantage, the CCSC copyright notice and the title of the
publication and its date appear, and notice is given that copying is by permission of the Consortium
for Computing Sciences in Colleges. To copy otherwise, or to republish, requires a fee and/or
specific permission.

124

CCSC: Southeastern Conference

the world. As the Internet grew, and is still growing, so are its uses. One of the newest
innovations for the use of the Internet is Web services. This new technology will change the
way business is done on the Web. It allows applications and Internet-enabled devices to easily
communicate with one another and combine their functionality to provide services to each other,
independent of platform or language.
A Web service is a programmable application component that can be accessed over the
Internet and used remotely. Web services are built on existing Internet standards such as XML,
HTTP, and other protocols that support interoperability. Using these standardized protocols,
Web services allow developers to create open applications that are compatible with different
programming languages, operating systems, hardware platforms, and are accessible from any
geographic location. As a result, any system capable of communicating via a standard Internet
transport protocol can communicate with a Web service. While Web services can be used
internally by a single application, they are designed to be used externally over the Internet by
multiple applications. The only information that the Web service provider and client need to
share are the inputs, outputs, and location of the Web service.
Some of the most prevalent pre-Web services technologies were Electronic Data
Interchange, Common Object Request Broker Architecture, Distributed Component Object
Model, Unix Remote Procedure Call, and Java Remote Method Invocation. EDI was difficult
to implement because of its complexity and cost. The problem with CORBA and DCOM was
that they competed with each other, and were relatively difficult for programmers. This led to
neither one of them gaining broad industry support. Unix RPC was never widely deployed
outside the Unix vendors and thus didn't gain a wider market share. Sun's Java RMI technology
was gaining acceptance but after the break with Microsoft its future is uncertain.
These technologies still exist today but failed to gain significant market share due to cost,
complexity, flexibility, industry support, and compatibility issues.
Web services allow developers to utilize four open Web standards: HTTP, SOAP, XML,
and WSDL. Markatos (2002) eloquently describes these standards:
"1. HTTP - Hypertext Transfer Protocol - the standard protocol used over Port 80 that
traverses firewalls, which is responsible for requesting and transmitting data over the
Internet.
2. SOAP - Simple Object Access Protocol - an XML inherent protocol enclosing a set
of rules for data description and process that is the center piece paralleling and
complementing the other three mentioned here, with which .NET utilizes nicely with Web
Services.
3. XML - Extensible Markup Language - the prominent markup language that all this
commonly understood information is written in.
4. WSDL - Web Services Description Language - an XML based method use in
identifying Web Services and their access at runtime. .NET provides a tool called
WSDL.exe which essentially makes it quite easy in generating an XML Web service,
rather an XML file containing all the methods and instructions the Web Service has, using
SOAP as its default btw" (¶2).

125

JCSC 19, 3 (January 2004)

A Web service is, therefore, any service that is available on an internal network, Intranet,
or on the Internet, which uses a standardized XML messaging system for communication
between client and service, is platform and programming language independent, has an interface
definition, and is discoverable using a simple find mechanism (Cerami, 2002).
The way a Web service works is that a requesting client application sends its request to
the service-providing application using the XML based SOAP protocol. The service-providing
application receives the request, processes its business logic, and sends the response back using
the same SOAP protocol. The SOAP protocol is an industry standard that is maintained by
the World Wide Web Consortium, otherwise known as W3C. Since the SOAP protocol is an
XML-based format it is used as a remote procedure call, transmitted over HTTP through
firewalls and proxy servers to invoke remote methods. SOAP is platform-independent and
therefore enables different applications to communicate. According to the SOAP 1.1 definition
by Box, Ehnebuske, et al (2000):
"SOAP provides a simple and lightweight mechanismfor exchanging structured and typed
information between peers in a decentralized, distributed environment using XML. SOAP
does not itself define any application semantics such as a programming model or
implementation specific semantics; rather it defines a simple mechanism for expressing
application semantics by providing a modular packaging model and encoding mechanisms
for encoding data within modules" (¶1).
A SOAP message consists of four XML elements: envelope, header, body, and fault. The
envelope is the root element of a message that describes what is in a message; it identifies the
SOAP message. The envelope also contains the optional header element that contains
application specific information about the message. A mandatory body element in the envelope
contains the actual data intended for the recipient of the message. The body element also
contains the fault element that is used to carry error messages from a SOAP message. It is a
standard way of communicating error messages back to the client.
The Web Services Description Language (WDSL) is used to describe the public interface
of a Web service. The WSDL file is an XML document that describes a set of SOAP
messages and provides the information necessary for a client to interact with the Web service.
It specifies the location of the service, the publicly available operations, functions (or methods)
the service exposes, data type information for all XML messages, and the communication
protocol used to talk to the service. WSDL specifies what a request message must contain and
what the response message will look like. Using WSDL, a client can locate a Web service, and
invoke any of the public functions.
All WSDL documents contain a definitions element that is the root element. Within this
element, are the following five elements that describe a Web service:
Types define the data types used by the Web service.
Messages describe the messages that are exchanged between a client and a service. Also
describes the data elements of an operation such as function parameters.

126


Port Type defines a Web service, the operations that can be performed, and refers to
input and output messages. Four basic operations supported by WSDL: one-way,
request-response, solicit-response, and notification.
Bindings define how an operation will actually be transmitted; the message format and
protocol details for each operation in the Port Type section. WSDL includes built-in
extensions for SOAP.
Services: Specifies port address (es) of each binding and the location of the service.
The availability of a Web service for public consumption can be advertised. The Web
service interfaces described by WSDL may be put into a directory called Universal Description,
Discovery and Integration (UDDI). The UDDI is a central directory service where businesses
can publish, register, and search for Web services. The data stored in the UDDI directory is
in XML format. The data captured within UDDI is divided into three main categories: white
pages, yellow pages, and green pages. The white pages contain general information like name,
description, address, etc. about a company offering the service. The yellow pages contain
general classification data on industrial categories based on standard taxonomies for either the
company or the service offered. The green pages contain detailed technical information about
a Web service allowing someone to write an application to use the web service (Cerami, 2002).
These categories make it easy for users to search for industry specific Web services and create
client applications to access them.

CREATING A WEB SERVICE
As previously outlined, Web services are characterized by SOAP messages used to talk
to a Web service, WSDL files that describe a Web service, and the UDDI used to find Web
services. Conceptually, Web services are very understandable. They eliminate many of the
complexities that have been required when there is a need for computer applications to interact
with each other. The question then becomes, is the development of Web services substantially
less complex than the prior options available for creating interoperable components. That
question is assessed in this paper through the development and annotation of a basic Web
service.

Figure 1. Choosing to Create a Web Service in Visual Studio.NET

127


Several development environments are available for creating Web services. This paper
employs the use of Microsoft's Visual Studio.NET. Web services are a major focus of
Microsoft's .NET initiative and Visual Studio.NET is designed to facilitate their development.

Imports System.Web.Services
<WebService(Namespace:="http://tempuri.org/")> _
Public Class SimpleCalc
Inherits System.Web.Services.WebService
#Region " Web Services Designer Generated Code "
Public Sub New()
MyBase.New()
'This call is required by the Web Services Designer.
InitializeComponent()
'Add your own initialization code after the
InitializeComponent() call
End Sub
'Required by the Web Services Designer
Private components As System.ComponentModel.IContainer
'NOTE: The following procedure is required by the Web Services
Designer
'It can be modified using the Web Services Designer.
'Do not modify it using the code editor.
<System.Diagnostics.DebuggerStepThrough()> Private Sub
InitializeComponent()
components = New System.ComponentModel.Container()
End Sub
Protected Overloads Overrides Sub Dispose(ByVal disposing As
Boolean)
'CODEGEN: This procedure is required
'Do not modify it using the code editor.
If disposing Then
If Not (components Is Nothing) Then
components.Dispose()
End If
End If
MyBase.Dispose(disposing)
End Sub
#End Region
<WebMethod(Description:="Add two numbers")> _
Public Function Add(ByVal a As Long, ByVal b As Long) As Long
Return a + b
End Function
End Class

Figure 2. Sample Code for a Simple Web Service
Getting started with Visual Studio .NET is fairly simple. Visual Studio.NET employs the
use of projects. When creating a new project, the user is prompted to choose from a list of
project types and which programming language will be used. To create a Web service the
ASP.NET Web Service template should be selected and then the preferred programming
language such as Visual Basic.NET. Figure 1 demonstrates the selection of icons for creating

128


a Web service in Visual Studio.NET. After selecting the template, Visual Studio .NET will
automatically create all the necessary files to support the solution along with a default Web
service .asmx file. The developer can use the default Web services file as a template.
The Web service created for this example is a simple Web service that takes in two
numbers and adds them together. The code for the Web service is depicted in Figure 2.
Most of the code in the example was Visual Studio .NET. Only the 'Public Class Name'
and the 'Public Function' code were modified. The next step is to build a solution, debug it if
necessary and then execute it. If done using Visual Studio.NET, the build will result in the Web
service being displayed in an Internet Explorer window as shown in Figure 3. Both the Web
service and its associated WSDL file appear as links.

Figure 3. Web Service as shown in an Internet Explorer Window

When the function of the Web service is clicked, (in this case Add) another Internet
Explorer window opens where the function can be tested by invoking it as seen in Figure 4.
The result, an XML document, will be shown in another Internet explorer window as seen in
Figure 5.

Figure 4. Testing the Web Service
Along with letting the user invoke the service the page also shows the SOAP and HTTP
GET and HTTP POST request and response. The code is automatically generated for the web
service. It is how the client and the web service communicate. Upon calling the web service the
client application would send the SOAP request via HTTP POST.

129


Figure 5. Results of Testing the Web Service in XML
The following SOAP message contains two parts: HTTP header and SOAP envelope.
The http header specifies the transport protocol that the message will be using to communicate.
It also specifies the name of the service along with where the host service is located. The
content type, character set, and content length are defined in the header. The message has a
SOAPAction header, which is a server-specific URI used to indicate objective of the request
message.

Figure 6. Example SOAP Request

Before the envelope element starts the XML version is specified. The envelope root
element references XML namespaces and schemas. The mandatory body element contains the
actual data intended for recipient of the message. It contains the function parameters necessary
for the interaction.
Below is the SOAP response, which indicates that the response was successful. It states
the XML version and schemas and namespaces used just like the SOAP request. The response
carries out the operation that the request asked for and responses with a return value.

130


Figure 7. Example of SOAP Response

In order to further understand what the service does, users can access the WSDL file by
clicking on the service description link. As mentioned earlier, WSDL specifies the public
interface for a Web service. The WSDL file contains 6 elements, which help further understand
what really goes on when a SOAP message is sent to a Web service. The definitions element
is the root element. It defines all the namespaces used in the document. The schemas are used
to reference WSDL, SOAP, and XML specifications.
The targetNamespace enables the WSDL document to refer to itself. A default
namespace: xmlns= http://schemas.xmlsoap.org/wsdl/ is used for elements without namespaces.
The types element describes the data types used between client and server. The data
types are specified as an XML schema data type. The message element describes how the
messages communicate and what messages are involved. The message name attribute provides
a unique name to all the messages in a WSDL document. The part name attribute provides a
unique name to all parts in a message. Type and element are message-typing attributes. Type
specifies an XML Schema data type, element refers to an XML schema element.
The port type element describes the port type using a unique name. It also defines what
kind of operation needs to be carried out from the four supported by WSDL: one-way,
request-response, solicit-response, and notification. The operation name uniquely identifies the
operation. The port type also shows the messages that form an operation. The message
attributes are specified as an XML schema.
The binding defines how an operation will actually be transmitted, the message format and
protocol details for each operation in the Port Type section. The binding name attribute
provides a unique name to all the bindings in a WSDL document. The type attribute references
a port type from the port type element. This Web service is using soap: binding to make the
binding available. The transport attribute indicates the transport of the SOAP message will be
via HTTP transport. The document style value indicates that the request and response messages
will be XML documents. The soap: operation element indicates the binding of the "Add"

131


WSDL includes built-in extensions for SOAP. This Web service is using soap: binding
to make the binding available. The transport attribute indicates the transport of the SOAP
message will be via HTTP transport. The document style value indicates that the request and
response messages will be XML documents. The soap: operation element indicates the binding
of the "Add" operation to SOAPAction. The service must be identified using the SOAPAction
HTTP header. The soap: body element specifies that the details of the input and output
messages be literal.
The service element specifies port address (es) of each binding and the location of the
service. The service name attribute specifies the name of the Web service. This should be the
same as the .asmx file. It specifies the port and binding used to access the service. The soap:
address element specifies the local host address for the service. Below is the WSDL document
for the SimpleCalc Web service.

132


Compared to the other means of developing interoperable components Web services
represent a much more simple method for achieving the same goals. With integrated
development environments such as Microsoft's Visual Studio.NET, the creation of a Web
service is greatly simplified by auto-generated code and supporting files. Further, by deploying
standards for discovery, description, and message communication, Web services are easy to
understand, utilize and implement.

CONCLUSION
In today's world, technology has affected how we live and function. New technology is
being created everyday and there are more and more people using these new gadgets and
software. The vision is for these technologies to integrate seamlessly. Web services provide
a means to move technology closer to this vision. Web services will change the face of business
on the Internet. Businesses will be able to create Web services and their clients will be able to
connect to them using SOAP and standard Internet protocols. The WSDL files will allow users
to understand how the service works. Businesses and clients will be able to search for other
Web services using the UDDI directory. Software applications like Visual Studio .NET will also
make the process of creating a Web service very easy. Due to the language and platform
independency Web services will flourish. Web services are the future.

133


REFERENCES
Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H. F., et al. (
May 8, 2000). Simple Object Access Protocol (SOAP) 1.1. Retrieved April 5, 2003 from
http://www.w3.org/TR/SOAP/
Cerami, Ethan. ( February 12, 2002). Top ten FAQs for Web Services. Retrieved April 11,
2003 from http://www.oreillynet.com/lpt/a/webservices/2002/02/12/webservicefaqs.html
Cerami, Ethan. (2002). Web Services Essentials. California: O'Reilly & Associates, Inc.
Christensen, E., Curbera, F., Meredith, G., Weerawarana, S. (March 15, 2001). Web
Services Description Language (WSDL) 1.1. Retrieved April 5, 2003 from
http://www.w3.org/TR/wsdl
Ewald, Tim. ( September 27, 2002). Understanding XML Web Services: The Web
Services Idea. Retrieved March 20, 2003 from
http://msdn.microsoft.com/webservices/understanding/readme/default.aspx
Introduction to Web Services Part I. (n.d.). Retrieved February 23, 2003 from
http://www.epionet.com/webservices/articles/art_webservicesintro1.html
Introduction to Web Services Part II. (n.d). Retrieved February 23, 2003 from
Introduction to Web Services Part II. (n.d). Retrieved February 23, 2003 from
Kalata, Kathleen. (2002). Introduction to ASP.NET. Massachusetts: Course Technology.
Markatos, Dimitrios. ( November 19, 2002). Creating and Consuming .NET Web Services
in Five Easy Steps. Retrieved March 25, 2003 from
http://www.dotnetjunkies.com/tutorials.aspx?tutorialid=603
Skonnard, Aaron. (March 2003). Understanding SOAP. Retrieved April 10, 2003 from
http://msdn.microsoft.com/webservices/understanding/webservicebasics
SOAP Tutorial.(n.d). Retrieved April 9, 2003 http://www.w3schools.com/wsdl/default.asp
Tapang, Carlos C. (July 2001). Web Service Description Language (WSDL) Explained.
Retrieved April 5, 2003 from http://msdn.microsoft.com/library
WSDL Tutorial.(n.d). Retrieved April 9, 2003 from
http://www.w3schools.com/wsdl/default.asp
Wolter, Roger. (December 2001). XML Web Services Basics. Retrieved April 9, 2003 from
http://msdn.microsoft.com/library
Levitt, Jason. (October 1, 2001). From EDI To XML And UDDI: A Brief History Of Web
Services. Retrieved May 5, 2003 from
http://www.informationweek.com/story/IWK20010928S0006

134

Anatomy Of A Web Service

More Related Content

What's hot (18)

Similar to Anatomy Of A Web Service (20)

Anatomy Of A Web Service