This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

QCon SF: Steve Vinoski -- REST Eye for the SOA Guy

Stefan Tilkov,

Here are my unedited notes from Steve Vinoski’s talk at QCon (“REST Eye for the SOA Guy”).

  • Steve does not work for a middleware vendor anymore, nor does he have anything to do with a product in that space
  • Steve has no agenda, no product to sell (in contrast to being at IONA)

  • governance as one of the things business likes about SOA - helps to control when divisional boundaries are crossed

  • SOA does not mean Scrap Old Applications, State of the Art, Special Object Annotations (Just flat out wrong - classes are entities that belong into a pogram), Samve (vendor) On All, Scalable Optimal Architecture (no magic)

  • SOA is comprised of loose recommendations that essentially reiterate elementary software development practices

  • SOA is lacking when it comes to actual architecture (elements, relationships, properties, constraints); technical SOA systems have these, but they’re not consistent
  • is really about organizational IT culture, and also nice for control freaks
  • you’ll never be able to pull of standardizing a whole company on such an approach

  • the SOA guy (a bow tie-equipped figure Steve uses in his slides) doesn’t like it …

  • REST is hypermedia, but not only suitable for browsers

  • major difference to SOA: certain constraints to achieve desirable properties
  • performance, scalability, portability, simplicity, visibility (ability to monitor and mediate)
  • modifiability, extensibility, evolvability, reliability (handling failure and partial failure), failover, load balancing

  • SOA guy: everybody wants those properties, including all SOA systems

  • As SOA has no constraints, it doesn’t help you there
  • You want to make tradeoffs and impose constraints that induce properties that you want
  • SOA talks only about the desired outcome, not how to get there

  • REST constraints: c/s, stateless, caching, layered, uniform, code-on-demand

  • the SOA guys complains C/S has been around forever

  • Maybe C/S is the one constraint of SOA

  • Stateless: Clients have app state, resources have resource state, more sensible than the CORBA style of creating an object, book recommendation: “Release it!” - trade-off: clients get more complicated. In SOA: undefined
  • Caching: of all the things you can do, caching gives you the most bang for the buck - Steve regularly uses 3-4 programming languages every day; customer story: reduce time from 4h to 4 seconds by introducing a cache for dumping a repository; in SOA: cache at your own risk or invent your own protocol - a “huge hole” in SOA
  • Layering: in REST, system layers interact only with adjacent layers - in SOA, undefined
  • Jim: processThis - Steve: governance required
  • Sanjiva & Glen: HTTP can be mis-used, governance needed there as well
  • interface and data are both variable - in a REST style: th
  • e uniform interface takes one variable out
  • Patrick Logan: is the number of operation a good number to have? SteveV: yes; if you have only one operation, you lose the cacheability effect; having too many operations leads to the governance need
  • Q: how does the uniform interface allow you to scale?
  • SOA guy: a uniform interface can’t possibly work? my services all work differently

  • revisiting SOA discovery: you need a registry to find something.

  • you have to know something when you look at a registry: the interface you’re looking for
  • Q: How can 4 operations be sufficient? Steve: The Web has a number of complex processes, and it’s working really well - the names of the operation don’t matter too much
  • Lots of pages devoted to interface definition specifications in CORBA, COM, WS, …
  • Interfaces and Scalability: specialized interfaces inhibit scalability - the likelihood of serendipitous reuse goes down with specialized interfaces
  • every interface is a new protocol
  • Sanjiva: Aren’t specialized resources a specialized protocol, too? Steve: Not every client is generic and can talk to everything, but some can.
  • Q. Are you saying “an interface is a protocol” or “an interface has a protocol”? Steve: A bit of both - it tells you how to use the thing at the other end, it’s just a different layer that the protocol that tells you how to move the bits
  • Q. Is this related to the sessions: Glen Daniels: it’s not just a session, even if you don’t have one, operations might need to be called in a particular order
  • worked on ORBs for so long that he has now become shaped like one
  • explanation of the HTTP verbs
  • The fact that and Flickr use a GET to delete something is just an abuse of the system
  • plug for Leonard’s and Sam’s book
  • one of the features of REST: the ability to relax constraints
  • one example of abuse: SOAP (tunneling through POST)

  • SOA guy: how do I generate code, how do I get type-safe services?

  • never forget that it’s distributed - reference to Waldo paper
  • Distributed systems generally don’t have distributed compile-time type safety and only fake run-time type safety
  • REST focuses on fully hetereogeneous distributed systems because that’s what “large-scale” implies

  • SOA guy: but where’s my IDL? Where’s my WSDL?

  • Traditional IDL exists for code generation
  • no automatic systems exist that download any ol’ IDL and generate fully-operational client applications
  • nobody reads only WSDL or IDL to write their clients - always accompanied by documentation

  • media types mean data and interface definition become completely orthogonal

  • URIs are cheap - name everything you possibly can
  • Allow for hyperlinks to guide the application
  • Keep verbs out of your URIs
  • Summary: SOA is about IT culture and organizations, not architecture
  • buy the RESTful Web services book

Great talk!

On November 9, 2007 2:49 AM, Phillip Ghadir said:

SOA is comprised of loose recommendations that essentially reiterate elementary software development practices

I’m happy to see such a statement from a guy like Steve …

And, as you might anticipate: I’ve told you that for ages. :-)

Even your unedited list of bullet points creates a nice picture of the talk. Hoping to hear/see/read the edited story…