2 SOAP/WS-* And REST: Complementary Communication Styles Mark Rees Microsoft Services New Zealand Session Code: ARC 306.

2

SOAP/WS-* And REST:Complementary Communication Styles

Mark ReesMicrosoft Services New Zealand

Session Code: ARC 306

3

SOAP, WS-*, and WCF

REST and WCF

Comparing SOAP/WS-* and REST: Making the Right Choice

Agenda

4

Web Services Today

Two approaches to Web servicesare in use today

SOAP and the WS-* specificationsRepresentational State Transfer (REST)

There is some competition between proponents of each approachBeginning with the .NET Framework 3.5, Windows Communication Foundation (WCF) provides built-in support for both

Microsoft is agnostic in this debate

5

WCF Service

WCF Client

HTTP, TCP, MSMQ, etc.

Transport Channel

Transport Channel

Channel A

Channel B

Channel C

Channel A

Channel B

Channel C

WCF Communication BasicsChannels

WCF communication relies on channelsChannels can be grouped into channel stacksThe lowest channel in a stack is always the transport channel

6

WCF Communication BasicsBindings

A WCF interface is associated with one or more bindingsEach binding creates a channel stack with specific functions

Binding 3Binding 1 Binding 2

WCF Service[ServiceContract]interface IExampleB{. . .}

[ServiceContract]interface IExampleA{. . .}

Transport Channel X

Channel A

Transport Channel X

Channel C

Transport Channel Y

Channel B

Channel C

Channel A

Channel B

7

SOAP/WS-* And WCF

8

POST /AccountAccess/Accounts.svcHost: www.quickbank.comSOAPAction: GetBalance…<soap:Envelope xmlns:soap= … <soap:Body> <GetBalance xmlns= … <Account>2</Account> </GetBalance> </soap:Body></soap:Envelope>

WCF Client

WCF Service

Account 1

Account 2

Account 3

Access Via SOAPIllustrating the approach

9

Access Via SOAPA WCF interface

[ServiceContract]interface IAccount{ [OperationContract] int GetBalance(int account);  [OperationContract] int UpdateBalance(int account, int amount);}

Indicates that this interface should be exposed a

a service

Indicates that this method should be exposed as a

remotely callable operation

10

Access Via SOAPA WCF binding

<endpoint address="http://www.qwickbank.com/AccountAccess/

Accounts.svc" contract=“AccountApp.IAccount" binding="basicHttpBinding“ />

Specifies where the service can be found

Specifies theservice’s interface

Specifies the binding that should be used to talk to the service

11

BasicHttpBinding

HTTP Transport (Text Message

Encoding)

Channel

WCF Application

WCF Binding For SOAPUsing HTTP

Sends standard XML SOAP messages

over HTTP

12

Describing WS-*Messaging and security

MessagingWS-Addressing: Allows using SOAP over any transport protocol, not just HTTPMessage Transmission Optimization Mechanism (MTOM): Allows sending binary data efficiently

SecurityWS-Security: Defines a way to convey various security tokens and moreWS-Trust: Defines how to request and receivesecurity tokensWS-SecureConversation: Allows establishing a security context, e.g., for more efficient encryption

13

Describing WS-*Reliability, transactions, policy, and metadata

ReliabilityWS-ReliableMessaging: Allows reliable end-to-end communication through SOAP intermediaries

TransactionsWS-AtomicTransaction, WS-Coordination: Define howto do two-phase commit for ACID transactions

PolicyWS-Policy: Allows defining policies in various areas, e.g., security policies with WS-SecurityPolicy

Acquiring interface definitionsWS-MetadataExchange: Allows accessing a service’s WSDL definition and more

14

WSHttpBinding

WCF Application

Reliable Session

Symmetric Security

Channel

Transaction Flow

HTTP Transport (Text Message

Encoding)

WCF Binding For SOAP/WS-*Using HTTP

Implements WS-AtomicTransaction

Implements WS-ReliableMesssaging

Implements WS-Security

15

WSTcpBinding

WCF Application

Reliable Session

Symmetric Security

Channel

Transaction Flow

TCP Transport (Binary Message

Encoding)

WCF Binding For SOAP/WS-*Using TCP

Sends binary SOAP messages over TCP

16

Access Via SOAP/WS-*Specifying WCF bindings

Using WS-Security, WS-ReliableMessaging, and/or WS-AtomicTransaction with WSHttpBinding or WSTcpBinding requires configuring the binding correctly

These configurations can get complicatedEspecially for securityWCF’s Configuration Editor Tool (SvcConfigEditor.exe) helps some

17

WS-* In The Real World

WCF isn’t yet the dominant technologyfor Web services on Windows

Which makes the WS-* technologies lesswidely available

Cross-vendor interoperability for SOAP and the WS-* technologies isn’t perfect

Developers expect types to move unchanged from .NET to XML to Java (and back), which is hard

18

REST And WCF

19

WCF Service

GET www.quickbank.com/Accounts/2

Account 1

Account 2

Account 3

Access Via RESTIllustrating the approach

WCF Client

20

Defining RESTAn architectural style

Two core principlesEverything is accessed through a uniform interfaceAll data is identified with a URI

Some subsidiary principlesBe cacheable whenever possibleBe statelessMore . . .

A first-rate description of RESTRESTful Web Services, by Leonard Richardson and Sam Ruby

21

Access Via RESTA WCF interface[ServiceContract]interface IAccount{ [OperationContract] [WebGet] int GetBalance(string account);  [OperationContract] [WebInvoke] int UpdateBalance(string account, int amount);}

Sends request using HTTP GET

Sends request using HTTP POST (by default)

22

The Semantics Of HTTP VerbsA closer look

REST typically depends on HTTP’s verbsPrimarily GET, PUT, POST, and DELETE

The semantics of some, e.g., GET, are well-definedThe semantics of POST are less clear

From the HTTP 1.1 spec:POST is designed to allow a uniform method to cover the following functions:

- Annotation of existing resources; - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; - Providing a block of data, such as the result of submitting a form, to a data-handling process; - Extending a database through an append operation.

The actual function performed by the POST method is determined by the server ...

23

WCF Support For RESTSpecifying verbs and data formats

The Method parameter for WebInvoke allows specifying HTTP verbs other than POST, e.g.,:[WebInvoke(Method="PUT")]

The ResponseFormat parameter for WebGet and WebInvoke allows specifying how information is sent:

XML (the default)JavaScript Object Notation (JSON)Binary

24

WCF Support For RESTWorking with URIs

RESTful communication typically requires workingwith lots of URIs

Every resource has its own URIURIs for a particular application commonly havea common format

Such as Accounts/<number>URI templates can make it easier to work with large numbers of similar URIs, providing

A way to express URI patternsSupport for working with URIs that match those patterns

25

Access Via RESTSpecifying a WCF binding

The configuration is fairly simple:Specify binding=“webHttpBinding”Set the webHttp behavior for this endpoint

Alternatively, an application can use WebServiceHost instead of ServiceHost

This defaults to webHttpBinding with the webHttp behaviorNo configuration is needed

26

WebHttpBinding

WCF Application

Channel

HTTP Transport (Web Message

Encoding)

WCF Binding For RESTUsing HTTP

Sends XML, JSON, or binary data

over HTTP

27

Truth In Naming

Calling SOAP-based services “Web services” makes no sense

It has little to do with Web technologies

REST-based services truly deserve the name “Web services”

They’re entirely based on Web technologies:HTTP and URLs

28

Comparing SOAP/WS-* And REST:Making The Right Choice

29

Areas For Comparison

Exposing operations vs. exposing resourcesSOAP/WS-* and REST emphasize different things

CapabilitiesSOAP/WS-* and REST provide different functions

30

Operations Versus ResourcesWhat is exposed?

REST Focused on accessing named resources(which usually means data) Every application exposes its data throughthe same interface

SOAP Focused on accessing named operations, each of which implements some logicDifferent applications provide different functionality, and so each one has a different interface

31

RESTful Data AccessAmazon’s Simple Storage Service (S3)

S3 allows storing Objects in BucketsMuch like storing files in directories

Example operations:GET Object: Returns the contents of this objectGET Bucket: Returns a list of objects in this bucketPUT Object: Creates a new objectPUT Bucket: Creates a new bucketDELETE Object: Deletes an objectDELETE Bucket: Deletes a bucket

32

RESTful Data AccessThe benefits of caching

For many (most?) services, the majority of client requests are reads

In a RESTful service, all reads rely on HTTP GET

The results of a GET are commonly cachedThis can allow better performance and more scalability for RESTful services exposed overthe Internet

33

SOAP-based Operation AccessThe banking interface shown earlier

A service for banking functions might include operations such as

GetBalance(Account)UpdateBalance(Account, Amount)

These work well with either REST or SOAPSuppose the interface must also include

Transfer(FromAccount, ToAccount, Amount)This doesn’t map well to REST’s data-oriented model

It’s exposing logic, not data access

34

SOAP/WS-* and RESTA capability summary

Conveying security tokens WS-Security HTTP, SSL

Protocol for invoking operations SOAP HTTP

Transport protocol HTTP, TCP, others HTTP

Language for describing interfaces

WSDL No standard

Acquiring security tokens WS-Trust No standard

Establishing a security context WS-SecureConversation SSL

Providing end-to-end reliability WS-ReliableMessaging No standard

Supporting distributed ACID transactions

WS-AtomicTransaction, WS-Coordination

No standard

Defining policy WS-Policy, et al. No standard

Acquiring interface definitions WS-MetadataExchange No standard

SOAP/WS-* REST

35

Broad Standardization Versus Keep it SimpleTwo views of the world

Broad standardizationProvides a wide range of functionalityAllows interoperability, since everyone providesthe capability in the same wayIncreases the odds of correct implementation, since each vendor implements (and tests) the capability once rather than each application developerdoing it

Keep it SimpleYou probably won’t need it, so keep things simple

36

SecurityREST

RESTful services commonly use HTTPS

Standards for carrying security tokensHTTP for username/passwordSSL for X.509 certificates

This is sufficient for many scenarios

37

SecuritySOAP/WS-*

SOAP-based services can use HTTPSStandards for carrying security tokens

WS-Security forUsername/passwordX.509 certificateSAML tokenKerberos ticket

WS-Security also defines how to useXML Signature for integrityXML Encryption for privacy

WS-Trust definesHow to acquire security tokens

38

TransactionsUsing WS-AtomicTransaction

ACID transactions that span multiple applications and/or databases are an important part of enterprise computing

They’re not all that common, but they’restill important

ACID transactions don’t usually make sense across the Internet

They’re mostly used within an enterpriseWS-AtomicTransaction addresses this problem

It relies on WS-Coordination

39

TransactionsA simplified WS-AtomicTransaction example

Java EE

Browser1) Submit request 3) Invoke operation via SOAP, conveying

transaction context as defined by WS-Coordination

.NET Framework

2) Update .NET Application

4) UpdateEJB Application

Internet

Transaction Coordinator

5) Perform two-phase commit as defined by WS-Atomic Transaction

Transaction Coordinator

40

Reliability

RESTAssumes the application deals with communication failures via application retries

SOAP with WS-ReliableMessagingBuilds acknowledgement/retry logic into the communications stackCan provide end-to-end reliability through one or more SOAP intermediaries

41

Making A ChoiceSOAP/WS-* or REST?

Neither is right for every situationEach has its place

Some questions to ask:Does the service expose data or logic?

REST can be a good choice for exposing dataSOAP/WS-* can be better for exposing logic

Does the service need the capabilities of WS-*, or is a simpler RESTful approach sufficient?What’s best for the developers who will build anduse the service?

SOAP’s operation-oriented approach will feel more natural to many

42

Conclusion

Both SOAP/WS-* and REST have good futures

WCF supports both

The best decisions come from reason,not emotion

43

For Further Reading

Dealing with Diversity: UnderstandingWCF Communication Options in the .NET Framework 3.5

http://www.davidchappell.com/articles/white_papers/WCF_Diversity_v1.0.docx

44

Q & A

45

Resources

www.microsoft.com/teched Tech·Talks Tech·Ed BloggersLive Simulcasts Virtual Labs

http://microsoft.com/technet

Evaluation licenses, pre-released products, and MORE!

http://microsoft.com/msdn

Developer’s Kit, Licenses, and MORE!

46

Please complete anevaluation

47

© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED

OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.