XML infrastructure for creating web services using ASP. NET

To succeed in Network Diversity, XML Web Services must not care about the selected operating system, object model, or programming language. Furthermore, XML Web Services must:
　　 Loose coupling: If only the commands used in the two systems can understand the self-describing text-based messages mentioned above, the two systems are considered loose coupling. On the other hand, tightly coupled systems use a large number of customized software to enhance inter-system communication, and need to know more between systems.

　　Ubiquitous communication: Currently, individuals are unlikely to be able to construct an operating system, or will not integrate Internet access capabilities in the near future. Therefore, this requires a ubiquitous communication channel. Similarly, the ability to connect almost any system or device to the Internet will ensure that such systems and devices can be used by other systems or devices connected to the Internet.

　　Common Data Format:
By adopting existing open standards rather than dedicated Closed-Loop communication methods, any system can support the ability to understand XML
The same open standards for Web Services. Use self-described text-based messages, XML
Web services and their customers can share these messages without having to know the composition of each underlying system, which can communicate between completely different independent systems. XML
Web services use XML to implement this function.

XML Web Services use a basic structure that provides the following functions: a discovery mechanism for locating XML Web Services; a service description for defining how to use these services; and the standard connection format used for communication. The following illustration shows an instance of this infrastructure.

XML Web Service Infrastructure

Infrastructure Block	Functions
XML Web Service Directory	The XML Web Service Directory provides a central address for locating XML Web Services provided by other organizations. The XML Web Service Directory such as UDDI registration implements this function. The XML Web Service client can reference the XML Web Service directory or not.
XML Web Service Discovery	XML Web Service Discovery uses the Web Service Description Language (WSDL) to locate or discover one or more documents describing special XML Web Services. The disco Specification defines the rules for locating the service description. 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 specific XML Web Service, you need to provide a description to define the interaction operations supported by the XML Web Service. The XML Web Service client must understand how to interact with an XML Web Service.
XML Web Service connection format	To facilitate general communication, XML Web Services use open connection formats for communication. These are protocols that can be understood by any system that supports the most common web standards. Soap is a key protocol used for XML Web Service communication.

　　XML Web Service Directory

　
Like any other resource on the Internet, the XML Web Service Directory cannot find a specific XML Web Service without some search methods. XML
The Web Service Catalog provides a central address for XML Web Service Providers to publish information about their XML Web Services. Such a directory can even be XML
The Web Service itself can be accessed programmatically and provide search results to respond to queries on the XML Web Service client. Use an XML Web Service Directory to locate an XML
Web services can be used as an organization for a specific purpose, or an XML Web Service provided by a specific organization. This may be necessary.

The UDDI (unified description discovery and integration specification) Specification defines a standard method to publish and discover XML Web Service information. The XML Schema associated with UDDI defines four types of information, allowing developers to use a published XML Web Service. These are: business information, service information, binding information and other standardized information for the service.

As the core component of the UDDI project, the UDDI business registry allows business programming to locate the XML Web Service Information published by other organizations. Developers can use the UDDI business registry to locate and discover files and service descriptions. For more information, see UDDI web site (http://uddi.microsoft.com ).

XML Web Service Discovery

XML Web Service Discovery uses the Web Service Description Language WSDL to locate or discover one or more operations that describe a specific XML Web Service file. It allows the XML Web Service client to know whether an XML Web Service exists and where to find the description file of the XML Web Service.

A published. disco file is an XML file that contains resources connected to other XML Web Services. It can be programmed to discover an XML Web Service. The following code provides an example of discovering the structure of a file:

<? XML version = "1.0" encoding = "UTF-8"?> <Discovery Xmlns: XSD = "http://www.w3.org/2001/XMLSchema" Xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" Xmlns = "http://schemas.xmlsoap.org/disco/"> <Contractref ref = "http://www.contoso.com/Counter.asmx? The WSDL "docref =" http://www.contoso.com/Counter.asmx" Xmlns = "http://schemas.xmlsoap.org/disco/scl/"/> <Soap address = "http://www.contoso.com/Counter.asmx" xmlns: Q1 = "http://tempuri.org/" binding = "Q1: countersoap" Xmlns = "http://schemas.xmlsoap.org/disco/soap/"/> </Discovery>

Note: A discovery document is an element container that generally contains links to resources that provide discovery information for XML Web Services. If they are associated with URLs, they are assumed to be associated with the location of the document found.

However, a web site implementing XML Web Services does not have to support discovery. Another site can describe this service, such as an XML Web Service Directory. There is no public method to discover a service, for example, when you create a private service.
　　XML Web Service Description

The XML Web Service infrastructure is created when an XML-based message communication follows a published service description.
. Service description is an XML document written using the XML syntax of the WSDL language. It defines XML that can be understood by XML Web Services.
Web Service Message format. A service description acts as a protocol to define the behavior of an XML Web Service and instruct potential customers to interact with it. XML
The Web service behavior depends on the service definition and supported message types. These modes indicate what the service user can expect when a message in the corresponding format is sent to the XML Web Service.

For example, the request/response mode associated with a Remote Procedure Call (RPC) service defines which SOAP message mode is used to call a specific method. This mode also defines the format in which the response SOAP message will follow.

　
Another example of message mode is unilateral interaction. This mode is used when one-way communication occurs. In this case, the sender does not
The Web Service receives any messages, including fault messages. The mode that defines the SOAP message format can be defined internally to describe the actual service. They can also be defined externally and imported into the service description.

In addition to the definition of the Message format and the message mode, the service description can also selectively contain the addresses of each XML Web Service endpoint. The address format corresponds to the protocol used to access the service. For example, the URL corresponds to HTTP or email address and SMTP (Simple Mail Transfer Protocol ).

For more information about the WSDL specification, see W3C Web site (http://www.w3.org/TR/wsdl ).

　　XML Web Service connection format

　
Binary protocols like DCOM are composed of a Method Request layer that removes the top of the proprietary communication protocol. This Protocol creates universally available XML
The Web service does not help. This is not to say that you are not blocked in XML
Web service solutions use such protocols, but their disadvantage is that such protocols rely on the specific structure of their underlying systems, thus limiting the increase of potential customers.

Instead, you can construct XML Web Services to work together with one or more open protocols, just like the integrated use of HTTP and soap. As you expected, the infrastructure requires support for different protocols.

The XML Web Service is not limited to providing remote process 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 processing.

　　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 pair parameters and use the relevant request semantics. Each HTTP-GET and HTTP-POST is composed of a series of HTTP request headers that define what the client has requested from the server, and the response is composed of a series of HTTP Response Headers and response data, if the request is successful, a response is returned.

　
The HTTP-GET Passes parameters in the format of urlencoded text that uses the MIME type application/X-WWW-form-urlencoded.
Urlencoding is a character encoding that ensures that transmitted parameters are composed of compliant texts. For example, the encoding of a space is "% 20 ". The additional parameter can also be considered as a query string.

Like a HTTP-GET, HTTP-POST parameters are URL encoded. However, the variable name/variable value is not transmitted as part of the URL, but is transmitted within the actual HTTP request message.

　　Introduction to soap

Soap is a simple, lightweight XML-based protocol used to exchange structured and modeled information on the Web. The overall design goal of soap is to keep it as simple as possible and provide the least functionality. This Protocol defines a message framework that does not contain applications or transport semantics. Therefore, this protocol is modular and very scalable.
Connect
Over the standard transmission protocol, soap can utilize the existing open architecture of the Internet and be accepted by any system that supports the most basic Internet standards. Soap benefits over the standard transmission protocol
Use the existing open architecture of the Internet and be accepted by any system that supports the most basic Internet standards. As you can see, the infrastructure requires a simple but powerful compliance with soap.
XML Web Service, because it basically does not add new content to the existing Internet infrastructure, but it helps access services constructed by soap.

The SOAP protocol specification consists of four main parts. The first section defines a forced extensible envelope (envelope) used to encapsulate data. A soap envelope defines a basic unit for exchanging a SOAP message with a soap information processor. This is the only mandatory part of the Specification.

The second part of the SOAP Protocol Specification defines the optional data encoding rules used to represent the data types and direct charts defined by the application, as well as a unified model for serializing non-syntactic data models.

　
The third part defines a Remote Procedure Call style (Request/Response) Information exchange mode. Each SOAP message is transmitted in one way. Although soap is rooted in RPC, it is not limited to requests.
/Response mechanism. XML Web Services often work with soap messages to achieve this mode, but soap does not have to use the information exchange mode, 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 optional. You can enable soap to work with any transfer protocol or mechanism that can send soap envelopes, including SMTP, FTP, or even a floppy disk.

For more information about soap specifications, see W3C Web site (http://www.w3.org/TR/soap ).