Asp. NET create the XML infrastructure for Web services

Asp.net|web|web Service |xml| creation in order to succeed in network diversity, XML Web services must not care about the operating system, object model, and program language that you choose. Moreover, XML Web services, which are as widely accepted as other web-based technologies, must:

　　 loosely coupled: If only the commands used in the two systems understand the self-describing text-based messages mentioned earlier, then the two systems are considered loosely coupled. On the other hand, tightly coupled systems use a large number of customized software to enhance communication between systems, and need to know more about the system.

　　 Ubiquitous Communication: Now individuals are unlikely to be able to build an operating system or to integrate the Internet in the near future, so this requires an ubiquitous communication channel. Similarly, the ability to connect virtually any system and device to the Internet will ensure that such systems and devices are used by other systems or devices connected to the Internet.

　　 Common data Formats: By adopting an existing open standard rather than a dedicated closed-loop communication approach, any system can support the same open standards that can understand XML Web services. Using self-describing text-based messages, XML Web services and their customers can share these messages without having to know the composition of each underlying system, which will be able to communicate across disparate systems independently. XML Web services use XML to implement this functionality.

An XML Web service uses an infrastructure that provides the following functionality: A discovery mechanism for locating XML Web services, a service description that defines how these services are used, and a standard connection format for communication. The following illustration shows an instance of this infrastructure.

Infrastructure blocks	Functions
XML Web Services Directory	The XML Web service directory provides a central address for locating XML Web services provided by other organizations. XML Web service catalogs such as UDDI registrations implement this function. The client of an XML Web service can reference an XML Web service directory, or it can not reference an XML Web service directory.
XML Web Service Discovery	XML Web service discovery uses Web Services Description Language (WSDL) to locate or discover one or more related documents that describe a particular XML Web service. Disco specifications Define the rules for locating service descriptions. If the XML Web service customer understands the location of the service description, they can bypass the discovery step.
XML Web Service Description	To understand how to interact with a particular XML Web service, you need to provide a description to define the interactive operations supported by the XML Web service. XML Web service clients must understand how to interact with an XML Web service when they can use it.
XML Web Service connection format	In order to be able to make universal communications, XML Web Services communicate using open connection formats, which are protocols that are understandable to any system that supports the most common web standards. Soap is a key protocol for XML Web service communication.

　　 XML Web Services Directory

As with any other resource on the Internet, the XML Web service directory cannot find a particular XML Web service without some lookup methods. The XML Web Services directory provides a central address that allows XML Web service providers to publish information about the XML Web services they provide. Such a directory can even be an XML Web service itself, which can be programmed to access and provide search results to respond to queries from XML Web service clients. It may be necessary to use an XML Web service directory to locate an organization that provides an XML Web service for a specific purpose, or to determine what XML Web services are provided by a particular organization.

The UDDI (Unified Description Discovery and Integration Specification) specification defines a standard method for publishing and discovering information about an XML Web service. The XML schema associated with UDDI defines four types of information, allowing developers to use a published XML Web service. These are information on business information, service information, binding information, and other specifications for services.

As a core component of UDDI Engineering, UDDI Business Registry (business registration) allows business programming to locate information about XML Web services published by other organizations. Developers can use UDDI Business registry to locate discovery files and service descriptions. For more information, see the UDDI Web site (http://uddi.microsoft.com).

XML Web Service Discovery

XML Web Service discovery is the operation of locating or discovering one or more files that describe a particular XML Web service using the Web Service Description Language WSDL. It lets the XML Web service client know if an XML Web service exists and where to find the description file for the XML Web service.

A published. disco file, which contains an XML file that connects to other resources that describe the XML Web service, is able to programmatically discover an XML Web service. The following code gives an example of the structure of a discovery file:

xmlns= "http://schemas.xmlsoap.org/disco/scl/"/> xmlns= "http://schemas.xmlsoap.org/disco/soap/"/>

Note: The discovery document is an element container that typically contains links to resources that provide discovery information for XML Web services. If they are associated with URLs, they assume that they are associated with the location of the discovery document.

However, a Web site that implements an XML Web service does not have to support discovery. Another site can be responsible for describing the service, such as an XML Web service directory. There is no public way to discover services, such as when you create a private-use service.

　　 XML Web Service Description

The XML Web Services infrastructure is created on the basis of communication using xml-based messages that follow an advertised service description. A service description is an XML document written using the WSDL language's XML syntax, which defines the XML Web service message format that an XML Web service can understand. A service describes the role of a contract to define the behavior of an XML Web service and to indicate how potential customers interact with it. The behavior of an XML Web service depends on the service definition and supported message types. These patterns conceptually indicate what a service consumer can expect when a message in the appropriate format is sent to an XML Web service.

For example, the request/response pattern associated with a remote procedure call (RPC)-style service will define which SOAP message pattern is used to invoke a particular method. This pattern will also define the format in which the SOAP message will be followed.

Another example of a message pattern is a unilateral interaction operation. This pattern is used when a one-way communication occurs. In this case, the sender does not receive any messages, including fault messages, from the XML Web service. Patterns that define SOAP message formats can be internally defined to perform actual service descriptions, which can also be defined externally and imported into the service description.

In addition to the definition of message format and message mode, the service description optionally contains the address of each XML Web service entry point. The format of this address corresponds to the protocol used to access the service, for example, the URL corresponds to HTTP or the e-mail address corresponds to SMTP (Simple Mail Transfer Protocol).

For more information on WSDL specifications, see the HTTP://WWW.W3.ORG/TR/WSDL Web site.

　　 XML Web Service connection format

A binary protocol like DCOM consists of a method request layer that removes the top of a proprietary communication protocol. Such a protocol is not helpful for creating a universally available XML Web service. That's not to say it prevents you from using such a protocol in an XML Web service scenario, but the disadvantage of using them is that they rely on the specific structure of their underlying systems, thereby limiting the potential customer's growth.

Instead, you can construct an XML Web service to work with one or more open protocols, just like the combined use of HTTP and soap. As you would expect, the infrastructure requires support for different protocols.

XML Web services are not limited to providing remote procedure call access. They can also be constructed to exchange structured information, such as purchase orders and invoices, and can also be used to automate and connect internal and external business processes.

　　 Http-get and Http-post

Http-get and http-post are standard protocol verbs that use HTTP to encode and transmit variable name/variable value pairs and use the relevant request semantics. Each http-get and Http-post consists of a series of HTTP request headers that define what the client requests from the server, and the response is made up of a series of HTTP answer headers and answer data, which returns a response if the request succeeds.

Http-get to pass parameters in the format of urlencoded text that uses MIME type application/x-www-form-urlencoded. Urlencoding is a character encoding that guarantees that the transmitted parameters are composed of text that follows the specification, for example, the encoding of a space is "%20". Additional parameters can also be considered as a query string.

Similar to Http-get, the Http-post parameter is also encoded by the URL. However, the variable name/variable value is not routed as part of the URL, but is sent inside the actual HTTP request message.

　　 Introduction to Soap

Soap is a simple, lightweight xml-based protocol for exchanging structured and patterned information on the web. The overall design goal of soap is to keep it as simple as possible and to provide minimal functionality. This protocol defines a message framework that does not contain application or transport semantics. Therefore, the Protocol is modular and very beneficial to the expansion.
By bypassing the standard transport protocol, SOAP can take advantage of the existing open architecture of the Internet and can be accepted by any system that supports the most basic Internet standards. By bypassing the standard transport protocol, SOAP can take advantage of the existing open architecture of the Internet and can be accepted by any system that supports the most basic Internet standards. As you can see, infrastructure requirements support a simple but powerful SOAP-compliant XML Web service because it doesn't add new content to the existing Internet infrastructure, but it helps access the services of soap constructs.

The SOAP protocol specification consists of four main parts. The first section defines a mandatory extensible envelope (envelope) for encapsulating data. The SOAP envelope defines a SOAP message and the basic unit that is exchanged between soap information processors. This is the only mandatory part of this specification.

The second part of the SOAP protocol specification defines an optional data encoding rule to represent application-defined data types and direct charts, and a unified model for serializing a non-grammatical data model.

The third section defines the pattern of a remote procedure invocation style (Request/response) information exchange. Each SOAP message is a one-way transport. Although soap is rooted in RPC, it is not limited to the request/response mechanism. XML Web services often combine SOAP messages to implement such a pattern, but soap does not have to use the information interchange pattern, and this part of the specification is optional.

The fourth part of this specification defines the binding between soap and HTTP. However, this part is still optional. You can use SOAP in conjunction with any forwarding protocol or mechanism that transmits soap envelopes, including SMTP, FTP, and even a floppy disk.

For more information on SOAP specifications, see the Http://www.w3.org/TR/soap Web site.