introduction to web services

J.E.D.I
1. Introduction to Web Services
1.1 Objectives
Towards the end of the chapter, you should be able to learn the following:
• Determine what web services are
• Identify the characteristics of a web service and how it works
• Point out the need for web services
1.2 Introduction
The domain of web services is an emerging technology due to the growing demand of
application-to-application communication and interoperability. The reason for its popularity is
because of its flexible nature, since it exhibits itself as a standard interface which is not only
platform-independent but technology independent as well. We'll talk more about this later.
This chapter will cover the evolution of network computing, an overview of how the web
service model came to be, the definition of web services, its properties and and what states or
scenes are they applicable to. And lastly, the discussion of the current status of web services and
where it is heading.
1.3 How did web services came to be? (A History of
Distributed Computing)
During the prehistoric era in software services, computer programs were written in
assembly and are executed using single memory space (see Figure 1). The software's subroutines
communicate digitally using the machine's registers. Programmers during this time find it hard to
write, more so, maintain codes.
Shortly after assembly, came procedural languages such as COBOL, C and FORTRAN, which
allowed programs to be written more easily than their forerunner since they resemble more the
human language. Moreover, these procedural languages allow programs to run on different
machines. The software service during this time were functions that were directed by the use of
control structures. Although this is a technological advancement in computing, it is no different
with assembly in the sense that programs are executed in single memory space.
1 of 14
J.E.D.I
Figure 1

Communication in single memory space in the same computer
The next generation was the development of network computing, wherein, instead of
communicating through magnetic tapes, the exchange of information became real-time. TCP/IP
network protocol and the C programming language became the “in” thing back then. This was
made possible by the invention of RPC (Remote Procedural Call) which allows software services to
invoke each other the network (see Figure 2). This effectively broke the chain that holds back
software services within the bounds of individual machines to collaborate in a larger scale.
2 of 14
J.E.D.I
Figure 2
Functions communicating between memory spaces using RPC
After procedural calls came the time of functional languages such as LISP, followed shortly
by object-oriented languages such as C++ and of course, Java. The development of object
oriented language allowed developers to create objects, which are real world counterparts. If you
haven't noticed, objects are in truth software services.
More sophisticated network protocols were discovered by this time. The most popular ones
are CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Common
Object Model). These two will not be expounded as they are not within the scope of this course
material, but suffice to say that they are network protocols that grants connection between
software services. The limitation of using the said protocols was that the deployment of these
technologies were homogeneous in nature. Homogeneous meaning, they are deployed in closed
environments.
The following was the case until the invention of the Internet. Thanks to the Internet,
geographical barriers started to blur and businesses began to flourish by taking advantage of this
wonderful innovation. Eventually, people began to see the power of distributed computing and the
promise it shows.
1.3.1 Communication Patterns
Two things sparked the start of web services the evolution of distributed computing
and the revolution in the way we think about building large scale systems. As a recap from the
previous courseware, web applications, we know that distributed computing

1
is as the definition
below says,
1 />3 of 14
J.E.D.I
A very good example of a distributed system is the World Wide Web (WWW). As you
are surfing the Internet, you might not realize it but, you are in reality, using distributed system.
Your web browser is communicating with other web servers providing the web pages you visit.
Your web browser talks to various web servers over the Internet via a system of routers, which
are themselves part of a bigger distributed system. The aim of distributed computing is to find a
way to connect users and resources in an open and scalable way. Before this goal was met,
various computing obstacles were encountered and eventually as these impediments are
overcome, the computing industry began to mature.
The next section gives a blow-by-blow series of event leading to the design of web
services. The illustration below (Figure 3) shows how distributed computing evolved from a simple
client server model to what is expected of it in the future. Web services lies pretty much in the
middle of it.
Figure 3
2
2 “Web Services Overview.” Web Service Programming (with Passion!). Sang Shin.
< />4 of 14
Distributed computing is parallel computing using multiple independent
computers communicating over a network to accomplish a common objective
or task. The type of hardware, programming languages, operating systems
and other resources may vary drastically.
J.E.D.I
Evoution of Communication Patterns
In the beginning, there was the client-server model (see the first image from the left of
Figure 3). If you would recall in the web programming module, in a client-server communication
pattern, there are two entities involved, the client, which we could think as the person and his

computer, requesting for a certain resource from the server (limited to the name of a document
needed or a call to a server-side program), and the server, which returns the information
requested.
Figure 4
The consumer fetches information through HTML and a protocol
Figure 4 is to look at the client-server model in finer detail. The graphical representation
shows that clients or consumers requests information from the server, which in turn processes the
requests and throws back a web page containing information requested by the client/consumer.
Remember that this is done through the use of HTML and a network protocol such as HTTP.
Although the client-server communication pattern made it easy for consumers to access web
pages, still that is not enough to integerate business systems more flexibly. Thus, the introduction
of the 3-tier communication pattern.
In the web application courseware, you are taught about the MVC framework, which is in
particular, the Model, View and Controller. It is a matter of fact a 3-tier communication pattern. A
3-tier communication pattern is a client-server model wherein the user-interface, a functional
process logic, and a computer data storage are developed and maintained as autonomous
modules. The illustration below shows the 3-tier communication pattern.

5 of 14
J.E.D.I
Figure 5
The 3-tier communication pattern
From 3-tier communication pattern, it evolved to the web application communication
pattern (Figure 6). The web application communication model (J2EE architecture) is comprised of
a web server, application server and a database server. On the other hand, J2SE and J2ME is
responsible for the client tier. I wouldn't linger more on this topic since it was disucssed in detail
in the previous courseware. As a matter of fact, the web service course assumes that you have
knowledge about web applications before moving on further.
Moving on, an improvement to the web application communication pattern is the web
services communication model (Figure 7), which is what this course is all about. The picture

shows the technolgies in which a lot of business organizations and industries could leverage on.
6 of 14
J.E.D.I
Figure 6
3
Web application as communication pattern
3 “Web Services Overview.” Web Service Programming (with Passion!). Sang Shin.
< />7 of 14
J.E.D.I
Figure 7
4
Web Services as Communication Pattern
Due to the attributes stated above, various software services are not confined to
interacting with their kind, such as the what is shown in Figure 8.
Figure 8
Software service interaction through the use of web service
The web service model above shows that a web service exhibits the application logic, also
known as the application function of one communication participant (can be thought of as the
server) to multiple or heterogeneous client base (such as cellphone, PDA, and other types of
clients) independent of its object model implementation, programming language or runtime
environment. This functionality is what distinguishes web services from other remote access
mechanisms like Remote Method Invocation (RMI), and CORBA.
Having said the these, the web service infrastructure can be view as though each of the
participants can act as both user and provider of service. This means that, information can be
retrieved from a PDA by a cellphone, a laptop to a swing client and vice versa. Having said all
these, let us go to the formal definition of what a web service is.
1.4 What is a web service?
When you look around the Internet and various reading materials, you must have
concluded that there's a lot of hype, and marketing talk about it. Not much of these materials can
be of use to developers. And even today, it is hard to grasp a consistent definition for what it

really is. The most reasonable definition I came up with my research is that from the World Wide
4 “Web Services Overview.” Web Service Programming (with Passion!). Sang Shin.
< />8 of 14
J.E.D.I
Web Consortium (W3C)
5
. The said governing body defined web service as follows:
Don't worry if you find the said definition a little overwhelming. You'll be able to
understand and appreciate it as we go along the rest of the chapters. For now, think of web
service as a software application available over the web that is accessed by clients using XML-
based protocols. For starters, you can look at the site . The said site
contains a handful of web services which are implemented using different technologies. At the
time of my visit, I found the following listing:
Figure 9
5 />9 of 14
“ a software system identified by a URL, whose public interface and bindings
are defined and described using XML. Its definition can be discovered by other
software systems. These systems then interact with the web service in a manner
prescribed by its definition, using XML based messages conveyed by Internet
protocols.”
J.E.D.I
Sample Web service listing
The listing above won't exactly bring you to the service itself. But you will be sent to a
page saying where to get the service that you want and who to contact for more information. To
be able to connect to the service being offered on the page, you need to create a client
application, which we will be discussing in the succeeding chapters. Suffice to say that these
services are free, and you only need a web browser and an Internet connection.
1.5 Why Web Services?
You must be thinking, what's so special about web services that HTML, JSP and other
technologies cannot accomplish? An example presented in the book, Java Web Services in a

Nutshell (A quick desktop references)
6
, presents the situation where a certain publisher wants to
keep track of the sale of books. He has three options to go about this:
1. Use the site's search facility to locate a few titles, read the review. To go about this, each
stage entails rendering HTML, and answering or clicking a form. Obviously, this option is
too tedious to do, bordering insanity.
2. Write a code that extracts information from HTML. This means that the application will strip
the HTML and get the raw data. This idea is better than the first one since it has some level
of automation into it. Although still not cost efficient since, you only need the figure of the
sales ranking of the book, to bother with the program. Apparently, this is still not the best
solution since the layout of the HTML can change, thereby rendering the program invalid.
3. The obvious choice is the use of web services. Amazon can provide a web service interface
and expose the appropriate information in XML form. The publisher only need to write a
client program to retrieve information from the web service. Through web services, the
publisher won't have to deal with markup, but instead go straight to data he/she needs. As
a matter of fact, Amazon really did that in the middle of 2002. Another advantage of using
web services is that with the retrieved information from the service, the publisher can
customize how the data is displayed to his/her own format and not conform with that of
Amazon's web page.
In addition to the advantages presented by the scenario, here are the other reasons why
web services is very appealing:
• XML-based – using XML rids any networking, operanting system, or platform binding
dependency that a protocol may have. As a data representation layer, XML allows for
iteroperability at the core level. We will talk about XML in detail in the next lesson.
• Loosely-coupled – the attribute of beind loosely-coupled could only be equated with
versatility, in the sense that a consumer of a web service is not bound to that web service
directly. This means that, say the service interface changes, the client need not adopt to
the changes made. Being loosely-coupled makes software systems more manageable.
• Coarse-grained – perhaps the best way to explain this attribute is to first show what the

opposite of it – fine-grained, means. A Java program has methods, and these methods
have specific tasks. These methods carrying-out specific jobs are fine-grained methods.
So, when we build a Java program from scratch, we are therefore making a lot of fine-
6 Topley, Kim. Java Web Services In a Nutshell. O'Reilly & Associates, Inc. June 2003
10 of 14
J.E.D.I
grained methods, which in turn will be used to create coarse-grained services. Businesses
and interfaces exposed by the service should be coarse-grained and web services provides
a natural way to accomplish this end.
• Ability to be synchronous or asynchronous – synchronicity, in general, refers to the
binding of the client to service execution. Web services allows for either synchronous or
asynchronous invocations. Here's the difference between the two:
■ Synchronous - the client blocks and waits for the service to complete its operation
before continuing.
■ Asynchronous – allows the client to call on a service, doesn't necessarily have to
wait for it to finish before it could execute another function since the client can
recover the result at a later time. This is the key factor to a loosely coupled system.
• Support for Remote Procedural Calls (RPC) – web services allows to access
procudures, functions and methods on remote objects using XML.
• Supports document exchange – Again, through the use of XML, data (as simple as
representing your full name), and complex document (an entire book) exchange is a
breeze.
• Platform, language and location neurality - This means that you can build applications
using MAC, Solaris, Unix, Windows, and what not. The developer of client program can
implement it in JSP, PHP, ASP and other languages and not have a care in the world how
and what the other service use to implement its program. The communicating servers need
not be in the same network location, and still the software service can still talk to one
another. Just goes to show why more and more businesses are using web services.
1.6 How can I use web services?
This question is more like, “How can web service benefit me?”. The answer to this actually

depends on your specific needs and the environment on which you are in.
1. Linking legacy systems. When we say legacy systems, these are existing and perfectly
functional programs or applications. For example, your task is to make two legacy systems
one running in C++ and the other is a portal written in Java, communicate with one
another. You can take advantage of web services' cross language and cross-platform
features by not rewriting the program running in C or to Java and instead use web
services. This obviously saves you time and money by not going to the trouble of re-
implementing existing code.
2. Business-to-business (B2B). With web services in the picture, simple and workable B2B
transactions are fairy-tales come true. With web services, your B2B partner can implement
their own client and never worry about details which only specific parties should have
control over. With this, exchange of information is just a click away.
Given our previous example, wherein a publisher wants to determine the sale of his books,
is an example of a B2B transaction. It doesn't matter whether you want to connect to
Ebay, Yahoo or Amazon, or some other sites as long as they would expose the same
interface, you can reuse the same client program. You don't need to know the nitty-gritty
of each supplier's system, what's important is that you are able to transact with them. End
of story.
11 of 14
J.E.D.I
3. Service-based software. An example of which are small shell clients connecting to
various web services that charge on a per subscription basis. The companies that hosts the
web service can charge you each time you access their application. For example, a
company that tells the exchange rate from a given currency to another, can charge users
who want to get their hands on this kind of information.
1.7 What comprises web services?
There are 5 major elements in this great scheme. To shed more light into what comprises a
web service, let us tackle them each in the general sense. More emphasis on these elements will
be encountered as we progress each chapter. Without further ado, these elements are namely:
1. Service element. This is a deployed and accessible business process or application.

2. Service registry. This is a place where you can find information about available services.
Although this element is optional if the provider is familiar with the clients trying to access
the service being provided.
3. Service client. Is obviously the client that attempts to retrieve or request information
from the service.
4. XML-based message. This is the information being channeled between the client and the
service.
5. Internet transport protocol. The means of the client and the service to communicate
over the Internet. Example of which are, HTTP (Hyper Text Transfer Protocol) or HTTPS.
1.8 How does the web service work?
After all the hullabaloo, it is time to get our hands dirty and take an example and study it
closely. Building on top of our previous example, say we have a fictitious company called
AkingAklat.com, this company is a partner of Amazon in the Philippines. The company earns by
getting royalties for every book from Amazon that it is able to sell. AkingAklat.com gets its book
listings from Amazon by providing a link leading to Amazon. But what the former wants is to be
able to display the book listing in accordance to its web site's format. This is made possible
through the use of web services. The entire process is reflected in the figure below:
12 of 14
J.E.D.I
Figure 10
Web service exchange between AkingAklat.com and Amazon using XML
Initially, AkingAklat.com needs to post a request to Amazon.com for the the list of books.
This HTTP request is routed via a servlet in AkingAklat.com's web server. This servlet in turn
determines that it needs the list of books from Amazon.com, among other service providers. The
servlet obtains this data through a web service client (implemented by AkingAklat.com) who can
talk SOAP (web service lingo more about this on the succeeding chapters) to Amazon.com's web
service interface. The web service client will invoke the specific method from the interface which
generates the list of books. The values from this is wrapped to an XML data and is returned to the
web service client through SOAP. The web service client in turn, translated this data, and uses JSP
to render it as HTML. The HTML is then returned to AkingAklat.com's browser with the information

needed.
Generally speaking, we can break down the entire process by thinking of stakeholders
involved in the process.
1. Service Provider. I'd like to think of service providers as though they are the producers in
the system since they are the ones that creates the web service, generates a service
interface. In the figure above, the service provider would be Amazon.com.
2. Service Requester. The counterpart of the service provider is the requester, which we
can probably imagine as the consumers who fetch the information from the service
provider. In the image above, you can identify this as AkingAklat.com.
3. Node Operator. The node operators are the ones that creates and maintains the service
registry. The service registry is the repository of services being offered by the service
providers. You can think about this as the classified ads in the newspaper. It announces
the services being offered by different service providers. You'll get more on this when you
get to the Chapter about UDDI. The figure above doesn't show what the node operator is,
but suffice to say that it manages the registry.
How the players work in the web service can be best represented by the following
illustration:
13 of 14
J.E.D.I
Figure 11
Web Service roles/players
The representation above shows the interaction between the different stakeholders in the
web service.
The node operator, creates a service registry and maintains it.
From the service provider point of view, the provider creates a web service and publishes
the said service in the registry for everyone to see.
The service requester, on the other hand, searches the registry for relevant services, the
service registry throws back search hits. The service requester gets its hand on the service by
creating a service client and sending request to that service. The service grants the request.
Its not that hard, isn't it? That pretty much is the gist of the web service life cycle.

1.9 Where is web services, and where it is heading?
Currently, the various technologies (SOAP, WSDL, UDDI) that holds web services together
are still evolving and releasing new versions to support more functionalities and aid for bug fixes.
Not to mention, the emerging additional standards that are currently being defined to enable web
services to realize their full potential. As a result, developers can expect that these technologies
may change as they are extended to provide enhanced web services support.
Having said this, you can say that web service is far from being perfect and has still a long
way to go. Although this is the case, more and more businesses are adopting it because of its
many strong points as mentioned in the previous section. However, for this technology to fully
satisfy the business industry, there are points for improvement that needs to be addressed
namely: the quality of service, more support for management and fortified security for
transactions.
14 of 14