Information Over The Web part II

1
Information Over The Web(part II)

• Introduction by
• Jackie Assa

2
Outline

• Previous episodes
• Web 2.0
• XML
• Schema
• Today
• Demo
• Coding with XML
• Web services (Soap/WSDL/UDDI)
• SOA
• Rest
• Json

3
Demo

• Oxygen XML editor

4
Java and XML

• A good introduction in http//java.sun.com/develo
  per/technicalArticles/xml/JavaTechandXML/
• https//jaxb.dev.java.net/
• Basic methods
• SAX
• DOM
• Advanced methods
• Binding (JAXB)

5
DOM
6
DOM
7
SAX
8
SAX
9
What is XML binding?

• Different metaphors
• XML focus on strings/tags/elements
• Objects focus on object graphs, inheritance /
  polymorphism and property / object-based
  relationships

10
Stages

• Build XML
• Build schema
• Generate classes
• Build application

11
Schema vs code

• XMLgtCode
• Code-gtXML
• External file-gtXML,code

12
JAXB
public class Customer public Name name
public String street1 public String city
public String state public String zip
public String phone public class Name
public String firstName public String
lastName
ltcustomergt ltnamegt ltfirst-namegtJohnlt/first-na
megt ltlast-namegtSmithlt/last-namegt lt/namegt
ltstreet1gt12345 Happy Lanelt/street1gt
ltcitygtPlunklt/citygt ltstategtWAlt/stategt
ltzipgt98059lt/zipgt ltphonegt888.555.1234lt/phonegt lt/c
ustomergt
13
XML-Java binding implementations(there are many
more)

• Jaxb
• Xstream
• Jibx

14
Web Services
15
How God Created the Web
HTTP. Get/Post
16
How We Plan to Use It
Application c
Application a
Soap/http
http html
XML/http
Application b
Soap/http
17
Goals

• Enable universal interoperability.
• Widespread adoption, ubiquity fast!
• Compare with the good but still limited adoption
  of the OMGs OMA.
• Enable (Internet scale) dynamic binding.
• Support a service oriented architecture (SOA).
• Efficiently support both open (Web) and more
  constrained environments.

18
Requirements

• Based on standards. Pervasive support is
  critical.
• Minimal amount of required infrastructure is
  assumed.
• Only a minimal set of standards must be
  implemented.
• Very low level of application integration is
  expected.
• But may be increased in a flexible way.
• Focuses on messages and documents, not on APIs.

19
Web Services
20
Some Terms

• SOAP
• Simple Object Access Protocol
• Allows the access of Simple Object over the Web.
• SOAP XML HTTP standards
• WSDL
• Web Services Description Language
• WSDL describes what a web service can do, where
  it resides, and how to invoke it.
• UDDI
• Universal Description, Discovery and Integration
• UDDI is a registry for connecting producers and
  consumers of web services.

21
SOAP
22
SOAP

• Applications communicate using Remote Procedure
  Calls (RPC)
• Objects examples DCOM and CORBA or RMI

23
SOAP

• SOAP stands for Simple Object Access Protocol
• SOAP is a communication protocol
• SOAP is for communication between applications
• SOAP is a format for sending messages
• SOAP is designed to communicate via Internet
• SOAP is platform independent
• SOAP is language independent
• SOAP is based on XML
• SOAP is simple and extensible
• SOAP allows you to get around firewalls
• SOAP will be developed as a W3C standard

24
SOAP Building Blocks

• A SOAP message is an ordinary XML document
  containing
• A required Envelope element that identifies the
  XML document as a SOAP message
• An optional Header element that contains header
  information
• A required Body element that contains call and
  response information
• An optional Fault element that provides
  information about errors that occurred while
  processing the message

25
A SOAP Example - Request

• POST /InStock HTTP/1.1
• Host www.stock.org
• Content-Type application/soapxml charsetutf-8
• Content-Length nnn
• lt?xml version"1.0"?gt
• ltsoapEnvelope
• xmlnssoaphttp//www.w3.org/2001/12/soap-envelope
  
• soapencodingStyle"http//www.w3.org/2001/12/soap
  -encoding"gt
• ltsoapBody xmlnsm"http//www.stock.org/stock"
  gt
• ltmGetStockPricegt
• ltmStockNamegtIBMlt/mStockNamegt
• lt/mGetStockPricegt
• lt/soapBodygt
• lt/soapEnvelopegt

26
A SOAP Response

• HTTP/1.1 200 OK
• Content-Type application/soap charsetutf-8
• Content-Length nnn
• lt?xml version"1.0"?gt
• ltsoapEnvelope
• xmlnssoaphttp//www.w3.org/2001/12/soap-envelope
  
• soapencodingStyle"http//www.w3.org/2001/12/soap
  -encoding"gt
• ltsoapBody xmlnsm"http//www.stock.org/stoc
  k"gt
• ltmGetStockPriceResponsegt
• ltmPricegt34.5lt/mPricegt
• lt/mGetStockPriceResponsegt
• lt/soapBodygt
• lt/soapEnvelopegt

27
WSDL
28
WSDL

• WSDL stands for Web Services Description Language
  
• WSDL is written in XML
• WSDL is an XML document
• WSDL is used to describe Web services
• WSDL is also used to locate Web services
• WSDL is not yet a W3C standard

29
WSDL Document
Service

• portType
• Abstract definition of a service (set of
  operations)
• Multiple bindings per portType
• How to access it
• SOAP, JMS, direct call
• Ports
• Where to access it

Port (e.g. http//host/svc)
Port
Binding (e.g. SOAP)
Binding
Abstract interface
portType
operation(s)
inMesage
outMessage
30
The WSDL Document Structure

• ltportTypegt
• The operations performed by the web service
• ltmessagegt
• The messages used by the web service
• lttypesgt
• The data types used by the web service
• ltbindinggt
• The communication protocols used by the web
  serviceThe

31
Soap Types

• Hmm.What can we pick here that will be generic
  enough.
• XML schema?

32
WSDL Port Type

• The ltportTypegt element is the most important WSDL
  element.
• It defines a web service, the operations that can
  be performed, and the messages that are involved.
• ltportTypegt - function or class

33
WSDL Message

• The ltmessagegt element defines the data elements
  of an operation.
• messages - parameters of a function call

34
WSDL Example

• ltmessage name"getTermRequest"gt
• ltpart name"term" type"xsstring"/gt
• lt/messagegt
• ltmessage name"getTermResponse"gt
• ltpart name"value" type"xsstring"/gt
• lt/messagegt
• ltportType name"glossaryTerms"gtltoperation
  name"getTerm"gtltinput message"getTermRequest"/gt
  ltoutput message"getTermResponse"/gt
• lt/operationgt
• lt/portTypegt

35
Bindings

• Map the operations in portType to soap
  operations. (protocol)

ltwsdlbinding name"AmazonS3SoapBinding"
type"tnsAmazonS3"gt ltwsdlsoapbinding
style"document"
transport"http//schemas.xmlsoap.org/soap/http"/gt
ltwsdloperation name"GetObject"gt
ltwsdlsoapoperation soapAction""/gt
ltwsdlinput name"GetObjectRequest"gt
ltwsdlsoapbody use"literal"/gt
lt/wsdlinputgt ltwsdloutput
name"GetObjectResponse"gt
ltwsdlsoapbody use"literal"/gt
lt/wsdloutputgt lt/wsdloperationgt
. lt/wsdlbindinggt
36
WSDL and UDDI

• Universal Description, Discovery and Integration
  (UDDI)
• UDDI is a directory service for storing
  information about web services
• Businesses can register and search for Web
  services.

37
UDDI

• UDDI is a directory of web service interfaces
  described by WSDL
• UDDI communicates via SOAP
• UDDI is built into the Microsoft .NET platform

38
UDDI - Example

• Airlines industry
• Airlines publishes an UDDI standard for flights
• Airlines register their services into an UDDI
  directory
• Travel agencies search the UDDI directory to find
  the airline's reservation interface.
• When found, the travel agency can communicate
  with the service immediately because it uses a
  well-defined reservation interface.

39
SOA
40

• SOA service oriented architecture

41
ESB enterprise service bus
42
Rest

• Some slides were taken from
• Peter Drayton
• peter_at_razorsoft.com

43
REST Representational State Transfer

• REST is an architectural style, not a standard
• REST emphasizes
• Scalability of component interactions
• Generality of interfaces
• Independent deployment of components
• Support for intermediaries

44
Key Principles of REST

• "Identification of resources"
• Resources are anything that can be named
• Naming authority assigns an identifier to a
  resource
• "Manipulation of resources through
  representations"
• Representations capture current/intended state of
  resources
• Representations are transferred between
  components
• Representations often contain links to related
  resources
• "Self-descriptive messages"
• Resource identifiers, representation data
  formats, control data
• "Hypermedia as the engine of application state"
• Servers are stateless, messages are independent
• Clients maintain state (representations)
  traverse links
• Induces scalability, generality, evolvability,
  extensiblity

45
RESTs Generic Actions

• GET
• obtained the state of a resource
• POST
• update the state of a resource (non idempotent)
• PUT
• replace the state of a resource with a new
  version (idempotent)
• DELETE
• delete the resource

46
REST First Example UNIX

• In UNIX, everything is a file
• file, but also sockets, pipes, devices, etc.
• a limited generic interface open, close, read,
  write(the, for some infamous, ioctrl command)
• In a REST architecture, everything is a resource
  (or the representation of a resource)
• limited generic interface GET, POST, PUT, DELETE

47
Second Example Locating Users

• (from http//en.wikipedia.org/wiki/Representationa
  l_State_Transfer)
• Imagine a RPC application with the following
  functions
• getUser()addUser()removeUser()updateUser()getLocat
  ion()addLocation()removeLocation()updateLocation()
  listUsers()listLocations()findLocation()findUser()
  
• RESTful version
• Two resource types User and Location
• URI for each individual user and location
• Updating a user PUTting some XML at the
  corresponding URI
• ltusergt ltnamegtJane Userlt/namegt
  ltgendergtfemalelt/gendergt ltlocation
  href"http//w.e.org/l/us/ny/NYC"gt New York
  City, NY, USlt/locationgtlt/usergt

48
REST the HTML Web
49
Common SOAP 1.1
50
Common SOAP 1.1 (2)
51
SOAP from a REST viewpoint Addressing

• REST architectures utilize the existing web
  addressing model
• Standardized URI schemes subsume protocols (http,
  ftp, etc.)
• Standardized distributed naming authorities (DNS)
• Standardized way of discovering, referring to
  resources (URIs)
• SOAP applications define their own addressing
  schemes
• Web service entrypoints have URIs
• Resources have custom, service-specific addresses
• No standardized way of discovering, referring to
  resources
• Issues
• Intermediaries (proxies, caching) cannot operate
  solely on URI
• Simple URI-based technologies (XSLT, XInclude)
  hampered
• Integrating disparate applications requires
  custom logic
• "Deep linking" into applications not generally
  possible

52
SOAP from a REST viewpoint Generic Interfaces

• REST emphasizes standardized, generic operations
• Technique widely used (SQL, file system,
  registry, Hailstorm)
• HTTP provides CRUD-like PUT, GET, POST, DELETE
• Allows for uniform manipulation of URI-identified
  resources
• SOAP does not provide for generic operations
• Each application defines it's own set of
  operations
• Creates need for description, discovery
  mechanisms
• Knowledge of semantics of operation is
  out-of-band
• Issues
• Clients need knowledge of description, discovery
  mechanisms
• Clients need foreknowledge of specific service
  semantics
• Generic clients not universally feasible (local
  standardization)
• "Deep linking" into applications not generally
  possible

53
SOAP from a REST viewpoint State Management

• REST applications have explicit state transitions
• Servers intermediaries are inherently stateless
• Resources contain data, links to valid state
  transitions
• Clients maintain state, traverse links in generic
  manner
• SOAP applications have implicit state transitions
• Servers intermediaries may (should!) be
  stateless
• Messages contain only data (not valid state
  transitions)
• Clients maintain state, require knowledge of
  state machine
• Issues
• Clients need foreknowledge of service's state
  machine
• Generic clients not universally feasible (local
  standardization)
• Limits independent evolution of client/server
  state machine
• State machine description needed for automated
  discovery

54
REST the XML Web
55
REST the XML Web (2)
56
REST from a SOAP viewpoint Counterpoint

• SOAP related technologies have broad industry
  support
• While HTTP is entrenched, WS hype machine is at
  fever pitch
• SOAP client server toolkits are widely deployed
• Tool support on client server matters
• SOAP headers provide a widely adopted
  extensibility model
• Despite presence of HTTP extension mechanisms
• WS specifications provide end-to-end
  protocols/features
• HTTP/REST only provides point-to-point solutions
• SOAP can be bound to other, non-HTTP transports
• Important for richer XML messaging in the future
• SOAP 1.2 can be used in a RESTful manner
• "Can't we all just get along?"

57
RESTful SOAP 1.2 Guidelines

• Model your system as a set of resources
• Consider both concrete conceptual resources
• Assign logical URIs to resources
• Nouns, not verbs Model whole/part relationships
• Define schemas for resource representations
• Plan for future evolution in schema instance
  documents
• Use WXS for interoperability reuse in WSDL
  definitions
• Enable discoverability of resources
• Representations include links to contained
  related resources
• Provide appropriate resource manipulation
  operations
• GET for idempotent operations (read)
• POST for state-modifying operations
  (create/update/delete/etc)
• Consider using a combination of POST GET for
  queries

58
RESTful SOAP 1.2
59
RESTful SOAP 1.2 (2)
60
Issues

• Client Server toolkits
• Support for SOAP 1.2 SOAP Response MEP
• Large-scale URI-based message dispatch
• Dynamic modification of client proxy URIs
• WSDL issues
• SOAP 1.2 support
• Typed service references (R085)
• HTTP GET-in/SOAP-out (a-la lthttpurlReplacement/gt)
  
• Tradeoffs
• SOAP extensibility model
• End-to-end properties
• Alternate protocol bindings

61
Summary

• REST describes the current Web architecture
• SOAP enjoys broad industry support, extensibility
• Classic SOAP has some limitations compared to
  REST
• REST principles can be applied to XML Web
  Services
• Combining SOAP 1.2 and REST is both possible
  powerful
• Unfortunately, there are still lots of issues to
  be resolved

62
Resources

• Roy T. Fielding Architectural Styles and the
  Design of Network-based Software Architectures
• Paul Prescod REST resources
• Sam Ruby REST SOAP
• Roger Costello REST Tutorial
• W3C Architectural Principles of the WWW WD, SOAP
  1.2 WD
• Mailing lists rest-discuss, rest-explore,
  www-tag, www-ws-desc, xml-dist-app, soapbuilders
• Web sites RESTwiki, Xml.com
• Bloggers Paul Prescod, Mark Baker, Sam Ruby

63
Json

• Some of the slides taken from Douglas Crockford
  / Yahoo! Inc.

64
Data Interchange

• The key idea in Ajax.
• An alternative to page replacement.
• Applications delivered as pages.
• How should the data be delivered?

65
JSON

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

66
JSON

• A Subset of ECMA-262 Third Edition.
• Language Independent.
• Text-based.
• Light-weight.
• Easy to parse.

67
JSON Is Not...

• JSON is not a document format.
• JSON is not a markup language.
• JSON is not a general serialization format.
• No recursive/recurring structures.
• No invisible structures.
• No functions.

68
History

• 1999 ECMAScript Third Edition
• 2001 State Software, Inc.
• 2002 JSON.org
• 2005 Ajax

69
Languages

• ActionScript
• C / C
• C
• Cold Fusion
• Delphi
• E
• Erlang
• Java
• Lisp

• Perl
• Objective-C
• Objective CAML
• PHP
• Python
• Rebol
• Ruby
• Scheme
• Squeak

70
Values

• Strings
• Numbers
• Booleans
• Objects
• Arrays
• null

71
Value
72
Strings

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

73
String
74
Numbers

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

75
Number
76
Booleans

• true
• false

77
null

• A value that isn't anything

78
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

79
Object
80
Object
"name""Jack B. Nimble","at large"
true,"grade""A","level"3, "format""type""rect
","width"1920, "height"1080,"interlace"false,
"framerate"24
81
Object
"name" "Jack B. Nimble", "at
large" true, "grade" "A",
"format" "type" "rect",
"width" 1920, "height" 1080,
"interlace" false, "framerate"
24
82
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.

83
Array
84
Array

• "Sunday", "Monday", "Tuesday", "Wednesday",
  "Thursday", "Friday", "Saturday"
• 0, -1, 0,
• 1, 0, 0,
• 0, 0, 1

85
Json on xstream (xstream.codehaus.org)
package com.thoughtworks.xstream.json.test import
com.thoughtworks.xstream.XStream import
com.thoughtworks.xstream.io.json.JettisonMappedXml
Driver public class WriteTest public static
void main(String args) Product
product new Product("Banana", "123", 23.00)
XStream xstream new XStream(new
JettisonMappedXmlDriver()) // XStream
xstream new XStream(new JsonHierarchicalStreamDr
iver()) xstream.alias("product",
Product.class) System.out.println(xstream
.toXML(product))
86
Json on xstream (xstream.codehaus.org)
package com.thoughtworks.xstream.json.test import
com.thoughtworks.xstream.XStream import
com.thoughtworks.xstream.io.json.JettisonMappedXml
Driver public class ReadTest public static
void main(String args) String json
"\"product\"\"name\"\"Banana\",\"id\"\"123\""
",\"price\"\"23.0\"" XStream xstream
new XStream(new JettisonMappedXmlDriver()) xst
ream.alias("product", Product.class) Product
product (Product)xstream.fromXML(json) System.
out.println(product.getName())