XML Web Service Basics

XML Web Service Basics

Roger Wolter
Microsoft Corporation
December 2001

Abstract:This section describes the value of XML Web Service for developers and SOAP, WSDL, and UDDI.

Directory

• What is XML Web Service?
• Soap
• WSDL
• UDDI
• Other content

What is XML Web Service?

XML Web Service is the basic construction block for distributed computing on the Internet. Open Standards and attention to communications and collaboration between users and applications have resulted in an environment in which XML Web Service becomes a platform for application integration. Applications are constructed by using XML Web Services from multiple sources. These services work together, no matter where they are located or how they are implemented.

How many XML Web Services can be defined by companies that build XML Web Services. However, almost all definitions share the following:

• XML Web Service provides useful functions to Web users through standard web protocols. In most cases, the SOAP protocol is used.
• XML Web Service can describe its interfaces in very detail, which enables users to create client applications to communicate with them. This description is usually included in the XML document called the Web Service Description Language (WSDL) document.
• XML Web Services have been registered so that potential users can easily find these services, which are achieved through universal discovery, description, and integration (UDDI.

This article will introduce these three technologies, but first we need to explain why we should pay attention to XML Web Service.

One of the main advantages of the XML Web Service Architecture is that various programs written in different languages on different platforms can communicate with each other in a standard-based manner. Users who have some knowledge about this industry may immediately say, "Wait a moment. Didn't the same promise have been made by CORBA and earlier DCE? What is the difference between this and them ?" The most important difference is that soap is much simpler than the previous method, so there are far fewer obstacles to implementing standard-compatible soap. Paul kulchenko provides a list of SOAP implementation schemes in http://www.soapware.org/directory/4/implementations. The list contains 79 items in the previous statistics. As you may expect, most major software companies provide SOAP implementation solutions, but there are also many implementation solutions created and maintained by individual developers. Compared with previous solutions, XML Web Service also has the advantage of using standard web protocols-XML, HTTP, and TCP/IP. Many companies have established the Web infrastructure, and their employees have the relevant knowledge and experience in maintenance. Therefore, the cost of introducing XML Web Service is much lower than that of the previous technology.

The XML Web Service is defined as a software service provided on the Web through soap. It is described using the WSDL file and registered through UDDI. Then, you may ask: "What can XML Web Service do ?" The original XML Web Service can be easily incorporated into the application's information sources, such as stock prices, weather forecasts, and sports scores. We can easily think of building a whole type of application to analyze and summarize the information of interest and provide it in various ways; for example, you can use the Microsoft Excel spreadsheet to summarize all the financial information-stock, 401 K, bank deposits, loans, and so on. If you can obtain this information through XML Web Service, Excel can continuously update it. Some of the information is free of charge, and some may need to be subscribed to for the corresponding service. Most of this information can be found on the web, but the XML Web Service can make programming access easier and more reliable.

Provide existing applications in XML Web Service Mode. You can build new and more powerful applications and use XML Web Service as the construction block. For example, a user can develop a purchase application to automatically obtain price information from different suppliers, so that the user can select a supplier, submit an order, and then track the transportation of the goods until the goods are received. In addition to providing services on the web, supplier applications can also use XML Web Service to check the customer's credit, collect the payment, and handle the freight formalities with the freight company.

In the future, some of the most interesting XML Web Services Support applications that can still use the Web to complete tasks that cannot be completed currently. For example, the calendar service is one of the services to be supported by the Microsoft. NET my services project. If your dentist and mechanic provide their schedules through this XML Web Service, you can schedule appointments with them over the Internet; if you want, they can also specify the date of cleaning and routine maintenance directly on your calendar. It's hard to imagine that as long as you can program the Web, you can create hundreds of applications.

For more information about the XML Web Service and the applications that can be built, see the msdn Web Service Homepage.

Soap

Soap is the communication protocol of XML Web Service. When soap is described as a communication protocol, most people will think of DCOM or CORBA and ask "How does soap activate objects ?" Or "What kind of Naming Service does soap use ?" . Although the SOAP implementation scheme may contain the above content, it is not specified by the soap standard. Soap is a specification used to define the XML format of a message-this is a required part of the Specification. The XML segment that is contained in a pair of soap elements with the correct structure is the SOAP message. Is this simple?

The other section of the SOAP specification describes how to express program data as XML and how to use soap for Remote Procedure Call (RPC ). These optional specifications are used to implement applications in the RPC form. The client sends a SOAP message (including the callable function and parameters to be transmitted to the function ), the server then returns a message containing the function execution result. Currently, most soap implementations support RPC applications because programmers who are used to Developing COM or CORBA applications are familiar with RPC. Soap also supports document-based applications. In such applications, soap messages are only a packaging of XML documents. Soap applications in the form of documents are very flexible. Many new XML Web Services use this feature to build services that are hard to implement using RPC.

The last optional part of the SOAP specification defines the HTTP message style that contains the SOAP message. This HTTP binding is very important because almost all current operating systems (and many previous operating systems) Support HTTP. Although HTTP binding is optional, almost all SOAP implementation solutions support HTTP binding because it is the only standard protocol for soap. For this reason, people often mistakenly think that soap must use HTTP. In fact, some implementations also support MSMQ, MQ series, SMTP or TCP/IP transmission, but because HTTP is very common, almost all current XML Web Services use it. As HTTP is the core web protocol, most organizations support HTTP in their network infrastructure, and employees have learned how to manage it. Now, the infrastructure for HTTP security protection, monitoring, and load balancing has been established.

What is most confusing when you start using soap is the differences between the SOAP specification and many implementation solutions. Most users who use soap do not directly write soap messages, but use the soap toolkit to create and analyze soap messages. These toolkit usually converts function calls from a language to a SOAP message. For example, Microsoft soap Toolkit 2.0 converts com function calls to soap, while Apache toolkit converts Java function calls to soap. Function call types and supported parameter data types vary with each SOAP implementation scheme. Therefore, functions applicable to one toolkit may not be applicable to another toolkit. This is not a soap restriction, but a restriction on the specific implementation scheme used.

So far, the most striking 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 different systems inside and outside the enterprise. I have tried multiple methods to propose a universal communication protocol for system integration in the past, but they are not widely recognized as soap. Why? Because soap is smaller and easier to implement than many earlier protocols. For example, the implementation of DCE and CORBA takes several years, so only a few implementation solutions are released. Soap can use the existing XML analyzer and HTTP library to complete most of the hard work. Therefore, the SOAP implementation solution can be completed within several months. This is why there are more than 70 SOAP implementation solutions. Of course, soap does not have all the functions of DCE or CORBA. Although its functions are reduced, it is easier to use because of its complexity.

The popularity of HTTP and the simplicity of soap allow you to call them in almost any environment, thus becoming the ideal basis for XML Web Services. For more information about soap, see the msdn soap homepage.

How secure is it?

Generally, the first question raised by users who are new to soap is how soap solves security issues. In its early development stage, soap was regarded as an HTTP-based protocol, so it was considered that HTTP security was sufficient for soap. After all, thousands of web applications are currently using HTTP security, so this is indeed enough for soap. Therefore, the current SOAP standard assumes that security is a transmission issue, rather than a security issue.

When soap is extended to a more common protocol and runs on numerous transmissions, security issues become prominent. For example, HTTP provides several methods to authenticate the identity of users who call soap. But how does one transmit a message from http to SMTP? Soap is designed as a block protocol. Therefore, we are lucky to have a specification to provide additional security protection for Web Services Based on soap. The WS-Security Specification (English) defines a complete encryption system, while the WS-license specification (English) defines the corresponding technology to ensure the identity of the caller, make sure that only authorized users can use the web service.

WSDL

Web Services Description Language (WSDL) indicates the Web Service Description Language. In this article, we can consider the WSDL file as an XML document to describe a set of soap messages and how to exchange them. In other words, the function of WSDL for soap is like that of IDL for CORBA or com. Since 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 WSDL value, assume that you want to call the soap method provided by one of your business partners. You can ask the other party to provide some SOAP message examples, and then write your application to generate and use messages similar to the example, but this can easily cause errors. For example, you may see a customer ID of 2837 and assume it is an integer, but it is actually a string. WSDL uses clear representations to specify the content that a request message must contain and the style of the Response Message.

The WSDL file is used to describe the Message format representation based on the XML architecture standard, which means it has nothing to do with the programming language and is based on the standard, therefore, it is applicable to XML Web Service interfaces that can be accessed from different platforms and in different programming languages. In addition to message content, WSDL also defines the service location and the communication protocol used to communicate with the service. That is to say, the WSDL file defines all the content required to write an XML Web Service Program. There are several tools that can read the WSDL file and generate the Code required to communicate with the XML Web Service. Some of the most powerful tools can be found in Microsoft Visual Studio. NET.

Currently, many soap toolkit tools include tools for generating WSDL files from existing program interfaces, but there are almost no tools for writing WSDL directly, and the WSDL tool support is not complete. But soon there will be tools for writing WSDL files, and then tools for generating proxies and stubs (similar to the com IDL tool) that will become part of most SOAP implementation solutions. By that time, WSDL will become the preferred method for creating the soap interface of the XML Web Service.

There is a very good WSDL description, and you can also find the WSDL specification in the http://www.w3.org/TR/wsdl (English.

UDDI

Common discovery, description, and integration (UDDI) are the yellow pages of Web Services. Like the traditional yellow pages, you can search for the companies that provide the services you need, read about the services you provide, and contact someone for more information. Of course, you can also provide Web services instead of registering in UDDI, just like running business in the basement, relying on verbal drinks; but if you want to expand the market, therefore, we need to use UDDI to make it available to customers.

A uddi directory entry is an XML file that describes the services and services provided. A uddi directory entry consists of three parts. "White Pages" describe the companies that provide services: names, addresses, and contact information. "Yellow Pages" include industry categories based on standard classifications (such as North American Industry Classification System and Standard Industrial Classification; the "Green page" describes the service access interfaces in detail so that users can write applications to use web services. A service definition is implemented through a UDDI document called a type model (or tModel. In most cases, tModel contains a WSDL file to describe the soap interface used to access the XML Web Service. However, tModel is flexible and can describe almost all types of services.

The UDDI directory also contains several methods to search for the services required to build your application. For example, you can search for a service provider in a specific geographic location or a specific business type. Then, the UDDI Directory provides information, contact information, links, and technical data so that you can determine 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 cooperate with, but do not know what services it can provide, what should you do? The WS-inspection specification allows you to browse the XML Web Service Set provided on a specific server and find the required service.

For more information about UDDI, visit the http://www.uddi.org/about.html ).

Other content

So far, we have discussed how to communicate with XML Web Service (SOAP), how to describe XML Web Service (WSDL), and how to find XML Web Service (UDDI ). These contents constitute a set of basic specifications and provide the foundation for Application Integration and aggregation. Based on these basic specifications, companies can build and benefit from practical solutions.

We have done a lot of work to implement the XML Web Service, but there is still a lot of work to be done. Today, people have succeeded in using XML Web Service, but there are still many steps for developers to complete. For example, security, operation management, transaction processing, and reliable message transmission. Global XML Web Services architecture will help XML Web Services enter the next development stage through the following methods: provide a consistent general model, add new advanced functions to the XML Web Service in a modular and scalable manner.

The preceding Security Modules (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 these servers for processing) are also part of global web services architecture, they are implemented through WS-routing specifications (English) and WS-referral specifications (English. With the development of global web services architecture, we will further introduce the specifications that meet the above requirements and other requirements.

For more information, see global XML Web Service Architecture ).

Extracted from: http://www.microsoft.com/china/msdn/archives/library/Dnwebsrv/html/webservbasics.asp