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.
This is the most common way to instigate a synchronous request/response from the HailStorm server.
Scenario 3: Response required somewhere else
If we needed to send the response to an endpoint other than the origin of the request, we would just add that as a value to the <via> element inside <rev>.
Scenario 4: Working through a proxy
For those behind firewalls, the fear that your SOAP messages won't go anywhere should be allayed with the knowledge that ports 80 and 443 (the defaults for HTTP and HTTPS respectively) are open on practically every firewall today. All that's required is for you to incorporate your firewall into your <fwd>/<via> and <rev>/<via> lists so the SOAP message knows how to find its way out and back in.
Of course, HTTP isn't the only transport protocol capable of synchronous messaging, but it is the simplest. It's also the only one whose binding with SOAP has been finalized. The TCP and UDP bindings in SOAP-RP are still in the preliminary stages.
Asynchronous Messaging via SMTP
Sending SOAP messages via email over SMTP or via some other asynchronous protocol is theoretically possible, in that the binding of SOAP to the SMTP protocol has been defined, but has yet to be implemented or documented. It should be only a matter of time before theory becomes practice though as SOAP-RP defines a binding to SMTP, allowing us to send our messages to HailStorm at least partly over email. We might perhaps see intelligent lyris-like servers as intermediary endpoints that know how to read and react to the contents of a HailStorm message, forwarding it to the next end point in the <via> list or storing it for your final consumption later. Theoretically then, we might one day be able to send messages that went via SMTP for some of the journey and not for the rest of it:
For the time being however, we must content ourselves with purposely embedding our SOAP message inside a MIME document and sending it on a one-leg journey to the server. MIME (Multipart Internet Mail Extensions) is a multipart mechanism for the bundling of several items within the same message. In this case, we would create a MIME document that held the SOAP message and any other files associated with it. For example, you could send a message to the myDocuments service saying 'Store the documents I have attached to this message', or perhaps send an electronic card to myContacts saying 'Read this card and store the information within.'
You can find the specification that describes how to bind SOAP 1.1 to MIME at http://www.w3c.org/TR/SOAP-attachments. In brief, it states that while the MIME envelope is aware of the SOAP message within (its content-type is set to text/xml), the SOAP message is unaware that it is being held inside a larger message. However, it does contain links to the other files attached in the MIME message within its <body> element. For example,
The actual insert request for the myDocuments service is left out because the schema for the content document of that service hasn't been released yet.
The top of the document declares the version of MIME the document conforms to and that it contains separate files which are related (Multipart/related) to a root document - our SOAP message, whose content type is given next (text/xml). The SOAP message follows in its usual form, the only difference is that the documents attached to the message are referred to in href links. In the message above then, we've included a reference to the Word document we want HailStorm to store for us. The document itself follows immediately after in the MIME message, an ASCII attachment with a content type of application/msword.
SOAP messages bound into a MIME document with or without any attachments they may have can be carried over any transport mechanisms - HTTP, messaging servers, etc - but the parsing of the MIME message itself is not very efficient. For this reason, Microsoft are developing an alternative to MIME encoding - DIME.