Understanding Web

Services
Web services represent a new architecture for creating applications that can be accessed from a different computer.

A Web service is a software application that can be accessed remotely using different XML-based languages.
Normally, a Web service is identified by a URL, just like any other Web site. What makes Web services different
from ordinary Web sites is the type of interaction that they can provide.

A Web service is similar in that it is accessed via a URL. The difference lies in the content of what is sent in the
request from the client to the service. Web service clients send an XML document formatted in a special way in
accordance with the rules of the SOAP specification.
The Great Promise of Web Services
The implications of this are significant:
• It doesn’t matter what kind of computer sends the SOAP message or on what operating
system it is running.
• It doesn’t matter where in the world the client is sending the message from.
• It doesn’t matter what language the software that the client is running on was written
in.
• There is no need for the client to know what type of SOAP processor is running on
the server.

the following are considered the core Web services standards:

• SOAP—SOAP originally stood for Simple Object Access Protocol. But SOAP is
now considered a specification name and not an acronym. SOAP is a specification
that defines an XML grammar for both sending messages and responding to messages
that you receive from other parties. The goal of SOAP is to describe a message
format that is not bound to any hardware or software architecture, but one that
carries a message from any platform to any other platform in an unambiguous
fashion.

The SOAP standard contains two parts:

the header that carries processing instructions and
the body that contains the payload. The payload contains the information that you want to send.

The two types of SOAP messages are documents and Remote Procedure Calls (RPCs). The payload of a document
message is any XML document that you want moved from one computer to another. An RPC is a method call that is
intended to be executed on the Web service’s computer. The RPC message performs the same function as an
ordinary method call in an ordinary programming language

• Extensible Markup Language (XML)—Extensible Markup Language (XML) is the language that all the Web
services Languages are built on. XML is a tool for constructing self-describing documents. In fact, XML is more of
a meta-language than a language in that it is used to create grammars. These grammars are described in XML
schemas that specify the tags that are allowed and the relationships between the elements defined by these tags.
SOAP, WSDL, and UDDI are all XML-based grammars.

• Hypertext Transport Protocol (HTTP)—Hypertext Transport Protocol (HTTP) is a standard that precedes the
advent of Web services. It was developed to facilitate the transfer of requests from a browser to a Web server. Web
services takes advantage of the existence of this mature protocol to move SOAP messages and WSDL documents
from one computer to another.

Web Services Description Language (WSDL)—Web services Description Language (WSDL) is a specification
that tells us how to describe a piece of software in terms of the method calls that it responds to. These methods are
described in an abstract way that is independent of what programming language the actual service is written in or
what computer and operating system it runs on. In fact, you can port an application from a personal computer to a
mainframe, and the abstract portion of the WSDL description will not change (assuming that the port and protocol
don’t change when you port them). The WSDL also contains a concrete section in which the various details of how
to actually make a connection to the service are stored. If a Web service could be accessed using HTTP, FTP, or
SMTP, you would find three entries in the concrete section—one for each service.

• Universal Discovery Description Integration (UDDI)—The Universal Discovery, Description, and Integration
(UDDI) specification describes how a potential customer of a Web service could learn about its capabilities and
obtain the basic information needed to make the initial contact with the site. Normally, this contact includes a
download of the WSDL.
UDDI registries can be public, private, or semiprivate. A public directory allows everyone on the planet to examine
the information that you post in the registry. A private registry exists behind the firewall of your organization and is
only accessible by members of your organization. A semiprivate registry is open only to a limited number of
outsiders such as you best trading partners.

Tools and Vendors

Web services can be developed using any programming language that supports sockets. You could write a client that
generated its own SOAP messages. You could then open a
socket and send the message to a Web service listening on that socket. That Web service
could do its own SOAP parsing, make its own method calls, write to its own logs, and
prepare its own SOAP response message. Finally, it could open a response socket and
send the return message to the client, who could then display the results.

Tools range from special Java classes that know how to create SOAP messages to fullblown
development environments that remind you of a high quality Fourth generation language tool. The following is a list
of the tools that we will cover in this book:
• Apache Axis—Apache Software Foundation coordinates the creation of open source projects. One of its projects
is a SOAP engine that is normally used with its Tomcat server. Axis is the subject of Hour 13, “Creating Web
Services with Apache Axis.”
• Java—Sun Microsystems has created a set of optional packages that can access UDDI registries, generate WSDLs,
and so on. These packages are the subject of Hour 14, “Creating Web Services with Java.”
• Visual Studio .NET—Microsoft’s new way to create Web services is to use this product in conjunction with any
one of the Visual Studio languages such as Visual Basic, Visual C++, or C#. Hour 15, “Creating Web Services
with .NET,” shows an example that creates a Web service using Visual Basic .NET.

• Web Services .NET Clients—Clients created using .NET that can interact with any Web service. Hour 16,
“Creating .NET Web Service Clients,” covers this.
• BEA WebLogic Workshop—BEA is a leading J2EE vendor that has created a user-friendly way to create Web
services by using an elaborate IDE. Hour 17, “Creating Web Services with BEA WebLogic Workshop,” covers this
tool.
• IBM WebSphere Studio Application Developer (WSAD)—IBM has made the creation of Web services a part of
its comprehensive package called WSAD. We cover the creation of Web services with WSAD in Hour 18, “Creating
Web Services with IBM WebSphere.”
• Other Important Products—Many lesser-known companies have quality entries in the Web services
development tool market. Hour 19, “Creating Web Services with Other Toolkits,” covers Iona XMLbus, The Mind
Electric GLUE, PocketSOAP, and SOAP::Lite.

Faster System Development

Many vendors provide rapid development tools that go beyond what is available for creating user interfaces. Web
services are based on the creation of both a service and a formal description of the service called the Web Services
Description Language (WSDL) document. This document contains enough information about the service to allow a
client to be generated. Instead of starting with a blank sheet of paper, the programmer of a Web service client starts
with a generated client that can successfully access a Web service. He can then enhance that client to interact with
the other systems on the client side. The time and learning curve savings from using this approach is significant.

New Revenue Opportunities

This level of cooperation between computer systems will open up new opportunities for virtual enterprises. A
virtual enterprise is one that is made up of several smaller enterprises. For example, if a hotel in Orlando booked
your room, scheduled your flight, reserved your rental car, and sold you tickets to the theme parks, you would be
doing business with a virtual company. No single company owns airplanes, cars, hotels, and theme parks. Each
company owns one of these assets and offers the others
through partnership agreements. In fact, you could start a company that owns none of these assets. Your sole reason
for existing is to provide one-stop shopping for these types of packages.
Pitfalls of Web Services
No technology is perfect. Although Web services do a great job at solving certain problems, they bring along issues
of their own. Some of these pitfalls are inherent to the technological foundations upon which Web services are
based, and others are based on the specifications themselves. It is important to know what these issues are so that
you can plan for and build around them.+

Some of the biggest issues are

• Availability—Everyone who uses the Internet knows that no site is 100% available. It follows that Web services,
which use the same infrastructure as Web sites, will not be 100% available either. Even if the server is up and
running, your ISP might not be, or the ISP hosting the other side of the transaction might not be either. If you need
100% up time, do something else. Because of this situation, it is often necessary to build mechanisms that will retry
the transaction or fail gracefully when this occurs.

Some of the newer protocols supported by Web services (JMS, for instance) will handle this automatically, but the
majority built on HTTP will not.

 Matching Requirements—Any time you create a general service that will handle
a variety of customers, you will run into specialized requirements. Some customers
might require the one extra little feature that nobody else needs. Web services are
envisioned as a “one size fits many customers” technology. If your business can’t
fit into that model, you should consider other solutions.