|
XML, SOAP, UDDI
XML
XML provides a standards-based method for describing data. XML is used extensively
in building and consuming Web services. XML has the ability to describe data that
is highly interoperable among many different systems on the Internet. Using the basic
elements of XML we can define simple and complex data types and relationships. XML
promotes the ability of Web services to communicate their data efficiently and effectively.
It's this XML that ensures a consistent and accurate interpretation of the data when
the service and consumer reside on different platforms.
You can have a overview of XML in the "Essential XML" section of
this site.
SOAP
We hear a lot about SOAP these days. Let's take a look what SOAP is and why it is
related to .NET. Simple Object Access Protocol (SOAP) is
a lightweight protocol for exchange of information in a decentralized, distributed environment.
It's an industry-standard message format that enables message-based communications
for Web services. It's XML based and consists of three parts, an envelop that
defines a framework for describing what is in a message and how to process it, a set
of encoding rules for expressing instances of application-defined
data types and a convention for representing remote procedure
calls (RPC). The capability of SOAP to provide a modular packaging model and encoding
mechanisms for encoding data within modules allows it to be used over multiple protocols
with a variety of different programming models.
There are optional parts of the SOAP specification and one optional part defines what
an HTTP message that contains a SOAP message looks like. This HTTP binding is important
as HTTP is supported by almost all operating systems. The HTTP binding is optional,
but almost all SOAP implementations support it as it's the only standardized protocol
for SOAP. For this reason, there's a common misconception that SOAP requires HTTP.
Some implementations support MSMQ, MQ Series, SMTP, or TCP/IP transports, but
almost all current XML Web services use HTTP because it is ubiquitous.
A major source of confusion when getting started with SOAP is the difference between
the SOAP specification and the many implementations of the SOAP specification. Most
people who use SOAP don't write SOAP messages directly but use a SOAP toolkit to create
and parse the SOAP messages. These toolkits generally translate function calls from
some kind of language to a SOAP message. For example, the Microsoft SOAP Toolkit 2.0
translates COM function calls to SOAP and the Apache Toolkit translates JAVA function
calls to SOAP. The types of function calls and the data types of the parameters supported
vary with each SOAP implementation, so a function that works with one toolkit may
not work with another. This isn't a limitation of SOAP but rather of the particular
implementation you are using.
By far the most compelling feature of SOAP is that it has been implemented on many
different platforms. This means that SOAP can be used to link disparate systems
within and without an organization. Many attempts have been made in the past to come
up with a common communications protocol that could be used for systems integration
but none of them have had the widespread adoption that SOAP has. That's because SOAP
is much smaller and simpler to implement than many of the previous protocols. For
example, DCE and CORBA took years to implement. SOAP, however, can use existing XML
Parsers and HTTP libraries to do most of the hard work, so a SOAP implementation can
be completed in a matter of months. This is why there are more than 70 SOAP implementations
available. SOAP obviously doesn't do everything that DCE or CORBA do, but the lack
of complexity in exchange for features is what makes SOAP so readily available.
UDDI
Universal Discovery Description and Integration is like the "Yellow
Pages" of Web services. As with traditional yellow pages, we can search for
a company that offers the services we need, read about the service offered and contact
the company for more information. We can also offer a Web service without registering
it in UDDI.
A UDDI directory entry is an XML file that describes a business and the services it
offers. There are three parts to an entry in the UDDI directory. The "white
pages" describe the company offering the service, like, name, address, contacts,
etc. The "yellow pages" include industrial categories based
on standard taxonomies the Standard Industrial Classification. The "green
pages" describe the interface to the service in enough detail for someone to
write an application to use the Web service. The way services are defined is through
a UDDI document called a Type Model or tModel. In many cases,
the tModel contains a WSDL file that describes a SOAP interface to an XML Web service,
but the tModel is flexible enough to describe almost any kind of service.
The UDDI directory also includes several ways to search for the services we need to
build our applications. For example, we can search for providers of a service in a
specified geographic location or for business of a specified type. The UDDI directory
will then supply information, contacts, links, and technical data to allow us to evaluate
which services meet our requirements.
UDDI allows us to find businesses we might want to obtain Web services from. If we
already know whom we want to do business with but if we don't know what services are
offered then we can use the the WS-Inspection specification that allows us to browse
through a collection of XML Web services offered on a specific server to find which
ones might meet your needs.
|