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 London 2008: Mark Little "Diary of a Fence-sitting SOA Geek"

Stefan Tilkov,

These are my unedited notes from Mark Little's talk at QCon London 2008.

  • Observes that the talks have been sort of an anti-climax
  • Some history about distributed computing (skipping some here)
  • In the late 1960s/1970s, spending months to integrate four machines
  • RPC invented in the early 1970s
  • RPC is NOT dead, neither is it pining for the fjords
  • RPC still running a lot of backend systems
  • 1990, some physicist invented the World Wide Web
  • Back then: "What does he know that we don't? How dare he? How could he come up with something when he's not even a computer scientist?"
  • 1999, Web Services were invented
  • CORBA's biggest problem: Microsoft not involved
  • Firewall vendors won't open up to CORBA or DCOM (dynamic ports), so we'll show them
  • HTTP is a useful 'transport' after all
  • 2000-2005: spent 5 years going backwards to distribution transparency - it feels like 1970 all over again
  • Distribution must be explicit, otherwise you're not able to deal with failures
  • Same fundamental laws, for Web services, WWW, CORBA, DCOM:
    • Develop "entity", define the unit of work it supports
    • Search for the entity
    • Request entity to perform unit of work
    • maybe try to make the remote interaction local
    • maybe do some "enterprise" stuff as well (security, transactions, replication)
  • Different approaches
    • EDA
    • SOA
    • Message-oriented (MOM, Pub/Sub)
    • Tuple Spaces
    • RPC
    • sync/async
    • group communication
    • There is no such thing as a global panacea!
  • Problems with tight coupling introduced by trying to make a remote interaction look like a local interaction
  • Explanation of client/server stubs/skeletons
  • Definition of SOA: Not purely technology, an architectural style trying to achieve loose coupling
  • Services as re-usable units
  • Explicitly not CORBA w/ angle brackets, coarse-grained services
  • SOA has two architectural constraints:
    • A small set of ubiquitous interfaces to all participating agents, only generic semantics -- often based on specific, but doesn't have to be
    • Descriptive messages, described by schema
    • sounds vaguely REST-like
  • At one extreme: very specific service interfaces, akin to IDL
  • At the other extreme: (e.g. single operation doWork)
  • There are degrees of coupling (not intended to evoke sexual associations ;-) and you should choose the level that's right for you
  • Shows picture of OSI 7 layer model (only known to people with grey hair)
  • With a uniform interface, your application has to do more
  • The same requirements are present throughout the stack
  • split differently between the application and the infrastructure
  • uniform interface enables generic infrastructural asupport
  • specific interface allows for more limited generic support
  • developers have to do less
  • REST over HTTP
    • original HTTP 0.9 had only GET
    • now HTTP has 8 methods
    • HTTP is NOT a transport
    • Often stated that HTTP/REST is only suitable for hypertext
    • Weak argument: nothing inherently limiting machine usage
    • Extra infrastructure could help (anyone remember URN name servers 1994/1995?)
    • Google and other search engines are fantastic name servers
    • Not enough "application" standards -- good point
    • Lack of good tooling (changed, e.g. via JAX-RS, WCF)
  • What about Web services?
    • Began life as CORBA-over-HTTP
    • Just as easy to develop non-SOA apps in WS as it is to write SOA apps with other tooling
    • WS-Addressing and WS-RF both good examples of WS not being used for SOA
    • Web Services and SOA gives benefits
  • Enterprise realities
  • Customers want interop, guaranteed delivery of messages, transactions (not ACID ones), audit trails, bullet-proof security, machine-readable contracts
  • Shows innoQ's WS poster ;-)
  • Can convey the wrong image -- that you need everything
  • Standards: The Web is a series of standards, universal adoption has to count for something, REST/HTTP is ubiquitous
  • application semantic interop is missing
  • Shows REST transactions by HP in 2000 (!)
  • Back then, Mark Baker's continuous interruptions in the mailing lists led to this
  • GET on http://\/transaction-coordinator
  • PUT on http://\/transaction-coordinator/begin?clientid will start new tx and return http://\/transaction-coordinator/\
  • Misses standards e.g. for search (ed: what about OpenSearch?)
  • WS-* has driven portability
  • clearly defined semantics for transactions, security, reliable messaging -- not specific to HTTP
  • WS-* vs. REST
  • Internet-scale computing for WS is no longer being talked about
  • What can REST learn from WS-*: Uniform interface isn't enough, e.g. support for transactions, in a standardized manner
  • Popularize HTTP outside the browser
  • Just because the Web works doesn't make it right for everything (when did you last ride a horse to work?)
  • Don't abuse transports, they don't like it -- HTTP is NOT a transport
  • Adopt SOA principles within Web services (no more WS-RF, WS-Context instead of WS-Addressing)
  • Late binding is good
  • KISS and make up
  • Remember the Web uses HTTP
  • One size doesn't fit all
  • Use the right tool for the right job
  • Both the REST and the WS communities should look at the work that has been done in the 80s and 90s
  • Question: What would you say to people who say "Squid is the ESB"?
  • Answer: It might work if you're just looking for an EAI framework, but he thinks an ESB is more than that