Home arrow ASP.NET arrow Page 6 - Sample Chapter: Early Adopter Hailstorm (.NET My Services)
ASP.NET

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.

Author Info:
By: Tim Pabst
Rating: 5 stars5 stars5 stars5 stars5 stars / 11
April 08, 2002
TABLE OF CONTENTS:
  1. · Sample Chapter: Early Adopter Hailstorm (.NET My Services)
  2. · Making Conversation
  3. · An Insecure Present
  4. · SOAP
  5. · Header
  6. · Scenario 1: No Response Necessary
  7. · DIME, not MIME?
  8. · The Response from HailStorm
  9. · Summary
  10. · Conclusion

print this article
SEARCH DEVARTICLES

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.
blog comments powered by Disqus
ASP.NET ARTICLES

- How Caching Means More Ca-ching, Part 2
- How Caching Means More Ca-ching, Part 1
- Reading a Delimited File Using ASP.Net and V...
- What is .Net and Where is ASP.NET?
- An Object Driven Interface with .Net
- Create Your Own Guestbook In ASP.NET
- HTTP File Download Without User Interaction ...
- Dynamically Using Methods in ASP.NET
- Changing the Page Size Interactively in a Da...
- XML Serialization in ASP.NET
- Using Objects in ASP.NET: Part 1/2
- IE Web Controls in VB.NET
- Class Frameworks in VB .NET
- Cryptographic Objects in C#: Part 1
- Sample Chapter: Pure ASP.Net

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials