In a previous article I had argued that the end-to-end model was a bad one for SOA. In comments on that article Nick Gall made the point that I was using the term end-to-end incorrectly. I countered that the meaning of the term was different for application protocols than for transport protocols (where Nick's usage came from). Below I explain how HTTP's violation of the 'end-to-end principle' sent application protocols on a path where the very idea of 'end-to-end' changed with unfortunate consequences for SOA.
After three years of rotting in prison with no charges as an 'enemy combatant', American citizen, Jose Padilla, arrested on American soil, has finally been charged with a crime and transfered from military to civilian authority. Lawyer's on Padilla's behalf had appealed his status as an 'enemy combatant' leading to a variety of legal cases including a Supreme Court Decision and a recent decision by the Fourth Circuit Court of Appeals.
In a sense I'm almost sorry that the George Bush decided to back down and not continue to assert the government's line that it could hold anyone, anywhere, for however long it thought appropriate. It would have been useful to have had a Supreme Court ruling reminding Mr. Bush that he is President, not Emperor. Of course given the new Justices that Mr. Bush is appointing I suppose I should be happy the case ended now before the new Supreme Court had a chance to rule that we have no rights other than the ones that Mr. Bush decides to give us.
In any case Mr. Bush has demonstrated that the U.S. government can steal three years of a citizen's life without any charges, judicial review, nothing. That alone is scary enough.
"This is an industry, it's a business. We exist to make money. We exist to put commercials on the air. The programming that is put on between those commercials is simply the bait we put in the mousetrap." – Ted Koppel, retiring anchor, ABC New, Nightline
Obvious? Yes. But still worth remembering.
Quote taken from Washington Post article "His Night in the Sun – After 25 Years, Ted Koppel Is Leaving the Show That Did It His Way", 9/8/2005 by Howard Kurtz.
In this article I first look at the use cases for encryption in SOA and explore three scenarios: hop-by-hop, end-to-end and beyond messaging. I conclude that most folks just need hop-by-hop messaging, specifically SSL. I then look at issues relating to encrypting messages outside of the enterprise and conclude that most services probably don't need encryption but they'll use it anyway so to reduce harm they should at least use SSL enabled proxies in order to make the unencrypted messages available within the corporate network. I then look at using encryption within the enterprise and strongly caution most companies to avoid it if at all possible. The bottom line is that SSL is enough for almost everything, GPG cleans up the rest and XML Encryption and the WS-Security framework are almost certainly more trouble than they are worth.
In this article I explain why (in my non-qualified opinion as a non-lawyer) I think most people are wasting their time when they worry about non-repudiation of SOA messages.
In my search for how real people are implementing SOA I just about never see SOAP, and WSDL seems unheard of. But when I point this out I inevitably get yelled at and told SOAP and WSDL are used all the time. Which is true, but misses the point. Because what SOAP and WSDL are generally being used for is not SOA but rather RPC, specifically RPC-Encoded. Of course RPC is the text book definition of "Not SOA". So I tip my hat to Web Service's major success – as Not SOA.
In an article I wrote about TOR I mentioned that one of the reasons to use TOR is that you don't know what you have to hide. Things you do today, like reading certain materials, visiting certain websites, exchanging e-mails with certain persons could, in the future, prove to be enough to destroy your life. Just ask Muslims who made the mistake of visiting the wrong Mosques, giving money to the wrong charities or buying the wrong books. None of their actions were illegal or problematic before 9/11 but now those entirely innocent actions are being used to ruin their lives. So it is with justifiable fear that American citizens should read the Washington Post's article on the massive abuses the government has been making of National Security Letters (NSLs).
In SOA application modeling there are two basic approaches, end-to-end and hop-by-hop. The end-to-end model is based on an originating sender, a series of intermediaries and a final destination. In the hop-by-hop model each service only knows about the next hop service and nothing more. Below I argue that the end-to-end model inevitably leads to having to create a single protocol that the whole world has to support, requires a painfully sophisticated security model and all but requires that services be tightly coupled. The hop-by-hop model, on the other hand, suffers from none of these problems but does introduce extra latency. On balance I don't believe the benefits of the end-to-end model justify its costs and therefore recommend that service implementers use the hop-by-hop model.
Authentication is often seen as a cheap and easy security solution but it is anything but. Authentication is a significant threat to re-use and it can cause a false sense of security that leaves services open to real threats. But when authentication is called for there are outstanding, well proven solutions that are almost certainly already in your data center – HTTP Digest and SSL. As I argue below, they are the right technologies for just about all your authentication needs.
SOAR-ity is intended to allow for "reliable" (this term is almost always a misnomer) messaging over HTTP. It achieves this goal by introducing two new request headers, MID which provides a unique ID for a message and MsgCreate which contains the date and time on which the first instance of the message with the associated MID was sent. The purpose of the MID/MsgCreate pair is to allow any HTTP request (e.g. any HTTP method can be used) to be repeated multiple times with a guarantee that the message will be processed no more than one time. In essence it makes any HTTP method call idempotent.
The SOA-Rity specification is now available as an Internet Draft. Below I provide links to different versions of the draft that are hosted locally so as to ensure accessibility if the draft should expire.:
- a text version,
- a HTML version,
- the XML source – I used XML2RFC to generate the text and Julian's XSLT translator for the HTML version and
the DTD – I made the organization element optional under author element to get rid of validation errors
I'd also like to take this opportunity to say that the Oxygen editor ROCKS! Make sure to check out their 'academic licenses' which are actually just for personal use in case you can't justify buying Oxygen for your job.