D41 - Web 2.0 Protocols.ppt

© 2007 IBM Corporation
Conference materials may not be reproduced in whole or in part without the prior written permission of IBM.
2007 WebSphere Services Technical Conference
world class skill building and technical enablement
April 23 - 27, 2007 • Las Vegas, NV
W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
Web 2.0 Protocols
Session Number: D41
Matthew Perrins Senior Certified IT Specialist
Roland Barcia Senior Software Engineer

2
IBM Confidentiality Statement
• The 2007 WebSphere Services Technical Conference
attendees include
 IBM internal employees
 Select Business Partners who are under confidentiality or
non-disclosure agreements (NDAs)
• If the contents of this presentation are IBM Confidential, you
must
 Edit the contents of this chart to remind attendees that it
is their responsibility to protect IBM Confidential material
 Edit the slide master to add a text box stating “IBM
Confidential”
 Include a slide reminding the attendee that this material is
confidential and dissemination must be controlled
• If the material in this presentation is not IBM Confidential,
you may remove this chart

3
Objectives
• Explain the main protocols that are being
used in the construction of Web 2.0
applications
• Explain why these protocols have evolved
• Details of where and when to use them

4
WS-* is complex
• Let own up !
 We have let WS-* become a monster, it is trying to
be everything to everybody
 Great for Computer to Computer solutions
 Great for Process Engines and BPM solutions
 Not so great for Human to Computer, and
developer to Computer
 Not a very consumable protocol, requires complex
development tools just to get started

5
Don’t get me wrong
WE NEED WS-* !!! For a lot of what it was
designed to do.
But not as the transport glueing Rich Internet
Applications together, we need something far
simpler and easier to use and have a wider
impact on every developer skill level.

6
Why
There is a big push back on complexity
Enterprise SOA
Web SOA
RSS
Web SOA
Bridge
ATOM
JSON
REST
AJAX
XML
PHP
Enterprise
MASHUPS
FEEDS
.NET
J2EE
WSDL
CICS
WS-*
MOM
SOAP
Ruby
J2SE
JDBC
JMS

7
Protocols and Standards
•Transport & Invocation
 HTTP Roland
 REST Roland
 COMET Matt
• Protocols Formats :
 JSON Roland
 JSON – RPC Matt
 Bayeux Matt
 XML ( POX ) Matt
 RSS Matt
 ATOM Roland

W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
HTTP
The transport foundation of the Internet

9
HTTP Overview
• Textual protocol, based on MIME
• Request-response exchanges
One connection per exchange
• RFC 2616 – see for details

10
•10
HTTP Message Structure
HTTP request/status line 
(Header  ) *

Entity ?
•  is CRLF

11
HTTP Request & Response
•Request message:
Method: GET, PUT, POST, DELETE…
Address, HTTP version
Headers, request entity
•Response message:
HTTP version
Status code and reason phrase
Headers, response entity

12
•12
HTTP Request Example
GET /blog/ HTTP/1.1 
Host: ibm.com:80 
User-agent: telnet 


13
•13
HTTP Response Example
HTTP/1.1 200 OK 
Date: Mon, 7 Nov 2005 16:07:59
GMT 
Server: Apache 
Connection: close 
Content-Type: text/html 

<html>
…

14
HTTP Methods GET & HEAD
•GET
Returns a representation of a resource
Safe method – no significant side effects
•HEAD
Returns only headers of what GET would
return
Useful for testing validity, accessibility,
metadata
•14

15
HTTP Methods
POST, PUT, DELETE
•Not necessarily available on all resources
Subject to access rights
•PUT
Replaces or creates a resource
•DELETE
Removes a resource
•POST
Submits data to a resource for any processing
Replace or add data, manipulate other resource
•15

16
HTTP Status Codes
• Success 2xx – request recognized and
accepted
 200 OK
 202 Accepted to be processed later
 204 No content
 206 Partial content (on partial GET)
• 1xx continue
 100 Continue – should be ignored
 101 Switching protocols
• Redirect 300 Multiple choices
 301 Moved permanently
 302 Found (temporary redirect)
 303 See result elsewhere (using GET)
 307 Temporary redirect
 304 Not modified (on conditional GETs)
 Usually client can automatically redirect
•16
• Errors
• 400 Bad, malformed request
• 401 Unauthorized
• 407 Proxy authentication required
• 404 Not found
• 410 Gone
• Usually client shouldn’t repeat same
request
• Server Errors
• 500 Internal server error
• 501 Not implemented
• 503 Temporarily unavailable
• 505 HTTP version not supported
•Usually client may repeat same
request later

17
Web Basics: Simple Set of Operations, via the HTTP API
• HTTP provides a simple set of operations.
Amazingly, all Web exchanges are done using this
simple HTTP API:
GET = "give me some info" (Retrieve)
POST = "here's some update info" (Update)
PUT = "here's some new info" (Create)
DELETE = "delete some info" (Delete)
• The HTTP API is CRUD (Create, Retrieve, Update,
and Delete)

W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
REST
(Representational State Transfer)

19
What is REST?
" REST " was coined by Roy Fielding
in his Ph.D. dissertation [1] to describe a
design pattern for implementing
networked systems.
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

20
20
REST Overview
• REST
 An Architectural Style, Not a Standard.
 Client-Server: a pull-based interaction style: consuming components pull
representations.
 Stateless: each request from client to server must contain all the information
necessary to understand the request, and cannot take advantage of any stored
context on the server.
 Uniform interface: all resources are accessed with a generic interface (e.g., HTTP
GET, POST, PUT, DELETE).
 Named resources - the system is comprised of resources which are named using a
URL.
 http://<host>/customer
• GET: Returns list of customers
• POST: Creates Customer Record
 http://<host>/customer/roland
• GET: Returns Roland customer record
• PUT: Updates Roland Record
• DELETE: Delete Roland Record

21
Why is it called
"Representational State Transfer? "
Resource
Client
http://www.boeing.com/aircraft/747
Boeing747.html
• The Client references a Web resource using a URL.
• A representation of the resource is returned (in this case as an HTML
document).
• The representation (e.g., Boeing747.html) places the client in a new state.
• When the client selects a hyperlink in Boeing747.html, it accesses another
resource.
• The new representation places the client application into yet another
state.
• Thus, the client application transfers state with each resource
representation.
Fuel requirements
Maintenance schedule
...

22
Motivation for REST
•The motivation for developing REST was to
create a design pattern for how the Web
should work, such that it could serve as the
guiding framework for the Web standards and
designing Web services.

23
REST - Not a Standard
•REST is not a standard
 You will not see the W3C putting out a REST specification.
 You will not see IBM or Microsoft or Sun selling a REST developer's
toolkit.
•REST is just a design pattern
 You can't bottle up a pattern.
 You can only understand it and design your Web services to it.
•REST does prescribe the use of standards:
 HTTP
 URL
 XML/HTML/GIF/JPEG/etc. (Resource Representations)
 text/xml, text/html, image/gif, image/jpeg, etc. (Resource Types, MIME
Types)

24
Services on the Web
•There is a large diversity of services
•The focus recently changed from human to machines
•Different philosophies about architectures have emerged
•Similarities
 XML is used as the document format
•Two main architectures
 Message-oriented, with machine processable descriptions
•defining a set of very extensible technologies
 Following more closely the architecture of the Web
•There is opposition between those approaches

25
HTTP core operations for REST
•GET
returns a state representation of the identified resource.
•POST
performs some form of application-specific update to the
identified resource
•PUT
creates a new resource at an identified location (URI)
•DELETE
destroys a resource at the identified location (URI).

26
REST is out there already
•Syndication using RSS
•Bla-bla List
 Secure, simple, sharable to-do
lists.
•AJAX
 Asynchronous JavaScript and
XML
•The blogosphere
 the universe of weblogs
•Openomy
 online file storage system
•Amazon
 offers its developer interface in
both REST and SOAP
versions
 with the REST version
accounting for most of the
traffic
•eBay
 offers a REST developer
interface
•Yahoo
 offers a REST developer
interface

27
How SOAP differs from REST
POST /BestPrice HTTP/1.1
Host: www.bestprice.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetPrice xmlns:m="acompany.example.org">
<m:Item>xbox</m:Item>
</m:GetPrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
http://bestprice.example/query?item=xbox

28
SOAP Get List of Widgets
Web
Service
POST /WidgetShop HTTP/1.1
…
<soap:Envelope>
<soap:Body>
<GetList/>
</soap:Body>
</soap:Envelope>
HTTP/1.1 200 OK
…
<soap:Envelope> …
<soap:Body>
<GetListResponse>
<WidgetNo>2572</WidgetNo>
…
</GetListResponse>
</soap:Body>
</soap:Envelope>

29
REST Get List of Widgets
Web
Server
GET /WidgetShop/ HTTP/1.1
HTTP/1.1 200 OK
…
<html>
<a href="2572">Widget 2572</a>
<a href="8732">Widget 8732</a>
…
</html>

30
SOAP Get Details of Widget
Web
Service
…
<soap:Envelope>
<soap:Body>
<GetDetails>
</GetDetails>
</soap:Body>
</soap:Envelope>
HTTP/1.1 200 OK
…
<soap:Envelope> …
<soap:Body>
<GetDetailsResponse>
<Widget> … </Widget>
</GetDetailsResponse>
</soap:Body>
</soap:Envelope>

31
REST Get Details of Widget
Web
Server
GET /WidgetShop/2572 HTTP/1.1
HTTP/1.1 200 OK
…
<html>
<h1>Widget Number 2572 </h1>
<a href="/order?id=2572">Buy it</a>
</html>

32
SOAP Order Widget
Web
Service
…
<soap:Envelope>
<soap:Body>
<OrderWidget>
<OrderDetails> … </OrderDetails>
</OrderWidget>
</soap:Body>
</soap:Envelope>
HTTP/1.1 200 OK
…
<soap:Envelope> …
<soap:Body>
<OrderWidgetResponse>
<OrderNo>txg742</OrderNo>
</OrderWidgetResponse>
</soap:Body>
</soap:Envelope>

33
REST Order Widget
Web
Server
POST /order?id=2572 HTTP/1.1
HTTP/1.1 200 OK
…
<html>
<a href="/orders/txg742">Order</a>
</html>

34
Arguments for and against
•Why not Web services
Web services are reinventing the Web through HTTP POST
Web services are too complex compared to REST services
•And are getting even more complicated
Losing benefits of the Web
•Why not REST services
Foolish to want to model everything as GET, POST, PUT
and DELETE operations
Only works for simple services
• How do you deal with things like transactions, reliability, etc.?
•Similar arguments have happened before
CORBA vs. early Web Services

35
References
•Xml.com
 http://www.xml.com/pub/a/2004/12/01/restful-web.html
•Roy Fielding's PhD dissertation
 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
•Building Web Services the REST Way
Roger L. Costello
 http://www.xfront.com/REST-Web-Services.html
•Second Generation Web Services
 http://www.xml.com/pub/a/2002/02/06/rest.html
•REST and the Real World
 http://www.xml.com/pub/a/2002/02/20/rest.html
•SOAP, REST and Interoperability
 http://www.prescod.net/rest/standardization.html
•Evaluating XML for Protocol Control Data
• http://www.prescod.net/xml/envelopes/

W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
COMET / Bayeaux
Web 2.0 Invocation Pattern

37
AJAX Polling
event
Server
Client
event
time
poll interval

38
Problems with AJAX Polling
•Overhead of processing “no message” HTTP requests/responses
 Server side
 Network
 Client side
•Latency of event delivery
 Depends on polling interval – fundamental design decision.
 From time of event delivery, a client/server roundtrip must be made for the event
to reach the client.
•Scalability
 Large numbers of clients and/or low latency (frequent poll) will not scale well.
 ex: 1000 clients, 100ms poll interval = 10,000 requests/second!

39
Comet
• Coined by Alex Russell, in Comet: Low
Latency Data for the Browser, to describe
event driven, server-push based data
streaming to browsers.
• Comet allows events to be delivered to the
browser in a much more timely manner than
previous AJAX polling approaches.
• Does not require browser plug-ins nor thick
clients
• Capable of being scaled to large numbers
of users on servers using event driven I/O.
• An event driven architecture on both the
client and server; a natural fit with a Service
Orientated Architecture.
• Just as merely naming AJAX was a useful
shortcut discussing an approach, so to with
Comet.
• Sidenote: (apparently) no specific inherent
meaning in the word “Comet” •http://alex.dojotoolkit.org/?p=545

40
Event Delivery via Long Polling
Client
wait
event
wait
event
Server
time

41
Benefits
•Low latency event delivery to the browser
•No additional plug-ins required

42
Example Applications
• Stock Quotes / Front Office Applications
• SIP Applications – Inbound Call Consoles
• Collaborative Document Authoring
• Chat & Instant Messaging
• Sporting Event Scores
• Browser Based Email
• Management Consoles / Monitoring & Alerts
...any application where delivery of events to the client in a
timely manner is important

43
Comet fills a gap in the existing AJAX model
• AJAX improves single user responsiveness
• Comet improves collaborative, multi-user
application responsiveness
 can deliver information to the user at any
time, not just in response to that user’s input
 e.g.
• Scales better than polling

W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
Protocols used in Web 2.0

W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
XML

46
XML Is…
• Extensible Markup Language (XML) is a set of syntax rules used to
define special purpose languages that meet the diverse needs of
business, science, and government, as well as the publishing world.
• The term "XML" also refers more broadly to the set of related
technical standards created with XML syntax, as well as to custom
(non-standard) languages based upon these standard
specifications.
• Collectively, the family of XML specifications enables the
interchange of data and structured text across dissimilar computer
systems, especially when the Internet is the transmission medium.

47
What is XML?
• Extensible web standard: a W3C
“Recommendation” (February 1998; standard for
9+ yrs): http://www.w3.org/TR/REC-xml
• human readable data format: visually similar to
HTML, but closer to Standard Generalized Markup
Language: HTML < XML < SGML
• HTML : SGML :: your language : XML
• machine understandable; easily parsable by
freeware
• structured (hierarchical) data, any degree of
complexity; database neutral format

48
Presentation vs. Structure
HTML: Only reflects how text should be presented. Not obvious to
computer that “Public” is a last name, or even that we’re referring to an
employee.
John Q Public 
john.q.public@ex.com
XML: Only indicates how information is structured. Relationship of LAST
name to EMPLOYEE is obvious, but how we display this info is not
specified, so different applications can extract or display pieces as per
their own requirements.
<EMPLOYEE>
<NAME>
<FIRST>John</FIRST>
<MIDDLE>Q</MIDDLE>
<LAST>Public</LAST>
</NAME>
<EMAIL>john.q.public@ex.com</EMAIL>
</EMPLOYEE>
John Q. Public
john.q.public@ex.com
PUBLIC
What is EMPLOYEE/NAME/LAST?

49
Benefits of XML
• Enables automatic validation of data compared to a model.
• Ideally suited for database integration since it is a platform-neutral and
vendor-neutral format.
• Facilitates re-purposing the same data for multiple target devices or output
formats.
• Lowers the entry bar for SMEs (small and medium-sized enterprises) to
participate in EDI transactions.
• Provides a flexible and extensible format with applicability to a wide range
of applications including Web development, relational and XML databases,
EDI, Web Services (SOAP, WSDL, UDDI), and publishing and content
management.

50
XML Big Picture
http://kensall.com/big-picture/bigpix22.html

51
XML Summary
• POX = Plain Old XML is very consumable as
a data format
• Most programming languages have
mechanisms for processing , creating and
manipulating XML
• Can be cumbersome in JavaScript to
navigate
• Move towards using JSON as a structured
format

W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
JSON
JavaScript Object Notation

53
JSON
•JavaScript Object Notation
•Minimal
•Textual
•Subset of JavaScript

54
JSON
• A Subset of ECMA-262 Third Edition.
• Language Independent.
• Text-based.
• Light-weight.
• Easy to parse.
• Not a document format.

55
Languages
• ActionScript
• C
• C++
• C#
• Cold Fusion
• Delphi
• E
• Erlang
• Java
• JavaScript
• Lisp
• Objective-C
• Objective CAML
• Perl
• PHP
• Python
• Rebol
• Ruby
• Scheme
• Squeak

56
Values
•Strings
•Numbers
•Booleans
•Objects
•Arrays
•null

57
Value
number
string
value
object
false
null
array
true

58
Strings
•Sequence of 0 or more Unicode characters
•No separate character type
A characters is represented as a string with a
length of 1
•Wrapped in "double quotes"
•Backslash escapement

59
String
string
"
Any UNICODE character except
" or or control character
"

quotation mark
reverse solidus
/
solidus
b
backspace
formfeed
newline
carriage return
horizontal tab
4 hexadecimal digits
f
n
r
t
u
"

60
Numbers
•Integer
•Real
•Scientific
•No octal or hex
•No NaN or Infinity
Use null instead

61
Number
number
digit
1 - 9
.
0
digit
e
E
digit
-
digit
+
-

62
Booleans
•true
•false

63
null
•A value that isn't anything

64
Object
•Objects are unordered containers of key/value
pairs
•Objects are wrapped in { }
•, separates key/value pairs
•: separates keys and values
•Keys are strings
•Values are JSON values
struct, record, hashtable, object

65
Object
{ : }
value
string
object
,

66
Object
{
"name": "Jack B. Nimble",
"at large": true,
"grade": "A",
"format": {
"type": "rect",
"width": 1920,
"height": 1080,
"interlace": false,
"framerate": 24
}
}

67
Array
•Arrays are ordered sequences of values
•Arrays are wrapped in []
•, separates values
•JSON does not talk about indexing.
An implementation can start array indexing at
0 or 1.

68
Array
[ ]
value
array
,

69
Array
["Sunday", "Monday", "Tuesday",
"Wednesday", "Thursday", "Friday",
"Saturday"]
[
[0, -1, 0],
[1, 0, 0],
[0, 0, 1]
]

70
Rules for encoders
• A JSON encoder must only produce well-formed JSON text.
• A JSON decoder must accept all well-formed JSON text.
• A JSON decoder may also accept non-JSON text.
• Be conservative in what you do, be liberal in what you accept
from others.

71
ECMAScript Fourth Ed.
•New Methods:
Array.prototype.toJSONString
Object.prototype.toJSONString
String.prototype.parseJSON
•Available now: JSON.org/json.js

72
JSON Looks Like Data
• JSON's simple values are the same as used in programming
languages.
• No restructuring is required: JSON's structures look like
conventional programming language structures.
• JSON's object is record, struct, object, dictionary, hash,
associate array...
• JSON's array is array, vector, sequence, list...

73
JSON Is Not XML
objects
arrays
strings
numbers
booleans
null
element
attribute
attribute string
content
<![CDATA[ ]]>
entities
declarations
schema
stylesheets
comments
version
namespace

74
REST
Mapper
RESTful JSON
findCustomer
Service
Method
CalculateInterest
Service
Method
{ firstName: “Matthew” , lastName : “Perrins”,
account : “123456”, sortCode : “11-22-33” }
/customer/Perrins
findCustomer(userna
me)
CalculateInterest (15)
{true}
/calculateInterest/15
JavaScript
e.g. J2EE Servlet +
Ajax Feature pack
JSON Serialisation

75
JSON Summary
• JSON is a simple, common representation of
data.
• Communication between servers and
browser clients.
• Communication between peers.
• Language independent data interchange.

W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
JSON-RPC

77
Whats is JSON-RPC
• Is the Web 2.0 version of a Remote Procedure Call (RPC)
• Similar in design to WSDL and SOAP
 But much much simpler
• Does not require complicated tooling products
• Exposes interface methods into JavaScript uses JSON as
data transport protocol
• Easy to program to service end points
•This is not REST

78
REST
Mapper
How it works
system.describe
dojo.rpc.JsonService
JSON Service Interface
findCustomer
Service
Method
CalculateInterest
Service
Method
REST URI
{ firstName: “Matthew” , lastName : “Perrins”,
account : “123456”, sortCode : “11-22-33” }
/customer/findCustomer
findCustomer(userna
me)
CalculateInterest (15)
{true}
/customer/calculateInterest
{ interest: “15” }
JavaScript
e.g. J2EE Servlet +
Ajax Feature pack
JSON Serialisation

79
View – WebSphere Ajax Feature Pack Example - JavaScript + Dojo
function doSearch()
{
var uid = document.getElementById("uid").value;
var pw = document.getElementById("pw").value;
customerClass = new dojo.rpc.JsonService("/customer/system.describe");
customerClass.serviceUrl = "/customer/findCustomer";
customerClass.findCustomer(uid,pw).addCallbacks(customerFound,displayError);
}
function customerFound(thiscustomer)
{
customer = thiscustomer;
// Change the Customer Name
document.getElementById("displayfirstname").innerHTML = ""+customer.firstName+"";
document.getElementById("displaylastname").innerHTML = ""+customer.lastName+"";
// Display the Account Details
dojo.lfx.chain(
dojo.lfx.implode("findCustomer", "logo", 200),
dojo.lfx.fadeShow("accountDetails",200)
).play();
}
JavaScript

80
system.describe
{
"sdversion": "1.0",
"name": "CustomerCallable",
"id": "urn:json-rpc:sample.payee.callable.CustomerCallable",
"methods": [
{
"name": "findCustomer",
"parameters": [
{
"name": "uid",
"type": "str"
},
{
"name": "pw",
"type": "str"
}
],
"return": {
"name": "return",
"type": "zero.sample.payee.model.Customer"
}
}
],
URI = /customer/system.describe
JSON

81
Controller – JSON Servlet Mapper – Simple Controller
public Customer findCustomer(String uid,String pw) throws Exception{
CustomerManagement cm = new CustomerManagement();
Customer customer = (Customer)cm.getCustomerbyUID(uid, pw);
if (customer == null ) {
throw new
CustomerNotFoundException("No customers found matching the input criteria");
}
return customer;
}
Java

82
Model – POJO Persistence Framework
private String findCustomerByID = "SELECT * FROM CUSTOMER C WHERE C.ID=? AND C.PASSWORD=?";
public Customer getCustomerbyUID(String uid, String pw) {
Customer customer = null;
DataManager session = DerbyUtil.getSession();
customer = session.queryFirst(findCustomerByUID,Customer.class,uid,pw);
DerbyUtil.closeSession();
return customer;
}
Java

W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
Bayeux Protocol

84
Bayeux Protocol
• JSON-based protocol for clients to subscribe to
events and for servers to deliver them more timely
than possible with AJAX-based polling.
• Goals
 Make event delivery fast
 Keep it simple
 Allow for the protocol to be
extended
•Extract from the Bayeux tapestry
•showing the arrival of Halley’s comet

85
// from client, to server
[
{
"channel": "/meta/handshake",
// all meta channel messages MUST contain the protocol version the
// client expects
"version": 0.1,
// the oldest version of the protocol that this client will support
"minimumVersion": 0.1,
"supportedConnectionTypes": ["iframe", "flash", "http-polling"],
// the authScheme is outside the realm of this specification and
// provided here for illustration only. It's also optional.
"authScheme": "SHA1",
// the authUser and authToken are optional and authScheme dependent
"authUser": "alex",
"authToken": "HASHJIBBERISH"
}
// servers MUST ignore other messages in the envelope should the first
// be a handshake request
]

86
Web Pub Sub ESB Bridge for AJAX
• Uses the Comet application pattern and is
considered a cometd implementation
• Uses Bayeux protocol
• Relies on dojo toolkit
• Ships with complete sample (Quote streamer)
• Ships with an enhancement to WAS Engine for
scalability
• Available as part of the Early Preview <> name
• Not (yet) supported for production usage

87
Architecture Overview
Cometd
(I/O)
Web Pub Sub
ESB Bridge for
AJAX
Bayeux protocol
JSON / HTTP
Browser WebSphere Application Server V6.x
Enterprise
Service
Bus
Vie
w
Dojo
Local
Bus
View
View

88
Server Architecture
Client
Service
Integration
Bus
Channel Framework
TCP HTTP HTTPQueueChannel
WebSphere
Platform
Messaging
Bridge
Pub/Sub Servlet
Bayeux
protocol
WebSphere Application Server V6.x
message
delivery
un/subscribe
Web Pub Sub
ESB Bridge for AJAX

W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
RSS

90
What does RSS stand for?
• It depends!
• Some call it Rich Site Summary
• Others call it Really Simple Syndication

91
So, what is it?
•RSS is a text-based format, a type of XML. RSS files are often
labeled as XML.
• RSS version 1.0 is also RDF (Resource Discovery
Framework), which is important only because an RSS file may
be labeled as RDF.
• By using XSLT (Extensible Stylesheet Language), these XML
files can be converted to a much more friendly view.

92
What does it look like?

93
What are web feeds?
• A way to share content
News stories
Movies and MP3’s
Blog entries
• Use XML to store data
• They don’t require the user to visit the site/resource in which
the content is coming from
•RSS and Atom are the most popular web feed formats in use

94
About RSS and Atom
-RSS (Really Simple Syndication)
•First widely adopted version was 0.90 created by Netscape in 1999
•RSS Versions 0.90, 0.91, 0.92, 1.0, 1.1, 2.0.1
•Many version and turmoil around the standard, only part of that is really
needed
•That is why Atom has taken over
-Atom
•In July 2003 Atom 0.2 was created on a Wiki owned by Sam Ruby
•Project moved to the IETF ‘Atompub working group' and created a formal
Atom 1.0 standard in July 2005
•Atom Versions 0.2, 0.3, 1.0

95
RSS
• Feeds – These are the actual content items
that are produced by web authors. These
could be taken from blogs, journals, news
sites, etc.
• Aggregators – An aggregator is a program or
site that collects the feeds for reading.
Aggregators can be installed as stand-alone
programs, or they can be web-based.

96
Advantages of RSS
•By using an aggregator, you can read
feeds from multiple websites in one
location.
•No SPAM!
•No Pop-Ups!
•Most blogs now have feeds, and more
journals and news sites are adding them.
•Organization!!

97
How to find RSS feeds
Look for a button like these within a site:
http://www.network-theory.co.uk/newtitles.html
http://www.nytimes.com/services/xml/rss/

98
How to find RSS feeds
•Or look for a button like this in your web
browser:

W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
W
ebSphere
C
o
n
f
e
r
e
n
c
e
T
e
c
h
n
i
c
a
l
S
e
r
v
i
c
e
s
2007
ATOM

10
0
Atom and RSS Compared
•Simple, strictly defined
standard; fixes the ambiguity
inherent in RSS
•Includes a RelaxNG schema
so you can validate the feed
•Includes a well-defined
publishing protocol
•Can be transmitted over any
protocol, such as XMPP
•Very flexible for reading and
writing many kinds of
application data
•Started at Netscape in
the late 90’s
• Used to publish meta
data about news with
links to the stories
• Separate and parallel
development
•Conflicting views for
and against RDF
•No publishing protocol
•Very loosely defined
specification
•Can’t contain well-formed
XML payload (only plain
text or escaped markup)
•Lacks a schema for
validation
•Great for news and
machine readable lists;
useless for anything else
•Dates, Authors, URIs, and
XML validity are left in
doubt
•No publishing protocol
Atom 1.0
RSS 1.0, 0.92, 0.91
RSS 2.0

10
1
A quick Atom tutorial
Atom
Atom Syndication Format
RFC 4287
Atom Publishing Protocol
Draft 8
Publishing
Atom is supported by: Bloglines, Google (Blogger, News), Typepad, LiveJournal,
NewsGator, FeedDemon, O’Reilly Developer Weblogs, Drupal, Flickr, Apple,
Microsoft and of course IBM
Feeds
Sam Ruby, who
invented Atom

10
2
Atom Syndication Format
Who created it
What it is called
What it contains
When it was updated
An XML format representing collections of resources
One trivial use case for it is news syndication
Where it is

10
3
A simple Atom feed
Feed
Entry
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title>BBCSport Cricket</title>
<link href="http://example.org/reilly/"/>
...
<entry>
<title>Simon Mann’s column</title>
<link href="http://example.org/reilly/3"/>
<author><name>Simon Mann</name></author>
<id>http://example.org/2004/12345679</id>
<updated>2006-04-03T12:28:02Z</updated>
<content>Andrew Flintoff experienced his toughest day so far…</content>
</entry>
...
<entry>
<title>Another Simple Title</title>
<edit href="http://example.org/reilly/1"/>
<content>More content.</content>
</entry>
</feed>

10
4
Atom Documents
•An Atom Entry contains at least the
minimum that needs to be known about
a resource – what it is called, where it
is, who created it, when it was updated,
and what it contains
•An Atom Feed contains the Atom
Entry documents resulting from a Query
over resources

10
5
What else can we represent?
•Contrary to popular use-cases, a feed is not always “the 15
most recent news articles” – Atom can represent other
resources and collections
•You can include additional namespaces in an Atom feed
•This means we can represent all kinds of things:
– Mail messages
– Vacation schedules
– Conference
registrations
– Expense approvals
– Activities
– Orders
– Prospects
– Documents
– Blog posts
– Calendar
entries

10
6
•“Atom Publishing Protocol” uses HTTP verbs to perform CRUD operations
•The feed itself contains all the info you need:
 The URI for posting new items
 A URI for each entry
•It means that everything is self-contained, and you know how to work with it,
regardless of what kind of data it contains!
How do you work with feeds and entries?
Create: POST a new entry to the collection’s URI
Read: GET on the collection’s URI to retrieve the feed
GET on the entry URI to retrieve a single entry
Update: PUT an updated entry to the entry URI
Delete: DELETE on the entry URI

10
7
Example: create a new entry
Request
POST /reilly HTTP/1.1
Host: example.org
Content-Type: application/atom+xml
<?xml version="1.0" encoding='utf-8'?>
<entry
xmlns="http://purl.org..." >
<title>Lotusphere 2006</title>
<author>
<email>robert_yates@us.ibm.com</email>
</author>
<updated>2006-12-05T12:29:29</updated>
<content type="XHTML" xml:lang="en-us">
I am a speaker and am staffing a stand in the innovation lab
</content>
</entry>
Response
HTTP/1.1 201 Created
Location: http://example.org/reilly/4

10
8
Example: update an entry
Request
PUT /reilly/4 HTTP/1.1
Host: example.org
<?xml version="1.0" encoding='utf-8'?>
<entry
xmlns="http://purl.org..." >
<author>
<email>robert_yates@us.ibm.com</email>
</author>
</content>
</entry>
Response
HTTP/1.1 200 OK

10
9
Example: read a collection
Request
GET /reilly/ HTTP/1.1
Host: example.org
Response
HTTP/1.1 200 Ok
Content-Length: nnnn
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom ">
<title>My Submitted Expenses</title>
<link href="http://example.org/reilly/"/>
<entry>
<link rel=“alternate” href="http://example.org/reilly/3.html"/>
<link rel=“edit” href=“http://example.org/reilly/3.html”/>
</content>
</entry>
</feed>

11
0
Example: delete an entry
Request
DELETE /reilly/4 HTTP/1.1
Host: example.org
Response
HTTP/1.1 200 Ok

11
1
Advantages so far
•We have a simple, scaleable REST api to work
against a wide variety of resources
Easy to discover
Easy to transmit
Easy to script
Easy to cache
Easy to secure
Low risk to adopt
Next, we’ll show that we can use this to build lots of
things without much code

11
2
Atom Summary
• Fully open, simple, transparent approach – you
don’t need to make up new REST apis for every
application
• Takes full advantage of the web’s natural strengths:
HTTP verbs, web caching, XML
• Flexible user interface options
• Flexible posting options
• Lots of “free” integration

11
3
References and Additional Reading
•Hacking Web 2.0: RSS and Atom Feed Implementation Vulnerabilities
 http://www.spidynamics.com/spilabs/education/whitepapers.html
•Cross-Site Request Forgery
 http://en.wikipedia.org/wiki/Cross-site_request_forgery
•Wikipedia RSS Page
 http://en.wikipedia.org/wiki/RSS_(file_format)
•RSS Specification
 http://www.rss-specifications.com/rss-specifications.htm
•Phishing with Superbait
 http://www.whitehatsec.com/presentations/phishing_superbait.pdf
•Atom Specification
 http://www.atomenabled.org/
•RSS Security Resource Archive (Big pimpin)
 http://www.cgisecurity.com/rss/

11
4
Sample Text and Graphic
• Feel free to include bulleted lists and graphics
in your presentation
• Remember: a picture is worth 1,000 words

11
5
Summary
• We have explained the main protocols that
are being used in the construction of Web 2.0
applications
• And explained why these protocols have
evolved
• Some scenarios of where and when to use
them

11
6
Summary
• The purpose of this page is to summarize
what you just told your audience
• The summary should match the objectives
Some speakers use the same text for the
summary and objectives
Be sure to leave a few minutes at the end
for questions

11
7
Questions
• Please complete your session evaluation
• Thank you!!

D41 - Web 2.0 Protocols.ppt

More Related Content

Similar to D41 - Web 2.0 Protocols.ppt (20)

Recently uploaded (20)

D41 - Web 2.0 Protocols.ppt