This is a little pet peeve of mine. I was pointed through Stefan to a presentation on Web Services (originally from April 2004, apparently) and once again as one alternative to HTTP for moving SOAP messages around the author mentioned SMTP. While I admit SMTP is a major protocol involved in email exchange, what people want for SOAP is email, not SMTP. I expect people want to use the existing infrastructure and receive their email (SOAP messages) via IMAP or POP and, expectedly, send their email using their OS capabilities which may be real SMTP, but also invoking sendmail.
I was among the authors of the SOAP Email Binding and I fought successfully against making this particular document an SMTP binding. The document in fact only mentions actual protocols in this paragraph:
It is not the responsibility of this SOAP binding to mandate a specific email infrastructure, therefore specific email infrastructure protocol commands (such as SMTP, POP3, etc) are not covered in this binding document. The underlying email infrastructure and the associated commands of specific email clients and servers along the message path are outside the scope of this email binding.
Repeat after me - email is a viable alternative to HTTP for delivering SOAP messages.
Posted at 1211 on Tue, Dec 21, 2004 in category Work | TrackBack | Comments feedHi Jacek,
This is interesting to me, because you’re basically saying that SOAP isn’t binding to a specific wire protocol, but instead to a more abstract protocol — that of e-mail messaging — that leaks into the application (e.g., by fetching your SOAP messages using POP, etc.).
One might draw a corollary regarding the HTTP binding; rather that binding to HTTP itself, maybe it would be more useful and appropriate to bind to REST.
I like this, because it tends to treat SOAP more as a format than a protocol (which I’ve written about before); however, it does make protocol independence problematic.
Cheers,
Posted by: Mark Nottingham at January 8, 2005 2:35 AMMark, I kinda disagree. Email is a name for a concrete suite of protocols, sending something by email is a very concrete action, even though the local configuration of how it's actually done may vary. HTTP is also, in fact, a set of protocols - 1.0, 1.1, perhaps even HTTPS can fall in this set.
On the other hand REST is an architectural style, which might be taken to designate all protocols built according to this style, but one cannot say a message is transferred using REST.
I like treating SOAP as a format but what my post was about was treating SOAP as a protocol. There is no space for the phrase "SOAP binding" when you treat SOAP as a format. It's not SOAP that uses the protocol, it's the app that combines SOAP and a protocol. In the traditional messaging view of SOAP the application uses SOAP (mostly) independently of protocol and the SOAP layer takes care of the binding.
Posted by: Jacek at January 10, 2005 9:48 AM