XML Web Services are the basic building blocks for distributed computing on the Internet. Open standards and a focus on communication and collaboration between users and applications have created an environment in which XML Web Services become the platform for application integration. Applications are constructed using XML Web Services from multiple different sources that work together regardless of where they are located or how they are implemented.
There are as many XML Web Service definitions as there are companies building XML Web Services. But almost all definitions have the following in common:
XML Web Services provide useful functionality to Web users through standard Web protocols. In most cases the SOAP protocol is used.
XML Web Services can specify their interfaces in great detail, which enables users to create client applications to communicate with them. This description is usually contained in an XML document called a Web Services Description Language (WSDL) document.
XML Web Services are registered so that potential users can easily find them, which is accomplished through Universal Discovery, Description, and Integration (UDDI).
This article will introduce these three technologies, but first we need to explain why you should pay attention to XML Web Services.
One of the main advantages of the XML Web Services architecture is that it allows a variety of programs written in different languages on different platforms to communicate with each other in a standards-based manner. Users who know something about this industry may immediately say: "Wait a minute, didn't CORBA and the previous DCE make the same commitment? What is the difference between this and them?" The most important difference is: SOAP is better than before The approach is much simpler, so there are far fewer barriers to implementing standards-compliant SOAP. Paul Kulchenko provides a list of SOAP implementations at http://www.soapware.org/directory/4/implementations (in English). At last count, the list contained 79 items. As you might expect, most major software companies provide SOAP implementations, but there are also many implementations created and maintained by individual developers. Another major advantage of XML Web Services over previous solutions is the use of standard Web protocols - XML, HTTP and TCP/IP. Many companies have already established Web infrastructure and their employees have the knowledge and experience to maintain it. Therefore, the cost of introducing XML Web Services is much lower than introducing previous technologies.
We define an XML Web Service as a software service provided on the Web via SOAP, described using a WSDL file, and registered via UDDI. So, you may ask: "What can you do with XML Web Services?" The original XML Web Services were often sources of information that could be easily incorporated into applications, such as stock prices, weather forecasts, sports scores, and so on. It's easy to imagine an entire class of applications that could be built to analyze and summarize the information you care about, and make that information available in a variety of ways; for example, you could use a Microsoft® Excel spreadsheet to summarize all your financial information—stocks, 401K , bank deposits, loans, etc. If this information is available through XML Web Services, Excel can continuously update it. Some of this information is free, and some may require a subscription to obtain the corresponding service. Much of this information is already available on the Web, but XML Web Services can make programmatic access easier and more reliable.
Existing applications are made available as XML Web Services, and new, more powerful applications can be built using XML Web Services as building blocks. For example, a user can develop a purchasing application to automatically obtain price information from different suppliers, allowing the user to select a supplier, submit an order, and then track the shipment of goods until the goods are received. In addition to providing services on the Web, the supplier's application can also use XML Web Service to check customer credit, collect payment, and handle freight procedures with freight companies.
In the future, some of the most interesting XML Web Services-powered applications will be able to leverage the Web to accomplish tasks that are currently impossible. For example, the calendar service is one of the services that will be supported by the Microsoft .NET My Services (English) project. If your dentists and mechanics provide their schedules through this XML Web Service, you can schedule appointments with them over the Web; if you prefer, they can also schedule cleanings and routine maintenance dates directly on your calendar. It's easy to imagine that if you could program the Web, you could create hundreds of applications.
For more information about XML Web Services and the applications you can build, see the MSDN Web Services (English) home page.
SOAP
SOAP is the communication protocol of XML Web Service. When describing SOAP as a communications protocol, most people think of DCOM or CORBA and ask questions such as "How does SOAP activate objects?" or "What naming service does SOAP use?" Although SOAP implementations may include these elements, they are not specified by the SOAP standard. SOAP A specification that defines the XML format of messages - this is a required part of the specification. A well-formed XML segment contained within a pair of SOAP elements is a SOAP message. Isn't this simple?
Other parts of the SOAP specification describe how to represent program data as XML and how to use SOAP for remote procedure calls (RPC). These optional parts of the specification are used to implement RPC-style applications, where the client will issue a SOAP message (containing a callable function, and the parameters to be passed to the function), and the server will return a message containing the results of the function execution. Currently, most SOAP implementations support RPC applications because programmers who are accustomed to developing COM or CORBA applications are familiar with the RPC format. SOAP also supports document-style applications, in which a SOAP message is just a wrapper around an XML document. Document-based SOAP applications are very flexible, and many new XML Web Services take advantage of this feature to build services that are difficult to implement using RPC.
The final optional part of the SOAP specification defines the style of HTTP messages that contain SOAP messages. This HTTP binding is important because almost all current OSs (and many previous OSs) support HTTP. Although optional, HTTP binding is supported by almost all SOAP implementations because it is the only standard protocol for SOAP. For this reason, people often mistakenly believe that SOAP must use HTTP. In fact, some implementations also support MSMQ, MQ Series, SMTP or TCP/IP transport, but because HTTP is so ubiquitous, almost all current XML Web Services use it. Because HTTP is the core protocol of the Web, most organizations' network infrastructure supports HTTP and employees already know how to manage it. Today, the infrastructure for HTTP security, monitoring, and load balancing has been established.
When starting to use SOAP, the most confusing thing is the difference between the SOAP specification and its many implementations. Most users of SOAP do not write SOAP messages directly but use SOAP toolkits to create and analyze SOAP messages. These toolkits typically convert function calls from a language into SOAP messages. For example, the Microsoft SOAP Toolkit 2.0 converts COM function calls to SOAP, and the Apache Toolkit converts JAVA function calls to SOAP. The types of function calls and supported parameter data types vary with each SOAP implementation, so a function that works for one toolkit may not work for another. This is not a limitation of SOAP, but of the specific implementation used.
By far, the most compelling feature of SOAP is that it can be implemented on many different software and hardware platforms. This means that SOAP can be used to link disparate systems within and outside the enterprise. Various approaches have been tried in the past to come up with a common communications protocol that could be used for system integration, but none of them has gained the widespread acceptance that SOAP has. Why? Because SOAP is smaller and easier to implement than many earlier protocols. For example, DCE and CORBA took years to implement, so only a few implementations have been released. SOAP can leverage 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. That's why there are now more than 70 SOAP implementations. Of course, SOAP does not have all the functions of DCE or CORBA. Although the functions are reduced, SOAP is easier to apply because its complexity is greatly reduced.
The popularity of HTTP and the simplicity of SOAP allow you to call them from almost any environment, making them an ideal foundation for XML Web services. For more information about SOAP, see the MSDN SOAP (English) home page.
How safe is it?
Often, the first question asked by users new to SOAP is how SOAP solves security issues. In its early development stages, SOAP was viewed as a protocol based on HTTP, so the security of HTTP was considered sufficient for SOAP. After all, there are thousands of Web applications currently using HTTP security, so this is indeed sufficient for SOAP. Therefore, the current SOAP standard assumes that security is a transport issue and is not treated as a security issue.
As SOAP expands into a more general protocol and runs on numerous transports, security issues become more prominent. For example, HTTP provides several ways to authenticate users making SOAP calls, but how does that identity propagate when messages are routed from HTTP to SMTP transport? SOAP was designed as a building block protocol, so fortunately there are specifications in place to provide additional security features for Web services based on SOAP. The WS-Security specification (English) defines a complete encryption system, and the WS-License specification (English) defines the corresponding technology to ensure the identity of the caller and ensure that only authorized users can use Web services.
WSDL
WSDL (Web Services Description Language) stands for Web Services Description Language. For the purposes of this article, we can think of a WSDL file as an XML document that describes a set of SOAP messages and how to exchange them. In other words, WSDL is to SOAP what IDL is to CORBA or COM. Because WSDL is an XML document, it is easy to read and edit; but in most cases, it is generated and used by software.
To view the values of the WSDL, imagine that you want to call a SOAP method provided by one of your business partners. You could ask for some sample SOAP messages and then write your application to generate and use messages similar to the samples, but this is easy to make mistakes. For example, you might see a customer ID of 2837 and assume it is an integer, when in fact it is a string. WSDL specifies through an explicit notation what the request message must contain and what the response message should look like.
The notation used by WSDL files to describe message formats is based on the XML Schema standard, which means that it is programming language agnostic and standards-based, making it suitable for describing XML Web Services that can be accessed from different platforms and in different programming languages. interface. In addition to describing the content of the message, WSDL also defines the location of the service and what communication protocol is used to communicate with the service. That is, the WSDL file defines everything needed to write a program that uses XML Web Services. There are several tools that can read WSDL files and generate the code required to communicate with XML Web services. Some of the most powerful tools can be found in Microsoft Visual Studio® .NET.
Currently, many SOAP toolkits include tools for generating WSDL files from existing program interfaces, but there are few tools for writing WSDL directly, and tool support for WSDL is incomplete. But soon there will be tools for writing WSDL files, followed by tools for generating proxies and stubs (much like COM IDL tools), and these tools will become part of most SOAP implementations. Until then, WSDL will become the preferred method for creating SOAP interfaces to XML Web services.
There is a very good description of WSDL here (in English), and you can also find the WSDL specification at http://www.w3.org/TR/wsdl (in English).
UDDI
Universal Discovery, Description, and Integration (UDDI) is the Yellow Pages of Web services. Like the traditional Yellow Pages, you can search for companies that offer the services you need, read to learn about the services offered, and then contact someone for more information. Of course, you can provide Web services without registering them in UDDI, which is like running a business in your basement and relying on word of mouth; but if you want to expand your market, you need UDDI so that you can be discovered by your customers.
UDDI directory entries are XML files that describe the services and services provided. A UDDI directory entry consists of three parts. "White Pages" introduce companies providing services: name, address, contact information, etc.; "Yellow Pages" include industry categories based on standard classifications (such as North American Industry Classification System and Standard Industrial Classification); "Green Pages" provide detailed information Access the interface to the service so that users can write applications to consume the Web service. The definition of a service is accomplished through a UDDI document called a type model (or tModel). In most cases, the tModel contains a WSDL file that describes the SOAP interface to access the XML Web Service, but the tModel is very flexible and can describe almost any type of service.
The UDDI directory also contains several methods for searching for the services required to build your application. For example, you can search for service providers in a specific geographic location or search for a specific type of business. The UDDI directory will then provide information, contact details, links and technical data so you can identify the services that meet your needs.
UDDI allows you to find companies that provide the Web services you need. What do you do if you already know who you want to do business with, but don’t yet know what else it can offer? The WS-Inspection specification (in English) allows you to browse the collection of XML Web Services available on a specific server to find the service you need.
For more information about UDDI, visit http://www.uddi.org/about.html (in English).
Other Content
So far, we've discussed how to communicate with XML Web Services (SOAP), how XML Web Services are described (WSDL), and how to find XML Web Services (UDDI). These form a basic set of specifications that provide the basis for application integration and aggregation. Based on these basic specifications, companies can build practical solutions and benefit from them.
We have done a lot of work to implement XML Web Services, but there is still a lot of work to be done. Today, people have achieved success using XML Web Services, but for developers, there are still many links to improve. For example, security, operations management, transaction processing, and reliable messaging. The Global XML Web Services Architecture will help XML Web Services enter the next stage of evolution by providing a consistent, common model for adding new advanced capabilities to XML Web Services in a modular and extensible manner.
The security modules mentioned above (WS-Security [English] and WS-License [English]) are part of the Global Web Services Architecture specification. Operational management needs (such as routing messages between multiple servers and dynamically configuring those servers for processing) are also part of the Global Web Services Architecture through the WS-Routing specification (English) and the WS-Referral specification (English) to achieve. As the Global Web Services Architecture evolves, specifications that address these and other needs will be introduced.