anniev57's picture
From anniev57 rss RSS  subscribe Subscribe

Service Oriented Development With Windows Communication Foundation Tulsa Dnug 


Tags:  location  based  service 
Views:  463
Published:  November 27, 2010

Share plick with friends Share
save to favorite
Report Abuse Report Abuse
Related Plicks
Java Script Based Client Server Webapps 2

Java Script Based Client Server Webapps 2

From: adib80
Views: 175 Comments: 0
Java Script Based Client Server Webapps 2
My collaboration patent application

My collaboration patent application

From: tarjei2
Views: 542 Comments: 0
My collaboration patent application
Customer Experience Lifecycle

Customer Experience Lifecycle

From: anon-444802
Views: 611 Comments: 0
Customer Experience Lifecycle
Qwest<sup>&#1 74;</sup> Dedicated Hosting Service

Qwest<sup>®</sup> Dedicated Hosting Service

From: agclark4
Views: 109 Comments: 0
Qwest<sup>®</sup> Dedicated Hosting Service
See all 
More from this user
Discovering What Faculty REALLY Need to Know about Teaching Online

Discovering What Faculty REALLY Need to Know about Teaching Online

From: anniev57
Views: 1634
Comments: 1

MSP2007 Table of Content

MSP2007 Table of Content

From: anniev57
Views: 296
Comments: 0

Interconcept Solutions 10 mins buz showcase

Interconcept Solutions 10 mins buz showcase

From: anniev57
Views: 1831
Comments: 3

Book   Collaboration In The Cloud   Ok

Book Collaboration In The Cloud Ok

From: anniev57
Views: 3109
Comments: 0

Pop Art

Pop Art

From: anniev57
Views: 628
Comments: 0

UShareSoft-applianc e-factory-solutions -linux


From: anniev57
Views: 402
Comments: 0

See all 
 URL:          AddThis Social Bookmark Button
Embed Thin Player: (fits in most blogs)
Embed Full Player :


Email (will NOT be shown to other users)


Comments: (watch)
Slide 1: Service Oriented Development with Windows Communication Foundation Jason Townsend
Slide 2: Jason Townsend • • • • • President, Bartlesville .NET User Group Sr. Analyst, ConocoPhillips 11+ Years Development Experience Father of 4 beautiful children Competitive Sailor
Slide 3: Evolution of Service Orientation
Slide 4: 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 typespecific behavior. ▫ 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. ▫ Subclass is a class that inherits some properties from its superclass. • Encapsulation • Subclassing
Slide 5: 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 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. ▫ Enabled the ability to build systems that dynamically loaded and bound to new functionality at runtime. • Dynamic Loading • Runtime Metadata
Slide 6: Service-Oriented • Message-based ▫ Communication is made by the sending of messages to recipients. ▫ Forms of messages include function invocation, signals, and data packets. ▫ Use schema to describe the structure of messages ▫ Use contract to define acceptable message exchange patterns. ▫ Use policy to define service semantics used for binding. • Schema and Contract • Binding via Policy
Slide 7: Tenets of Service Orientation
Slide 8: 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.
Slide 9: 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.
Slide 10: 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.
Slide 11: 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.
Slide 12: 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.
Slide 13: WCF Design Goals
Slide 14: 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
Slide 15: XML Specifications • • • • • • • • XML (eXtensible Markup Language) XML Namespaces XML Schema XPath XQuery XML Information Set XInclude XML Pointer
Slide 16: 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
Slide 17: 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 • WS-Resource Framework (WSRF) ▫ Web Services Semantics (WSDL-S)
Slide 18: 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
Slide 19: Privacy • P3P Reliable Messaging • WS-ReliableMessaging • WS-Reliability • WS-RM Policy Assertion
Slide 20: Resource Specifications • • • • • • • Web Services Resource Framework WS-BaseFaults WS-ServiceGroup WS-ResourceProperties WS-ResourceLifetime WS-Transfer Resource Representation SOAP Header Block
Slide 21: Web Services Interoperability Organization (WS-I) Specifications • WS-I Basic Profile • WS-I Basic Security Profile • Simple Soap Binding Profile
Slide 22: Business Process Specifications • • • • • WS-BPEL WS-CDL Web Services Choreography Interface WS-Choreography XML Process Definition Language
Slide 23: Transaction Specifications • • • • • • • WS-BusinessActivity WS-AtomicTransaction WS-Coordination WS-CAF WS-Transaction WS-Context WS-CF
Slide 24: Management Specifications • • • • WS-Management WS-Management Catalog WS-ResourceTransfer WSDM
Slide 25: 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…
Slide 26: REST • Focus is on the URI • GET is special, other verbs are application specific ▫ HTTP GET ▫ HTTP POST • Content Type is the data model ▫ ▫ ▫ ▫ XML JSON Binary Etc... ▫ GET verb always means “View It” ▫ PUT/POST/DELETE mean “Do It” but depend on client implementation • Support built on via WCF extensibility points
Slide 27: 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
Slide 28: WCF Architecture (Application)
Slide 29: Messaging • • • • • • • • WS Security Channel WS Reliable Messaging Channel Encoders: Binary/MTOM/Text/XML HTTP Channel TCP Channel Transaction Flow Channel NamedPipe Channel MSMQ Channel
Slide 30: 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
Slide 32: Channel Shaping (Message Exchange Patterns) • Possible mismatch: • Channel shapes implemented in transport bindings • WCF ServiceModel analyzes contract ▫ Which channel shapes will be supported? ▫ Physical transport ▫ Logical message exchange patterns ▫ Express support for Message Exchange Patterns • ServiceChannelFactory.BuildChannelFactory and DispatcherBuilder.GetSupportedChannelTypes have the details
Slide 33: Contracts • Service Contract ▫ Operations ▫ Behaviors ▫ Communication Shape • Data Contract • Message Contract ▫ Schema and Versioning Strategy ▫ Application specific headers and unwrapped body content • Policy and Binding
Slide 34: Contracts (Request-Reply) • Most commonly used MEP • R/R can be implemented in WCF by several approaches ▫ ▫ ▫ ▫ Parameter list DataContract MessageContract Message ▫ It is easy to use and looks natural • Mind the “public face” of contracts, i.e. the metadata
Slide 35: 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
Slide 36: 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
Slide 37: 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 • Only works with appropriate binding ▫ Headers will be buffered ▫ Body as System.IO.Stream will be streamed
Slide 38: Transport Protocols (Bindings) • • • • HTTP TCP MSMQ More can be added through built-in extension points.
Slide 39: 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
Slide 40: 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
Slide 41: Bindings (Duplex) • Duplex out-of-the-box ▫ ▫ ▫ ▫ netTcp wsDualHttp netNamedPipe netPeerTcp • Manual duplex session-less, e.g. <compositeDuplex /> <oneWay /> <binaryMessageEncoding /> <httpTransport />
Slide 42: Bindings (Streaming) • Enable streaming on the baked-in bindings • Enable streaming on the transport binding element, e.g. • Possible transferMode values ▫ ▫ ▫ ▫ Buffered Streamed StreamedRequest StreamedResponse <httpTransport transferMode=„Streamed“ /> ▫ All standard bindings besides MSMQ-based • Only transport security and no reliable sessions allowed
Slide 43: MSMQ Transport • MSMQ is different – always has been • Duplex Message Exchange Pattern over MSMQbased 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
Slide 44: Service Runtime • • • • • • • • • Throttling Behavior Error Behavior Metadata Behavior Instance Behavior Message Inspection Transaction Behavior Dispatch Behavior Concurrency Behavior Parameter Filtering
Slide 45: 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
Slide 46: 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
Slide 47: 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
Slide 48: Hosting and Activation • • • • Windows Activation Service/IIS .EXE Windows Services COM+
Slide 49: WCF Offers Features You Need • • • • • • • • Logging Tracing Instance Control Throttling Rich Configuration Extensibility Hosting Options And More….
Slide 50: 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.
Slide 52: Further Resources • My Blog • Linkedin ▫ ▫ ▫ • Bartlesville .NET User Group • Twitter • Email ▫ ▫
Slide 53: Key Terms
Slide 54: Message • A message is a self-contained unit of data that may consist of several parts, including a body and headers.
Slide 55: Service • A service is a construct that exposes one or more endpoints, with each endpoint exposing one or more service operations.
Slide 56: Endpoint • An endpoint is a construct at which messages are sent or received (or both). It comprises a location (an address) that defines where messages can be sent, a specification of the communication mechanism (a binding) that described how messages should be sent, and a definition for a set of messages that can be sent or received (or both) at that location (a service contract) that describes what message can be sent. • An WCF service is exposed to the world as a collection of endpoints.
Slide 57: Application Endpoint • An endpoint exposed by the application and that corresponds to a service contract implemented by the application.
Slide 58: Infrastructure Endpoint • An endpoint that is exposed by the infrastructure to facilitate functionality that is needed or provided by the service that does not relate to a service contract. For example, a service might have an infrastructure endpoint that provides metadata information.
Slide 59: Address • An address specifies the location where messages are received. It is specified as a Uniform Resource Identifier (URI). The URI schema part names the transport mechanism to use to reach the address, such as HTTP and TCP. The hierarchical part of the URI contains a unique location whose format is dependent on the transport mechanism. • The endpoint address enables you to create unique endpoint addresses for each endpoint in a service, or under certain conditions share an address across endpoints. The following example shows an address using the HTTPS protocol with a non-default port: • HTTPS://okcodemonkey:8080/Service/MonkeyService
Slide 60: Binding • A binding defines how an endpoint communicates to the world. It is constructed of a set of components called binding elements that "stack" one on top of the other to create the communication infrastructure. At the very least, a binding defines the transport (such as HTTP or TCP) and the encoding being used (such as text or binary). A binding can contain binding elements that specify details like the security mechanisms used to secure messages, or the message pattern used by an endpoint. For more information, see Configuring Services.
Slide 61: Binding Element • A binding element represents a particular piece of the binding, such as a transport, an encoding, an implementation of an infrastructure-level protocol (such as WS-ReliableMessaging), or any other component of the communication stack.
Slide 62: Behaviors • A behavior is a component that controls various runtime aspects of a service, an endpoint, a particular operation, or a client. Behaviors are grouped according to scope: common behaviors affect all endpoints globally, service behaviors affect only service-related aspects, endpoint behaviors affect only endpoint-related properties, and operation-level behaviors affect particular operations. For example, one service behavior is throttling, which specifies how a service reacts when an excess of messages threaten to overwhelm its handling capabilities. An endpoint behavior, on the other hand, controls only aspects relevant to endpoints, such as how and where to find a security credential.
Slide 63: System-Provided Bindings
Slide 64: Configuration versus Coding • Control of an application can be done either through coding, through configuration, or through a combination of both. Configuration has the advantage of allowing someone other than the developer (for example, a network administrator) to set client and service parameters after the code is written and without having to recompile. Configuration not only enables you to set values like endpoint addresses, but also allows further control by enabling you to add endpoints, bindings, and behaviors. Coding allows the developer to retain strict control over all components of the service or client, and any settings done through the configuration can be inspected and if needed overridden by the code.
Slide 65: Service Operation • A service operation is a procedure defined in a service's code that implements the functionality for an operation. This operation is exposed to clients as methods on a WCF client. The method may return a value, and may take an optional number of arguments, or take no arguments, and return no response. For example, an operation that functions as a simple "Hello" can be used as a notification of a client's presence and to begin a series of operations.
Slide 66: Service Contract • The service contract ties together multiple related operations into a single functional unit. The contract can define service-level settings, such as the namespace of the service, a corresponding callback contract, and other such settings. In most cases, the contract is defined by creating an interface in the programming language of your choice and applying the ServiceContractAttribute attribute to the interface. The actual service code results by implementing the interface.
Slide 67: Operation Contract • An operation contract defines the parameters and return type of an operation. When creating an interface that defines the service contract, you signify an operation contract by applying the OperationContractAttribute attribute to each method definition that is part of the contract. The operations can be modeled as taking a single message and returning a single message, or as taking a set of types and returning a type. In the latter case, the system will determine the format for the messages that need to be exchanged for that operation.
Slide 68: Message Contract • A message contract describes the format of a message. For example, it declares whether message elements should go in headers versus the body, what level of security should be applied to what elements of the message, and so on.
Slide 69: Fault Contract • A fault contract can be associated with a service operation to denote errors that can be returned to the caller. An operation can have zero or more faults associated with it. These errors are SOAP faults that are modeled as exceptions in the programming model.
Slide 70: Data Contract • The data types a service uses must be described in metadata to enable others to interoperate with the service. The descriptions of the data types are known as the data contract, and the types can be used in any part of a message, for example, as parameters or return types. If the service is using only simple types, there is no need to explicitly use data contracts.
Slide 71: Hosting • A service must be hosted in some process. A host is an application that controls the lifetime of the service. Services can be self-hosted or managed by an existing hosting process.
Slide 72: Self-Hosted Service • A self-hosted service is one that runs within a process application that the developer created. The developer controls its lifetime, sets the properties of the service, opens the service (which sets it into a listening mode), and closes the service.
Slide 73: Hosting Process • A hosting process is an application that is designed to host services. These include Internet Information Services (IIS), Windows Activation Services (WAS), and Windows Services. In these hosted scenarios, the host controls the lifetime of the service. For example, using IIS you can set up a virtual directory that contains the service assembly and configuration file. When a message is received, IIS starts the service and controls its lifetime.
Slide 74: Instancing • A service has an instancing model. There are three instancing models: "single," in which a single CLR object services all the clients; "per call," in which a new CLR object is created to handle each client call; and "per session," in which a set of CLR objects are created, one for each separate session. The choice of an instancing model depends on the application requirements and the expected usage pattern of the service.
Slide 75: Client Application • A client application is a program that exchanges messages with one or more endpoints. The client application begins by creating an instance of a WCF client and calling methods of the WCF client. It is important to note that a single application can be both a client and a service.
Slide 76: Channel • A channel is a concrete implementation of a binding element. The binding represents the configuration, and the channel is the implementation associated with that configuration. Therefore, there is a channel associated with each binding element. Channels stack on top of each other to create the concrete implementation of the binding: the channel stack.
Slide 77: WCF Client • A WCF client is a client-application construct that exposes the service operations as methods (in the .NET Framework programming language of your choice, such as Visual Basic or Visual C#). Any application can host a WCF client, including an application that hosts a service. Therefore, it is possible to create a service that includes WCF clients of other services. • A WCF client can be automatically generated by using the ServiceModel Metadata Utility Tool (Svcutil.exe) and pointing it at a running service that publishes metadata.
Slide 78: Metadat • The metadata of a service describes the characteristics of the service that an external entity needs to understand to communicate with the service. Metadata can be consumed by the ServiceModel Metadata Utility Tool (Svcutil.exe) to generate a WCF client and accompanying configuration that a client application can use to interact with the service. • The metadata exposed by the service includes XML schema documents, which define the data contract of the service, and WSDL documents, which describe the methods of the service. • When enabled, metadata for the service is automatically generated by WCF by inspecting the service and its endpoints. To publish metadata from a service, you must explicitly enable the metadata behavior.
Slide 79: Security • Security in WCF includes confidentiality (encryption of messages to prevent eavesdropping), integrity (the means for detection of tampering with the message), authentication (the means for validation of servers and clients), and authorization (the control of access to resources). These functions are provided by either leveraging existing security mechanisms, such as TLS over HTTP (also known as HTTPS), or by implementing one or more of the various WS-* security specifications.
Slide 80: Transport Security Mode • Security can be provided by one of three modes: transport mode, message security mode, and transport with message credential mode. The transport security mode specifies that confidentiality, integrity, and authentication are provided by the transport layer mechanisms (such as HTTPS). When using a transport like HTTPS, this mode has the advantage of being efficient in its performance, and well understood because of its prevalence on the Internet. The disadvantage is that this kind of security is applied separately on each hop in the communication path, making the communication susceptible to a "man in the middle" attack.
Slide 81: Message Security Mode • Message security mode specifies that security is provided by implementing one or more of the security specifications. Each message contains the necessary mechanisms to provide security during its transit, and to enable the receivers to detect tampering and to decrypt the messages. In this sense, the security is encapsulated within every message, providing endto-end security across multiple hops. Because security information becomes part of the message, it is also possible to include multiple kinds of credentials with the message (these are referred to as claims). This approach also has the advantage of enabling the message to travel securely over any transport, including multiple transports between its origin and destination. The disadvantage of this approach is the complexity of the cryptographic mechanisms employed, resulting in performance implications.
Slide 82: Transport with Message Credential Security Mode • This mode uses the transport layer to provide confidentiality, authentication, and integrity of the messages, while each of the messages can contain multiple credentials (claims) required by the receivers of the message.
Slide 83: WS-* • Shorthand for the growing set of Web Service (WS) specifications, such as WS-Security, WSReliableMessaging, and so on, that are implemented in WCF.

Time on Slide Time on Plick
Slides per Visit Slide Views Views by Location