Knowlegde Through Fun Welcome To Mady's Site.

Technically speaking, a Web Service is "a component of programmable
application logic that can be accessed using standard web protocols".
That is, it's quite similar to the components we considered earlier
on, but let us access all its functionality via the Web. In principle,
anyone who can browse the Web can see and use a web service.

Think of a Web Service as a black box resource that accepts requests
from a consumer (some kind of program running on the web client),
performs a specific task, and returns the results of that task. In
some respects, a search engine such as Google (www.google.com) is a
kind of Web Service – you submit a search expression, and it compiles
a list of matching sites, which it sends back to your browser.

Currently the term, Web Service, is something of a buzzword within
the sphere of software development, thanks to a number of new
protocols that have opened up the scope of what we can expect Web
Services to do. XML plays a central role in all these technologies.

There's a very important distinction between a web service like
Google and the kind of XML Web Service that we're going to be talking
about: on Google, you submit the search expression, and you read the
list of sites that gets sent back. Okay, the browser provides you with
a textbox, and parses the response stream so that it looks nice – but
it doesn't actually understand the information you've submitted, let
alone the HTML that Google sends back.

If you are using an XML Web Service, you can assume the results will
be returned as some kind of XML document, that's explicitly structured
and self-describing.

It's, therefore, quite straightforward to write a program that
interprets these results and
perhaps even formulate a new submission.

As we're going to see, ASP.NET makes it very easy to build XML Web Services,
and just as easy to use them – ultimately you need only to reference
the Web Service in your code, and you can use it just as is it were a
local component. As with normal components, we don't need to know
anything about how the service functions, just the tasks it can do,
the type of information it needs to do them, and the type of results
we're going to get back.

1. KINDS OF WEB SERVICES

Practical applications of web services technologies fall into three groups:

1.1 PLUG-IN FUNCTIONALITY.
The simplest and most prevalent web services in use today add
third-party functions to web pages and portals. Common examples
include external news feeds and stock quotes, banner ad serving, and
search boxes. Few use XML and SOAP, relying instead on HTML based
technologies such as JavaScript, CGI calls and Java.

1.2 REMOTE INFRASTRUCTURE SERVICES.
Third-party providers use web services technologies to deliver
behind-the-scenes functionality for commercial websites, such as user
authentication, payment processing and visitor traffic analysis.

1.3 ENTERPRISE APPLICATION INTEGRATION.
Web services technologies are rapidly finding favour as a solution to
the complex integration challenges of linking applications within the
enterprise, or across a value chain. EAI implementations are the most
likely to use formal web services standards.

2. REQUIREMENTS OF WEB SERVICES

The original Internet made it possible to send and receive email and
to share access to files. The World Wide Web added a software layer
that made it easier to publish and access other content. The final
development has been the emergence of web
services, enriching the software layer with application functionality.
The task of the web services infrastructure is to support
commercial-grade application functionality.

The difference between content and applications comes from the
addition of process — the sequence of events that need to happen in
order to produce a result. When participants in the application are
distributed across the web, the need to complete processes adds some
important new operating requirements:

2.1 CONSISTENCY
Each separate component must act within certain parameters, such as
response times and availability.

2.2 AUTHENTICITY
There must be some way of assuring the identity of each of the
participants in the process.

2.3 TIMELINESS
Each step in the process must execute in the correct order, and
promptly — especially if a user is waiting on the result in order to
continue with their work

2.4 INTEGRITY
There must be mechanisms to avoid data becoming corrupted as it passes
between participants

2.5 PERSISTENCE
Each participant in the process must maintain a permanent record of
their part in the transaction.
The web services infrastructure must provide a platform that supports
these requirements and more. That demands an array of tools and
services to enhance, monitor
and maintain quality-of-service.