Service Oriented Development With Windows Communication Foundation 2003
Upcoming SlideShare
Loading in...5

Service Oriented Development With Windows Communication Foundation 2003



This is the presentation on Service Oriented Architecture and Windows Communication Foundation that I gave to the Bartlesville .NET User Group

This is the presentation on Service Oriented Architecture and Windows Communication Foundation that I gave to the Bartlesville .NET User Group



Total Views
Slideshare-icon Views on SlideShare
Embed Views



4 Embeds 27 10 9 7 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Service Oriented Development With Windows Communication Foundation 2003 Service Oriented Development With Windows Communication Foundation 2003 Presentation Transcript

    • 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 POST
      • 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
      • Linkedin
      • Bartlesville .NET User Group
      • Twitter
      • Email
        • [email_address]