One of the more confusing items about Web Services regards defining exactly what and
why they are. Let's begin with why they exist.
Web Services exist to make it easier to integrate applications. Existing technologies include
Java RMI, CORBA, and DCOM. All of these technologies work over networked
environments and allow for application integration. This application integration is possible if
all the components are reachable over a LAN. However, when going out to the public
Internet, these networked applications start to break down. Another problem is that none of
these technologies work well for cross platform, cross language integration. Often, working
with one of these technologies ties you to a particular language, operating system, or toolkit
that must be uniform across the solution. In today's world, the odds of having all systems
being written in the same language or using the same operating system and
interconnection libraries is fairly small. Add to this a desire to connect these applications
across large distances using the Internet and you will find that almost all of these
technologies come up short. The necessity of addressing these shortcomings gave birth to
Web Services. So, what are they?
A Web Service is a programmatic interface that is accessible via the Internet. As such, it
must rely on standardized protocols. You may be aware of the various technologies
surrounding Web Services. SOAP (an abbreviation that does not really mean anything
anymore), Web Services Description Language (WSDL), and Universal Description
Discovery and Integration (UDDI) are just a few of the technologies that are a part of Web
Services. To make Internet accessibility a reality, SOAP v1.1 and v1.2 rely on existing,
widely deployed technologies.