Transcript PRE09: Working with WCF Demonstration and Perspectives

Juval Lowy
IDesign
Ron Jacobs
Microsoft
Working with WCF
Demonstration and Perspectives
About Juval Löwy
Software architect
Consults and trains on .NET 3.0 architecture
Microsoft's Regional Director for the Silicon Valley
Authored
Programming WCF Services 2nd Edition (2008, O’Reilly)
Programming .NET Components (2003,2005, O’Reilly)
Participates in the .NET/WCF design reviews
Publishes at MSDN and other magazines
Recognized Software Legend by Microsoft
Contact at www.idesign.net
Time
Topic
Presenter(s)
10:00a
Welcome / Agenda
Ron / Juval
10:10a
WCF Session 1
Juval
11:10a
Break
11:15a
WCF Session 2
12:15p
Lunch
1:15p
WCF Session 3
2:15p
Break
2:20p
WCF Session 4
3:20p
Break
Juval
Juval
Juval
Time
Topic
Presenter(s)
3:25p
Implementing RESTful Services with WCF
Part 1: Concepts and Intro
Ron Jacobs / Rob
Bagby
4:25p
Break
4:30p
Implementing RESTful Services with WCF
Part 2: Implementation in Depth
5:30p
Break
5:35p
Workflow Services Demo
5:45p
<End>
Ron Jacobs / Rob
Bagby
Ron Jacobs
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
Why Service-Orientation
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
Where is .NET?
The bad
Code coupled to
Technology and platform
Concurrency management
Transactions
Communication protocols
The plumbing crisis
Communication
patterns
Versioning
Security
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
SOA Benefits
Inside services
Languages
Technologies
Platforms
Versions
Between services
Standards
Policies
Contracts
Messages exchange
Service
Service
Service
Service
Service
SOA Benefits
Decoupled application
Reduced assumptions
Changes are contained
SO application is internally decoupled
Location independent
Local or remote accessed the same way
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
Service-Oriented Applications
Service-Oriented Applications
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
Service-Oriented Applications
Services can be
Local or remote
From multiple parties
Developed using any
technology
Versioned independently
Execute on
different timelines
Application
Service
Service
Service
Service
Service
Service-Oriented Programming
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
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
Windows Communication
Foundation
Provides
Interoperability
Based on industry standards
Productivity and quality
Essential off-the-shelf plumbing
Extensibility
System.ServiceModel.dll
System.ServiceModel namespace
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
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
Windows Communication
Foundation
Process A
Process B
App Domain 1
Proxy
App Domain 3
Client
Proxy
Service
Proxy
Client
App Domain 2
Client
Windows Communication
Foundation
Machine A
Machine B
Process 2
Process 1
Client
Proxy
Service
Machine C
WWW
Process 3
Proxy
Client
Addresses
Addresses
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
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
Service Contract
Service Contract
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;}
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
{...}
Service Contract
Service class looks like any regular .NET class
[ServiceContract]
interface IMyContract
{
[OperationContract]
string MyMethod(string text);
}
class MyService : IMyContract
{
public string MyMethod(string text)
{
return "Hello " + text;
}
}
Windows Communication
Foundation
WCF is the new .NET
More like the new C#/VB
Superior way of building systems
Hosting
Hosting
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
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
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
Self Hosting
Application config file usually lists service's type
Use fully-qualified type name
<system.serviceModel>
<services>
<service name = "MyNamespace.MyService">
...
</service>
</services>
</system.serviceModel>
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
}
Self Hosting
static void Main()
{
ServiceHost host = new ServiceHost(typeof(MyService));
host.Open();
//Can do blocking calls:
Application.Run(new MyForm());
host.Close();
}
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
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
Binding
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
TCP
IPC
n
n
n
HTTPS
P2P
MSMQ
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
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
Why Bindings
Many options for interoperability
Basic web services
WS-*
WCF
MSMQ
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
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
Bindings
WCF defines 6 frequently-used bindings
Basic
TCP
Named Pipe
WS
Duplex WS
MSMQ
Can customize standard bindings
Can define custom bindings
Bindings
Transport and encoding
Bindings
Selecting a binding
[no]
WCF
To
WCF
[yes]
[no]
[no]
WS
Legacy
ASMX Client
[yes]
Basic
[no]
Named
Pipes
Cross
Machine
Disconnected
Calls
[yes]
[yes]
TCP
MSMQ
Endpoints
Endpoints
Every services has
Address
Binding
Contract
Address
Where the service is
Binding
How to talk to the service
Contract
What the service can do
Endpoints
Endpoint is the fusion of the address, binding and
contract
Every endpoint must have all three
Logically, endpoint is the service's interface
Address
Contract
Binding
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
Administrative EP Configuration
Option of choice in the majority of cases
Application App.Config
IIS/WAS Web.Config
Add under each service its endpoints
<system.serviceModel>
<services>
<service name = "MyNamespace.MyService">
<endpoint
address = "http://localhost:8000/MyService/"
binding = "wsHttpBinding"
contract = "MyNamespace.IMyContract"
/>
</service>
</services>
Administrative EP Configuration
Multiple endpoints on same service
<service name = "MyNamespace.MyService">
<endpoint
address = "http://localhost:8000/MyService/"
binding = "wsHttpBinding"
contract = "MyNamespace.IMyContract"
/>
<endpoint
address = "net.tcp://localhost:8001/MyService/"
binding = "netTcpBinding"
contract = "MyNamespace.IMyContract"
/>
<endpoint
address = "net.tcp://localhost:8002/MyService/"
binding = "netTcpBinding"
contract = "MyNamespace.IMyOtherContract"
/>
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
<system.serviceModel>
<services>
<service name = "MyNamespace.MyService">
<endpoint
address = "net.tcp://localhost:8000/MyService/"
bindingConfiguration = "TransactionalTCP"
binding = "netTcpBinding"
contract= "MyNamespace.IMyContract"
/>
<endpoint
address = "net.tcp://localhost:8001/MyService/"
bindingConfiguration = "TransactionalTCP"
binding = "netTcpBinding"
contract= "MyNamespace.IMyOtherContract"
/>
</service>
</services>
<bindings>
<netTcpBinding>
<binding name = "TransactionalTCP"
transactionFlow = "true"
/>
</netTcpBinding>
</bindings>
WCF Clients
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
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
Client-Side Programming
Client-Side Programming
For this contract definition:
[ServiceContract]
interface IMyContract
{
[OperationContract]
void MyMethod();
}
class MyService : IMyContract
{
public void MyMethod()
{...}
}
//Metadata-generated code in Proxy.cs - partial listing
[ServiceContract]
interface IMyContract
{
[OperationContract]
void MyMethod();
}
class MyContractClient : ClientBase<IMyContract>,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();
}
}
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
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
<system.serviceModel>
<client>
<endpoint name = "MyEndpoint"
address = "http://localhost:8000/MyService/"
binding = "wsHttpBinding"
contract= "IMyContract"
/>
</client>
Administrative Client
Configuration
<system.serviceModel>
<client>
<endpoint name = "FirstEndpoint"
address = "http://localhost:8000/MyService/"
binding = "wsHttpBinding"
contract= "IMyContract"
/>
<endpoint name = "SecondEndpoint"
address = "net.tcp://localhost:8001/MyService/"
binding = "netTcpBinding"
contract= "IMyContract"
/>
<endpoint name = "ThirdEndpoint"
address = "net.tcp://localhost:8002/MyService/"
binding = "netTcpBinding"
contract= "IMyOtherContract"
/>
</client>
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();
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();
WCF Architecture
WCF Architecture
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
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
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
WCF Architecture
Client
Endpoints
Proxy
Channel
Channel
Channel
Channel
Transport
Channel
Transport
Channel
Dispatcher
Service
WCF Architecture
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
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
<client>
<endpoint
...
binding = "wsHttpBinding"
bindingConfiguration = "LongTimeout"
...
/>
</client>
<bindings>
<wsHttpBinding>
<binding name = "LongTimeout" sendTimeout = "00:05:00"/>
</wsHttpBinding>
</bindings>
Interception Demo
WCF provides numerous performance counters
Host
Service
Endpoint
Operation
<system.serviceModel>
<diagnostics performanceCounters = "All"/>
<services>
...
</services>
<client>
...
</client>
</system.serviceModel>
Interception Demo
Tracing and logging
Can propagate and trace activity IDs
Can interleave entries
Built-in viewer
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
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
Reliability
Reliability
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
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
Reliability
<system.serviceModel>
<services>
<service name = "MyService">
<endpoint
bindingConfiguration = "ReliableTCP"
...
/>
</service>
</services>
<bindings>
<netTcpBinding>
<binding name = "ReliableTCP">
<reliableSession enabled = "true"/>
</binding>
</netTcpBinding>
</bindings>
</system.serviceModel>
Data Contracts
Data Contracts
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
Serialize
in-parameters
Message transport
to service
Deserialize
in-parameters
Execute
operation
Serialize
out-parameters
Return
message to client
Deserialize
out-parameters
Data Contracts
[DataContract]
struct Contact
{
[DataMember]
public string FirstName;
[DataMember]
public string LastName;
}
[ServiceContract]
interface IContactManager
{
[OperationContract]
void AddContact(Contact contact);
[OperationContract]
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
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
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
Versioning Round Trip
Ignoring new members and defaults missing ones
is sub optimal
No support for pass-through scenarios
Client
Service
A
Service
B
Sends
Knows About
Data Member
Client
Service
C
Instance Management
Instance Management
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
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
Singleton Service
All clients connected to same single instance
Regardless of endpoints
Lives forever
Created when host is launched
Singleton Service
Host Process
Client Process
App Domain
App Domain
Singleton
Proxy
Client
Client Process
WWW
App Domain
Proxy
Client
Singleton Service
InstanceContextMode.Single
[ServiceBehavior(InstanceContextMode =
InstanceContextMode.Single)]
class MySingleton : ...
{...}
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
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
}
Faults
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
Concurrency Management
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
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
ConcurrencyMode.Single
The WCF default
These are equivalent
[ServiceContract]
interface IMyContract
{...}
class MyService : IMyContract
{...}
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
class MyService : IMyContract
{...}
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
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
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
Queued Calls
Queued Calls
Client
MSMQ
Queue
Dispatcher
Service
Proxy
MSMQ
Message
MSMQ
Channel
Listener
Dispatcher
Service
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
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();
Security
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
Call Protection Level
All calls are protected by default
Encrypted
Can insist on protection
[ServiceContract(ProtectionLevel =
ProtectionLevel.EncryptAndSign)]
interface IMyContract
{...}
WCF Security
Service class can always obtain identity of its caller
Unlike classic .NET
WCF also sets thread principal to client's identity
Security Audit
Built-in support for service-side auditing
Logging
Authentication and authorization attempts
Time and location
Client’s identity
Security audit is a service behavior
ServiceSecurityAuditBehavior
Transactions
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
Transaction Setting
class MyService : IMyContract
{
[OperationBehavior(TransactionScopeRequired = true)]
public void MyMethod(...)
{
Transaction transaction = Transaction.Current;
Debug.Assert(transaction != null);
}
}
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
Transaction Flow Management
Can use any transactional resource
Database
MSMQ
Volatile
Transaction
TxFlow = true
Client
TxFlow = true
MyService
MyOtherService
Throttling
Software systems are not elastic
Yield and snap under load
Load
Time
Throttling
Even regular load may spike
Spiked load may max out system
Absolute value or rate of growth
Load
Time
Throttling
<system.serviceModel>
<services>
<service name = "MyService"
behaviorConfiguration = "ThrottledBehavior">
...
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name = "ThrottledBehavior">
<serviceThrottling
maxConcurrentCalls
= "12"
maxConcurrentSessions = "34"
maxConcurrentInstances = "56"
/>
</behavior>
</serviceBehaviors>
</behaviors>
One-Way Operations
One-Way Operations
Fire-and-forget calls
Service executes in the background
No results or returned value possible
Exception does not propagate to client
One-Way Operations
IsOneWay property of
OperationContractAttribute
Defaults to false
[ServiceContract]
interface IMyContract
{
[OperationContract(IsOneWay = true)]
void MyMethod();
}
Resources
Programming WCF Services 2nd Edition
Juval Lowy, O'Reilly 2008
www.idesign.net
Code library
Coding standard
Sample architecture report
IDesign Method™
Master Classes
WCF
Architect's Master Class
Time
Topic
Presenter(s)
10:00a
Welcome / Agenda
Ron / Juval
10:10a
WCF Session 1
Juval
11:10a
Break
11:15a
WCF Session 2
12:15p
Lunch
1:15p
WCF Session 3
2:15p
Break
2:20p
WCF Session 4
3:20p
Break
Juval
Juval
Juval
Time
Topic
Presenter(s)
3:25p
Implementing RESTful Services with WCF
Part 1: Concepts and Intro
Ron Jacobs / Rob Bagby
4:25p
Break
4:30p
Implementing RESTful Services with WCF
Part 2: Implementation in Depth
5:30p
Break
5:35p
Workflow Services Demo
5:45p
<End>
Ron Jacobs / Rob Bagby
Ron Jacobs
 Ron Jacobs
Sr. Technical Evangelist
Microsoft Corporation
 Rob Bagby
Developer Evangelist
Microsoft Corporation










Why The Web Works













<headers>
<body>
(response)
(fault)





Why The Web Works
What is REST?








Header: value
body
Status code
Header: value
body
Purists

RESTfullness
Pragmatists

Querystrings OK



















Why The Web Works
What is REST?
How REST works in WCF 3.5





















Hole
[OperationContract]
[WebGet(UriTemplate=“product/{productId}")]
Product GetProduct(int productId);

[OperationContract]
[WebInvoke( Method=“PUT",
ResponseFormat=WebMessageFormat.Json,
UriTemplate=“product/{productId}")]
Product UpdateProduct(int productId, product p);
[OperationContract]
[WebGet(
ResponseFormat=WebMessageFormat.Json,
UriTemplate=“product/{productId}")]
ProductData GetProduct(int productId);























Time
Topic
Presenter(s)
3:25p
Implementing RESTful Services with WCF
Part 1: Concepts and Intro
Ron Jacobs / Rob Bagby
4:25p
Break
4:30p
Implementing RESTful Services with WCF
Part 2: Implementation in Depth
5:30p
Break
5:35p
Workflow Services Demo
5:45p
<End>
Ron Jacobs / Rob Bagby
Ron Jacobs
Time
Topic
Presenter(s)
3:25p
Implementing RESTful Services with WCF
Part 1: Concepts and Intro
Ron Jacobs / Rob Bagby
4:25p
Break
4:30p
Implementing RESTful Services with WCF
Part 2: Implementation in Depth
5:30p
Break
5:35p
Workflow Services Demo
5:45p
<End>
Ron Jacobs / Rob Bagby
Ron Jacobs
 Ron Jacobs
Sr. Technical Evangelist
Microsoft Corporation
 Rob Bagby
Developer Evangelist
Microsoft Corporation




URI
Verb
Collection
Action
/wine
POST
Wine
Create
/wine/{wineId}
GET
Wine
Read
/wine/{wineId}
PUT
Customers
Update
/wine/{wineId}
DELETE
Customers
Delete
/wine/series/{seriesId}
GET
Wine Series
Read
/wine/{wineId}/reviews
GET
Wine Reviews
Read
/wine/{wineId}/reviews
POST
Wine Reviews
Create
http://localhost/service.svc/method?arg1=1

UriTemplate

[OperationContract]
[WebGet(UriTemplate="Wine/{wineId})]
WineData GetWine(string wineId);
http://localhost/service.svc/Wine/1

Default Values

[OperationContract]
[WebGet(UriTemplate="Wine/{wineID=17})]
WineData GetWine(string wineID);

Compound Template Segments
[OperationContract]
[WebGet(UriTemplate=“wine({wineID})]
WineData GetWine(string wineID);
http://localhost/service.svc/wine(17)


Tip/Trick: Url Rewriting with ASP.NET

Using WCF WebHttpBinding and WebGet with nicer
Urls






URL Rewrite Module









microformats


<div id="" class="vcard">
<a class="url fn n" href="http://www.cohowinery.net">
<div class="org">Coho Winery</div>
</a>
<a class="email" href="mailto:[email protected]">[email protected]</a>
<div class="adr">
<div class="street-address">555 Wine Lane</div>
<span class="locality">Napa</span>
<span class="region">CA</span>
<span class="postal-code">94558</span>
<span class="country-name">USA</span>
</div>
<div class="tel">800-555-1212</div>
</div>
Using the new WCF REST Kit Template










[WebGet(UriTemplate ="wine/{wineID}")]
[WebCache(CacheProfileName =
"CacheWine")]
[OperationContract]
WineData GetWine(string wineID);
// web.config cache profile
<outputCacheProfiles>
<add name="CacheWine"
duration="60"
enabled="true"
location="Any" />
</outputCacheProfiles>




























OAuth.net
Beginners Guide to OAuth










Enable Ajax web site for security
Using Forms Auth with client side script
Enabling login with Ajax script service







simple
open
© 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.