Service Oriented Development With Windows Communication Foundation 2003

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

▫[email protected]