Sample Chapter: Early Adopter Hailstorm (.NET My Services) - Scenario 1: No Response Necessary
(Page 6 of 10 )
The first and simplest is the minimal case where the SOAP request is sent over HTTP and doesn't require a response (indicated by not including the <rev> element).
<srp:path>
<srp:action>
http://schemas.microsoft.com/hs/2001/10/core#request</srp:action>
<srp:to>http://this.cluster.myContacts.msn.com/danm@wrox.com/</srp:to>
<srp:id>uuid:764CBFB8-A9FF-46D0-BAEC-3D11F9AA44A8</srp:id>
</srp:path>With all the optional elements taken out it's not too difficult to see how this all fits together.
Scenario 2: Response needed from sender If we add in an empty element to this <path>, like so, we effectively add in that we would like a response and that it should be returned as an HTTP response to the original POST request.
<srp:path>
<srp:action>
http://schemas.microsoft.com/hs/2001/10/core#request</srp:action>
<srp:to>http://this.cluster.myContacts.msn.com/danm@wrox.com/</srp:to>
<srp:rev>
<srp:via/>
</srp:rev>
<srp:id>uuid:764CBFB8-A9FF-46D0-BAEC-3D11F9AA44A8</srp:id>
</srp:path>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>.
<srp:rev>
<srp:via>http://send.response.here.com</srp:via>
</srp: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.
<srp:path>
<srp:action>
http://schemas.microsoft.com/hs/2001/10/core#request</srp:action>
<srp:to>http://this.cluster.myContacts.msn.com/danm@wrox.com/</srp:to>
<srp:fwd>
<srp:via>http://internal_firewall_name:80</srp:via>
</srp:fwd>
<srp:rev>
<srp:via>http://external_firewall_name</srp:via>
</srp:rev>
<srp:id>uuid:764CBFB8-A9FF-46D0-BAEC-3D11F9AA44A8</srp:id>
</srp:path>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:
<srp:fwd>
<srp:via>smtp://192.168.0.1:25</srp:via>
<srp:via>http://firewall_at_other_end:80/</srp:via>
</srp:fwd>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,
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
start="<InsertDocument.xml@wrox.com>"
Content-Description: Document Storage Request
--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <InsertDocument.xml@wrox.com>
<?xml version='1.0' ?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
...
>
<s:Header>
...
</s:Header>
<s:Body>
<insertRequest select="/myDocuments">
<Document href="cid: <DocumentToStore.doc@wrox.com"/>
...
</insertRequest>
</s:Body>
</s:Envelope>
--MIME_boundary
Content-Type: application/msword
Content-Transfer-Encoding: ascii
Content-ID: <DocumentToStore.doc@wrox.com>
... Word document here ...
--MIME_boundary--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.
Next: DIME, not MIME? >>
More ASP.NET Articles
More By Tim Pabst
