Web ServicesIntroduction to Web Services Part 2: Architecture

Introduction to Web Services Part 2: Architecture

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

In the previous article, the first in this series, we got a brief overview of Web Services. We also touched on some simple concepts and took a quick look at the problem space that Web Services try to address in the overall context of enterprise applications.

In this article, we will aim to set the overall direction for the rest of the articles in this series. We will cover the architecture of Web services and the technologies used in Web Services. Finally, we will study the steps involved in building a Web Services application.

The underlying premise on which Web Services is based is a purely service-oriented architecture. So, what exactly is a service-oriented architecture? And how different is it from popular architectures that are currently in use?

Architecture of Web Services

Client/server applications in use in the 80s and early 90s were primarily data-centric in nature. The focus was more on retrieval and display of data than on the business rules of the application. Web application architectures changed all this. Because Web applications are based on a distributed architecture, Web applications have moved away from the data-centric nature of client/server applications and tended more to a service-oriented architecture. The basic distributed technologies from Remote Procedure Calls (RPC), to Remote Method Invocation (RMI), to Common Object Request Broker Architecture (CORBA) are inherently service-oriented. Web applications have evolved from simple applications accessed and deployed in an Intranet to applications of different businesses/organizations “talking” to each other and exchanging data. The next step for Web applications is to provide business services that can be accessed by other applications of different businesses/organizations using the service-oriented architecture of Web Services. Moreover, the advantages of re-use in distributed Web applications have resulted in applications being designed to provide more business-related services.

When we talk about service-oriented architecture for Web Services applications, quite a few things come up. The application providing a service and the client application using the service talk to each other in a common language. Without both applications talking in the same language and exchanging information, the entire architecture will turn into one more addition to the tower of babel of distributed enterprise applications! Next, a service providing application and a client application using the service need some way to locate each other before they start talking with each other. This is especially true for distributed applications, where applications have no knowledge of each other’s location.

Hence, we can conclude that a basic service-oriented architecture for Web Services has:

  • a standard way for communication
  • a uniform data representation and exchange mechanism
  • a standard meta language to describe the services offered
  • a mechanism to register and locate Web Services-based applications

Take a look at Figure 1 that displays these building blocks.

Figure 1: Architecture of Web Services

After this discussion on the architecture of Web Services, let us take a brief look at the different technologies involved.

Technology Stack of Web Services

The mapping between the different layers of the Web Services architecture and the technologies used is listed below.

XML is a tried and tested way for exchanging data and has been extensively used in B2B applications. Hence, XML is used in the Web Services architecture as the format for transferring information/data between a Web Services provider application and a Web Services client application. The data embedded in an XML file is generated as well as processed using a powerful set of XML parser APIs viz. Simple API for XML (SAX) and Document Object Model (DOM) parser API.

Layer Technology Description
Uniform data representation and exchange XML

Extended Markup Language (XML) is a meta language that has a well-defined syntax and semantics. The syntax and semantics “self describing” features of XML make it a simple, yet powerful, mechanism for capturing and exchanging data between different applications.

Standard communication channel SOAP The Simple Object Access Protocol (SOAP) is the channel used for communication between a Web Services provider application and a client application. The simplicity of SOAP is that it does not define any new transport protocol; instead, it re-uses the Hyper Text Transfer Protocol (HTTP) for transporting data as messages. This use of HTTP as the underlying protocol ensures that Web Services provider applications and client applications can communicate using the Internet as the backbone. It is the use of SOAP that multiplies the capabilities of Web Services and make it all the more exciting!
Standard meta language to describe the services offered WSDL Web Services provider applications advertise the different services they provide using a standard meta language called the Web Services Description Language (WSDL). Interestingly, WSDL is based on XML and uses a special set of tags to describe a Web service, services provided, where to locate it, and so forth. Client applications obtain information about a Web service prior to accessing and using a Web service of a Web Service provider.
Registering and locating Web Services UDDI The “yellow pages” of Web Services is the Universal Description Discovery and Integration (UDDI). Web Services application providers are listed in a registry of service providers using UDDI. Similarly, client applications locate Web Services application providers using UDDI. Like in the case of WSDL, UDDI also is based on XML.

Figure 2: Technologies in Web Services

In the final part of this article, let’s get a quick overview of the general steps involved in building a Web Services application.

Basic Steps in a Web Services Application Development

If you have previously built applications based on distributed technologies such as RPC, RMI, CORBA, or EJB, you will have little difficulty in writing an application based on Web Services. The basic building blocks in a Web services application are:

Service Provider Service User
Define the services that will be provided Identify the services that will be required
Implement the functionality behind the services Locate the Web service by querying a directory service
Deploy the service provider application Send the request to the service
Publish the Web services with a directory service Receive the response from the service
Wait for processing client requests

Figure 3: Steps for building a Web Services application

These steps will be the same irrespective of which major technology/programming language that you use to implement the Web service. We will be writing an example Web service using one of the available programming languages in the coming weeks.


Today, we covered the overall architecture of Web services and listed the broad technologies involved. In the coming articles, we will elaborate and study each of these technologies step-by-step in detail to understand them better.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories