Page 216 - DCAP312_WEB_TECHNOLOGIES_II

Web Technologies-II

Notes The next logical question is. “What can we do with XML Web services?” The first XML Web
services tended to be information sources that you could easily incorporate into applications—
stock quotes, weather forecasts, sports scores etc. It is easy to imagine a whole class of applications
that could be built to analyze and aggregate the information you care about and present it
to you in a variety of ways; for example, you might have a Microsoft® Excel spreadsheet
that summarizes your whole financial picture—stocks, 401K, bank accounts, loans, etc. If this
information is available through XML Web services, Excel can update it continuously. Some
of this information will be free and some might require a subscription to the service. Most of
this information is available now on the Web, but XML Web services will make programmatic
access to it easier and more reliable.
Exposing existing applications as XML Web services will allow users to build new, more
powerful applications that use XML Web services as building blocks. For example, a user might
develop a purchasing application to automatically obtain price information from a variety of
vendors, allow the user to select a vendor, submit the order and then track the shipment until
it is received. The vendor application, in addition to exposing its services on the Web, might in
turn use XML Web services to check the customer's credit, charge the customer's account and
set up the shipment with a shipping company.
In the future, some of the most interesting XML Web services will support applications that
use the Web to do things that cannot be done today. For example, one of the services that XML
Web Services would make possible is a calendar service. If your dentist and mechanic exposed
their calendars through this XML Web service, you could schedule appointments with them
on line or they could schedule appointments for cleaning and routine maintenance directly in
your calendar if you like. With a little imagination, you can envision hundreds of applications
that can be built once you have the ability to program the Web.
10.2.1 SOAP
SOAP is the communications protocol for XML Web services. When SOAP is described as a
communications protocol, most people think of DCOM or CORBA and start asking things like,
“How does SOAP do object activation?” or “What naming service does SOAP use?” While a
SOAP implementation will probably include these things, the SOAP standard does not specify
them. SOAP is a specification that defines the XML format for messages—and that's about it for
the required parts of the spec. If you have a well-formed XML fragment enclosed in a couple
of SOAP elements, you have a SOAP message. Simple is not it?
There are other parts of the SOAP specification that describe how to represent program data
as XML and how to use SOAP to do Remote Procedure Calls. These optional parts of the
specification are used to implement RPC-style applications where a SOAP message containing
a callable function, and the parameters to pass to the function, is sent from the client, and the
server returns a message with the results of the executed function. Most current implementations
of SOAP support RPC applications because programmers who are used to doing COM or
CORBA applications understand the RPC style. SOAP also supports document style applications
where the SOAP message is just a wrapper around an XML document. Document-style SOAP
applications are very flexible and many new XML Web services take advantage of this flexibility
to build services that would be difficult to implement using RPC.

The last optional part of the SOAP specification defines what an HTTP message that contains a
SOAP message looks like. This HTTP binding is important because HTTP is supported by almost
all current OS's (and many not-so-current OS's). The HTTP binding is optional, but almost all
SOAP implementations support it because it is the only standardized protocol for SOAP. For this
reason, there are a common misconception that SOAP requires HTTP. Some implementations
support MSMQ, MQ Series, SMTP, or TCP/IP transports, but almost all current XML Web

210 LOVELY PROFESSIONAL UNIVERSITY