Sample Chapter: Early Adopter Hailstorm (.NET My Services)
Microsoft's .NET My Services is a family of XML web services that improves operational functionality of .NET applications and web pages. In this article Tim takes a look at a sample chapter from Wrox's "Early Adopter Hailstorm (.NET My Services)" book. The chapter talks about what exactly .NET My Services are and how they are composed amongst other things.
Sample Chapter: Early Adopter Hailstorm (.NET My Services) - Header (Page 5 of 10 )
The <path> header, as defined by the SOAP Routing Protocol, lets the creator of the message define its ultimate destination and the routes that message and replies will take to get there and back. It is a mandatory part of every HailStorm message, be it request or response.
The constituent sub-elements of <path> are described in the table below.
The route from endpoint to server and back can involve several intermediaries that know how to receive and send on SOAP messages as required. It might also make use of several transport protocols as well. SOAP-RP currently allows us to define a path over the synchronous messaging protocols HTTP, UDP, and TCP only, but the need to support asynchronous messaging over SMTP as given in the SOAP specification should mean that SMTP will also be supported soon. Other messaging systems like Microsoft's MSMQ, IBM's MQSeries, .NET Remoting, and the Java Message Service (JMS) also have the capacity to send and receive SOAP messages as either intermediaries or endpoints.
Synchronous Messaging via HTTP
The HTTP request/response model mirrors that of SOAP almost perfectly and is the protocol of choice for synchronous messaging using SOAP. If a secure connection is required, HTTPS (HTTP + SSL) can be used in exactly the same fashion. It's generally recommended to use the HTTP POST request to send your SOAP message, as this will keep it hidden, as opposed to HTTP GET, which will attempt to append it to the destination URI. Indeed, the SOAP 1.1 specification provides details for binding SOAP to HTTP POST. It's all in the header.
The key lines of the HTTP header, specifying that the request contains an XML document using the utf-8 character set (HailStorm uses only utf-8 encoding) and that it is a HailStorm request are highlighted. In response, a SOAP message with the header:
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: zzzz
is returned if the query worked and the SOAP message following the header contains a response indicating success. If, however, something went wrong on the server and an attempt to processing your query generated a SOAP Fault, the response header will always take this form:
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml; charset="utf-8"
Content-Length: zzzz
There are several different scenarios using HTTP we can hypothesize now, which should be working when HailStorm becomes a reality next year.