Building Blocks
of WEB services
Some standards and
protocols are still going through revisions, but still the following diagram
will provide simple view of the technologies used in XML WEB services:
Directory and
Discovery
The key to XML Web
Services is to expose the description of its services that is provided. This is
because a user of these services should be able to find it and use the services
properly. Here are some forms of
discovery mechanisms:
UDDI (Universal
Description, discovery and Integration): This is like a Yellow Page of existing Web Services
– it’s location and functionality provided. UDDI helps consumers (typically
programmers) trying to use a service from other existing WEB Services. Some of
the UDDI registries available to public are:
·
IBM:
www.ibm.com/services/uddi
·
SAP:
http://uddi.sap.com
·
Microsoft:
http://uddi.microsoft.com
Companies also may
have internal private UDDI registry for use by different offices and
departments within the same companies or partners.
DISCO: Stands for discovery that
allows the web sites to publish the descriptions of WEB services available.
This is Microsoft’s proprietary technology and only Visual Studio .NET is
integrated with the DISCO files. The DISCO maintenance is easy that UDDI, so
small companies may want to use it internally for publishing the available
services.
Description
(WSDL):
Once an XML Service
is discovered, the client consumer needs to understand the detailed information
on interaction. This is done in WSDL, Web Services Description Language. WSDL
is an XML format that contains information about the incoming (request) and
outgoing (response) format of each message associated with the Service. It’s a
contract between the consumer (client) and the producer (WEB service) on how it
behaves.
Visual Studio .NET
wraps the WSDL, so we do not have to worry about the WSDL implementation.
Messaging (SOAP):
SOAP – Simple Object
Access Protocol has been adopted as the preferred way to communicate with WEB
Services. SOAP is based on XML and is platform independent.
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 isn't
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). Since
HTTP is a core protocol of the Web, most organizations have a network
infrastructure that supports HTTP and people who understand how to manage it
already. The security, monitoring, and load-balancing infrastructure for HTTP
are readily available today.
By far
the most compelling feature of SOAP is that it has been implemented on many
different hardware and software platforms. This means that SOAP can be used to
link disparate systems within and without your 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. Why is this? Because SOAP is much smaller and simpler
to implement than many of the previous protocols. DCE and CORBA for example
took years to implement, so only a few implementations were ever released.
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.
For more information
on XML and SOAP, you may want to visit these web sites:
http://msdn.microsoft.com/SOAP
Transport (HTTP)
SOAP messages are
sent over wire using the HTTP protocol (the one you are using now to read this
tutorial). Since HTTP is easy to use and goes through firewall it’s more
popular over other existing protocols for Web services communications:
SMTP: Simple MAIL
Transfer Protocol may also be used for WEB services.
WEB service
architecture:
The following diagram
shows the WEB service architecture under Microsoft .NET framework:
PROXY OBJECTS: .NET web service proxy is
glue between .NET framework and XML Web Service. This proxy is a C# (or any
other language like VB) class that exposes the functionality of XML web
services.
With no proxy,
programmers need to manually code the method interactions using WSDL document.
This would need writing the SOAP messages manually for send and receive which
is error prone.
Visual Studio .NET
creates proxy objects automatically so all the manual coding of lower layer is
not needed making the software development process more faster and reliable.
For more information
on how proxy objects are generated go to WebFormsClient
page.