COMP60370
SOA and More

Bijan Parsia

{bparsia@cs.man.ac.uk}

Interfaces (i.e., Endpoint APIs)

• The constraints on component interfaces:
• identification of resources
• resource manipulation via "representations"
• self-descriptive messages
• hypermedia is the engine of application state
• Web Architecture
• URI
• HTTP
• HTTP, HTML, XML, MIMEtypes
• URI, <a>

WA: URIs

• The generic syntax:

• URI = scheme ":" 
       hier-part [ "?" query ] [ "#" fragment ]
  hier-part = "//" authority path-abempty...

• foo://example.com:8042/over/there?name=ferret#nose
  \_/   \______________/\_________/ \_________/ \__/
   |         |               |          |         |
  scheme   authority       path      query   fragment
   |   _____________________|__
  / \ /                        \
  urn:example:animal:ferret:nose

• Semantics controlled:
• By the scheme (up to a point)
• By the authority/server
• By the document (and document's type) (esp. fragment)

WA: HTTP Scheme

• HTTP treats URIs in (up to) three pieces:
• Authorities (endpoints): ultimate target addresses
• Paths (hier-part + query): OPAQUE, passed to target
• Fragments: OPAQUE, kept for requester
• The server never sees these
• Paths key part of URI design
• For both user and programmer
• Consider file system path mappings
• Many frameworks assign meaning
• E.g., paths -> object fields and methods
• E.g., standard behaviors (New, Edit, Show)

WA: Messages

• HTTP messages
• Request/response
• Plain text
• Headers + body
• A standard kind of "internet protocol"
• You can telnet into an HTTP server
• Lots of stuff can happen to messages
• Cached, proxied, redirected...

SMTP session 

S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:<bob@example.org>
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <bob@example.org>
C: To: Alice Example <alice@example.com>
C: Cc: theboss@example.com
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 headers and 4 lines in the body.
C: Your friend,
C: Bob
C: .
C: QUIT
S: 221 Bye
  

GET

• GET /2007/OWL/wiki/index.php?title=User_talk:BijanParsia&action=edit HTTP/1.1
  Host: www.w3.org
  User-Agent: Mozilla/5.0 ...
  Accept: text/xml,application/xml,...,text/html;q=0.9,...
  Accept-Language: en-us,en;q=0.5
  Accept-Encoding: gzip,deflate
  Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
  Keep-Alive: 300
  Connection: keep-alive
  Referer: http://www.w3.org/2007/OWL/wiki/User_talk:BijanParsia
  ...

POST

• POST /2007/OWL/wiki/index.php?title=User_talk:BijanParsia&action=submit HTTP/1.1
  Host: www.w3.org
  User-Agent: Mozilla/5.0...
  Accept: text/xml,application/xml,...text/html;q=0.9,...
  Accept-Language: en-us,en;q=0.5
  Accept-Encoding: gzip,deflate
  Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
  Keep-Alive: 300
  Connection: keep-alive
  ...

A response (headers)

• HTTP/1.x 200 OK
  Date: Mon, 25 Feb 2008 01:03:52 GMT
  Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch7
  X-Powered-By: PHP/5.2.0-8+etch7
  Content-Language: en
  Vary: Accept-Encoding,Cookie
  Expires: Thu, 01 Jan 1970 00:00:00 GMT
  Cache-Control: private, must-revalidate, max-age=0
  Content-Encoding: gzip
  Content-Length: 5032
  Content-Type: text/html; charset=utf-8
  P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml"
  Keep-Alive: timeout=2, max=100
  Connection: Keep-Alive...

WA: Metadata

• In many places!
• HTTP headers
• XML Level (encoding!)
• HTML (or application) level (encoding! headers!)
• Built into the application
• Metadata inconsistency is an issue
• People don't synch it up
• Often can't! (No server/generator control)
• Often don't
• Often screw up
• Design for ideal or not?
• What should the architecure say?

WA: Hypermedia

• "Stuff happens" in a web browserwhen
• a user clicks a link
• the parser finds a URI in the src attribute of an img tag (and many other cases)
• a user clicks a form button
• some Javascript fires
• Which of these are hypermedia in action?

A Case: Google Maps

• We can link to a map (page) or....
• Embed by
• Custom code (map)
• Google supplied iFrame (page)
• Static "API" (image)
  

A Case: Google Maps

• URIs rule the day
• Flexible
• but some variance!
• Plenty of link based interaction
• View larger, print, etc.
• Some non-link widgets/interaction
• L&F like classic map apps

HTTP and CRUD

• CRUD	HTTP	SQL
  Create	POST	INSERT
  Read	GET	SELECT
  Update	PUT	UPDATE
  Delete	DELETE	DELETE

SELECT vs. ?

• Query parts of URI are opaque
• I.e., server determined
• no structure but key value
• SELECT involves a query language
• General, rich semantics
• Still need to know table layout, names, etc.
• Documentation critical in either case

Web App Options

• More backend
• REST
• Web Services
• More frontend
• Rich Internet Applications (Flash, Applets, etc.)
• Web Applications (HTML5, AJAX)
• Front and back end line a bit blurry!
• All use HTTP

Web Services

• Old school
• "Programs" on the web 
• Not just documents
• Replace DCOM, CORBA, etc.
• Emerged from RPC style
• "XML over HTTP"
• XML-RPC
• Function invocation model
• Need function names
• Need arguments, thus datatypes
• Today
• Blizzard of languages and standards (WS-*)
• "Enterprise" everything
• Dead?

SOA

• Core: Loosely coupled, platform independant components
• Message oriented
• Not distributed objects!
• Not self-describing
• but "well described"
• Do we have an execution problem?
• Lots of money and ink spilt
• Very "big enterprise" oriented
• Few SOAP endpoints on the open Web
• Many came and then left

(Self-)Description

• What is it for something to be self-describing?
• Format?
• Is XML self-describing?
• Is Well Formed XML self-describing?
• Is Valid XML self-describing?
• Interfaces?
• Is HTTP self-describing?
• Why is self-description a good thing?

Messages

• Messages are fundamental
• Actor model
• And various sorts of message passing systems
• Distributed objects
• Just about anything, really
• So be careful! Just having messages doesn't mean much
• Messages vs. procedures
• How is a message send different from a function call?

SOAP

• Message format + data model + and message processing model
• Some key aspects
• Headers in the body from an HTTP perspective
• "mustUnderstand"

Description

• Actions
• Are not self-describing
• Same message can mean different things
• What's sameness of message?
• State matters; participants matter
• Statelessness at one level doesn't preclude state at others!
• Interfaces aren't uniform
• Description
• DBC
• Describe constraints and capabilities
• Integrate with normal development
• Push a button IDE culture

The RDBMS Analogy

• Prior to RDBMS
• Physical, logical, and conceptual layer all mixed up
• Data definition, querying, and data layout all mixed
• Brittle!
• RDBMS
• Introduced clean layer separation
• Queries don't care about indexes
• Tables don't care about data layout
• Separation of concerns
• Applications string together queries and updates
• Presentation, business logic, etc. all separated from information management
• Same SQL in principle reusable
  
• Portability a nice side effect

BPMS?

• Prior to SOA
• Physical, logical, and conceptual layer all mixed up
• Data definition, querying, and data layout all mixed
• Fine grained exposure of tightly coupled components
• where you had components
• Brittle!
• SOA!
• Want a clean layer separation
• Don't care about protocol or wire format
• Don't care where service is
• Or most details
• Applications string together service actions

WSDL

• Web Services Description Language
• "Machine readable" descriptions
• But...WSDL is pretty weak
• An IDL at best
• Names, Types, some minimal constraints
• But abstracts from concrete details
• Via bindings
• WSDL conceptualizes services:
• Service, endpoints, interfaces, operations, messages, message patterns

High level

• Operations
• Conceptual: Actions which a service may perform
• Without reference to protocol, location, wire format...
• Operational: Typed message exchanges
• Grouped into interfaces, but WSDL says nothing about their interrelations
• Endpoint
• Conceptual: The concrete realization of a service; you can invoke a service only on an endpoint in a particular way
• Operational: Addresses plus bindings (of interfaces)
• Service
• Conceptual: A set of invokable behaviors
• Operational: An interface plus a set of endpoints

An example

• A blogging service
• Simple set of actions (interface)
• Setup blog; register user; create, update, or delete post
• Consider setup blog
• Should fault if you aren't a registered user
• Consider register user
• Could involve several steps, including those with other parties (e.g., credit card or open id check)
• Types are simple
• Simple person/blog records, and ATOM/RSS like items
• Different endpoints
• Can post via HTTP, Email, or Jabber

Registration

• The blogger is commercial
• To register you must supply a valid credit card
• To register you must supply a valid email address
• Work flow involves several steps and different parties
• 

A key point

• The interface is not uniform
• At least, not from our perspective
• Layerable on HTTP!
• Each application can have its own specific operations
• Even if they do the "same" high level task
• We can distinguish different underlying actions
• And blur them!
• So, GETting and POSTing could be bindings of the same operation
• Advantages
• Consider mapping to a programming language
• Rich description
• Can think of action dependencies

Composition: Orchestration

• The metaphor:
• One "controller", many players
• There is a local perspective
• I.e., an ultimate client/invoker
• Simplest model: 
• A program which invokes a series of remote procedures
• The language
• Business Process Execution Language (BPEL)
• Executable (though there is "abstract BPEL")
• Defining your process

Composition: Choreography

• The metaphor
• Many controllers, many players
• Players (more or less) control themselves
• There is a global (or unbiased) perspective
• All "observable" behavior of all parties
• Not what am I going to do, but what are we all allowed to do
• Multi-party contract
• Generalization of WSDL
• The language
• Web Services Choreography Description Language (WS-CDL)
• Fairly moribund

HTTP Extensions

• An alternative to specific app specific interfaces
• Extend the "uniform" interface
• Key difference: predefined meaning
• (But not all the meaning! URIs and Types and documentation matter)
• Examples
• WebDav (new verbs!)
• PROPFIND, PROPPATCH, COPY, MOVE, LOCK, UNLOCK
• Atom API
• Just Plain HTTP

Stepping back

• So much we could talk about!
• User interfaces & RIAs
• Extensibility and versioning
• Schema languages and SSD
• When to make a new format
• Microformats!
• How do formats and behavior interact?
• When does architecture matter?
• How to evaluate technology?
• Be reflective and skeptical

A brief on microformats

• Remember div, span, class, and id
• User defined "semantic" markup
• Extensible HTML
• Without coining new tags!
• Use these to "structuralize" human visible data
• Consider an address
• Or consider the HTML blog posts
• What was wrong with this before?
• Aribitrariness
• So coordinate!
• Not much more than that

Why is this good?

• It allows for progress
• Conforming hCalendar let you extract event info to your diary
• You don't need to rework the browser
• Though an addon may be nice
• It fits in with and reinforces good practice
• Semantic chunks are stylable chunks
• Convergence on stylable chunks makes styles more general
• To a degree
• Degrades somewhat nicer than new elements
• Which require care, Javascript, both, or plugin/browser update

References

• Scalable Web Architectures
• An excellent slide show about scaling a server (setup).  Gets into the nitty gritty (accessibly, though) of e.g., server caching.
• The pragmatic’s guide to Web architectures 
• Reviewing Web Architecture parts 1, 2, 3, 4, 5, 6, 7
• A comprehensive analysis of the TAG's Web Architecture document
• REST Wins, noone goes home
• REST and WS-*
• Web Services Architecture
• SOAP 1.2 (Primer), A Brief History of SOAP
• WDSL 1.1, 2.0 (Primer, Part 1)
• A Note on Distributed Computing 
• Why use SOAP?