On 5/26/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
Heh, so would I. :)
I think that depends on what sort of developer you are, and wherre your comfort levels sit. There are many things I think about which aren't part of my "job description" (I've always said that I'm allowed to do premature optimisations in my head as long as I don't do it with my designs :) all the way down to the wire level, simply because I don't always trust others to make the right descission for all the silly little things I feel that our systems should do. And as such I'll have an opinion on it. :)
But yes, SOAP vs. REST should be void of wire discussions, up until a point where even wire means something to an enterprise architect. Again, it depends on how big a bang you're designing.
Hmm. Not sure all the implications you speak of here; what do you mean by dumbing down? As with all things, there is a golden path between too complex and too simple. The whole SOA thinking in itself tries to push that golden path (now on a different level than say RPC and good ol' CORBA/COM) at the same time trying to make it business friendly, so from there it's just a matter of taste, really.
A lot of emphasis has been made on the simpler but simplified nature of REST and the flexible but more complex nature of SOAP, but I'm willing to say that really, in the end it's a discussion about semantics more than anything else. For example, in terms of data integrity I'd say that with a good XML schema REST *can* be better than SOAP, but with a bad schema it *could* be worse; I personally design Topic Maps-based XML schemas over REST, and get a far more precise data integrity and higher throughput through that than SOAP and WS-* could ever hope to offer. But hey, I'm not a huge transactions hub, either.
It all ... depends. If you're in control, I'd choose REST, but if I'm relying on third-parties a lot, I'd go with SOAP, just as a pragmatic rule.
Okay, I'll agree that emotions are everywhere. But, if we have to argue about
who's emotions are better, I think I'm gonna half to sit that one out...
Heh, so would I. :)
Technically, my argument is away from SOAP. My argument is that wire transport shouldn't be part of the puzzle that a developer thinkgs about.
I think that depends on what sort of developer you are, and wherre your comfort levels sit. There are many things I think about which aren't part of my "job description" (I've always said that I'm allowed to do premature optimisations in my head as long as I don't do it with my designs :) all the way down to the wire level, simply because I don't always trust others to make the right descission for all the silly little things I feel that our systems should do. And as such I'll have an opinion on it. :)
But yes, SOAP vs. REST should be void of wire discussions, up until a point where even wire means something to an enterprise architect. Again, it depends on how big a bang you're designing.
The dumbing
down of the interface for messaging/RPC causes people to think of problems with less flexibility. What that implies, to me, is that they will me worse
decisions about how to manage data integrity and coherency, because they have few language based tools at their disposal.
Hmm. Not sure all the implications you speak of here; what do you mean by dumbing down? As with all things, there is a golden path between too complex and too simple. The whole SOA thinking in itself tries to push that golden path (now on a different level than say RPC and good ol' CORBA/COM) at the same time trying to make it business friendly, so from there it's just a matter of taste, really.
A lot of emphasis has been made on the simpler but simplified nature of REST and the flexible but more complex nature of SOAP, but I'm willing to say that really, in the end it's a discussion about semantics more than anything else. For example, in terms of data integrity I'd say that with a good XML schema REST *can* be better than SOAP, but with a bad schema it *could* be worse; I personally design Topic Maps-based XML schemas over REST, and get a far more precise data integrity and higher throughput through that than SOAP and WS-* could ever hope to offer. But hey, I'm not a huge transactions hub, either.
It all ... depends. If you're in control, I'd choose REST, but if I'm relying on third-parties a lot, I'd go with SOAP, just as a pragmatic rule.
Alex
--
"Ultimately, all things are known because you want to believe you know."
- Frank Herbert
__ http://shelter.nu/ __________________________________________________
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
