Web Services in the 21st
Century
Designing for it
Nature
•
•
•
•
•
Services, not software
Massive scale (everything is a grid)
Asynchrony where possible
Dynamic change
The 3 C’s
– Content
– Collaboration
– Communication
Why Web Services at All
• Web is about communication
– P2P, P2App, App2App, App2P
• Real problems Integrating applications
– Throughput
– Platforms, Deployment and Change (PDC)
– Availability
– Re-Use
• IIOP, RMI, and DCOM didn’t address
these issues (assembling objects)
Why Web Services at All
•
•
•
•
Throughput => Coarse Grained
PDC => Loosely Coupled
Availability => Asynchronous
Reuse => Service oriented world
How is this accomplished
• Throughput => Coarse Grained => XML
• PDC => Loosely Coupled => WSDL/REST
– Ideally would be machine only, but..
• Availability => Asynchronous =>
– RSS World : Pub/Sub, Ping Services
– SOAP World: WS-Eventing, WS-ADDRESSING
• Reuse => Service oriented world =>
– RSS World : Syndication & Closure
– SOAP World : WSIL, BPEL Services,
Really Simple Picture
APP
A
BINDING
FORMAL
CONTRACT
On XML
BINDING
APP
B
What makes it hard
• Loose Coupling
• Performance
Loose Coupling
• In the Small
• In the Medium
• In the Large
Loose Coupling in the Small
• A doesn’t share ANY code with party B
• A or B can change their implementations
at anytime and be sure that they can still
interact with the other party IFF the
semantics haven’t changed
Loose Coupling in the Medium
• A can send a message to B even if B isn’t
running/available within reasonable
latency constraints at that moment
• B can reply to A even if A isn’t
running/available within reasonable
latency constraints at that moment
Loose Coupling in the Large
• A can send to B even though A doesn’t
know who B is and over time B will change
from
– B to
– B1 to
– B1 and B2 and B3
• This requires Pub/Sub as an intemediary
• See Blue Titan, Grand Central, …
Architectural Issues
• Most XML is being processed as requests
• Most of it is synchronous so latency an
issue, not just throughput
• Services must be up more or less all the
time so requires live dynamic extension
Architectural Needs
– Super efficient Front End for XML
handling/routing
•
•
•
•
•
Super efficient XML pipe
Minimize parsing & garbage collection
Dynamic rewiring of the front end
Avoid state of course
Caching when possible
– Need Asynchronous connections to back end
• Let front ends be quick
• Requires IO completion port type of architecture
Ideal Architecture
1) Message
Ack
C
A
C
H
E
3) DeQueue into
Stream
2)
Can batch/agg
EnQueue Similar messages
T
E
S
T
9) Send Responses
To initial Request
8)
EnQueue
Responses
4) Pull mode
Parser
Has filters pushed
Up at it
Returns tokens
On demand
Policies
Meta Data
5) Policies Engine About how
To handle
Executes
Pipeline of Policies Incoming
messages
Each reads
Thru pull, writes
Thru push
BPEL lite done
right
6) BINDING
7) LOCAL CODE
Sync Architecture
1) Request
2) Parallel Pipeline
C Each part is a sync flow
A Pull mode parser ->
Push mode emitter
C
H
E
T
E
S
T
7) Return
Responses
To initial Request
2a)
Send
Then
Sleep
6) OUT BIND
Send to
Front End
3) Read into Stream
Invoke appropriate
Local service,
4) IN BINDING
5) Local code
executes,
Returns data
Into container
Policies
Meta Data
About how
To handle
Incoming
messages
Binding
IN BIND
Map the
Token into
The objects
That the local
Code will
use
Local Code
Processes
Requests in
Object model
It understands
Bad if lots of
GC
OUT BIND
Local Code
Creates return
Type, this is
Then converted
Into out
tokens
IN BIND
Pipeline Logic
Lazily populate data in
Interface from Stream
Materialize values on
Demand (XML Beans)
Dynamic End Points
Try to use interpretive lang
If compiled, then your code
Is an interpreter and
Should use a pull mode
Parser with lazy caching
Static End Points
Push tokens directly
Into objects
Using binding language
Avoid auto-generated
classes
YOUR USEFUL CODE
OUT BIND
YOUR USEFUL CODE
Pipeline Logic
Lazily Extend the
XML Bean
Return it
End Point
High Speed
Push XML out into
Push mode
Token API
End Point
Normal
Map from
object to returned
XML
Use code on left
End Point
Lazy
Build String
Worse
Build DOM
Missing pieces
• Standard Pipeline language for front end
• Programming language for server side workflow
for normal people with XML as a core
competency
–
–
–
–
XL
BPEL
Ecmascript 4X
LAMP
• Soap Cookies
• F/W support for WS-Eventing and WSAddressing
• Standard for Caching
Hard Issues
•
•
•
•
How to author policy
See Blue Titan
How to be truly async in sync world
Just now getting pull mode parsers with
push down filters
• XML Beans versus Language versus
Direct Binding
What’s wrong with this picture
•
•
•
•
Forgot some basic principles in XML
KISS
Minimal
Design for Humans
– Simple
– Sloppy
– Plastic
– Protean
Examples
•
•
•
•
•
HTTP
HTML
Spreadsheets
PHP
Search/Query
Conflict
•
•
•
•
•
RSS versus WS-*
Simple versus Complex
Sloppy versus Precise
Plastic versus Pristine
Protean versus Circumscribed
How did this happen
• Over Specification
• Try to remove humans
• Specs without implementations
What will happen
• RSS growth will be HTML levels
• XML will grow too, but more slowly
• Most new standards will be ignored if
history is any judge
– SQL 97 versus rest of SQL
– ISO versus TCP/IP
– HTTP NG versus HTTP