Service Oriented Development with Windows Communication Foundation
Jason Townsend
Evolution of Service Orientation
Object-Oriented• Polymorphism
▫ Lets you treat derived class members just like their parent class' members.
▫ Process of using an operator or function in different ways for different set of inputs given.
▫ The ability of objects belonging to different types to respond to method calls of the same name, each one according to an appropriate type-specific behavior.
• Encapsulation▫ Often used interchangeably with information hiding.▫ Reduces software development risk by shifting the code's
dependency on an uncertain implementation (design decision) onto a well-defined interface.
• Subclassing▫ Subclass is a class that inherits some properties from its
superclass.
Component-Based• Interface-based
▫ Insists that Interfaces are to be added to components. ▫ The entire system is thus viewed as Components and
the interfaces that helps them to coact.• Dynamic Loading
▫ Dynamic loading is a mechanism by which a computer program can, at runtime, load a library (or other binary) into memory, retrieve the addresses of functions and variables contained in the library, execute those functions or access those variables, and unload the library from memory.
• Runtime Metadata▫ Enabled the ability to build systems that dynamically
loaded and bound to new functionality at runtime.
Service-Oriented• Message-based
▫Communication is made by the sending of messages to recipients.
▫Forms of messages include function invocation, signals, and data packets.
• Schema and Contract▫Use schema to describe the structure of
messages▫Use contract to define acceptable message
exchange patterns.• Binding via Policy
▫Use policy to define service semantics used for binding.
Tenets of Service Orientation
Boundaries are Explicit• Based on the underlying concept of encapsulation,
this tenet specifies the publishing and consumption of functionality as sets of services that abstract their underlying implementation.
• With WCF, the attribute-based programming enables developers to explicitly define external service contracts. Without explicitly defining these, nothing within the class will be exposed publicly.
• WCF provides an opt-in model for explicitly defining service boundaries.
Autonomous Evolution
•Services are Autonomous. •Autonomy
▫We design the system to support the inevitable evolution of the service’s implementation over time. As we build our services, we need to assume that their internal implementation will evolve (become versioned) over time and that our services as well as the services on which we depend could change location at (almost) any time.
Share Schema & Contract, Not Class•Services share schema and contract, not
class. ▫This is how ASMX works.
Service publishes a contract (WSDL, XSD) No types are shared between service and its
client (by default)▫Neither service requires knowledge of each
others’ internal workings in order to exchange data.
Compatibility Based on Policy•Service compatibility is determined based
on policy.•Services communicate through
dynamically negotiated communications channels that support the necessary semantics.
•Service policy statements created automatically based on configuration, class attributes, and method signatures.
•Client channels automatically configured via retrieved service policy.
Why Service Orientation?
•Facilitates loosely coupled standards based integration.
•Enables independence in deployment, versioning, and management of the client (caller) and the server (called).
•Promotes reuse of application investments over time.
WCF Design Goals
WS-*• Used as a reference to many web service based
standards covering topics such as:▫ XML Specifications▫ Messaging Specifications▫ Metadata Exchange Specifications▫ Security Specifications▫ Privacy▫ Reliable Messaging Specifications▫ Resource Specifications▫ Web Services Interoperability organization (WS-I)
Specifications▫ Business Process Specifications▫ Transaction Specifications▫ Management Specifications
XML Specifications
•XML (eXtensible Markup Language) •XML Namespaces •XML Schema •XPath •XQuery •XML Information Set •XInclude •XML Pointer
Messaging Specifications• Simple Object Access Protocol (SOAP) • SOAP Message Transmission Optimization
Mechanism • WS-Notification
▫WS-BaseNotification ▫WS-Topics ▫WS-BrokeredNotification
• WS-Addressing • WS-Transfer • WS-Eventing • WS-Enumeration
Metadata Exchange Specifications• WS-Policy • WS-PolicyAssertions • WS-PolicyAttachment • WS-Discovery
▫WS-Inspection • WS-MetadataExchange • Universal Description, Discovery, and
Integration (UDDI) • WSDL 2.0 Core • WSDL 2.0 SOAP Binding
▫Web Services Semantics (WSDL-S) • WS-Resource Framework (WSRF)
Security Specifications• WS-Security • XML Signature • XML Encryption • XML Key Management (XKMS) • WS-SecureConversation • WS-SecurityPolicy • WS-Trust • WS-Federation • WS-Federation Active Requestor Profile • WS-Federation Passive Requestor Profile • Web Services Security Kerberos Binding • Web Single Sign-On Interoperability Profile • Web Single Sign-On Metadata Exchange Protocol • Security Assertion Markup Language (SAML) • XACML
Privacy
•P3P
Reliable Messaging•WS-ReliableMessaging •WS-Reliability •WS-RM Policy Assertion
Resource Specifications
•Web Services Resource Framework •WS-BaseFaults •WS-ServiceGroup •WS-ResourceProperties •WS-ResourceLifetime •WS-Transfer •Resource Representation SOAP Header
Block
Web Services Interoperability Organization (WS-I) Specifications•WS-I Basic Profile •WS-I Basic Security Profile •Simple Soap Binding Profile
Business Process Specifications
•WS-BPEL •WS-CDL •Web Services Choreography Interface •WS-Choreography •XML Process Definition Language
Transaction Specifications
•WS-BusinessActivity •WS-AtomicTransaction •WS-Coordination •WS-CAF •WS-Transaction •WS-Context •WS-CF
Management Specifications
•WS-Management •WS-Management Catalog •WS-ResourceTransfer •WSDM
WCF Make WS-* Easy
•Binding selection abstracts WS-* internals•WCF has Oasis Standard Bindings (3.5)•Single Object model for
▫Transports▫Choreographies▫Message Exchange Patterns (MEPs)▫Etc…
WCF Offers Features You Need
•Logging•Tracing•Instance Control•Throttling•Rich Configuration•Extensibility•Hosting Options•And More….
Communicating through Messages•Messages travel between communication
parties•Messages can be grouped into different
message exchange patterns (MEPs)•MEPs can be implemented synchronously
or asynchronously•WCF supports different MEPs•WCF MEPs implemented by different
kinds of channels
Channel Shaping•Possible mismatch:
▫Physical transport▫Logical message exchange patterns
•Channel shapes implemented in transport bindings▫Express support for Message Exchange Patterns
•WCF ServiceModel analyzes contract▫Which channel shapes will be supported?
•ServiceChannelFactory.BuildChannelFactory and DispatcherBuilder.GetSupportedChannelTypes have the details
Types of Contracts
•Service Contract▫Operations▫Behaviors▫Communication Shape
•Data Contract▫Schema and Versioning Strategy
•Message Contract▫Application specific headers and
unwrapped body content
Contracts (Request-Reply)•Most commonly used MEP
▫It is easy to use and looks natural•R/R can be implemented in WCF by
several approaches▫Parameter list▫DataContract▫MessageContract▫Message
•Mind the “public face” of contracts, i.e. the metadata
Contracts (One-Way)
•One Way operations smell more feasible when decoupling is goal
•No return values, rather void•Use IsOneWay property of
OperationContract•OneWay operations can still block
▫Not really fire-and-forget semantics
Contracts (Duplex)
•Having peer communication parties▫Blurring the line between client and server
•Use CallbackContract property of ServiceContract
•Operations in contracts can be one-way, but need no to be▫If using non-one-way beware of threading
issues
Contracts (Streaming)•Buffered communication can be very
expensive with large data•WCF offers streamed transfer
▫Contract parameters must have certain shape•Use Message, IXmlSerializable or
System.IO.Stream or derivate as type•Use MessageContract
▫Headers will be buffered▫Body as System.IO.Stream will be streamed
•Only works with appropriate binding
Bindings (Request-Reply)
•Almost all out-of-the-box bindings support request-reply▫MSMQ-based bindings do not
•For all bindings and MEPs:▫Beware of default min/max values on
binding elements for e.g. message sizes and buffers and timeouts
▫Beware of possible throttles on service behavior
Bindings (One-Way)
•All bindings support one-way operations•Use OneWayBindingElement for custom
bindings to shape channel▫Performs a message-level shape change ▫Can take a IDuplexSessionChannel or a
IRequestChannel and expose it as a IOutputChannel, or conversely it can take a IDuplexSessionChannel or a IReplyChannel and expose it as a IInputChannel
Bindings (Duplex)•Duplex out-of-the-box
▫netTcp▫wsDualHttp▫netNamedPipe▫netPeerTcp
•Manual duplex session-less, e.g.<compositeDuplex /><oneWay /><binaryMessageEncoding /><httpTransport />
Bindings (Streaming)• Enable streaming on the baked-in bindings
▫All standard bindings besides MSMQ-based• Enable streaming on the transport binding
element, e.g.<httpTransport transferMode=„Streamed“ />
• Possible transferMode values▫Buffered▫Streamed▫StreamedRequest▫StreamedResponse
• Only transport security and no reliable sessions allowed
MSMQ Transport
•MSMQ is different – always has been•Duplex Message Exchange Patern over
MSMQ-based binding can be achieved manually:▫Leverage message headers▫Access headers through OperationContext
in user code▫Access headers through message
inspectors in ServiceModel extensions▫Use GUID to correlate messages
REST• Focus is on the URI
▫ HTTP GET http://dog.com/dogs.id/12▫ HTTP POST http://dog.com/updateDog
• GET is special, other verbs are application specific▫ GET verb always means “View It”▫ PUT/POST/DELETE mean “Do It” but depend on
client implementation• Content Type is the data model
▫ XML▫ JSON▫ Binary▫ Etc...
• Support built on via WCF extensibility points
WS-* versus REST
•Which is better?•Each has strengths:
▫REST: proliferation of clients, easy to understand Flash Silverlight Javascript Etc…
▫WS-*: rich Messaging Exchange patterns, Topologies, and Choreographies
WCF Security• Claims based end-to-end security
▫Secure end-to-end message exchanges▫Secure access to resources▫Record resource access requests
• X509, Username/Password, Kerberos, SAML, and custom credentials
• Message Security▫Confidentiality and Integrity▫Transport or Message Level
• Access to resources▫Authentication and Authorization
WCF Reliability and Transactions•End-to-End Reliable Messaging
▫In-Order guarantees▫Exactly once guarantees
•Transport-Independent Sessions▫Integration with ASP.NET Sessions in IIS-
Hosted compatibility mode•Transactions
▫Guaranteed atomic success or failure across services
WCF Instancing, Concurrency, and Sessions•Service classes can be instantiated
▫Singleton▫Per-Call▫Per-Session▫Shareable
•Service code can be either:▫Single-threaded▫Re-entrant▫Multi-threaded
WCF Summary
•WCF is the future of distributed computing
•It combines the best of all existing Microsoft distributed computing stacks
•It uses WS-* standards for interoperability and .NET value-add for performance and integration with existing solutions.
Further Resources•My Blog
▫http://www.okcodemonkey.com•Linkedin
▫http://www.linkedin.com/in/okcodemonkey•Bartlesville .NET User Group
▫http://www.bdnug.com•Twitter
▫http://twitter.com/okcodemonkey•Email