Working with WCF Demonstration and Perspectives 2008 IDesign
Inc. All rights reserved Juval Lowy IDesign Ron Jacobs
Microsoft
Slide 2
About Juval Lwy Software architect Consults and trains on.NET
3.0 architecture Microsoft's Regional Director for the Silicon
Valley Authored Programming WCF Services 2 nd Edition (2008,
OReilly) Programming.NET Components (2003,2005, OReilly)
Participates in the.NET/WCF design reviews Publishes at MSDN and
other magazines Recognized Software Legend by Microsoft Contact at
www.idesign.net
TimeTopicPresenter(s) 3:25pImplementing RESTful Services with
WCF Part 1: Concepts and Intro Ron Jacobs / Rob Bagby 4:25pBreak
4:30pImplementing RESTful Services with WCF Part 2: Implementation
in Depth Ron Jacobs / Rob Bagby 5:30pBreak 5:35pWorkflow Services
DemoRon Jacobs 5:45p
Slide 5
Objectives Motivation for SOA and WCF Understand WCF
fundamentals Share the power and productivity of WCF Demonstrate
WCF as a Better.NET Enable educated decisions Assess benefits and
advantages Focus on key system features
Slide 6
Why Service-Orientation
Slide 7
Where is.NET? The good Component-orientation provided
interchangeable interoperable binary components Interface-based
reuse and polymorphism Metadata type sharing Dynamic loading
Cleaned-up COM
Slide 8
Where is.NET? The bad Code coupled to Technology and platform
Concurrency management Transactions Communication protocols The
plumbing crisis Communication patterns Versioning Security
Slide 9
Service Oriented Architecture SOA is to the best of our
knowledge the best way to build distributed, maintainable, robust
and secure applications Maintainable Decouples the right aspects
Extensible Reusable Productive
Slide 10
SOA Benefits Inside services Languages Technologies Platforms
Versions Between services Standards Policies Contracts Messages
exchange Service
Slide 11
SOA Benefits Decoupled application Reduced assumptions Changes
are contained SO application is internally decoupled Location
independent Local or remote accessed the same way
Slide 12
SOA Benefits Crossing boundaries Technological boundary
Platform boundary Security and trust boundary Geographical boundary
Organizational boundary Time-line boundary Transaction boundary
Business model boundary Team boundary Industry and domain
boundary
Slide 13
Service-Oriented Applications
Slide 14
A service is a unit of functionality exposed to the world Over
standard plumbing SO application Aggregates services into a single
logical application May define and expose new functionality as
services
Slide 15
Service-Oriented Applications Services can be Local or remote
From multiple parties Developed using any technology Versioned
independently Execute on different timelines Application
Service
Slide 16
Service-Oriented Programming
Slide 17
Windows Communication Foundation WCF is an SDK for building SOA
on Windows Service execution runtime Released with Windows Vista
Part of.NET 3.0 Requires.NET 2.0 Available also on Windows XP SP2
Windows Server 2003 Windows Server 2008
Slide 18
Windows Communication Foundation Built on top of the CLR
Exposing CLR types as services Similar to ATL and COM/C++ Consume
services as CLR types Microsoft's implementation of set of industry
standards defining service interactions Type conversion and
marshaling Protocol management
Slide 19
Windows Communication Foundation Provides Interoperability
Based on industry standards Productivity and quality Essential
off-the-shelf plumbing Extensibility System.ServiceModel.dll
System.ServiceModel namespace
Slide 20
Windows Communication Foundation Services send and receive
messages All messages are SOAP messages Usually Not necessarily web
services Not necessarily over HTTP Messages may go directly from
client to service or via an intermediary WCF services may
interoperate with non-WCF services May also require both endpoints
to be WCF
Slide 21
Windows Communication Foundation Can communicate across all
execution boundaries Always use a proxy Same machine Same app
domain Cross app domain in same process Cross process Cross machine
Intranet calls Internet calls
Slide 22
Windows Communication Foundation Process A App Domain 1 Service
Client Process B App Domain 3 Proxy Client App Domain 2 Proxy
Client Proxy
Slide 23
Windows Communication Foundation Machine A Process 1 Service
Machine B Process 2 Proxy Client WWW Machine C Process 3 Proxy
Client
Slide 24
Addresses
Slide 25
Every service is associated with a unique address Address is
the location of the service Address provides Transport protocol to
use Name of target machine, site or network Communication port,
pipe or queue Specific path or URI
Slide 26
Addresses Address format [base address]/[optional URI] Base
address format [transport]://[domain][:optional port] Examples
http://localhost:8001 http://localhost:8001/MyService
net.tcp://localhost:8002/MyService net.pipe://localhost/MyPipe
net.msmq://localhost/private/MyQueue
net.msmq://localhost/MyQueue
Slide 27
Service Contract
Slide 28
ServiceContract attribute Interface/class Independent of
visibility Opt-in model Other types not included
[AttributeUsage(AttributeTargets.Interface|AttributeTargets.Class,
Inherited = false)] public sealed class ServiceContractAttribute :
Attribute { public string Name {get;set;} public string Namespace
{get;set;} //More members }
Slide 29
Service Contract OperationContract attribute Methods only No
properties/indexers/events Independent of visibility Opt-in model
Other methods not included
[AttributeUsage(AttributeTargets.Method)] public sealed class
OperationContractAttribute : Attribute {...}
Slide 30
Service Contract [ServiceContract] interface IMyContract {
[OperationContract] string MyMethod(string text); } class MyService
: IMyContract { public string MyMethod(string text) { return "Hello
" + text; } Service class looks like any regular.NET class
Slide 31
Windows Communication Foundation WCF is the new.NET More like
the new C#/VB Superior way of building systems
Slide 32
Hosting
Slide 33
WCF services must be hosted in a process Called host process
Single host process can host multiple services Host may or may not
be the client process
Slide 34
Hosting Separate host process can be provided by IIS 5/6
Windows Activation Service (WAS) The developer Called self-hosted
In-proc must be self hosted Option for inter-app domain as
well
Slide 35
Self Hosting For separate process from client or in-proc
Developer provides a process Windows Forms application WPF
application WF application Console application Windows NT service
Process must be running before client calls service Non-issue for
in-proc
Slide 36
Self Hosting Application config file usually lists service's
type Use fully-qualified type name...
Slide 37
Self Hosting Host process must explicitly register service type
and open host Typically in Main() public interface
ICommunicationObject { void Open(); void Close(); void Abort();
//More members } public abstract class CommunicationObject :
ICommunicationObject {...} public abstract class ServiceHostBase :
CommunicationObject,IDisposable,... {...} public class ServiceHost
: ServiceHostBase { public ServiceHost(Type serviceType,params
Uri[] baseAddresses); //More members }
Slide 38
Self Hosting static void Main() { ServiceHost host = new
ServiceHost(typeof(MyService)); host.Open(); //Can do blocking
calls: Application.Run(new MyForm()); host.Close(); }
Slide 39
WAS Hosting Windows Activation Service Can be used separately
from IIS7 System service Vista/Windows 2008 only Supply a.svc file
similar to IIS Configure application pool Can use any protocol and
port One-time server configuration cost Can be scripted
Slide 40
WAS Vs. Self-Hosting WAS need not be running before client
calls System service Self-host must be running before requests come
in WAS offers Idle time management Identity management Application
pooling Isolation Choose WAS whenever possible Maximize
manageability and availability
Slide 41
Binding
Slide 42
Why Bindings Many possible communication patterns Synchronous
request/reply Asynchronous fire-and-forget Bidirectional Duplex
Queued and disconnected Volatile or durable queues Many possible
transport protocols HTTP HTTPS TCP P2P IPC MSMQ
Slide 43
Why Bindings Many possible message formats and encoding Plain
text Binary MTOM Many ways of securing messages No security
Transport security Message security Authenticating and authorizing
callers
Slide 44
Why Bindings Many degrees of message delivery reliability No
reliability End-to-end reliability Ordered/unordered Multiple
options of transaction management Using client's transaction Using
service-side transaction Transaction protocols
Slide 45
Why Bindings Many options for interoperability Basic web
services WS-* WCF MSMQ
Slide 46
Bindings A simple way of wrapping multiple aspects of
communication Protocols Format and encoding Security Reliability
Transaction propagation Interoperability Extract all of that out of
your code Use a pre-defined template Can customize Can write custom
bindings from scratch
Slide 47
Bindings Service publishes its binding in metadata Service can
support multiple bindings On separate addresses Services do not
care about binding Can constrain binding Nothing in service code
pertains to binding Client must use exactly same binding as
service
Slide 48
Bindings WCF defines 6 frequently-used bindings Basic TCP Named
Pipe WS Can customize standard bindings Can define custom bindings
Duplex WS MSMQ
Slide 49
Bindings Transport and encoding
Slide 50
Bindings Selecting a binding WCF To WCF [no] [yes] Legacy ASMX
Client [no] [yes] BasicWS Disconnected Calls [no] [yes] MSMQ Cross
Machine [no] [yes] Named Pipes TCP
Slide 51
Endpoints
Slide 52
Every services has Address Binding Contract A ddress Where the
service is B inding How to talk to the service C ontract What the
service can do
Slide 53
Endpoints Endpoint is the fusion of the address, binding and
contract Every endpoint must have all three Logically, endpoint is
the service's interface AddressContract Binding
Slide 54
Endpoints Every service must expose at least one endpoint Each
endpoint has exactly one contract All endpoints should have unique
addresses Single service can expose multiple endpoints Can use same
or different bindings Can expose same or different contracts
Service
Slide 55 ">
Administrative EP Configuration Option of choice in the
majority of cases Application App.Config IIS/WAS Web.Config Add
under each service its endpoints
Slide 56 ">
Administrative EP Configuration Multiple endpoints on same
service
Slide 57
Administrative EP Configuration Can customize standard bindings
Use bindingConfiguration tag in endpoint Name customized section in
the bindings section Can be used by all endpoints Example Enabling
transaction propagation
Slide 58 ">
Slide 59
WCF Clients
Slide 60
Client-Side Programming Client needs.NET types representing
service contracts And types In same solution Can reference
contracts assembly Can import and convert metadata to.NET types
Client uses a proxy to consume the service Tools-generated proxy
file contains both proxy and contracts
Slide 61
Client-Side Programming The proxy.NET interface and class
representing the service Provides same operations as service Has
additional methods for managing the proxy and the connection Proxy
encapsulates the service Location Technology Platform
Transport
Slide 62
Client-Side Programming
Slide 63
For this contract definition: [ServiceContract] interface
IMyContract { [OperationContract] void MyMethod(); } class
MyService : IMyContract { public void MyMethod() {...} }
Slide 64
//Metadata-generated code in Proxy.cs - partial listing
[ServiceContract] interface IMyContract { [OperationContract] void
MyMethod(); } class MyContractClient : ClientBase,IMyContract {
public MyContractClient() {} public MyContractClient(string
endpointConfigurationName) : base(endpointConfigurationName) {}
public MyContractClient(Binding binding,EndpointAddress
remoteAddress) : base(binding,remoteAddress) {} /* Additional
constructors */ public void MyMethod() { Channel.MyMethod(); }
Slide 65
Client-Side Programming Proxy file has no reference to the
service implementing class Contract only Proxy can be used in
conjunction with a config file Proxy can be used without a config
file Each proxy instance points at exactly one endpoint Provided at
construction time
Slide 66 ">
Client-Side Programming Client needs to Know where the service
is Use same binding as service Import service metadata and consume
contract Service may or may not be WCF In essence same info as in
the service endpoint
Slide 67 ">
Administrative Client Configuration
Slide 68
Client-Side Programming Client needs to instantiate proxy
object Provide constructor with endpoint Endpoint section name from
config file Endpoint address and binding objects Use service
methods Close proxy instance MyContractClient proxy = new
MyContractClient("MyEndpoint"); proxy.MyMethod();
proxy.Close();
Slide 69
Programmatic Client Configuration Client code will be Binding
wsBinding = new WsHttpBinding(); EndpointAddress endpointAddress =
new EndpointAddress("http://localhost:8000/MyService/");
MyContractClient proxy = new
MyContractClient(wsBinding,endpointAddress); proxy.MyMethod();
proxy.Close();
Slide 70
WCF Architecture
Slide 71
Interception-based Client always interacts with a proxy Proxy
serializes stack frame to message and sends message down chain of
channels Structure of chain depends on binding and behaviors
Slide 72
WCF Architecture Each client-side channel does pre-call
processing of message Encoding Security credentials and privacy
Transaction propagation Encryption Reliability and session Queuing
Last channel on the client side is the transport channel Sends
message over transport to host
Slide 73
WCF Architecture First channel on host side is the transport
channel Receives message from transport Message passed through
chain of channels Channels do pre-call processing Decryption
Transaction settings Decoding Last channel on host side passes
message to dispatcher Dispatcher Converts message to stack frame
Calls object
Slide 74
Client Proxy Channel Service Endpoints Dispatcher Channel
Transport Channel Channel Transport Channel WCF Architecture
Slide 75
Call returns to dispatcher that converts it to a returned
message Pass message back up host and client chains Post-call
processing Proxy converts returned message to stack frame Control
returns to client Almost all points in the architecture provide
hooks for custom channels Extensibility Security Proprietary
Slide 76
Interception Demo Calls must complete within a configurable
timeout TimeoutException otherwise SendTimeout property of binding
Default is one minute public abstract class Binding :... { public
TimeSpan SendTimeout {get;set;} //More members }
Interception Demo Tracing and logging Can propagate and trace
activity IDs Can interleave entries Built-in viewer
Slide 80
Errors and Exceptions Service can encounter errors in execution
Error handling is a local implementation detail Should not affect
client Client may not care Client may not have anything meaningful
to do Service should continue operating in face of errors Services
are autonomous Host is not terminated even if service has unhandled
exception Client should not be able to keep using service
instance
Slide 81
Errors and Exceptions Avoid Error codes Custom exceptions Fault
contracts WCF masks all errors to FaultException If client required
to be coupled to specific faults Use fault contracts Promote
downstream exceptions
Slide 82
Reliability
Slide 83
End-to-end guaranteed delivery and order Across intermediaries
Multiple hops Retries in face of transport failures Dropping
wireless connections Network maintenance Congestion and flow
control Connection verification and cleanup
Slide 84
Ordered Messages Ordered delivery assurance Messages delivered
exactly once, in same order as were sent Resilient to transport
disconnections and SOAP intermediary failures Non-ordered Calls
delivered in order they were received
Slide 85 "> "> " title="Reliability ">
Reliability
Slide 86
Data Contracts
Slide 87
WCF operations accept and return CLR types CLR types are
technology specific Cannot be exposed across service boundaries
Need a formal way of converting CLR types to and from neutral
representation XML schema Formal way is a contract called data
contract Data contract is part of contractual behavior Included
with MEX
Slide 88
Serialize in-parameters Deserialize in-parameters Message
transport to service Execute operation Serialize out-parameters
Deserialize out-parameters Return message to client
Slide 89
Data Contracts [DataContract] struct Contact { [DataMember]
public string FirstName; [DataMember] public string LastName; }
[ServiceContract] interface IContactManager { [OperationContract]
void AddContact(Contact contact); [OperationContract] Contact[]
GetContacts(); }
Slide 90
Data Contract Equivalence //This data contract is equivalent to
Contact before [DataContract(Name = "Contact")] struct Person {
[DataMember(Name = "FirstName")] public string Name;
[DataMember(Name = "LastName")] public string Surname; } //Client
side imported definition //same as before
Slide 91
Versioning Tolerance By default data contracts are versioning
tolerant Most common change is adding new members Service can
accept data with new members not part of original contract Ignores
new members Service can return data with new members not part of
contract Client ignores new members
Slide 92
Versioning Tolerance By default can remove members from
contract Missing members will be deserialized to their default
value null for reference type Zero whitewash for value type Service
can accept data with missing members Default values Service can
return data with missing members Client gets default values
Slide 93
Versioning Round Trip Ignoring new members and defaults missing
ones is sub optimal No support for pass-through scenarios Client
Service A Service B Client Service C Sends Knows About Data
Member
Slide 94
Instance Management
Slide 95
Which service instance handles client request No one-size fits
all Applications differ too much in their need for Scalability and
throughout Performance Transactions Queued calls App needs to be
smart about Way it handles service instances Idle time
management
Slide 96
Instance Management Per-call A new service instance created and
destroyed for every call Session-full services Service instance per
client Singleton All clients get same service instance Implicitly
shared
Slide 97
Singleton Service All clients connected to same single instance
Regardless of endpoints Lives forever Created when host is
launched
Slide 98
Singleton Service Host Process App Domain Client Process App
Domain Proxy Client WWW Client Process App Domain Proxy Client
Singleton
Slide 99
Singleton Service [ServiceBehavior(InstanceContextMode =
InstanceContextMode.Single)] class MySingleton :... {...}
InstanceContextMode.Single
Slide 100
Durable Services Long-running workflows or execution sequences
Days or weeks Clients may connect, do some work and disconnect
Clients also may end workflow Little point in keeping proxies and
hosts in memory Not robust enough Not scalable enough
Unmanageable
Slide 101
Durable Services Solution Do not keep service state in memory
At every operation Get state from configurable durable storage Do
requested work Save state back to durable store [Serializable]
[DurableService] class MyService : IMyContract { public void
MyMethod() { //Do work }
Slide 102
Faults
Slide 103
Faults Management Service masks out all its exceptions Best
practice for decoupling Unhandled exceptions are isolated
Process-level isolation same-process client Channel is faults
Cannot catch and keep using instance Best practice
Slide 104
Concurrency Management
Slide 105
Service Thread Safety Incoming calls are dispatched on threads
from thread pool Service instance can sustain multiple concurrent
calls Must provide correct thread affinity when required
Slide 106
ConcurrencyMode.Single Automatic synchronization Disallows
concurrent calls WCF associates instance with a lock Allows only
one caller at a time Pending callers placed in a queue Served FIFO
Caller can timeout at the queue TimeoutException Timeout controlled
in binding Defaults to 1 minute
Slide 107
ConcurrencyMode.Single The WCF default These are equivalent
[ServiceContract] interface IMyContract {...} class MyService :
IMyContract {...} [ServiceBehavior(ConcurrencyMode =
ConcurrencyMode.Single)] class MyService : IMyContract {...}
Slide 108
Resource Synchronization Context Service calls execute on
worker threads Service cannot by default rely on thread affinity
Always being accessed by same thread Service cannot by default rely
executing on custom threads Some resources may rely on thread
affinity UI TLS Some resources may require their own threads When
affinity to other threads expected Service must marshal calls to
correct thread(s) resource requires
Slide 109
Resource Synchronization Context.NET 2.0 provides
synchronization contexts Assures calls execute on correct thread(s)
Typically the same single thread Supports cancellation, completion
Can be extended to support progress reports
Slide 110
UI Synchronization Context Canonical synchronization context
Service may need to update UI WPF/Windows Forms use the underlying
Win32 message loop Only the thread which created the window can
process its messages Calls on the wrong thread may result in an
exception Must marshal the call to owning thread WCF can marshal
the call automatically
Slide 111
Queued Calls
Slide 112
Client Proxy Dispatcher MSMQ Queue MSMQ Message Service MSMQ
Channel Listener Dispatcher Service
Slide 113
Queued Calls Host may be off-line Calls are dispatched once
host is launched If host is running when client posts messages Host
will start processing calls
Slide 114
Queued Calls Queued service and client look like any other
service and client [ServiceContract] interface IMyContract {
[OperationContract(IsOneWay = true)] void MyMethod(); } class
MyService : IMyContract { public void MyMethod() {
MessageBox.Show("MyMethod()","MyService"); } MyContractClient proxy
= new MyContractClient(); proxy.MyMethod(); proxy.Close();
Slide 115
Security
Slide 116
WCF Security WCF approach to security Secured by default Except
BasicHttpBinding Can be secured All other WCF binding and services
by default utilize Authentication Transfer security
Slide 117
Call Protection Level All calls are protected by default
Encrypted Can insist on protection [ServiceContract(ProtectionLevel
= ProtectionLevel.EncryptAndSign)] interface IMyContract {...}
Slide 118
WCF Security Service class can always obtain identity of its
caller Unlike classic.NET WCF also sets thread principal to
client's identity
Slide 119
Security Audit Built-in support for service-side auditing
Logging Authentication and authorization attempts Time and location
Clients identity Security audit is a service behavior
ServiceSecurityAuditBehavior
Slide 120
Transactions
Slide 121
Transaction Setting Must indicate wanting a transaction in each
method Via TransactionScopeRequired property of OperationBehavior
attribute Defaults to false If client transaction propagated Will
set client transaction as ambient Else will create new transaction
and set as ambient
Declarative Voting WCF can automatically vote on behalf of
service Commit or abort If there were no unhandled exceptions WCF
will vote to commit If unhandled exception WCF will vote to abort
Allows the exception up the call chain
Slide 124
Transaction Flow Management Can use any transactional resource
Database MSMQ Volatile Client MyService Transaction MyOtherService
TxFlow = true
Slide 125
Throttling Software systems are not elastic Yield and snap
under load Time Load X
Slide 126
Throttling Even regular load may spike Spiked load may max out
system Absolute value or rate of growth Time Load
Slide 127 ... ...
Throttling ...
Slide 128
One-Way Operations
Slide 129
Fire-and-forget calls Service executes in the background No
results or returned value possible Exception does not propagate to
client
Slide 130
One-Way Operations IsOneWay property of
OperationContractAttribute Defaults to false [ServiceContract]
interface IMyContract { [OperationContract(IsOneWay = true)] void
MyMethod(); }
TimeTopicPresenter(s) 3:25pImplementing RESTful Services with
WCF Part 1: Concepts and Intro Ron Jacobs / Rob Bagby 4:25pBreak
4:30pImplementing RESTful Services with WCF Part 2: Implementation
in Depth Ron Jacobs / Rob Bagby 5:30pBreak 5:35pWorkflow Services
DemoRon Jacobs 5:45p
Slide 134
Ron Jacobs Sr. Technical Evangelist Microsoft Corporation Rob
Bagby Developer Evangelist Microsoft Corporation
Slide 135
Slide 136
Slide 137
Slide 138
Slide 139
Slide 140
Slide 141
Slide 142
(response) (fault) (response) (fault)
Slide 143
Slide 144
Slide 145
Header: value body Header: value body Status code Header: value
body Status code Header: value body
TimeTopicPresenter(s) 3:25pImplementing RESTful Services with
WCF Part 1: Concepts and Intro Ron Jacobs / Rob Bagby 4:25pBreak
4:30pImplementing RESTful Services with WCF Part 2: Implementation
in Depth Ron Jacobs / Rob Bagby 5:30pBreak 5:35pWorkflow Services
DemoRon Jacobs 5:45p
Slide 159
TimeTopicPresenter(s) 3:25pImplementing RESTful Services with
WCF Part 1: Concepts and Intro Ron Jacobs / Rob Bagby 4:25pBreak
4:30pImplementing RESTful Services with WCF Part 2: Implementation
in Depth Ron Jacobs / Rob Bagby 5:30pBreak 5:35pWorkflow Services
DemoRon Jacobs 5:45p
Slide 160
Ron Jacobs Sr. Technical Evangelist Microsoft Corporation Rob
Bagby Developer Evangelist Microsoft Corporation
Enable Ajax web site for security Using Forms Auth with client
side script Enabling login with Ajax script service
Slide 186
Slide 187
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.
