Web Services

Web services constitute a distributed computer architecture made up of many

different computers trying to communicate over the network to form one system.
Web services are a type of service that can be shared by and used as components of
Distributed Web-based applications. They consist of a set of standards that allow
developers to implement distributed applications using radically different tools
provided by many different vendors to create applications that use a combination of
software modules called from systems in disparate departments or from other
companies.

Both monolithic systems running on mainframes or client server applications work

well but they are relative closed to outside world cannot be easily accessed by the
diverse users of the web.

Thus the software industry is evolving toward loosely coupled service-oriented

applications that dynamically interact over the Web. The applications break down the
larger software system into smaller modular components, or shared services. These
services can reside on different computers and can be implemented by vastly
different technologies, but they are packaged and transported using standard Web
protocols, such as XML and HTTP, thus making them easily accessible by any user on
the Web.

The concept of services is not new—RMI, COM, and CORBA are all service-oriented
technologies. However, applications based on these technologies require them to be
written using that particular technology, often from a particular vendor. This
requirement typically hinders widespread acceptance of an application on the Web.

To make Web services easily accessible from heterogeneous environments Web

services describe themselves using an XML-based description language. Web services
communicate with clients (both end-user applications or other Web services) through
XML messages that are transmitted by standard Internet protocols, such as HTTP.

Web services represent a new standard based and simplified model for creating and
connecting distributed applications across the web in the form of services. While web
services are still maturing customers may begin to start development without
significant new investment given the burgeoning growth application server software.

Web services is a technology that allows applications to communicate with each other
in a platform- and programming language-independent manner. A Web service is a
software interface that describes a collection of operations that can be accessed over
the network through standardized XML messaging. It uses protocols based on the
XML language to describe an operation to execute or data to exchange with another
Web service. A group of Web services interacting together in this manner defines a
particular Web service application in a Service-Oriented Architecture (SOA).
The software industry is finally coming to terms with the fact that integrating
software applications across multiple operating systems, programming languages,
and hardware platforms is not something that can be solved by any one particular
proprietary environment. Traditionally, the problem has been one of tight-coupling,
where one application that calls a remote network is tied strongly to it by the
function call it makes and the parameters it requests. In most systems before Web
services, this is a fixed interface with little flexibility or adaptability to changing
environments or needs.

Web services uses XML that can describe any and all data in a truly platform-
independent manner for exchange across systems, thus moving towards loosely-
coupled applications. Furthermore, Web services can function on a more abstract
level that can reevaluate, modify or handle data types dynamically on demand. So,
on a technical level, Web services can handle data much easier and allow software to
communicate more freely.

On a higher conceptual level, we can look at Web services as units of work, each
handling a specific functional task. One step above this, the tasks can be combined
into business-oriented tasks to handle particular business operational tasks, and this
in turn allows non-technical people to think of applications that can handle business
issues together in a workflow of Web services applications. Thus, once the Web
services are designed and built by technical people, business process architects can
aggregate them into solving business level problems.

To borrow a car engine analogy, a business process architect can think of putting
together a whole car engine with the car frame, body, transmission, and other
systems, rather than look at the many pieces within each engine. Furthermore, the
dynamic platform means that the engine can work together with the transmission or
parts from other car manufacturers.
What rises from this last aspect is that Web services are helping to bridge the gap
between business people and technologists in an organization. Web services make it
easier for business people to understand technical operations. Business people can
describe events and activities and technologists can associate them with appropriate
services.

With universally defined interfaces and well-designed tasks, it also becomes easier to
reuse these tasks and thus, the applications they represent. Reusability of application
software means a better return on investment on software because it can produce
more from the same resources. It allows business people to consider using an
existing application in a new way or offering it to a partner in a new way, thus
potentially increasing the business transactions between partners.
Therefore, the primary issues that Web services tries to tackle are the issues of data
and application integration, and that of transforming technical functions into
business-oriented computing tasks. These two facets allow businesses to
communicate on a process or application level with their partners, while leaving
dynamic room to adapt to new situations or work with different partners on demand.

Why use Web Services

The major reasons for using Web services are to gain:
1. Interoperability among distributed applications that span diverse hardware and
software platforms.
2. Accessibility of applications through firewalls using Web protocols.
3. A cross-platform, cross-language data model (XML) that facilitates developing
heterogeneous distributed applications.
Because Web services are accessed using standard Web protocols, such as XML and
HTTP, the diverse and heterogeneous applications on the Web (which typically
already understand XML and HTTP) can automatically access Web services, solving
the ever-present problem of how different systems communicate with each other.
These different systems might be Microsoft SOAP Toolkit clients, J2EE applications,
legacy applications, and so on. These systems might be written in a variety of
programming languages, such as Java, C++, or Perl. As long as the application that
provides the functionality is packaged as a Web service each of these systems can
communicate with any other.

Web Services represent a new standard-based and simplified model for creating and
connecting distributed applications across the web in the form of services. Web
Services are built on the top of existing and widely adopted Internet protocols such
as HTTP, XML, TCP/IP, HTML, Java and XML. This means the base foundation for
building the Web Services is already in place. From a more technical perspective,
Web Services are XML depictions of objects, messages, and documents designed to
interact over the web to enable application integration. Web Services applications can
be published found or invoked as atom like services anywhere ion the Internet thus
creating service grid of dynamic business components.

By providing a common interoperability layer between disparate platforms, Web

Services allow companies to connect with each other based on business
considerations as opposed to underlying infrastructure requirements. The benefit will
come in the form of enhanced user experience as a much wider variety of services
are offered to customers. As business begin to adopt the Web Services scenario,
whereby vendors strictly focus on their core competencies and aggregate
supplementary services. Further more one of the most attractive aspects of the Web
Services is that there is now a significant amount of additional technological
investment in the application server technology, so these companies can begin taking
advantage of the Web Services today.

Web Services Standards

Web services are registered and announced using the following services and
protocols. Many of these and other standards are being worked out now by the UDDI
project, a group of industry leaders that is spearheading the early creation and
design efforts.

• UDDI (Universal Description, Discovery, and Integration) is a protocol for

describing available Web services components. This standard allows businesses to
register with an Internet directory that will help them advertise their services, so
companies can find one another and conduct transactions over the Web. The online
yellow pages directory that UDDI provides is a key part of how Web services plans
such as Sun ONE and Microsoft .NET will work together. This registration and lookup
task is done using XML and HTTP (S)-based mechanisms. The UDDI project is
working to provide a common access method for the metadata needed to determine
if a piece of previously developed code will suffice and, if so, how to access it.

• SOAP (Simple Object Access Protocol) defines the XML based message format
that applications use to communicate and inter-operate with each other over the
Internet. The heterogeneous environment pf the Internet demands that applications
support a common data encoding protocol and message format. SOAP is a protocol
for initiating conversations with a UDDI service. SOAP makes object access simple by
allowing applications to invoke object methods, or functions, residing on remote
servers. A SOAP application creates a request block in XML, supplying the data
needed by the remote method as well as the location of the remote object itself.

• WSDL (Web Service Description Language), the proposed standard for how a
Web service is described, is an collection of metadata about XML-based service used
for describing what business do and how to access their services electronically. We
can cay WSDL is a XML- Based service IDL (Interface Definition Language) that
defines the service interface and its implementation characteristics. WSDL is
referenced by UDDI entries and describes the SOAP messages that define a
particular Web service.

• ebXML (e-business XML) defines core components, business processes, registry

and repository, messaging services, trading partner agreements, and security. The
purpose of ebXML initiative is to enable an E-marketplace where companies of
various size and geographical location can conduct business with each other through
the exchange of XML-based messages. A key feature of ebXML, which differentiate it
from other XML-based standards, is its emphasis on business process such as
delivering a product rather than business documents such as purchase order. The
ebXML architecture is divided into three layers with business process models in one
layer and common business objects such as name, address etc. in another layer. The
third layer contains the registry that enables companies to electronically locate a
business partner and obtain requirements to facilitate the exchange of data
electronically.

Difference between RPC and Web Services

• Data is formatted for transfer using XML, improving or eliminating marshalling, un
marshalling, and various other translation-related requirements normally coded by a
developer.
• Data is passed using standardized protocols such as HTTP or SMTP, which have
published well-defined standards.
• The underlying exposed service is well defined using a known accepted mechanism,
WSDL.
• Services are found using a well-defined standard, UDDI, and the more advanced
ebXML.

Specifically WSDL provides a number of key pieces of information:

• A definition of the format of the messages that are passed between two endpoints
using its <types> and <message> elements and appropriate schema definitions.
• The semantics of the service: how it might be called to make a synchronous
request/reply, synchronous reply-only or asynchronously communicate.
• The end point and transport of the service via the <service> element: that is, who
provides the service.
• An encoding via the <binding> element, that is how the service is accessed.
A WSDL example
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
 </portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">

<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>

<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>
</definitions>

A SOAP example
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://example.org/2001/06/quotes"

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

<env:Body>
<m:GetLastTradePrice
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://example.org/2001/06/quotes">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</env:Body>
</env:Envelope>
SOAP supports both synchronous and asynchronous call semantics; that is, standard
RPC as well as message-based, and can be used with a variety of protocols other
than HTTP.