QCon SF: Steve Vinoski -- REST Eye for the SOA Guy
November 8, 2007
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!
About
This page contains a single entry from Stefan Tilkov's Random Stuff posted on November 8, 2007 9:01 PM. The previous post in this blog was QCon SF: Sanjiva Weerawarana -- WS-* vs. REST: Mashing up the Truth from Facts, Myths and Lies. The next post in this blog is QCon SF: Pete Lacey -- "Demonstrating the 'ilities' of REST". Many more can be found on the main index page or by looking through the archives.
Comments
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…
Best,
Phillip
Posted by: Phillip Ghadir at November 9, 2007 2:49 AM | link