You are hereWhat are Web services?
What are Web services?
Let's start by looking at the overall view of what Web services actually are, and why they're important to software development.
If you hadn't been hearing lots and lots of information about Services-oriented architecture (SOA) and Web services, you wouldn't be here, so the question is, why is this such a big deal? The answer is that it's a big deal because it's a paradigm shift in the way applications communicate with each other. SOAs have been around for a long, long, time. Originally they mostly consisted of middleware applications in which a single type of middleware owns, at the very least, both ends of the wire. Web services, on the other hand, consist of a group of standards intended to make it possible for diverse systems to communicate, without requiring a particular type of middleware, programming language or even operating system. Let's look at the progression from where we started out to where we are now.
 |
|
In the beginning, there were computers. And it was good. Computers performed seemingly miraculous tasks, automating many of the things that people did by hand, starting with complex calculations, and moving to financials, and many other tasks.
But traditional applications are "silos". The human resources application couldn't really talk to the financials application, which couldn't really talk to the distribution application. All of these applications had their own home, on their own computer, and while they were useful, there wasn't a good way to share data between them. You had the option to write batch processes to move data from one system to another, but that was no substitute for real-time integration.
|
|
The next step in our evolutionary chain is distributed computing. Distributed computing enabled different applications to talk to each other, even if they weren't on the same computer. Technologies such as CORBA, MTS, and Enterprise Java Beans (EJB), provided a system that included a registry of sorts so that applications could find components with which they wished to interact, and then call these components as though they were located on the local machine.
These systems were supported by middleware, or more specifically, message-oriented middleware, which provided both of these requirements. Applications could now be built in such a way that they could access resources on other systems, even if they were in different geographic locations.
But there was still a problem. While applications were free to communicate anywhere within the system, it was still a closed system. At the very least, your client application had to use the same technology as the server application. Also, the systems were not designed, as a rule, for access from outside of the individual organization that had created them.
|
|
The next, almost inevitable link in this evolutionary chain is Web services. Based on XML, and, in most cases, HTTP, "Web services" still means many things to many people, but in this case, we're going to talk about Web services as the exchange of SOAP-based messages between systems.
These messages are composed of XML, which is a text-based open standard, accessible by anyone from any application (any application that's been designed to accept it). This expands the world for your application to include anyone who can reach it over your network. (If that sets off security bells for you, that's OK, you'll learn how to deal with that in part four of this series.)
A SOAP-based Web service involves the sending of an XML message such as shown in Listing 1.
Listing 1. A SOAP-based web service
These messages move from one system to another, usually via HTTP. The receiving system interprets the message, does what it's supposed to do, and sends back a response in the form of another SOAP message.
It is a simple system, and as such, there are many aspects of enterprise-level computing that are not covered by it. Fortunately, many of these aspects have been taken into consideration, and have their own specifications to determine how this transaction should take place to incorporate many of the security and other aspects of traditional message-oriented middleware.
|
|
I would be remiss if I didn't mention that SOAP is not the only way to do Web services. There are other XML-based means for sending messages between systems, some of which are applicable to an enterprise environment, and some of which are not. For example, Amazon was one of the first Web-based companies to provide Web services access to its system to the public. Amazon includes a SOAP-based service, but it also provides a service based on Representational State Transfer (REST).
REST is a type of Web service in which the user simply accesses a URL, and the response is a straight XML document such as the one shown in Listing 2.
There is no particular format to these messages. It is just whatever the data happens to be.
Another type of Web service involves the use of a standard such as XML-RPC. In this case, commands are sent to a system via XML such as shown in Listing 3.
The response follows a similar format.
As you're learning to use SOAP, in the back of your mind you may be thinking that REST and XML-RPC are much simpler than a SOAP-based system. And you're right. In some ways, they are. However, we are not talking about a simple application to display the weather on your web site. We're talking about enterprise-level applications here, and enterprise-level applications need enterprise-level attributes such as security, interoperability, and so on. These capabilities are covered by additional specifications that have sprung up around SOAP-based Web services, which makes SOAP a better choice for enterprise-level applications in the long run.
Let's look at some of these specifications.
|
|
Basic Web services specifications
Web services specifications typically fall into two categories: basic Web service specs, and expanded Web service specs. The basic specifications are:
- SOAP: The foundation of all SOAP-based Web services, the SOAP specification details the format of the actual messages. It also details the way applications should treat certain aspects of the message, such as elements in the "header", which enable you to create applications in which a message is passed between multiple intermediaries before reaching its final destination. This tutorial will cover the SOAP specification.
- WDSL: Web Services Description Language is a specification that details a standard way to describe a SOAP-based Web service, including the form the messages should take, and where they should be sent. It also details the response to such a message. WSDL, when combined with the appropriate tools, enables you to create a call to a web service programmatically without ever actually knowing what the Web service is looking for; the application can extract those details from the WSDL file and provide you with programmatic interfaces to use. We'll cover WSDL in part two of this series.
- UDDI: Universal Description, Discovery and Integration is a standard that has undergone somewhat of a change since its initial inception. The idea was to provide a way for companies to register their services in a global registry, and search that global registry for services they may be interested in using. However, because many companies are understandably reticent about opening their systems to outsiders, this goal hasn't quite materialized. However, UDDI has taken hold as an internal registry of services and service information; part three of this series details its use.
Those are the basics. There are also literally dozens of extended standards to make SOAP-based services more useful.
|
|
Extended Web services specifications
Of the dozens all of WS-*specifications floating around, several distinguish themselves as being particularly useful to the enterprise. They are:
- WS-Security: This specification handles encryption and digital signatures, enabling you to create an application in which messages can't be eavesdropped, and in which non repudiation as possible. Part four of this series covers WS-Security.
- WS-Policy: This specification expands on WS-Security, enabling you to more specifically detail how and by whom a service can be used. Part five of this series covers WS-Policy.
- WS-I: Although Web services are supposed to be designed for interoperability, in actuality there is enough flexibility in the specifications that interpretations between different implementations can cause problems. WS-I provides a set of standards and practices to prevent the sorts of problems, as well as standardized tests to check for problems. WS-I is the subject of part six of this series.
- WS-BPEL: a single service is nice, but in most cases it is hardly an application. At the very least, enterprise-level computing requires you to compose multiple services into an overall system, and WS-BPEL provides a way to specify interactions such as branching and concurrent processing that are necessary for creating such systems. Part seven of this series covers WS-BPEL.
Other specifications that play an important role in Web services are not covered in this series including WS-ReliableMessaging, which enables you to be certain that one and only one copy of a message has been received, and that it has definitely been received; WSRF, the Web Services Resource Framework, which enables you to use state in what is essentially a stateless environment; and Web Services Distributed Management (WSDM), which discusses the issue of management of and using Web services. You can find more information about these and other specifications in the Resources for this tutorial.
Source:
https://www6.software.ibm.com/developerworks/education/ws-understand-web-services1/section2.html