0% found this document useful (0 votes)
36 views5 pages

System Design:: Application Model

Web services are modular, distributed applications that use XML for communication, allowing interoperability between different programming languages and platforms. SOAP is a protocol for exchanging structured information in web services, enabling communication across disparate systems. Web services simplify application integration, reduce development costs, and support loosely coupled connections, enhancing reusability and maintenance.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
36 views5 pages

System Design:: Application Model

Web services are modular, distributed applications that use XML for communication, allowing interoperability between different programming languages and platforms. SOAP is a protocol for exchanging structured information in web services, enabling communication across disparate systems. Web services simplify application integration, reduce development costs, and support loosely coupled connections, enhancing reusability and maintenance.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

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

You might also like