System Design
Figure 2: Application Model
A web service is any piece of software that makes itself available over the internet and uses a
standardized XML messaging system. XML is used to encode all communications to a web
service. For example, a client invokes a web service by sending an XML message, then waits
for a corresponding XML response. As all communication is in XML, web services are not
tied to any one operating system or programming language—Java can talk with Perl;
Windows applications can talk with Unix applications. Web services are self-contained,
modular, distributed, dynamic applications that can be described, published, located, or
invoked over the network to create products, processes, and supply chains. These applications
can be local, distributed, or web-based. Web services are built on top of open standards such
as TCP/IP, HTTP, Java, HTML, and XML. Web services are XML-based information
exchange systems that use the Internet for direct application-to-application interaction. These
systems can include programs, objects, messages, or documents. A web service is a
collection of open protocols and standards used for exchanging data between applications or
systems. Software applications written in various programming languages and running on
various platforms can use web services to exchange data over computer networks like the
Internet in a manner similar to inter-process communication on a single computer. This
interoperability (e.g., between Java and Python, or Windows and Linux applications) is due
to the use of open standards.
SOAP
SOAP was originally part of the specification that included the Web Services
Description Language (WSDL) and Universal Description, Discovery, and Integration
(UDDI). It is used now without WSDL and UDDI. SOAP (Simple Object Access Protocol) is
a protocol specification for exchanging structured information in the implementation of web
services in computer networks. SOAP allows processes running on disparate operating
systems (such as Windows and Linux) to communicate using Extensible Markup Language
(XML).
Instead of the discovery process described in the History of the Web Services
Specification section below, SOAP messages are hard-coded or generated without the use of
a repository. The interaction is illustrated in the figure below.
A web service is a unit of managed code that can be remotely invoked using HTTP.
That is, it can be activated using HTTP requests. Web services allow you to expose the
functionality of your existing code over the network. Once it is exposed on the network, other
applications can use the functionality of your program.
.
Web services allow various applications to talk to each other and share data and
services among themselves. Other applications can also use the web services. For example, a
VB or .NET application can talk to Java web services and vice versa. Web services are used
to make the application platform and technology independent.
The bottom of the web service protocol stack is service transport. This layer is
responsible for actually transporting XML messages between two computers. Hyper Text
Transfer Protocol (HTTP) Currently, HTTP is the most popular option for service transport.
HTTP is simple, stable, and widely deployed. Furthermore, most firewalls allow HTTP
traffic. This allows XMLRPC or SOAP messages to masquerade as HTTP messages.
This is good if you want to integrate remote applications, but it does raise a number
of security concerns. Blocks Extensible Exchange Protocol (BEEP) This is a promising
alternative to HTTP.. BEEP is a new Internet Engineering Task Force (IETF) framework for
building new protocols. BEEP is layered directly on TCP and includes a number of built-in
features, including an initial handshake protocol, authentication, security, and error handling.
Using BEEP, one can create new protocols for a variety of applications, including instant
messaging, file transfer, content syndication, and network management.
SOAP is not tied to any specific transport protocol. In fact, you can use SOAP via
HTTP, SMTP, or FTP. One promising idea is therefore to use SOAP over BEEP. As we have
just seen, writing web services is easy in the .NET Framework. Writing web service
consumers is also easy in the .NET framework; however, it is a bit more involved. As said
earlier, we will write two types of service consumers, one web-based and another Windows
application-based consumer. Let us write our first web service consumer. A single web
service may consist of a chain of applications. For example, one large service might tie
together the services of three other applications. In this case, SSL is not adequate; the
messages need to be encrypted at each node along the service path, and each node represents
a potential weak link in the chain. Currently, there is no agreed-upon solution to this issue,
but one promising solution is the W3C XML Encryption Standard. This standard provides a
framework for encrypting and decrypting entire XML documents or just portions of an XML
document.
Web services simplify the process of making applications talk to each other.
Simplification results in lower development cost, faster time to market, easier maintenance,
and reduced total cost of ownership. The bottom line is this: Web services allow you to
integrate your applications at a fraction of the cost of traditional middleware. Traditional
RPC-style middleware, such as RPC, CORBA, RMI, and DCOM, relies on tightly coupled
connections.
A tightly coupled connection is very brittle, and it can break if you make any modi-
fication to the application. Tightly coupled connections are the source of many a maintenance
nightmare. In contrast, Web services support loosely coupled connections. Loose coupling
minimizes the impact of changes to your applications. A Web service interface provides a
layer of abstraction between the client and server. A change in one doesn’t necessarily force a
change in the other.
The abstract interface also makes it easier to reuse a service in another application.
Loose coupling reduces the cost of maintenance and increases reusability A service is an
application that exposes its functionality through an application programming interface
(API). In other words, a service is a resource that is designed to be consumed by software
rather than by humans. The term “service” implies something special about the application
design.
It refers to something known as the service-oriented architecture (SOA). The SOA is
the basic architecture used by most RPC-style middleware systems. Chapter 3 talks about the
SOA in detail. One of the most important features of the SOA is the separation of interface
from implementation. A service exposes its functionality through an interface, and that
interface hides the inner workings of the application. A client application doesn’t need to
understand how the service actually performs its work. All it needs to understand is how to
use the interface. To give you an analogy, let’s look at a car. A car is a complicated machine,
but the car provides a set of interfaces that’s relatively simple to use. To start a car, you don’t
need to know how an internal combustion engineworks, or even how the starter motor works.
You only need to know how to use the interface that the car supplies to start it: Turn the key.
A Web service possesses the characteristics of both a Web resource and a service.
It is an application that exposes its functionality through an API, and it is a Web resource
that is designed to be consumed by software rather than by a human sitting at a browser.
Understanding the concept of a service is key to understanding Web services. A service is a
piece of software that does work for other software. In most circumstances, a service runs on
a server, waiting for an application to call it and ask it to do some work. In many cases
services don’t provide any type of human interface, and the only way to access the service is
through its API. A service can perform system functions or business application functions.
For example, a file service can create, find, save, or delete a file. A stock quote service can
retrieve the current ask and bid prices of an equity