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.

Stefan Tilkov,

These are my unedited notes from Ian Robinson's very interesting talk at JAOO.

  • Context: Engagement w/ a large entertainment and communications company.
  • replace 20+ year old VAX BASIC billing application
  • order capture, fulfilment, product catalogue, field force management, …
  • new design for the next 10-15 years
  • general SOA-like structure - product mgmgt, customer mgmt, order mgmt, provisioning, …
  • 12-14 business meaningful services, relatively self-contained
  • overall view of service estate doesn't change when new products are introduced or processes changed
  • self-sufficient business services - no chatty service architecture
  • each service can do its job from beginning to end
  • services contain the data they need
  • [very nice - actually matches my understanding of services perfectly]
  • redundant information in services - therefore no hard runtime dependencies
  • is it really redundant? no - order management and product management both need product info, but don't care about the others
  • within the service boundary, there may be other distributed development to support e.g. wrapping a COTS app
  • how are these data items replicated between systems?
  • first question: who needs what
  • events are used to distribute information
  • some events related to entity state, some related to application state (e.g. service ordered, service provided)
  • Implementation options for events: point to point (publisher maintains subscriber list), bus/middleware, consumer pull events (consumers poll publishers, guaranteed delivery delegated to consumers, no list of subscribers to maintain)
  • bridge within the service that wraps a 3rd party app: atom client retrieves feed and applies them via the vendor app's WS
  • Atom - what does published information look like
  • AtomPub - how is information published
  • atom feeds for specific time ranges - request to generic URI, specific URI returned in Content-Location header
  • link rel=next to get to the previous archive (decided to stick with Atom terminology instead of inventing a "previous" rel)
  • entries have a self link - each entry can be returned individually
  • multiple category elements to classify (e.g. "product" and "created")
  • links to objects within the entries as XML "Href" elements [I would have preferred an attribute called href]
  • clients can follow links to retrieve the full archive
  • interesting link to Pat Helland's data on the inside, data on the outside - set cache max age to 30 days for stuff that's no longer mutable (events of the past)
  • cache responses locally when following links
  • used WinInet local cache (same one as used by IE) for implementation
  • navigate backwards first, then forward again; second request served from local cache
  • archive size/granularity could change - as long as clients just follow links, they don't care
  • support for conditional GETs and ETags
  • "conservative" in using application/xml for the content types instead of some custom media type
  • etag attribute in links to underlying resources http://...
  • client can extract ETag, do a conditional GET [nice idea]
  • high degree of connectedness
  • [unfortunately, time was up - a pity. I'd have loved to here more.]