Teach you the basics of learning XML Web Service

Web|xml

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:

1. The XML Web Service provides useful functionality to Web users through standard Web protocols. In most cases, the SOAP protocol is used.

2. XML Web Service can describe its interfaces in great detail, which enables 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.

3. The XML WEB Service has been registered so that potential users can easily find these services through universal discovery, description, and Integration (UDDI).

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? The most important difference is that soap is much simpler than previous methods, so there are far fewer barriers to implementing standard-compliant soap. 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 I do with an XML Web service?" The initial XML Web Service is often 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 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 Microsoft. NET My Services project will 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.

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? 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.

[1] [2] Next page