Dec 7, 2007 Can you read this? If not, please sit closer. Thank you.

Request doSomeWork Response T14:08:55 Something here XML RPC (1998)

<soap-env:envelope soap-env:encodingStyle=" xmlns:soap-env=" xmlns:soap-enc=" xmlns:xsd=" xmlns:xsi=" <soap-env:Envelope soap-env:encodingStyle=" xmlns:soap-env=" xmlns:soap-enc=" xmlns:xsd=" xmlns:xsi=" Something here Early SOAP (2000) section 5 encoding

SOAP fancy encoding rules My Life and Work Henry Ford References: Sparse arrays: Third row, third col Eighth row, third col

<soap-env:envelope soap-env:encodingStyle=" xmlns:soap-env=" xmlns:xsd=" xmlns:xsi=" … your XML Schema compliant document goes here … Document/literal (2003): Forget all the fancy encoding rules

<soap-env:envelope soap-env:encodingStyle=" xmlns:soap-env=" xmlns:soap-enc=" xmlns:xsd=" xmlns:xsi=" … XML Schema compliant value… … … XML Schema compliant value… … I want my, I want my RPC (rpc/literal) Namespace does not have to be the same as the parameter values Argument elements dont even have a namespace Lets you model procedure calls, but cant validate SOAP body with an XML Schema

SOAP encoding convention line-up circa RPC/encoded (the original) 2.Document/literal (based on XML Schema, but doesnt model RPC) 3.RPC/literal (adds RPC modeling, breaks XML Schema validation) Cant we model RPC without breaking Schema validation?

Wrapped document literal style (2005) <soap-env:envelope soap-env:encodingStyle=" xmlns:soap-env=" xmlns:soap-enc=" xmlns:xsd=" xmlns:xsi=" … … Entire body complies with an XML Schema containing element doSomething containing a sequence of elements foo and bar

Handy summary SchemeRatingWhy? rpc/encoded (1998) BAD Because encoded means section 5 encoding and that hairy scheme has been displaced by XML Schemas doc/literal (2003) BEST Send an XML Schema compliant document, get one back. Awesome. rpc/literal (2003) BADFailed attempt to reconcile document style with RPC. wrapped/literal (2005) GOODSuccessful attempt to reconcile document style with RPC.

Web Service Definition Language (WSDL 1.1)... Wrapped style. Notice the operation has one message part called parameters which is an XML sequence of the args

WSDL IS IMPORTANT

Code first / WSDL first decision algorithm Will other projects be using these services? i.e. is this part of an SOA? Yes Write WSDL first. Think through interfaces carefully, plan for backward compatibility, write lots of comments, and maintain in source control. No Are you in a great hurry? Yes Write code first and use doc/literal style. i.e. Every method has one arg. Use annotations to name everything and review WSDL afterward. No Write code first in wrapped/literal style, i.e. Use annotations to name everything and review WSDL afterward.

Goodies WS-Security (message integrity, confidentiality, and authentication) WS-ReliableMessaging WS-Routing (messaging patterns and routes) WS-Eventing (pub/sub) Many other incomprehensible extensions, collectively referred to as WS-*

The SOAP way of thinking

In the meantime…

Will SOAP collapse under its own weight?

Complexity LowHigh SOAP REST ?

Comparison points WSDL is a good idea for both SOAP and REST (not a long-term differentiator) SOAP and REST both allow you to name resources with URIs (also not a long-term differentiator) REST adds value to the entire web (we dont care) REST is easier to program (not for long) SOAP provides better support for async messaging SOAP is better if developers and network administrators dont have a good relationship

In conclusion For enterprise apps, default to SOAP. But if (like Amazon.com) you are catering to people who are not making a large investment in connecting to your service have control over your network are trying to reach a broad audience … then go with REST. Expires: Mon, 31 Mar :00:00 GMT

Questions?