Insights
Sunday, March 06, 2005
Get Over It: It's a Tool, not a Religion
In my inbox tonight was a link to this post on TheServerSide.COM: Opinion: SOAP is comatose, long live REST. Since October, I've been involved in a pretty good sized SOA project which is not based around SOAP, but isn't quite based around REST either (although the original design was heavily influenced by someone who is certainly an advocate of REST).
REST vs. SOAP is currently enjoying a similar polarization to vi vs. Emacs. There is a large body of people who believe in Keep It Simple, Stupid (KISS) principles for Web Services, and most of them are in the REST camp. A lot of these same people seem to see the SOAP camp as being a conspiratorial movement by big software vendors like IBM and Microsoft. Personally, I believe the reality is somewhere in between.
The thing that I can't quite understand (after much reading on the WS-* and REST philosophies) is: what the hell difference does it make?
Both of them are tools. To me, it is up to us architects to figure out which tool best suits the job at hand. Lots of places seem to offer both. This would seem to indicate that you can, in fact, accomplish the same things with a degenerate application of SOAP that is based on document-based message exchanges.
Where it really gets interesting is how hard do you want it to be to integrate with an application or system. Of course, this is where you can get locked in to proprietary vendor implementations, but, at least, if the vendors are working together, there's a chance that more than one vendor will be able to talk to each other. If you "roll your own", you've got to not only provide a reliable implementation of said custom mechanism, but you've also got to 1) tell people how to use it and 2) support it when it breaks.
I agree with one commenter on one of the blog comments (can't remember which one now, sorry) who said something along the lines of: the KISS principles of REST work great when talking to Amazon or Yahoo, but if that's not what you want to do (or, more importantly, need to do), then you have a bit of a problem. From my own personal experience, most of these problems arise from the security requirements of SOA architectures. Most people are totally behind the asynchronous messaging capabilities of such a system, but they want the reliability and security they've come to expect from being exposed to years of deployments of MQSeries and other proven messaging systems. When they ask about security, they say things like, "We had that years ago. Ok, sure, it didn't talk to everything, but it worked."
Before everyone gets too upset and thinks that I'm on the side of the vendors, I'm not. I would much prefer to have an open source implementation of some tool than one that I couldn't fix when it broke, however, in the "real world" where a lot of these systems get deployed, that isn't an option. You don't have that many people capable (or willing) to bet their career on an open source solution. Fortunately, there are more than there used to be, but the people behind a lot of big projects want support contracts, not support teams. This is just a fact of life.
Where the REST vs. SOAP debate gets really interesting is after you get the message. Now what?
While I agree that the WS-* specifications are vast, sometimes confusing and not widely implemented, I'd rather try and find one that worked than try and write one myself. If I write it, I'm not working on the problem I'm trying to solve (believe me, this has been one of my great historical problems). Again, specifically with regards to security, SSL only goes so far—even using two-way client authentication. If you want to encrypt part of the data in your XML message so that it can be audited, do you come up with something yourself, or do you try and find a solution that other people have already proven works? In my mind, this is where the complexity comes from. The only thing is that the W3C and others have just tried to standardize some of it. That makes it public. That also makes it a target.
Is SOAP+WSDL+UDDI+WS-* overkill for looking up a book on Amazon? Of course it is, but that's only one context. In another context, you either rely on parts of the infrastructure to solve your problems for you, or you have to push all that complexity on the client. In a lot of the cases for my project, the client doesn't want that complexity because they don't have the capability to handle it themselves. They have to pay a Systems Integrator (SI) to sort all that out for them. That's cost, which limits their willingness to "join the club". While I really don't like the "point-n-click your way to Hell" tools, they're a reality we have to deal with (and no, I'm not going off on that tangent in the middle of this post).
Personally, I don't think the client application should necessarily have to care about message correlation, security, or reliability. We have to build the system so that it's easy to join in, but not just on the surface. You have to make it possible to automate that processing without a lot of burnt sawdust. This is what makes the ESB approach to SOA such a draw for me. Looking at it from the client's point of view, if I have to pay $30K for a software license so that it's easy for me to "join the club" vs. several million to an SI, I know what I'd choose. It's up to us architects to keep the dependencies on that $30K piece of software to a minimum through "integrating at the edge" and other, sensible design idioms and patterns.
The bottom line is that you pay either way. If you're providing the SOA that pushes the complexity on the client, they pay the money, but you loose customers because doing something once they're connected is so damn hard. If you provide a sophisticated infrastructure, you pay up-front to put it in place, but you also take away a lot of the pain involved with sending the messages from point A to point B. Which is more important to your customer?
System's design is about putting the complexity in the right place. Simple systems can do very powerful things, but, sometimes, you need complex systems to solve simple problems. Our job is to know the difference, identify the right solution and do the best for our customers, because, if we don't have customers, we don't have jobs. ¶ 9:50 PM 0 comments
REST vs. SOAP is currently enjoying a similar polarization to vi vs. Emacs. There is a large body of people who believe in Keep It Simple, Stupid (KISS) principles for Web Services, and most of them are in the REST camp. A lot of these same people seem to see the SOAP camp as being a conspiratorial movement by big software vendors like IBM and Microsoft. Personally, I believe the reality is somewhere in between.
The thing that I can't quite understand (after much reading on the WS-* and REST philosophies) is: what the hell difference does it make?
Both of them are tools. To me, it is up to us architects to figure out which tool best suits the job at hand. Lots of places seem to offer both. This would seem to indicate that you can, in fact, accomplish the same things with a degenerate application of SOAP that is based on document-based message exchanges.
Where it really gets interesting is how hard do you want it to be to integrate with an application or system. Of course, this is where you can get locked in to proprietary vendor implementations, but, at least, if the vendors are working together, there's a chance that more than one vendor will be able to talk to each other. If you "roll your own", you've got to not only provide a reliable implementation of said custom mechanism, but you've also got to 1) tell people how to use it and 2) support it when it breaks.
I agree with one commenter on one of the blog comments (can't remember which one now, sorry) who said something along the lines of: the KISS principles of REST work great when talking to Amazon or Yahoo, but if that's not what you want to do (or, more importantly, need to do), then you have a bit of a problem. From my own personal experience, most of these problems arise from the security requirements of SOA architectures. Most people are totally behind the asynchronous messaging capabilities of such a system, but they want the reliability and security they've come to expect from being exposed to years of deployments of MQSeries and other proven messaging systems. When they ask about security, they say things like, "We had that years ago. Ok, sure, it didn't talk to everything, but it worked."
Before everyone gets too upset and thinks that I'm on the side of the vendors, I'm not. I would much prefer to have an open source implementation of some tool than one that I couldn't fix when it broke, however, in the "real world" where a lot of these systems get deployed, that isn't an option. You don't have that many people capable (or willing) to bet their career on an open source solution. Fortunately, there are more than there used to be, but the people behind a lot of big projects want support contracts, not support teams. This is just a fact of life.
Where the REST vs. SOAP debate gets really interesting is after you get the message. Now what?
While I agree that the WS-* specifications are vast, sometimes confusing and not widely implemented, I'd rather try and find one that worked than try and write one myself. If I write it, I'm not working on the problem I'm trying to solve (believe me, this has been one of my great historical problems). Again, specifically with regards to security, SSL only goes so far—even using two-way client authentication. If you want to encrypt part of the data in your XML message so that it can be audited, do you come up with something yourself, or do you try and find a solution that other people have already proven works? In my mind, this is where the complexity comes from. The only thing is that the W3C and others have just tried to standardize some of it. That makes it public. That also makes it a target.
Is SOAP+WSDL+UDDI+WS-* overkill for looking up a book on Amazon? Of course it is, but that's only one context. In another context, you either rely on parts of the infrastructure to solve your problems for you, or you have to push all that complexity on the client. In a lot of the cases for my project, the client doesn't want that complexity because they don't have the capability to handle it themselves. They have to pay a Systems Integrator (SI) to sort all that out for them. That's cost, which limits their willingness to "join the club". While I really don't like the "point-n-click your way to Hell" tools, they're a reality we have to deal with (and no, I'm not going off on that tangent in the middle of this post).
Personally, I don't think the client application should necessarily have to care about message correlation, security, or reliability. We have to build the system so that it's easy to join in, but not just on the surface. You have to make it possible to automate that processing without a lot of burnt sawdust. This is what makes the ESB approach to SOA such a draw for me. Looking at it from the client's point of view, if I have to pay $30K for a software license so that it's easy for me to "join the club" vs. several million to an SI, I know what I'd choose. It's up to us architects to keep the dependencies on that $30K piece of software to a minimum through "integrating at the edge" and other, sensible design idioms and patterns.
The bottom line is that you pay either way. If you're providing the SOA that pushes the complexity on the client, they pay the money, but you loose customers because doing something once they're connected is so damn hard. If you provide a sophisticated infrastructure, you pay up-front to put it in place, but you also take away a lot of the pain involved with sending the messages from point A to point B. Which is more important to your customer?
System's design is about putting the complexity in the right place. Simple systems can do very powerful things, but, sometimes, you need complex systems to solve simple problems. Our job is to know the difference, identify the right solution and do the best for our customers, because, if we don't have customers, we don't have jobs. ¶ 9:50 PM 0 comments
Rebranding
First of all, I should explain the new title and description. One of the things I've been doing over the last month or so is doing a lot of reading. For those of you who know me personally, this shouldn't come as a surprise. The book that sparked this all off recently was Synchronicity: The Inner Path to Leadership, by Joseph Joworski. A very enlightening book which has since lead me to the works of David Bohm, Eric Fromm and Peter Senge.
All of this reading has convinced me that there really are only insights that lots of people take as truths. According to Bohm in Wholeness and the Implicate Order, "all theories are insights, which are neither true nor false but, rather, clear in certain domains, and unclear when extended beyond these domains." He later goes on to say that "we have to be careful here not to identify truth as nothing more than 'that which works' [given a particular context]." The important thing is the context, for "the persistent holding to a truth beyond its proper limits, has evidently been one of the major sources of illusion and delusion throughout the whole of history and in every phase of life."
All this to explain a little about what I'm publishing here. These are my insights—my way of viewing the world. Take them at your own risk. Agree or disagree. Hopefully, it's entertaining and/or useful. ¶ 9:45 PM 0 comments
All of this reading has convinced me that there really are only insights that lots of people take as truths. According to Bohm in Wholeness and the Implicate Order, "all theories are insights, which are neither true nor false but, rather, clear in certain domains, and unclear when extended beyond these domains." He later goes on to say that "we have to be careful here not to identify truth as nothing more than 'that which works' [given a particular context]." The important thing is the context, for "the persistent holding to a truth beyond its proper limits, has evidently been one of the major sources of illusion and delusion throughout the whole of history and in every phase of life."
All this to explain a little about what I'm publishing here. These are my insights—my way of viewing the world. Take them at your own risk. Agree or disagree. Hopefully, it's entertaining and/or useful. ¶ 9:45 PM 0 comments
