Web services communicate in the form of messages. A request message delivers information about an operation to be executed and any data required to carry out that operation. Request messages flow from clients to Web services. A response message delivers information about the results of the operation execution. Response messages flow from Web services to clients.
Communication via messages is an extremely effective method for insulating Web service consumers from the implementation details of the service. Of course, it is necessary to define, in a standard way, the rules for how these messages should be formatted and what they can contain.
Message exchange with SOAP
The Simple Object Access Protocol (SOAP) is an industry-standard message format that enables message-based communication for Web services. SOAP implements a message format based on XML to exchange function requests and responses. Using XML as the basis for SOAP messages makes it possible for these messages to be understandable and transportable by any system that implements basic Internet communications services.
SOAP simply defines a message format. It does not impose a specific transport protocol for exchanging these messages. Thus, it is possible to transport SOAP messages over any one of many different and widely available transport protocols such as HTTP, SMTP, FTP, and so on. Note, however, that the HTTP POST command is the default method for transporting SOAP requests and responses.
SOAP uses the term "binding" when referring to a specific protocol that is used to transport SOAP messages.
A SOAP request is an HTTP POST request. An HTTP POST request (like all HTTP commands) consists of human-readable text that contains one or more headers followed by the command payload. The payload is separated from the headers by a blank line.
A SOAP request over HTTP uses the payload section of the HTTP POST request to contain the encoded SOAP envelope.
In addition to SOAP, Web services can also exchange messages using HTTP -GET and HTTP-POST. These verbs are standard messages of the HTTP protocol that enable the exchange of information as name/value pairs.
HTTP-GET passes name/value pairs as UUencoded text appended to the URL of a request. This method of passing parameters is referred to as a query string.Because HTTP -GET and HTTP-POST utilize name/value pairs to encode data, the list of data types that can be supported is more limited than using SOAP.
Web Service Capabilities
Given a standard method to encode data (XML) and a standard method to exchange Web service requests and responses via messages (SOAP), we need a standard way to describe the specific message exchanges (or capabilities) that a Web service supports.
Recall that SOAP defines a message format based on XML to enable exchange of method requests and responses. However, SOAP does not define the specific methods and results that a Web service may offer.
COM components use interfaces to describe their capabilities to a potential consumer. This is done using a language called Interface Definition Language (IDL). Compiling an IDL file results in the creation of a Type Library (TLB). A Type Library in COM contains all the information necessary to query the specific capabilities of the COM component .
Similar to the Type Library concept in COM, Web services must have a method to describe to potential consumers the specific capabilities that the service offers. Without this capability, consumers would not be able to determine how to request some functionality of the Web service or what to expect as a response.
A Web service description is an XML document (surprise!) that defines the capabilities that a Web service offers. This document provides essential information in a structured form that enables a consumer to understand how to interact with a Web service. The Web Service Description Language (WSDL) defines a standard, extensible XML grammar that is used to define these Web service descriptions in the form of an XML document.
The WSDL document defines the message formats and message exchange patterns that a Web service can process. In addition to these definitions, the WSDL document contains the address of each Web service entry point, formatted according to the protocol used to access the service (for example, a URL for HTTP or an e-mail address for SMTP).
Publishing and Finding Web Services
Given a standard means to describe the capabilities of a Web service via the WSDL document, we must now consider how a potential consumer of a Web service will locate a WSDL document on a target Web server. Recall that to consume a service, a client must be able to determine how to interact with that Web service, which means that it must follow the message formats and message exchange patterns described for the Web service in the WSDL document.
Web service consumers employ a discovery process to learn that a Web service exists and where to find the Web service's WSDL document. Web service consumers enact this discovery process on a target Web server by providing a URL to a discovery tool.
The discovery tool attempts to locate DISCO documents on the target server and informs the consumer of the location of any available WSDL documents.
Finding Web Service Providers
As more and more Web services are created and deployed by numerous organizations on the Internet, it will become increasingly more difficult for consumers to find these services. This is analogous to the difficulty Web users might experience in finding a specific page of information amongst the billions of pages of information currently published on the Web were it not for Web search engines.
Similar to the search engine approach that is used to query and locate Web pages, the Universal Description, Discovery, and Integration (UDDI) specification defines a logically centralized but physically distributed, XML-based registry database and API for companies to find each other and the Web services that they offer. The UDDI registry API offers support for querying as well as updating the registry database.
The true power of the UDDI business registry lies in the UDDI Web service (that's right, UDDI is itself a Web service), which provides a mechanism for ad-hoc discovery of potential business partners and dynamic integration of Web services. Visual Studio .NET has support for UDDI built into the "Web Reference" metaphor used to locate and consume Web services.
UDDI defines, classifies and stores three basic types of information:
related post
CREATING ASSEMBLIES WITH ASP.NET
BUILDING HANDLERS IN ASP.NET
INTERFACES AND CLASSES CREATION IN ASP.NET
CACHING IN ASP.NET
CACHING IN ASP.NET PART TWO
WIRE LESS APPLICATION WITH ASP.NET
SECURITY IN ASP.NET PART ONE
SECURITY IN ASP.NET PART TWO
LOCALIZING ASP.NET APPLICATIONS
DEPLOYING ASP.NET APPLICATIONS
ASP.NET CONFIGURATION SYSTEM
WEB SERVICES IN ASP.NET
WEB SERVICES PART TWO
WEB SERVICE INFRASTRUCTURE
WEB SERVICE INFRASTRUCTURE PART TWO
EXCHANGING MESSAGES IN ASP.NET
MICROSOFT HAIL STORM
SOAP AND DOT NET PART ONE
SOAP AND DOT NET PART TWO
Communication via messages is an extremely effective method for insulating Web service consumers from the implementation details of the service. Of course, it is necessary to define, in a standard way, the rules for how these messages should be formatted and what they can contain.
Message exchange with SOAP
The Simple Object Access Protocol (SOAP) is an industry-standard message format that enables message-based communication for Web services. SOAP implements a message format based on XML to exchange function requests and responses. Using XML as the basis for SOAP messages makes it possible for these messages to be understandable and transportable by any system that implements basic Internet communications services.
SOAP simply defines a message format. It does not impose a specific transport protocol for exchanging these messages. Thus, it is possible to transport SOAP messages over any one of many different and widely available transport protocols such as HTTP, SMTP, FTP, and so on. Note, however, that the HTTP POST command is the default method for transporting SOAP requests and responses.
SOAP uses the term "binding" when referring to a specific protocol that is used to transport SOAP messages.
A SOAP request is an HTTP POST request. An HTTP POST request (like all HTTP commands) consists of human-readable text that contains one or more headers followed by the command payload. The payload is separated from the headers by a blank line.
A SOAP request over HTTP uses the payload section of the HTTP POST request to contain the encoded SOAP envelope.
In addition to SOAP, Web services can also exchange messages using HTTP -GET and HTTP-POST. These verbs are standard messages of the HTTP protocol that enable the exchange of information as name/value pairs.
HTTP-GET passes name/value pairs as UUencoded text appended to the URL of a request. This method of passing parameters is referred to as a query string.Because HTTP -GET and HTTP-POST utilize name/value pairs to encode data, the list of data types that can be supported is more limited than using SOAP.
Web Service Capabilities
Given a standard method to encode data (XML) and a standard method to exchange Web service requests and responses via messages (SOAP), we need a standard way to describe the specific message exchanges (or capabilities) that a Web service supports.
Recall that SOAP defines a message format based on XML to enable exchange of method requests and responses. However, SOAP does not define the specific methods and results that a Web service may offer.
COM components use interfaces to describe their capabilities to a potential consumer. This is done using a language called Interface Definition Language (IDL). Compiling an IDL file results in the creation of a Type Library (TLB). A Type Library in COM contains all the information necessary to query the specific capabilities of the COM component .
Similar to the Type Library concept in COM, Web services must have a method to describe to potential consumers the specific capabilities that the service offers. Without this capability, consumers would not be able to determine how to request some functionality of the Web service or what to expect as a response.
A Web service description is an XML document (surprise!) that defines the capabilities that a Web service offers. This document provides essential information in a structured form that enables a consumer to understand how to interact with a Web service. The Web Service Description Language (WSDL) defines a standard, extensible XML grammar that is used to define these Web service descriptions in the form of an XML document.
The WSDL document defines the message formats and message exchange patterns that a Web service can process. In addition to these definitions, the WSDL document contains the address of each Web service entry point, formatted according to the protocol used to access the service (for example, a URL for HTTP or an e-mail address for SMTP).
Publishing and Finding Web Services
Given a standard means to describe the capabilities of a Web service via the WSDL document, we must now consider how a potential consumer of a Web service will locate a WSDL document on a target Web server. Recall that to consume a service, a client must be able to determine how to interact with that Web service, which means that it must follow the message formats and message exchange patterns described for the Web service in the WSDL document.
Web service consumers employ a discovery process to learn that a Web service exists and where to find the Web service's WSDL document. Web service consumers enact this discovery process on a target Web server by providing a URL to a discovery tool.
The discovery tool attempts to locate DISCO documents on the target server and informs the consumer of the location of any available WSDL documents.
Finding Web Service Providers
As more and more Web services are created and deployed by numerous organizations on the Internet, it will become increasingly more difficult for consumers to find these services. This is analogous to the difficulty Web users might experience in finding a specific page of information amongst the billions of pages of information currently published on the Web were it not for Web search engines.
Similar to the search engine approach that is used to query and locate Web pages, the Universal Description, Discovery, and Integration (UDDI) specification defines a logically centralized but physically distributed, XML-based registry database and API for companies to find each other and the Web services that they offer. The UDDI registry API offers support for querying as well as updating the registry database.
The true power of the UDDI business registry lies in the UDDI Web service (that's right, UDDI is itself a Web service), which provides a mechanism for ad-hoc discovery of potential business partners and dynamic integration of Web services. Visual Studio .NET has support for UDDI built into the "Web Reference" metaphor used to locate and consume Web services.
UDDI defines, classifies and stores three basic types of information:
- White Pages: Describes address, contact, and other standard business demographic information
- Yellow Pages: Describes industrial categorizations for businesses based on standard categories
- Green Pages: Describes the technical specification for Web services Collectively, these three types of data provide a flexible and effective method for locating Web services.
related post
CREATING ASSEMBLIES WITH ASP.NET
BUILDING HANDLERS IN ASP.NET
INTERFACES AND CLASSES CREATION IN ASP.NET
CACHING IN ASP.NET
CACHING IN ASP.NET PART TWO
WIRE LESS APPLICATION WITH ASP.NET
SECURITY IN ASP.NET PART ONE
SECURITY IN ASP.NET PART TWO
LOCALIZING ASP.NET APPLICATIONS
DEPLOYING ASP.NET APPLICATIONS
ASP.NET CONFIGURATION SYSTEM
WEB SERVICES IN ASP.NET
WEB SERVICES PART TWO
WEB SERVICE INFRASTRUCTURE
WEB SERVICE INFRASTRUCTURE PART TWO
EXCHANGING MESSAGES IN ASP.NET
MICROSOFT HAIL STORM
SOAP AND DOT NET PART ONE
SOAP AND DOT NET PART TWO
No comments:
Post a Comment