Services The Web Services Idea

learningsnortΑσφάλεια

3 Νοε 2013 (πριν από 4 χρόνια και 6 μέρες)

58 εμφανίσεις

Services

The Web Services Idea

Tim Ewald

Microsoft Corporation

July 12, 2002

Updated September 27, 2002

Editors Note:
This article offers a developers introduction to the basic Web service idea. If you are
looking for a business perspective on Web services

and .NET see
http://www.microsoft.com/net/business
.

The Web model has been more rapidly and widely adopted than any other approach to building distributed
applications to date. The phenomenal success
of the Web model can be attributed to one core
characteristic: it is more loosely coupled than traditional distributed programming models like RPC, DCOM
and CORBA. The interactions between Web clients and servers are simple: they exchange messages that
car
ry MIME
-
typed data, and the semantics of a message can be modified using headers. The destination of
a message is specified indirectly using a URL, and this level of indirection can be leveraged to implement
load balancing, session tracking and other featu
res.

The simplicity of the interactions in the Web programming model makes it possible to build systems
incrementally. Unlike tightly
-
coupled RPC and distributed object systems, which require all the pieces of
an application be deployed at once, you can ad
d clients and servers to Web
-
based systems as needed.
You can establish connections to new applications fairly easily. And you can do all of this in a decentralized
manner, without any central coordination beyond the registration of DNS names, and with a d
egree of
interoperability, scalability and manageability that is remarkably high.

The basic idea behind Web services is to adapt the loosely coupled Web programming model for use in
applications that are not browser
-
based. The goal is to provide a platform

for building distributed
applications using software running on different operating systems and devices, written using different
programming languages and tools from multiple vendors, all potentially developed and deployed
independently.

How do Web servi
ces work?

Web services build on the loose coupling of the traditional Web programming model, and extend it for use
in other kinds of applications. There are three major differences between Web services and traditional
Web applications: Web services use SOA
P messages instead of MIME messages, Web services are not
HTTP
-
specific, and Web services provide metadata describing the messages they produce and consume.
Lets consider each of these differences in detail

First, Web services communicate using SOAP messag
es. SOAP formalizes the use of XML as a way to pass
data from one process to another. SOAP defines a framing model for protocol versioning and extensibility,
a way to convey error information and a way to send messages over HTTP. The body of a SOAP message

contains whatever XML an application wants to send, as shown below

<env:Envelope

xmlns:env="http://www.w3.org/2001/12/soap
-
envelope">


<env:Body>


<ns:Order xmlns:ns="urn:fabrikam
-
com:orders">


<item>Wallabee</item>


<item>Wombat</i
tem>


<item>Wren</item>


</ns:Order>


</env:Body>

</env:Envelope>

The shift from MIME
-
typed messages to XML
-
based messages reflects a key difference between a
traditional Web application client
-

a browser
-

and a Web service client. Browser
s usually just render
HTML pages (or other MIME
-
typed data, like images) and leave interpretation of the information they
display up to the user. Web service clients, on the other hand, typically need to interpret the data they
receive and do something mea
ningful with it
-

they may not even have a user interface. XML provides a
standard way to represent and manipulate data, and XML processing tools are ubiquitous, so it is a logical
choice as a message format for Web services. (It is also possible to use a
packaging format like DIME to
attach arbitrary MIME
-
typed data to a SOAP message in cases where converting the data to XML is
inefficient or otherwise unacceptable.)

While SOAP mandates the use of XML to represent a message payload, it says nothing about w
hat that
XML should look like. It is up to you, as a Web service designer, to decide what data each message should
carry. In some cases, your messages may contain parameters for method invocations. The advantage of
this approach is that it is very familiar

it offers a programming model similar to classic RPC. The
disadvantage is that it typically leads to tighter coupling between clients and servers, at least in terms of
what expectations a message receiver has about the data being sent. Specifically, most
method
-
centric
systems expect a message to contain exactly the right number of arguments, in exactly the right order
and with exactly the right types. In some cases, your messages may contain information that does not
represent a method call. This approach

allows looser coupling; clients and servers can be more flexible
about the format and content of data they produce and consume. This programming model is more like
the classic Web, which does not mandate how the data being sent in a message is processed.

The second major difference between Web services and traditional Web applications is that Web services
are not transport protocol specific. While the SOAP specification only defines how to send SOAP messages
over HTTP
-

and that's what the vast majority of

today's Web services do
-

other transport protocols can
also be used. SOAP messages can be sent using SMTP, raw TCP, an instant messaging protocol like
Jabber, or any other protocol you like. While most SOAP messages will be sent over HTTP for the
foresee
able future, the ability to use other protocols is very important. HTTP was not designed to support
long
-
running requests or sending event notifications to clients. These problems are best solved using
other protocols, and standardized support for this wil
l come over time.

Because Web services can communicate using a variety of transport protocols, any higher
-
level services
like security need to be defined in a message
-
centric, transport
-
neutral way. To support that, the SOAP
message format includes an opti
onal Header element. The Header carries message metadata; that is,
additional information that is not directly related to the problem domain data in the message's body. This
mechanism was inspired by HTTP, which uses message headers as a way to extend its
basic
request/response behavior. Defining protocol extensions at the SOAP level ensures a message's semantics
are well understood, regardless of the transport protocol that was used to deliver it.

In addition to being transport neutral, SOAP does not requi
re that a message be sent from a client to a
server in a single "hop". The SOAP specification defines the notion of intermediaries, nodes that a
message passes through on its way to its final destination. Using intermediaries, you can "virtualize"
physical

network topology so that messages can be sent to Web services using whatever path and
whatever combination of transport protocols is most appropriate. There is no widespread support for using
SOAP intermediaries with today's Web service toolkits; but it w
ill come over time. Once this functionality
becomes more mainstream, however, you will be able to deploy Web services in a wide range of different
network configurations without having to modify either client or server code.

The third major difference betw
een Web services and traditional Web applications is that Web services are
self
-
describing; they provide metadata describing the messages they produce and consume, the message
exchange patterns they use to expose behaviors, the physical transport protocols

they use, and logical
addressing information required to invoke them. A Web service's message formats are defined using XML
Schema (XSD). XML Schema is flexible enough to describe a wide range of message structures, including
open content models with fine
-
grained control over extensibility, which is critical for services to be loosely
coupled in terms of the data they send and receive. A Web service's behaviors are described using the
Web Service Description Language (WSDL), which map message exchanges to
operations grouped into
portTypes (interfaces) and describe how those operations can be invoked using particular transport
protocol bindings. You use these descriptions to write software that communicates with a service, either
directly or indirectly via s
ome t006Fol
-
generated code.

Living in a brave new world

The Web service movement is about creating a new, general
-
purpose platform for building loosely coupled
distributed systems. If you want to live in the new Web service world, there are four things yo
u need to
remember:



It is all about loose coupling. That's what made the Web successful and what makes Web services
interesting.



It is all about XML. The more you understand about XML

the more deeply you embrace it the
better off you'll be.



Objects may b
e used to implement Web services, but they are not central to the programming
model.



The evolution of the platform continues. You can build basic services on a wide range of platforms
today. Work is ongoing on higher
-
level services, the use of alternate t
ransport protocols, and other
interesting topics.

This web site is designed to help you as you move forward with Web services. It can help you
understand

how they work and how to build t
hem using today's tools. (Both
Getting Started with XML Web Services in
Visual Studio .NET

and
Using Web Services Instead of DCOM

provide introductions to building Web
services with the

.NET Framework.) It can also provide access to useful software
downloads

and link you
to the larger Web service
community
. Fi
nally, it can keep an eye on the future and tell you
what's coming
next
.

http://msdn.micr
osoft.com/webservices/understanding/readme/default.aspx



Web service
-

a programmatic definition

A Web service is a software component with the following features:



It is accessible through a SOAP (Simple Object Access

Protocol) interface. (See
http://www.w3c.org/TR/SOAP/
)



Its interface is described in a WSDL (Web Service Description

Language) document. (See
http://www.w3c.og/TR/wsdl/
)


SOAP is an extensible XM
L messaging protocol that forms the foundation

for Web Services. SOAP provides a simple and consistent mechanism that

allows one application to send an XML message to another application. A

SOAP message is a one
-
way transmission from a SOAP sender to a SOA
P

receiver, and any application can participate in an exchange as either

sender or receiver. SOAP messages may be combined to support many

communication behaviors, including request/response, solicit response,

one
-
way asynchronous messaging, or event notif
ication. SOAP is a highlevel

protocol that defines only the message protocol and a few rules for

message processing. It is completely independent of the underlying

transport protocol, so SOAP messages can be exchanged over HTTP, JMS,

or mail transport prot
ocols. Currently the HTTP protocol is the most

frequently used transport for SOAP messages. We'll show some sample

SOAP messages later in this article.


WSDL is an XML document that contains a set of definitions that describes

a Web service. It provides al
l the information needed to access and use a

Web service. A WSDL document describes what the Web service does, how

it communicates, and where it resides. You use the WSDL document at

development
-
time to create your service interfaces. Some SOAP

implementat
ions, including Systinet WASP, also use WSDL at runtime to

support dynamic communications.


http://www.systinet.com/download/TutorialOne.pdf