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

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 del.icio.us 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!