What is XML Web Service?
The XML Web Service is a basic construction block for distributed computing on the Internet. Open standards and focus on communications and collaboration between users and applications produce such an environment, in which XML Web Service is a platform for application integration. The application is constructed by using multiple different sources of XML Web Service, these services work together, regardless of where they are located or how they are implemented.
How many companies build XML Web Service companies may have many XML Web Service definitions. However, almost all definitions have the following common:
XML Web Service provides useful features to web users through standard Web protocols. Using the SOAP protocol in most cases. XML Web Service can explain its interface very detail, allowing users to create client applications communicate with them. This description is typically included in an XML document called a Web Service Description Language (WSDL) document. XML Web Service has been registered so that potential users can easily find these services, which is done by General Discovery, Description, and Integration (UDDI).
This article will introduce these three technologies, but first, you need to explain why you want to pay attention to XML Web Service.
One of the main advantages of the XML Web Service architecture is to allow various programs written in different platforms to communicate with each other in a standard manner on different platforms. Users who have aware of this industry may immediately say: "Wait, CORBA and previous DCE do not have the same commitment? What is the difference between this?" The most important difference lies in: SOAP ratio Methods should be much simpler, so it is necessary to achieve SOAP compatible with standards, and barriers should be much less. Paul Kulchenko provides a list of SOAP implementations on http://www.soapware.org/directory/4/implementations. When the last statistics, the list already contains 79 items. As you expect, most software companies provide SOAP implementation, but there are also many implementations to create and maintain individual developers. Relative to the previous scheme, another advantage of XML Web Service is to use standard web protocols - XML, HTTP, and TCP / IP. Many companies have established a web infrastructure, while their employees have corresponding knowledge and experience in maintenance. Therefore, the introduction of XML Web Service is much lower than the introduction of previous technologies.
We define the XML Web Service as: Use the WSDL file to explain with the software service provided on the web, and register via UDDI. Then, you may ask: "What can I do with XML Web Service?" The initial XML Web Service is usually conveniently incorporated into the application source, such as stock prices, weather forecasts, sports, and more. We can easily think that you can build a category application to analyze and summarize the information concerned, and provide this in a variety of ways; for example, you can use Microsoft® Excel spreadsheets to summarize all financial information - stock, 401K , Bank deposits, loans, etc. If you can get this information through XML Web Service, Excel can constantly update it. Some of this information is free, some may need to subscribe to get the appropriate service. Most of this information can now be found on the Web, but XML Web Service can make programmable access easier and more reliable. Provide existing applications in XML Web Service, you can build new, more powerful applications, and use XML Web Service as constructing blocks. For example, users can develop a procurement application to automatically obtain price information from different vendors, allowing users to select suppliers, submit orders, and then track the transportation of goods until they receive goods. In addition to providing services on the Web, the supplier's application can also use XML Web Service to check the customer's credit, charge the payment, and use the freight procedures with the shipping company.
In the future, some of the most interesting XML Web services supported can also take advantage of the Web to complete the currently unpleasant tasks. For example, the calendar service is one of the upcoming services of Microsoft .NET My Services (English) project. If your dentist and mechanic offer its schedule through this XML Web Service, you can arrange a date with them through the network; if you like, they can also agree on your calendar. Date of cleaning and daily maintenance. It's hard to imagine, as long as you can program the web, you can create hundreds of applications.
For more information on XML Web Service and Its applications you can build, see the MSDN Web Services (English) home page.
SOAP
SOAP is a communication protocol for XML Web Service. When describing SOAP is a communication protocol, most people think of DCOM or CORBA, and will ask "How to activate the object?" Or "What kind of naming service is used for SOAP?" And so on. Although the SOAP implementation may contain the above, the SOAP standard is not specified. SOAP is a specification that defines the XML format of the message - this is the part necessary for the specification. Contains the correct XML segment of the SOAP element is SOAP message. Is this very simple?
Other parts of the SOAP specification describes how to represent the program data as XML, and how to use SOAP to remotely call (RPC). These optional specifications are used to implement an application in the RPC form, where the client will issue a SOAP message (including the modified function, and parameters to be transmitted to the function), and then the server will return messages that contain functions. Currently, most SOAP implementations support RPC applications because programmers who are accustomed to developing COM or CORBA applications are familiar with RPC form. SOAP also supports documentation applications, in which SOAP messages are just a package of XML documents. The SOAP app in the document is very flexible. Many new XML Web services use this feature to build services that use RPC difficult to implement. The last optional section of the SOAP specification defines the style of the HTTP message containing the SOAP message. This HTTP bind is very important because almost all current OS (and many previous OS) support HTTP. Although HTTP bindings are optional, almost all SOAP implementations support HTTP bindings because it is the only standard protocol for SOAP. For this reason, people usually 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. Since HTTP is a core protocol of the web, most organization's network infrastructure supports HTTP, and employees have learned how to manage it. Today, the infrastructure of security, monitoring, and load balancing of HTTP has been established.
When you start using SOAP, it is easier to confuse the difference between SOAP specifications and many of its implementations. Most users who use SOAP do not write SOAP messages directly, but use the SOAP toolkit to create and analyze SOAP messages. These kits typically convert function calls to SOAP messages from some language. For example, Microsoft SOAP Toolkit 2.0 converts the COM function call to SOAP, and Apache Toolkit converts the Java function call to SOAP. The type of function call and the data type of the supported parameters are different from each SOAP implementation scheme, so the function applied to a kit may not apply to another toolkit. This is not the limit of SOAP, but the limitations of specific implementations used.
So far, SOAP's most striking feature 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 the interior of the company. A variety of methods have been tried in the past to propose a general communication protocol that can be used for system integration, but they have no extensive recognition as SOAP. why? Soap is smaller than the many early agreements, and it is easier to implement. For example, the implementation of DCE and CORBA takes a few years, so only a few implementation is released. SOAP can use existing XML analyzers and HTTP libraries to complete most of hard work, so SOAP implementation can be done in months. That's why there have been more than 70 SOAP implementations. Of course, SOAP does not have full functions of DCE or CORBA, although the function is reduced, but since the complexity is greatly reduced, SOAP is easier to apply.
HTTP's popularity and simplicity of SOAP allow you to call them almost any environment, so become an ideal basis for XML Web Service. For more information on SOAP, see the MSDN SOAP home page. What is safety?
Typically, the first question that is just exposed to SOAP is the first problem that SOAP solves security issues. In its early development phase, SOAP is seen as an HTTP-based protocol, so it is considered that HTTP security is enough for SOAP. After all, there are thousands of Web applications currently use HTTP security, so this is really enough for SOAP. Therefore, current SOAP standards assume that security belongs to transmission issues, and does not have a security issue.
When SOAP is extended to a more general protocol, the security problem becomes prominent when running on numerous transmission. For example, HTTP provides several ways to authenticate the user who performs SOAP calls, but how to propagate the identity when the message is transmitted from the HTTP route to the SMTP transmission? SOAP is designed as a structural block protocol, so fortunately, there is already a corresponding specification to provide additional security protection features based on SOAP-based WEB services. The WS-Security specification (English) defines a complete set of encryption systems, while the WS-License specification defines the corresponding technology to ensure the caller's identity, and ensure that only authorized users can use the web service.
WSDL
WSDL (Web Services Description Language) represents a Web Service Description Language. In this article, we can think that the WSDL file is an XML document to illustrate a set of SOAP messages and how to exchange these messages. In other words, WSDL's role in SOAP is like the role 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 value of WSDL, you can assume that you want to call the SOAP method provided by your business partner. You can ask the other party to provide some SOAP message examples, then write your application to generate and use messages similar to samples, but this is easy to make mistakes. For example, you may see a 2837 client ID and assume it as an integer, and it is actually a string. WSDL specifies the content of the request message must contain the content and the style of the response message by specifying the content of the request message.
The WSDL file is used to illustrate the representation of the message format, which means that it is independent of the programming language, and is based on standard, so it is suitable for explaining the XML Web Service accessible from different platforms to different programming languages. interface. In addition to the description of the message content, WSDL also defines the location of the service, and communicates with the service using what communication protocol is used. That is, the WSDL file defines the full content required to write the program that uses the XML Web Service. There are several tools to read the WSDL file and generate the code required to communicate with the XML Web Service. Some of these most powerful tools can be found in Microsoft Visual Studio® .NET.
Currently, many SOAP kits include tools from existing program interfaces, but almost no direct use of WSDL tools, and WSDL tool support is also very incomplete. But shortly, the tool to write WSDL files will have a tool that generates agent and stub (similar to the COM IDL tool), which will become part of Most SOAP implementations. By then, WSDL will become the preferred method of creating the SOAP interface of XML Web Service. Here is a very good WSDL instructions (English), you can also find the WSDL specification at http://www.w3.org/tr/wsdl (English).
UDDI
General Discovery, Description and Integration (UDDI) is a yellow page for web services. Like traditional yellow pages, you can search for companies that serve the services to learn about the services provided, and then contact someone to get more information. Of course, you can also provide web services without registering in UDDI, just in the basement, relying on oral 吆 drink; but if you want to expand your market, you need UDDI to be discovered by customers.
The UDDI directory entry is an XML file that describes the service and services provided. The UDDI directory entry consists of three parts. "White Page" introduces the company: name, address, contact information, etc. "Yellow pages include industry categories based on standard classification (eg, North American Industry Classification System and Standard Industrial Classification);" Green Page "details Access the interface of the service so that users can write applications to use web services. The definition of the service is done by a UDDI document called a type model (or TMODEL). In most cases, TMODEL contains a WSDL file that describes the SOAP interface to XML Web Service, but TMODEL is very flexible and can illustrate almost all types of services.
The UDDI directory also contains several methods that can be used to search for the services required to build your application. For example, you can search for a particular location service provider or search for a specific business type. After that, the UDDI directory will provide information, contact information, links, and technical data so that you can determine that you can meet the needs.
UDDI allows you to find companies with the required Web services. If you already know who wants to cooperate with who is business, I don't know what services it can provide. How to deal with it? WS-Inspection Specifications (English) allows you to browse the collection of XML Web Service on a particular server and find the required services.
For more information on UDDI, please visit http://www.uddi.org/about.html.
Other content
So far, we have discussed how to explain XML Web Service Communications (SOAP), XML Web Service, and how to find XML Web Service (UDDI). These contents constitute a basic specification that provides the foundation for the integration and aggregation of the application. According to these basic specifications, companies can build practical solutions and benefit from it.
To implement XML Web Service, we have done a lot of work, but there is still a lot of work needs to be done. Today, people have already succeeded in using XML Web Service, but there are still many links to be improved for developers. For example, security, operation management, transaction processing, and reliable messaging, etc.. Global XML Web Services Architecture helps XML Web Service in the following ways: Provides a consistent generic model to add new advanced features to XML Web Service in modular and scalable ways. The security module mentioned above (WS-Security [English] and WS-license [English]) is part of the Global Web Services Architecture specification. The needs of operation management (such as routing messages between multiple servers, and dynamically configuring these servers for processing) is also part of Global Web Services Architecture, which is through WS-Routing Specifications (English) and WS-REFERRAL Specifications (English) Realize it. With the development of Global Web Services Architecture, it will further introduce specifications that meet the above needs and other needs.
For more information, see Global XML Web Service Architecture (English).
