web|xml| Microsoft XML Web Service Basics
Roger Wolter
Microsoft Corporation
December 2001
Summary:This article outlines the value of XML Web Service for developers, as well as SOAP, WSDL, and UDDI.
Directory
- What is an XML Web Service?
- Soap
- Wsdl
- Uddi
- Other content
What is an XML Web Service?
XML Web Service is the basic building block for distributed computing on the Internet. Open standards and the focus on communication and collaboration between users and applications create an environment in which XML Web Service becomes the platform for application integration. Applications are constructed from XML Web services of several different sources, which work in concert with each other, regardless of where they are located or how they are implemented.
How many XML Web service definitions are possible for the number of companies that build the XML Web service. But almost all definitions have the following in common:
- The XML Web Service provides useful functionality to Web users through standard Web protocols. In most cases, the SOAP protocol is used.
- The XML Web Service can describe its interfaces in great detail, which allows users to create client applications to communicate with them. This description is typically contained in an XML document called a WEB Service Description Language (WSDL) document.
- The XML WEB Service has been registered so that potential users can easily find these services through universal discovery, description, and Integration (UDDI).
This article describes the three technologies, but first you need to explain why you should focus on XML Web Service.
One of the main advantages of the XML Web Service architecture is that it allows various programs written in different languages to communicate with each other in a standards-based way on different platforms. Users who know about the industry may soon say, "Wait a minute, is CORBA not the same commitment as the previous DCE?" What's the difference between this and them? "The most important difference is that soap is much simpler than previous methods, so there are far fewer barriers to implementing standard-compatible soap." Paul Kulchenko provides a list of SOAP implementations in Http://www.soapware.org/directory/4/implementations (English). At the last count, the list already contains 79 items. As you might expect, most large software companies offer SOAP implementations, but there are many implementations that are created and maintained by individual developers. Another great advantage of XML Web service relative to previous scenarios is the use of standard WEB protocols-XML, HTTP, and TCP/IP. Many companies have built WEB infrastructures, and their employees have the knowledge and experience to maintain them. Therefore, the introduction of XML Web Service is much less costly than the introduction of previous technologies.
We define an XML Web service as a software service that is provided by SOAP on the web, described using a WSDL file, and registered through UDDI. So, you might ask, "What can you do with an XML Web service?" "The initial XML Web Service is usually a source of information that can easily be incorporated into an application, such as stock prices, weather forecasts, sports scores, and so on." It's easy to think that you can build an entire class of applications to analyze and summarize the information you care about, and provide that information in a variety of ways; For example, you can use the MICROSOFT®EXCEL spreadsheet to summarize all the financial information-stocks, 401K, bank deposits, loans, and so on. If you can get this information through an XML Web Service, Excel can keep updating it. Some of this information is free and some may require subscriptions to get the service. Most of this information can now be found on the web, but XML Web Service makes programmatic access simpler and more reliable.
Providing existing applications as XML Web service, you can build new, more powerful applications and use XML Web service as building blocks. For example, a user can develop a sourcing application to automatically obtain price information from different vendors, allowing the user to select a vendor, submit an order, and then track the shipment until the goods are received. In addition to providing services on the Web, the vendor's application can use the XML Web service to check the customer's credit, collect the payment, and handle shipping formalities with the shipping company.
In the future, some of the most interesting XML Web Service-supported applications can also take advantage of the WEB to accomplish tasks that are not currently complete. For example, the calendar service is one of the services that the Microsoft. NET my Services (English) project is about to support. If your dentists and machinists provide their schedules through this XML Web Service, you can schedule appointments with them through the network, and if you wish, they can also make a date for cleaning and daily maintenance on your calendar. It's not hard to imagine that you can create hundreds of applications as long as you can program the WEB.
For more information about XML Web services and the applications that can be built, see the MSDN Web Service (English) home page.
SOAP
Soap is the communication protocol for XML Web Service. When describing soap as a communication protocol, most people think of DCOM or CORBA and ask "How does soap activate an object?" "or" What kind of naming service does SOAP use? "And so on. Although the SOAP implementation scenario may contain the above, the SOAP standard does not prescribe it. SOAP A specification that defines the XML format of a message-this is a necessary part of the specification. The well-formed XML segment, contained within a pair of soap elements, is the SOAP message. Is it easy?
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 specification sections are used to implement applications in RPC form where clients emit a SOAP message (including callable functions and parameters to be passed to the function), and the server returns a message containing the result 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 RPC forms. SOAP also supports applications in the form of documents in which SOAP messages are only one wrapper in an XML document. A document-style SOAP application is flexible, and many new XML Web services use this feature to build a service that is difficult to implement with RPC.
The last optional part of the SOAP specification defines the style of the HTTP message that contains the SOAP message. This HTTP binding is important because almost all of the current OS (and many previous OS) support HTTP. Although HTTP bindings are optional, almost all SOAP implementations support HTTP binding because it is the only standard protocol for SOAP. For this reason, it is often mistaken that SOAP must use HTTP. In fact, some implementations also support MSMQ, MQ series, SMTP, or TCP/IP transmissions, but because HTTP is very common, almost all current XML Web service uses it. Because HTTP is the core protocol for the WEB, most organizations have a network infrastructure that supports HTTP, and employees have learned how to manage it. Today, the infrastructure for security protection, monitoring, and load balancing for HTTP has been established.
When you start using SOAP, the most confusing is the difference between the SOAP specification and many of its implementation scenarios. Most users who use SOAP do not write SOAP messages directly, but instead use soap toolkits to create and parse SOAP messages. These toolkits typically convert a function call from a language to a SOAP message. For example, Microsoft SOAP Toolkit 2.0 Converts a COM function call to soap, while the Apache Toolkit converts JAVA function calls to soap. The type of the function call and the data type of the supported parameter vary depending on each SOAP implementation, so functions that apply to one toolkit may not be applicable to another toolkit. This is not a limitation of SOAP, but of the specific implementation that is being used.
The most compelling feature of SOAP so far is that it can be implemented on many different software and hardware platforms. This means that SOAP can be used to link different systems within and outside the enterprise. Several methods have been tried in the past to propose a universal communication protocol that can be used for system integration, but none of them has been widely recognized as SOAP. Why, then? Because SOAP is smaller and easier to implement than many earlier protocols. For example, the implementation of DCE and CORBA takes years, so only a few implementations are released. While soap can do most of the hard work with existing XML parsers and HTTP libraries, the SOAP implementation scenario can be completed in a few months. That's why there are now more than 70 SOAP implementations. Of course, SOAP does not have all the functionality of DCE or CORBA, and although the functionality is reduced, soap is easier to apply because it is significantly less complex.
The popularity of HTTP and the simplicity of SOAP allow you to call them almost anywhere from any environment, making it an ideal base for XML Web Service. For more information about SOAP, see the MSDN Soap (English) home page.
What about security?
Often, the first question that a user who has just contacted SOAP raises is how SOAP resolves security issues. In its early stages of development, soap was considered an HTTP based protocol, so the security of HTTP was considered sufficient for soap. After all, there are thousands of WEB applications using HTTP security, so this is really enough for SOAP. Therefore, the current SOAP standard assumes that security is a transport issue and is not handled as a security issue.
When SOAP expands to a more generic protocol and runs on numerous transmissions, security issues become prominent. For example, HTTP provides several methods for authenticating a user who makes a SOAP call, but how does it propagate when a message is routed from HTTP to an SMTP transmission? SOAP is designed as a building block protocol, so fortunately, there is already a specification for providing additional security protection for WEB services based on SOAP. The Ws-security specification defines a complete set of cryptographic systems, while the Ws-license specification defines the appropriate technology to ensure the identity of the caller and ensures that only authorized users can use the Web service.
WSDL
The WSDL (Web Services Description Language) represents the Web Service description language. In 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 acts on SOAP as if IDL were for 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 see the value of the WSDL, you can assume that you want to invoke the SOAP method provided by one of your business partners. You can ask the other person to provide examples of SOAP messages, and then write your application to build and use a message similar to the example, but it's easy to go wrong. For example, you might see a 2837 customer ID and assume it's an integer, but it's actually a string. The WSDL specifies the content that the request message must contain and the style of the response message by explicit notation.
The presentation of the WSDL file to describe the message format is based on the XML Schema standard, which means that it is independent of the programming language and is based on the standard, so it is suitable for describing XML Web Service interfaces that can be accessed from different platforms and in different programming languages. In addition to stating the content of the message, WSDL defines the location of the service and what communication protocols are used to communicate with the service. That is, the WSDL file defines all the content required to write a program that uses an XML Web service. There are several tools that can read the WSDL file and generate the code needed to communicate with the XML Web Service. Some of the most powerful tools can be found in Microsoft Visual studio®.net.
Currently, many SOAP toolkits include tools to generate WSDL files from existing program interfaces, but there are few tools directly used to write WSDL, and the tool support for WSDL is incomplete. But there will soon be a tool for writing WSDL files, and then there will be tools for generating proxies and stubs (similar to COM IDL tools) that will be part of most SOAP implementation scenarios. By then, the WSDL will be the preferred method of creating the SOAP interface for the XML Web Service.
Here is a very good WSDL description (in English), and you can also find the WSDL specification in HTTP://WWW.W3.ORG/TR/WSDL (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 provide the services you need, read about the services you provide, and then contact someone for more information. Of course, you can also provide WEB services instead of registering in UDDI, like doing business in a basement, relying on verbal yelling, but if you want to expand the market, you need UDDI to be discovered by your customers.
A UDDI directory entry is an XML file that describes the business and services that are provided. A UDDI directory entry consists of three parts. "White" describes the company that provides the service: name, address, contact information, and so on; "Yellow Pages" includes standards-based taxonomies (such as North American Industry classification System and Standard Industrial Classification) industry category; The green page details the interface to access the service so that users can write applications to use the WEB service. The definition of a service is done through a UDDI document called a type model (or TModel). In most cases, TModel contains a WSDL file that describes the SOAP interface to access the XML Web service, but TModel is flexible enough to illustrate almost any type of service.
The UDDI directory also contains several methods that you can use to search for the services needed to build your application. For example, you can search for a specific geographic service provider or search for a specific business type. The UDDI directory will then provide information, contacts, links, and technical data so that you can identify the services that meet your needs.
UDDI allows you to find companies that provide the required WEB services. If you already know who you want to work with, but you don't yet know what services it offers, how do you handle it? The Ws-inspection specification allows you to browse the collection of XML Web services provided on a specific server to find the service you want.
For more information about UDDI, please visit http://www.uddi.org/about.html (English).
Other content
So far, we've talked about how to communicate with XML Web service (SOAP), how XML Web service is described (WSDL), and how to find XML Web service (UDDI). These elements form a set of basic specifications that provide the foundation for application integration and aggregation. Based on these basic specifications, the company can build and benefit from the actual solution.
We've done a lot of work to implement XML Web Service, but there's still a lot of work to be done. Today, people have been successful with XML Web service, but there are still a lot of things to be done for developers. For example, security, operations management, transaction processing, and reliable messaging. Global XML Web Services architecture will help the XML Web service move into the next phase of development by providing a consistent, common model to add new advanced functionality to XML Web service in a modular and scalable manner 。
The security modules mentioned above (ws-security [English] and Ws-license [English]) are part of the Global Web Services architecture specification. The need for operational management (such as routing messages between multiple servers and dynamically configuring these servers for processing) is also part of Global Web Services architecture, through the Ws-routing Specification (English) and ws-referral Specification (English) to achieve. With the development of Global Web Services Architecture, the specification for meeting these needs and other requirements will be further described.
For more information, see Global XML Web Service Architecture (English).
