Web Services Explained
Web services are basically services
available over the web. There are
already many services available over the web, today. Services include: search engines, language translators, weather
guides, dictionaries, directories, maps and many more. But, these types of web services generally
require a human intervention.
That is, a human will punch up the URL in the browser, view the response
and make appropriate selections from that point forward.
Existing web applications
are not easy to access with different client applications. However, some client application have
accomplished integration with existing web applications using Internet
Inter-ORB Protocol (IIOP) or data mining from the response stream sent as a web
page. The IIOP approach requires
installation of specialized software on the client layer, and the later
approach is not predictable and standardized.
Also, in developing web
applications, the service developer must provide presentation logic coupled
with the business logic. That is not
always good. Today, most people browse
the Internet with some PC-based software.
Browsers are now found in cell-phones which require specialized
presentation. The user may also wish to
integrate the result from a service inside his/her own software, without all
the presentation stuff coming from the server. Therefore, to provide services over the web, standards have to
exist. But, whose and which standards?
It would be great if the
implementation can accommodate almost any programming language on the server or
the client. We’ve already had
experiences with single language implementations as in remote procedure
calls. Also, the data exchange should
be done in some human readable form.
Because there will be many services over the web, a convenient lookup of
available services would be required. It would be great to lookup those
services by name or by service type to get the necessary technical details of
using that service. Finally, it would
be really cool if we could do all this using existing protocols.
Well the current answer to
these requirements is web services. Web
services promises to be easy to implement using existing technologies, while
providing important integration opportunities.
Client applications
communicate with the web services using Hyper-Text Transfer Protocol (HTTP),
that’s been around for a while. It is
the protocol when you use the World Wide Web (www). HTTP defines the formatting of messages and
its transmission. Additionally, it guides the web server or the browser in
handling the message. When you type: http://www.object-ideas.com,
called a Universal Resource Locator (URL) in your browser, you are sending an
HTTP command to the web server. The web
server scans this request and locates the appropriate web page request and
sends it back to the requestor. HTTP
is stateless, meaning that each command is executed independently without
knowledge of the previous command.
That type of functionality can be supported by the use of Java, ASP,
JavaScript and cookies.
Extensible Markup Language
(XML) provides a neutral data format to carry the request or response
parameters in a web service. XML is
widely discussed in the media and has applications in many areas. XML provides a simple way to describe the data
and is also platform-independent.
Additionally, XML is not tied to any particular programming language.
The actual web service is
constructed using Java, Perl, VB or C++, to name a few programming
languages. Then to obtain the
programming interface to this service, several other components and standards
are involved.
Messages are exchanged using the Simple Object Access
Protocol (SOAP). It is used to
construct the request & response message(s), to and from the web
service. In essence SOAP is the
mechanism to make remote procedure calls.
SOAP uses structured XML messages between the requestor and the supplier
of a web service. SOAP is already
supported in about 60 development languages and about 20 application
platforms. Many vendors, including Sun,
IBM and Microsoft support SOAP. Sun
provides support for SOAP in the J2EE specification, while Microsoft provides
support in its .NET products. The SOAP
specification has been submitted to the World Wide Web Consortium (W3C) to become
an industry wide web standard.
A SOAP message is composed of several parts. These include the envelope, header, body
and the actual payload. The entire XML
message is wrapped within an envelope (<Soap:Envelope>…</Soap:Envelope>) clause. Headers are optional, but may contain
routing and authentication type of content. These are found within the (<Soap:Header> </Soap:Header>)
clauses. The body contains the actual payload wrapped in the (<Soap:Body>…</Soap:Body>) clause. A
SOAP message can select from one
of two transmission styles. A message can be transmitted in a
“document-style” or a “remote-procedure-call style”.
The World Wide Web Consortium (W3C) has recently undertook
the standardization of SOAP and will likely introduce other XML-based
components to SOAP to remedy some the deficiencies from the original
specification.
SOAP is a simple protocol.
It is not designed to handle advanced options such as the sender and
receiver information; message lifecyle; security of the message. Several bolt-on specifications have been
introduced to handle these additional requirements.
Microsoft’s BizTalk defines additional elements which are
interpreted by their BizTalk Server.
Another standard called ebXML, is sponsored by UN/CEFACT (United Nations
Center For Trade Facilitation And Electronic Business) and OASIS (Organization
for the Advancement of Structural Information Standards). It is based on SOAP-with-attachments, and is
highly influenced by the EDI experience of its users.
Combined with SOAP, the
Universal Description, Discovery and Integration (UDDI) initiative was created
to facilitate discovery of web services over the Internet. The web service developer registers the
service definition and response specifications with the registery.
IBM, Microsoft, and Ariba
have jointly developed UDDI standard.
It was developed to register businesses, products and services available
over the net. UDDI standard specifies
the method by which businesses can discover each others’ services and then link
up to transact business. UDDI registry
itself can be accessed via SOAP to make the initial entry or to search by topic
or name.
UDDI registry organizes the
content by yellow pages, white pages and green pages. The white pages provide an index to locate companies by name,
providing contact information among other items. The yellow pages provide an index by business category or
industry codes (NAICS), products and services codes (UN/SPSC) and geographic
locations. Finally the green pages
provide technical information such as API, binding information, service names,
and groupings
Web services are registered
with UDDI registry using SOAP messages constructed using the Web Service
Description Language (WSDL). WSDL
defines the interface contract supported by a web service, in the same way the
Interface Definition Language (IDL) defined the interface to a Common Object
Request Broker Architecture (CORBA) object.
WSDL is a joint
specification offered by both IBM and Microsoft to formally describe the
capabilities and interfacing to a web service. These registries are currently hosted by several organizations,
including IBM and Microsoft. The
registry is free at this time and is accessible over the Web.
Most of the software companies that support web
services, also provide tools to generate WSDL for the web services, but
generally the WSDL contains the following sections:
1.
A description or the
format of the messages that can be exchanged.
These are contained within the (<types> … </types>) and the
(<message> … </message>) elements.
2.
The type of service is
specified in the (<portType>…</portType>) element. It specifies if the service is
request-response, request-only or response-only behaviour.
3.
The encoding scheme,
i.e. HTTP, HTTPS, or SMTP is specified within the
(<service>…</service>) element.
Role of Web Services
Corporations have been
integrating enterprise applications to exchange information such as purchase
orders, inventory levels or shipment notices, to name a few. Some applications allow several companies to
collaborate on joint efforts such as product design. The larger corporations have attempted to link their business
processes together to achieve a higher level of efficiency.
This level of application
integration has used various technologies.
They included various protocols built over TCP/IP. Generally, large
volume of data is exchanged using FTP, while the smaller volume data has been
exchanged using messaging protocols.
The integration software (aka, connectors) built layers over these
transport mechanisms to integrate business processes between companies. The connectors are highly coupled to the
concerned applications. Different or
new applications require custom connectors to achieve a level integration with
existing applications.
Web services can play an
important role in helping companies achieve application integration
quickly. Rather than going thru
cumbersome definition of interfaces and development of compatible connectors,
the service provider simply exposes a service on the web, publishes the
interface and service naming specifications in the UDDI registry and wait for a
connection. The integration
responsibility is pushed to the client application.
Key Issues
Web services are not a
panacea. The current level of
technology will require other services such as security to make it
industrial-strength.
<to be continued>
Tools
.net
J2EE
Online Links
www.webservicesarchitect.com
http://www-106.ibm.com/developerworks/webservices/
http://www.microsoft.com/ms.htm
http://java.sun.com/webservices/