SOAP is a lightweight, XML-based protocol for exchanging information in a decentralized, distributed environment, such as that offered by the Internet. In other words, SOAP enables two processes (possibly on different machines) to communicate with each other regardless of the hardware and software platforms on which they are running.
One of the greatest benefits of SOAP is that it has been created and adopted as part of an open process, which has been embraced at an unprecedented level by most of the major hardware and software vendors. The SOAP specification is an open technology (having been submitted to the W3C) that provides the basis for application-to-application integration, known as Web services.
The fundamental building block of SOAP is XML. SOAP defines a specialized, yet flexible XML grammar that standardizes the format and structure of messages. Messages are, in turn, the fundamental method for exchanging information between Web services and Web service consumers. Using XML to encode SOAP messages provides several benefits, such as these:
XML is human readable, making it easier to understand and debug.
XML parsers and related technologies are widely available.
XML is an open standard.
XML includes many related technologies that can be leveraged in SOAP.
Thus, XML is a natural choice for encoding SOAP messages and contributes to the simplicity of the specification (at least in relation to more complex binary protocols such as COM and CORBA).
Typically, a Web service consumer will send a message to a Web service, requesting a specific operation to be performed. The Web service processes this request and typically (but not necessarily) returns the results in a response message. This request/response model is conceptually akin to the Remote Procedure Call (RPC) model.
To transport SOAP messages, we need a transport protocol. The obvious choice for a transport protocol is HTTP, because it is in use on so many systems today, making it widely available. In addition, HTTP is typically allowed through most firewalls today, making it easy to get up and running without requiring administrators to open more ports through their corporate firewalls.
Although HTTP is an obvious choice for a transport protocol ( and the one that most major vendors are implementing), the SOAP specification does not require a specific transport protocol.
It is quite possible to transport SOAP messages over other transport mechanisms such as SMTP and FTP. However, the default transport protocol for ASP.NET Web Services based on SOAP is HTTP. So, in a nutshell, SOAP provides the following capabilities:
Enables interoperability between systems using standard, widely available protocols such as XML and HTTP.
Allows systems to communicate with each other through firewalls, without having to open additional, potentially unsafe ports.
SOAP fully describes each data element in the message, making it easier to understand and troubleshoot problems that may occur.
Arguably, as important as what SOAP addresses to enable interoperability is what it does not attempt to address. Specifically, SOAP does not do the following:
Attempt to define how objects are created or destroyed
Impose any specific security mechanism or implementation
Define an authentication scheme
At first glance, these might seem to be serious shortcomings. However, in reality, these omissions allow each platform to address these issues in a way that best suits its needs. For example, SOAP messages can also be exchanged over Secure Sockets Layer (SSL), which is a standard Web protocol that provides a secure, encrypted HTTP connection between the client and server.
The SOAP Specification
The SOAP protocol specification is a W3C-submitted note that is now under the umbrella of the XML Protocols working group. Version 1.2 of the specification (the follow-up to version 1.1) was under development as a working draft at the beginning of October 2001. The .NET Framework and ASP.NET Web Services produce and consume SOAP messages that are compliant with version 1.1 of the SOAP protocol specification.
The SOAP protocol specification consists of four primary parts, each of which has a specific purpose:
A definition for a mandatory, extensible message envelope that encapsulates all SOAP data. The SOAP envelope is the fundamental message carrier that forms the basis for SOAP message exchange between SOAP-aware endpoints. This is the only part of the SOAP specification that is mandatory.
A set of data-encoding rules for representing application-defined data types and a model for serializing data that appears within the SOAP envelope.
A definition for an RPC-style (in other words, request/response) message exchange pattern. SOAP does not require two-way message exchanges;
however, Web services typically implement such RPC-style request/response patterns when used with HTTP as the transport protocol.
Thus, the request/ response RPC-style protocol is a function of HTTP and not of SOAP.
§ A definition for a protocol binding between SOAP and HTTP. This describes how SOAP messages are transmitted using HTTP as the transport protocol.
SOAP Data Type Support
The SOAP specification defines data type support in terms of XSD, the XML Schema specification. This specification defines standards for describing primitive data types as well as complex, hierarchical structures. As you would expect, there is support for integers, strings, floats, and many other primitive types, as well as lists (or arrays) of these primitive types.
In addition to primitive types, user-defined structures can be represented. This is significant, because it paves the way for describing complex, hierarchical data relationships such as what might be found in an invoice or purchase order. The bottom line here is that it is possible to describe any type of data using XSD. Thus, SOAP is capable of supporting any data type, from the built-in primitives defined by XSD all the way to any arbitrary user-defined structure.
This is one of the primary reasons that SOAP is the preferred protocol for exchanging Web service request and response messages, because it enables Web services to accept as well as return any type of data that can be represented by an XSD schema. The Common Language Runtime within .NET provides support for a wide variety of the common data types. All of these data types are shared equally across all of the .NET languages and also have a well-defined
mapping to XSD data types.
SOAP Exceptions
If Web service methods were guaranteed to work at all times, we would not need any form of error notification or processing capabilities. Unfortunately, things can (and often do) go wrong. As such, errors or exceptions that occur in a Web service method call need to be communicated back to the consumer of the Web service in some manner.
This is where SOAP exceptions come into play. SOAP exceptions are used to return error or exception information to the consumer of a Web service as the result of a failed method call.
The SOAP specification uses the term faults rather than exceptions. I have chosen to use the latter to maintain consistency with the terminology used within the .NET Framework, which
refers to SOAP faults as exceptions. This terminology is also reflected in the SOAP classes within .NET.
SOAP exceptions can occur at various stages of processing a Web service request. For example, an error can occur at the HTTP level before the method call can actually be delivered to the Web service. In this case, an HTTP response must be returned, using the standard HTTP status code numbering conventions. If the message makes it past the HTTP layer, it must be translated and dispatched to the actual implementation code that executes the method request. If an error occurs here, the server must return a fault message.
RELATED POSTOne of the greatest benefits of SOAP is that it has been created and adopted as part of an open process, which has been embraced at an unprecedented level by most of the major hardware and software vendors. The SOAP specification is an open technology (having been submitted to the W3C) that provides the basis for application-to-application integration, known as Web services.
The fundamental building block of SOAP is XML. SOAP defines a specialized, yet flexible XML grammar that standardizes the format and structure of messages. Messages are, in turn, the fundamental method for exchanging information between Web services and Web service consumers. Using XML to encode SOAP messages provides several benefits, such as these:
XML is human readable, making it easier to understand and debug.
XML parsers and related technologies are widely available.
XML is an open standard.
XML includes many related technologies that can be leveraged in SOAP.
Thus, XML is a natural choice for encoding SOAP messages and contributes to the simplicity of the specification (at least in relation to more complex binary protocols such as COM and CORBA).
Typically, a Web service consumer will send a message to a Web service, requesting a specific operation to be performed. The Web service processes this request and typically (but not necessarily) returns the results in a response message. This request/response model is conceptually akin to the Remote Procedure Call (RPC) model.
To transport SOAP messages, we need a transport protocol. The obvious choice for a transport protocol is HTTP, because it is in use on so many systems today, making it widely available. In addition, HTTP is typically allowed through most firewalls today, making it easy to get up and running without requiring administrators to open more ports through their corporate firewalls.
Although HTTP is an obvious choice for a transport protocol ( and the one that most major vendors are implementing), the SOAP specification does not require a specific transport protocol.
It is quite possible to transport SOAP messages over other transport mechanisms such as SMTP and FTP. However, the default transport protocol for ASP.NET Web Services based on SOAP is HTTP. So, in a nutshell, SOAP provides the following capabilities:
Enables interoperability between systems using standard, widely available protocols such as XML and HTTP.
Allows systems to communicate with each other through firewalls, without having to open additional, potentially unsafe ports.
SOAP fully describes each data element in the message, making it easier to understand and troubleshoot problems that may occur.
Arguably, as important as what SOAP addresses to enable interoperability is what it does not attempt to address. Specifically, SOAP does not do the following:
Attempt to define how objects are created or destroyed
Impose any specific security mechanism or implementation
Define an authentication scheme
At first glance, these might seem to be serious shortcomings. However, in reality, these omissions allow each platform to address these issues in a way that best suits its needs. For example, SOAP messages can also be exchanged over Secure Sockets Layer (SSL), which is a standard Web protocol that provides a secure, encrypted HTTP connection between the client and server.
The SOAP Specification
The SOAP protocol specification is a W3C-submitted note that is now under the umbrella of the XML Protocols working group. Version 1.2 of the specification (the follow-up to version 1.1) was under development as a working draft at the beginning of October 2001. The .NET Framework and ASP.NET Web Services produce and consume SOAP messages that are compliant with version 1.1 of the SOAP protocol specification.
The SOAP protocol specification consists of four primary parts, each of which has a specific purpose:
A definition for a mandatory, extensible message envelope that encapsulates all SOAP data. The SOAP envelope is the fundamental message carrier that forms the basis for SOAP message exchange between SOAP-aware endpoints. This is the only part of the SOAP specification that is mandatory.
A set of data-encoding rules for representing application-defined data types and a model for serializing data that appears within the SOAP envelope.
A definition for an RPC-style (in other words, request/response) message exchange pattern. SOAP does not require two-way message exchanges;
however, Web services typically implement such RPC-style request/response patterns when used with HTTP as the transport protocol.
Thus, the request/ response RPC-style protocol is a function of HTTP and not of SOAP.
§ A definition for a protocol binding between SOAP and HTTP. This describes how SOAP messages are transmitted using HTTP as the transport protocol.
SOAP Data Type Support
The SOAP specification defines data type support in terms of XSD, the XML Schema specification. This specification defines standards for describing primitive data types as well as complex, hierarchical structures. As you would expect, there is support for integers, strings, floats, and many other primitive types, as well as lists (or arrays) of these primitive types.
In addition to primitive types, user-defined structures can be represented. This is significant, because it paves the way for describing complex, hierarchical data relationships such as what might be found in an invoice or purchase order. The bottom line here is that it is possible to describe any type of data using XSD. Thus, SOAP is capable of supporting any data type, from the built-in primitives defined by XSD all the way to any arbitrary user-defined structure.
This is one of the primary reasons that SOAP is the preferred protocol for exchanging Web service request and response messages, because it enables Web services to accept as well as return any type of data that can be represented by an XSD schema. The Common Language Runtime within .NET provides support for a wide variety of the common data types. All of these data types are shared equally across all of the .NET languages and also have a well-defined
mapping to XSD data types.
SOAP Exceptions
If Web service methods were guaranteed to work at all times, we would not need any form of error notification or processing capabilities. Unfortunately, things can (and often do) go wrong. As such, errors or exceptions that occur in a Web service method call need to be communicated back to the consumer of the Web service in some manner.
This is where SOAP exceptions come into play. SOAP exceptions are used to return error or exception information to the consumer of a Web service as the result of a failed method call.
The SOAP specification uses the term faults rather than exceptions. I have chosen to use the latter to maintain consistency with the terminology used within the .NET Framework, which
refers to SOAP faults as exceptions. This terminology is also reflected in the SOAP classes within .NET.
SOAP exceptions can occur at various stages of processing a Web service request. For example, an error can occur at the HTTP level before the method call can actually be delivered to the Web service. In this case, an HTTP response must be returned, using the standard HTTP status code numbering conventions. If the message makes it past the HTTP layer, it must be translated and dispatched to the actual implementation code that executes the method request. If an error occurs here, the server must return a fault message.
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