- XML Reference Guide
- Overview
- What Is XML?
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- Table of Contents
- The Document Object Model
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- DOM and Java
- Informit Articles and Sample Chapters
- Books and e-Books
- Implementations
- DOM and JavaScript
- Using a Repeater
- Repeaters and XML
- Repeater Resources
- DOM and .NET
- Informit Articles and Sample Chapters
- Books and e-Books
- Documentation and Downloads
- DOM and C++
- DOM and C++ Resources
- DOM and Perl
- DOM and Perl Resources
- DOM and PHP
- DOM and PHP Resources
- DOM Level 3
- DOM Level 3 Core
- DOM Level 3 Load and Save
- DOM Level 3 XPath
- DOM Level 3 Validation
- Informit Articles and Sample Chapters
- Books and e-Books
- Documentation and Implementations
- The Simple API for XML (SAX)
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- SAX and Java
- Informit Articles and Sample Chapters
- Books and e-Books
- SAX and .NET
- Informit Articles and Sample Chapters
- SAX and Perl
- SAX and Perl Resources
- SAX and PHP
- SAX and PHP Resources
- Validation
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- Document Type Definitions (DTDs)
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- XML Schemas
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- RELAX NG
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- Schematron
- Official Documentation and Implementations
- Validation in Applications
- Informit Articles and Sample Chapters
- Books and e-Books
- XSL Transformations (XSLT)
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- XSLT in Java
- Java in XSLT Resources
- XSLT and RSS in .NET
- XSLT and RSS in .NET Resources
- XSL-FO
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- XPath
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- XML Base
- Informit Articles and Sample Chapters
- Official Documentation
- XHTML
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- XHTML 2.0
- Documentation
- Cascading Style Sheets
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- XUL
- XUL References
- XML Events
- XML Events Resources
- XML Data Binding
- Informit Articles and Sample Chapters
- Books and e-Books
- Specifications
- Implementations
- XML and Databases
- Informit Articles and Sample Chapters
- Books and e-Books
- Online Resources
- Official Documentation
- SQL Server and FOR XML
- Informit Articles and Sample Chapters
- Books and e-Books
- Documentation and Implementations
- Service Oriented Architecture
- Web Services
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- Creating a Perl Web Service Client
- SOAP::Lite
- Amazon Web Services
- Creating the Movable Type Plug-in
- Perl, Amazon, and Movable Type Resources
- Apache Axis2
- REST
- REST Resources
- SOAP
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- SOAP and Java
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- WSDL
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- UDDI
- UDDI Resources
- XML-RPC
- XML-RPC in PHP
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- Ajax
- Asynchronous Javascript
- Client-side XSLT
- SAJAX and PHP
- Ajax Resources
- JSON
- Ruby on Rails
- Creating Objects
- Ruby Basics: Arrays and Other Sundry Bits
- Ruby Basics: Iterators and Persistence
- Starting on the Rails
- Rails and Databases
- Rails: Ajax and Partials
- Rails Resources
- Web Services Security
- Web Services Security Resources
- SAML
- Informit Articles and Sample Chapters
- Books and e-Books
- Specification and Implementation
- XML Digital Signatures
- XML Digital Signatures Resources
- XML Key Management Services
- Resources for XML Key Management Services
- Internationalization
- Resources
- Grid Computing
- Grid Resources
- Web Services Resource Framework
- Web Services Resource Framework Resources
- WS-Addressing
- WS-Addressing Resources
- WS-Notifications
- New Languages: XML in Use
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- Google Web Toolkit
- GWT Basic Interactivity
- Google Sitemaps
- Google Sitemaps Resources
- Accessibility
- Web Accessibility
- XML Accessibility
- Accessibility Resources
- The Semantic Web
- Defining a New Ontology
- OWL: Web Ontology Language
- Semantic Web Resources
- Google Base
- Microformats
- StructuredBlogging
- Live Clipboard
- WML
- XHTML-MP
- WML Resources
- Google Web Services
- Google Web Services API
- Google Web Services Resources
- The Yahoo! Web Services Interface
- Yahoo! Web Services and PHP
- Yahoo! Web Services Resources
- eBay REST API
- WordML
- WordML Part 2: Lists
- WordML Part 3: Tables
- WordML Resources
- DocBook
- Articles
- Books and e-Books
- Official Documentation and Implementations
- XML Query
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- XForms
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- Resource Description Framework (RDF)
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- Topic Maps
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation, Implementations, and Other Resources
- Rich Site Summary (RSS)
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- Simple Sharing Extensions (SSE)
- Atom
- Podcasting
- Podcasting Resources
- Scalable Vector Graphics (SVG)
- Informit Articles and Sample Chapters
- Books and e-Books
- Official Documentation
- OPML
- OPML Resources
- Summary
- Projects
- JavaScript TimeTracker: JSON and PHP
- The Javascript Timetracker
- Refactoring to Javascript Objects
- Creating the Yahoo! Widget
- Web Mashup
- Google Maps
- Indeed Mashup
- Mashup Part 3: Putting It All Together
- Additional Resources
- Frequently Asked Questions About XML
- What's XML, and why should I use it?
- What's a well-formed document?
- What's the difference between XML and HTML?
- What's the difference between HTML and XHTML?
- Can I use XML in a browser?
- Should I use elements or attributes for my document?
- What's a namespace?
- Where can I get an XML parser?
- What's the difference between a well-formed document and a valid document?
- What's a validating parser?
- Should I use DOM or SAX for my application?
- How can I stop a SAX parser before it has parsed the entire document?
- 2005 Predictions
- 2006 Predictions
- Nick's Book Picks
Every time we get a new innovation, eventually the "old world" of applications tries to use it to its advantage. We had the web, which was designed for documents, and eventually everyone was creating "web enabled applications". Now we have web services, and everyone's creating "web services applications". If you look at it in a more general sense, we even have "Service Oriented Architectures". I'm sure it's not the first time that a "new" way of doing things was co-opted and absorbed by the old way, and I'm even more sure it won't be the last. But this need to adapt web services to the old way of creating programs creates a need to get around some of the things about web services that were considered great in the first place.
For example, web services are inherently stateless. You make a call, and you get a result. Technically, that's the end of the association between sender and receiver. But if you've ever tried to create any kind of serious application, you know that that's hardly the end of it. You know that you often need to pass information that approximates a state, such as a message identifier or a session id.
Then there's the matter of parameters. In a traditional API, you have methods and functions and properties (oh my!) and you pass and receive values. Sure, you can approximate that in a SOAP message, but that would mean fundamentally changing the way that you think about programming. And That Will Not Do, apparently.
So to that end, we have the need to create a web service in such a way that we can program with it as we would program with any other language or environment. We need to be able to uniquely identify a service or a service instance, we ned to be able to pass parameters back and forth.
It has to be standard.
In other words, it doesn't do any good to solve all of those problems if everybody solves them differently. To that end, one proposed method that is gathering steam, particularly when it comes to Grid Computing, is WS-Addressing.
WS-Addressing has two basic functions: to provide a standard way of referencing endpoints, and to provide a standard set of headers providing information about a message, such as where it's going and where replies and faults should go. Let's start by looking at endpoint references.
The purpose of endpoint references is to provide a way to give more information that a simple URL can provide. For example, consider this endpoint reference, slightly modified from our discussion on Web Services Resource Framework:
<wsa:EndpointReference> <wsa:Address> http://www.example.com/services/someService </wsa:Address> <wsa:ReferenceProperties> <tns:resourceID>DataChunk42</tns:resourceID> </wsa:ReferenceProperties> <wsa:ReferenceParameters> <tns:expires>32000</tns:expires> </wsa:ReferenceParameters> </wsa:EndpointReference>
In this case, we have an endpoint with two pieces of information: the address of the serivce, and a reference property. Endpoint references can have five different types of information:
- address: The address is a URI (such as a URL) the represents the location of the service and identifies it. This information is required.
- reference properties: This peices of information (such as the one in the example above) help to identify the resource to which the service refers.
- reference parameters: This information is anything else that helps to facilitate the interaction.
- selected port type: The primary
portType
of the endpoint being conveyed, as defined in the WSDL file. - service-port: Also referencing the WSDL definition of the service, the service-port points to the
service
element that describes the service. - policy: This information refers to WS-Policy elements.
The Address
element represents the location of the service, so there's no
need to represent it in a message, but the SOAP binding specifies that all other information
is to be included in the Header
of the SOAP message. So this endpoint might
receive a SOAP message of:
<SOAP-ENV:Envelope> <SOAP-ENV:Header> <tns:resourceID>DataChunk42</tns:resourceID> <tns:expires>32000</tns:expires> </SOAP-ENV:Header> <SOAP-ENV:Body> ... </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Now, this isn't the only information that WS-Addressing specifies. It also defines
Message Information Headers, or specific bits of information about a message that
also get included in the SOAP header. For example, we could specify that this message
was from http://www.example.com/clients/someClient
, and that the reply should go to
http://www.example.com/clients/someOtherClient
. We could even send any faults to yet
a third endpoint. We can also specify an action, which is similar to the old SOAPAction
header:
<SOAP-ENV:Envelope> <SOAP-ENV:Header> <wsa:MessageID>msgid:1234567902282223</wsa:MessageID> <wsa:To>http://www.example.com/services/someService</wsa:To> <wsa:Action>http://www.example.com/someAction</wsa:Action> <wsa:From>http://www.example.com/clients/someClient</wsa:From> <wsa:ReplyTo><wsa:Address>http://www.example.com/clients/someOtherClient</wsa:Address></wsa:ReplyTo> <wsa:FaultTo><wsa:Address>http://www.example.com/clients/yetAnotherClient</wsa:Address></wsa:FaultTo> <tns:resourceID>DataChunk42</tns:resourceID> <tns:expires>32000</tns:expires> </SOAP-ENV:Header> <SOAP-ENV:Body> ... </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Notice that the ReplyTo
and FaultTo
are endpoint references, and not simple
URIs. When we send a response, we put some of this information to use:
<SOAP-ENV:Envelope> <SOAP-ENV:Header> <wsa:MessageID>msgid:1234567902282429</wsa:MessageID> <wsa:RelatesTo>msgid:1234567902282223</wsa:RelatesTo> <wsa:To>http://www.example.com/clients/someOtherClient</wsa:To> <wsa:Action>http://www.example.com/someOtherAction</wsa:Action> <wsa:From> <wsa:Address>http://www.example.com/services/someService</wsa:Address> <wsa:ReferenceProperties> <tns:resourceID>DataChunk42</tns:resourceID> </wsa:ReferenceProperties> <wsa:ReferenceParameters> <tns:expires>32000</tns:expires> </wsa:ReferenceParameters> </wsa:From> </SOAP-ENV:Header> <SOAP-ENV:Body> ... </SOAP-ENV:Body> </SOAP-ENV:Envelope>
In this case, the RelatesTo
element serves to tie the two messages together, and
the From
element represents an endpoint reference.
Message Information Headers include the following:
To
: This is the destination of the message, and is required.Action
: Expressed as a URI, this property is required.MessageID
: The message id is only required if you are usingReplyTo
orFaultTo
.RelatesTo
: When used in a reply, this property ties the message back to the original request. Other possible roles may be defined for this element using theRelationshipType
attribute..ReplyTo
: This optional property contains an endpoint reference for the endpoint that is to receive the reply, if any. If this element is not present, the reply is sent back to the original requestor.From
: Optional, this property refers to the endpoint reference of the requestor of the current message.FaultTo
: Represents the destination endpoint reference for any faults generated by the operation.
WS-Addressing generally enhances WSDL, and is designed to work with it. For example, the WSDL file can contain references to WS-Addressing elements, and vice versa.