Complexity Summary

I’d like to sum up the discussion on the complexity topic, including the SOAP and REST comparison, before moving on to other topics for the blog.
I also still think it would be interesting to try out an XML example, and I hope to get to that soon.
I’d like to thank everyone who participated in the discussion by posting comments. I wanted a discussion, and I got one ;-).
Ok, so what have I learned?
— I still have a lot to learn about REST (and apologies again for the mistakes)
— REST can indeed be useful for program to program communications, and therefore it makes sense to include it within the “Web services” umbrella, as they do at Amazon.com
— REST has advantages over SOAP for simple applications and is also a lower cost solution for many applications
— SOAP has advantages over REST in terms of tool support, an interface definition language (WSDL), and enterprise qualities of service (reliability, security, and transactions)
— Combinations of REST and SOAP based solutions seem very plausible and practical for applications that span simple and complex requirements
— A lot of resentment still exists about software companies over-hyping Web services, and the proliferation of WS-* specs isn’t helping (and of course we had another one today, WS-Management)
A lot of discussion tends to get generated over “what can technology x do” or “what is technology y capable of.” What I’m interested in is what is the best use of technology x or technology y, not what’s possible. As I like to say, it’s possible to build a phone using string and tin cans, but that doesn’t mean it’s the best technology for that application.

Advertisements

3 responses to “Complexity Summary

  1. mike champion

    “A lot of discussion tends to get generated over “what can technology x do” or “what is technology y capable of.” What I’m interested in is what is the best use of technology x or technology y, not what’s possible.”
    Me too. You can provably implement a wordprocessor using a Turing machine or decompose deeply nested documents in to relational tables, but that doesn’t mean it’s a good idea in practical projects.

  2. FWIW, I don’t consider having an interface definition language to be an advantage, since the bulk of the simplicity of REST is a result of all services exposing the same interface and therefore not needing one.
    Not a bad summary though, although I’d do a big search-and-replace on “SOAP” -> “SOA”. SOAP is largely architectural-style agnostic.

  3. Mike & Mark,
    Thanks very much. I guess the only small thing left to say is that an interface definition language is an advantage when a custom interface is appropriate. I think that fixed interface solutions are very powerful and appropriate for many solutions, but custom interfaces are very important for many other solutions.
    I know that a lot of mainframe transactions in CICS for example use a kind of fixed interface, as in “execute transaction” and pass the name of the transaction program to execute in the message.
    When I first started programming back in (yeesh) 1975, we had to store everything on sequential tape. The hard drives only had scratch areas. And we would often write programs like “input()” from tape or “output()” to tape, and place information about the program to be executed in the header of the tape so we could have some generic tape reading and writing programs.
    In some cases though it seems like a real advantage to be able to directly request the execution of a specific program through a custom interface instead of using a generic program that in turn calls the specific program.