Microsoft Windows Communication Foundation In the Channel Layer

Microsoft Windows® Communication Foundation “In the Channel Layer”

Agenda �DISCLAIMER �INTRO TO WCF �WHY SERVICE ORIENTATION �THE 10, 000 FOOT VIEW �IN THE CHANNEL LAYER �CONCLUSION �REFERENCES �QUESTIONS

Disclaimer �“Not an expert” �Knew nothing about WCF �Took as an opportunity to learn �All knowledge came from one book, a few websites, and a software architect �Take it for what it’s worth �Did I mention I’m “not an expert”?

INTRO TO WCF unifies the capabilities from many of the. NET 2. 0 API’s communication mechanisms into a single, common, general “service -oriented (SO) model [3]. � WCF can also use Simple Object Access Protocol (SOAP) messages between two processes, making WCF-based applications interoperable with any other processes that communicate via SOAP messages [3]. � When a WCF-to-Non. WCF communication occurs, XML-based encoding is used for the SOAP messages but when WCF-to-WCF communication occurs, the SOAP messages can be encoded in an optimized binary format with both encodings conforming to the data structure of the SOAP format [3]. � WCF uses a pluggable encoding system, allowing developers to write their own encoders [3]. � ◦ With the release of the. NET 3. 5 Framework, Microsoft released an encoder that added support for the JSON serialization format –allowing WCF a means of servicing requests from AJAX-powered web pages [3]. � At a high level, WCF is an API that is exposed as an object model abstraction of a very extensible and adaptable messaging infrastructure.

WHY SERVICE ORIENTATION � SO makes sense for a number of reasons ◦ ◦ [2] Maintainability Interoperability Flexibility. Versioning � With SO, autonomous boundaries partition layers of encapsulation allowing “Versioning” of different parts of a software system independent of other parts of the system. ◦ Load Balancing � When data access is the bottleneck for workflow applications, a data-access service can mitigate the traffic by allowing a means of load balancing on the database. ◦ Platform Independence � SO relays on messaging contracts expressed in a platform neutral XML grammar; thus, decoupling sender from receiver regardless of hosting environments or technologies. ◦ ◦ Content Based Routing � SO allows for content-based routing by essentially allowing routable metadata inside SOAP messages. End-to-End Security � One other note worth mentioning is that End-to-End Security is possible with SO messages by ways of using standard XML security mechanisms. In the past, distributed components technologies like DCOM tightly bound distributed components together. At the bare minimum, these distributed components had to share a common type system and often a common runtime. Given these dependencies, upgrades and software updates can become complex, time-consuming, and expensive endeavors [2]. � It is apparent that SO provides great value in a number of manners such as granting control over functionality previously reserved for the transport. However, probably the greatest value comes in the form of allowing pieces of software that aggregate to form a software system to be versioned independent rather than incurring to cost of having to choreograph “massive” system-wide upgrades with each version release [2]. �

THE 10, 000 FOOT VIEW � From the outside � Seemingly as simple as specifying an “Endpoint” (ABC’s) �An Address –a CLR abstraction of a WS-Addressing endpoint reference (ultimate or intermediary target of the sent message) �A Binding –means of expressing how a messaging application processes, sends, and receives messages; more specifically, it is the primary way we express the transport, WS-* protocols, security requirements, and transactional requirements and endpoint uses � Creates stacks of channel factory or channel listener objects � In Design Pattern terms, a binding is a factory � Visible in the service model layer, but objects it creates impact the channel layer �A Contract –mapping OO constructs to messaging constructs; more specifically, contracts define the endpoints in a receiving application, the MEP used by those endpoints, and the structure of the messages that an endpoint processes � Over time, the industry has developed and refined vendor-agnostic grammars like Web Services Description Language (WSDL) and Extensible Schema Definition (XSD) � In WCF applications, a contract is not necessarily a set of WSDL and XSD documents, but rather a set of. NET type definitions, that once in place, can be turned into a set of WSDL and XSD documents as needed

THE 10, 000 FOOT VIEW (cont. ) � From the inside ◦ Two major architectural layers � Service Model Layer � Bridge between user code and Channel Layer � Part of the API � Channel Model Layer � Does the “real” work of messaging � Understands details of a particular transport and WS-* specifications ◦ On the sender, the category of types is known as the Client � Tasks include using a binding and a contract to build the channel factory and channel stack to send a Message to a receiving application. ◦ On the receiver, the category of types is known as the Dispatcher � Tasks include routing received messages to the appropriate service object instance, managing service object lifetime, throttling the usage of a Service. Host instance, and handling errors.

THE 10, 000 FOOT VIEW (cont. ) � From the inside (cont. ) ◦ ABC’s are part of the developer’s API ◦ ABC’s are distinct from the Service Model and Channel Model Layers ◦ ABC’s influence the creation of these “two” layers � On the receiver, the address tells the Channel Layer where to listen to incoming addresses. � On the sender, the address tells the Channel Layer where to connect to the receiving app. � Bindings are factories that create the Channel Layer. � Contracts are Service Model constructs that dictate message serialization/deserialization and MEPs.

IN THE CHANNEL LAYER �Message Exchange Patterns ◦ Datagram –one way message from sender to receiver (no response) � Responses can be sent but must be out-of-band –requires new connection in which receiver & sender swap roles � HTTP/HTTPS transports support Datagram MEP as well (202 reply responses sent upon receipt but before processing; thus client does not wait unnecessarily for the transport reply, and the exchange is as close to one-way as possible) ◦ Request/Reply –receiver sends a reply message for each message sent by the sender � Over UDP/MSMQ transports originally no out of box support (would need two connections over these transports –one for each direction) ◦ ◦ Duplex –two way comm from sender to receiver (each can send at will) *Topologies –point 2 point (one sender & one receiver), forward only point 2 point (chain of datagram message exchanges), brokered (received messages broadcasted to other receivers), peer 2 peer (1 to 1, 1 to many, many to many comm over pre-joined set of nodes or mesh)

IN THE CHANNEL LAYER (cont. ) �Message Type ◦ A WCF abstraction of a SOAP message �. NET type that defines members that represent the SOAP version, envelope, header blocks, and body elements ◦ Adapts easily to non-SOAP based XML messing applications �Can adapt to Plain Old XML (POX) messages �Can adapt to Java. Script Object Notation (JSON) �JSON (using Java. Script to represent objects) fully embraces AJAX enabling technologies ◦ Much of the Message type object model is dedicated to message serialization/deserialization

IN THE CHANNEL LAYER (cont. ) �Channels ◦ Send and receive messages ◦ Responsible for work at the transport layer and for WS-* protocol implementations ◦ Relates to one aspect of the messaging functionality in an application � If a WCF application is secure & reliable, there will be one channel for security & another for reliability ◦ Channels are arranged in a stack and leverage the functionality across the stack � A WCF application references the topmost channel in the stack only. � The bottom most channel in a channel stack is the transport channel. � Once a message is sent to the channel stack, the channel stack itself pulls or pushes messages through the stack. � The composition of the stack dictates many of the features of the WCF messaging application. � For the most part, channel stacks accept or return a message at the topmost channel in the stack, and the channel at the bottom of the stack emits or receives bytes at the transport level. � Channel stacks on a sending application accept a message at the top of the stack and emit bytes at the bottom of the stack. � Channel stacks on a receiving application accept bytes at the bottom of the channel stack and return a message at the top of the stack. � What happens in the middle of the stack depends on the channels residing there. Typically, the channels in the middle of a channel stack are the physical implementations of a WS-* protocol or security toll gates.

IN THE CHANNEL LAYER (cont. ) �Channel Shapes ◦ Key means to categorize channels ◦ Corresponds to one or more MEP ◦ WCF type system defines shapes that map to the MEPs Channel Shapes Session Channel Shapes

IN THE CHANNEL LAYER (cont. ) � Channel State Machine ◦ � The States ◦ � Common type to both Channels and Channel Managers Created, Opening, Opened, Closing, Closed, Faulted The Means ◦ ICommunication. Object Interface � � ◦ Communication. Object Abstract Class � � Defines variations of Open, Abort, & Close methods Defines “state” transition events Implements ICommunication. Object, raises ICommunication. Object events at the appropriate time, invokes abstract and virtual methods for derived type implementation, and provides several helper methods for consistent error handling Defines a Fault method (not part of ICommunication. Object) –means for Communication. Object derived types to abruptly shutdown when problems happen How the “stack” is handled ◦ Each Communication. Object is “composed” of another Communication. Object (an inner instance) –this is the next Communication. Object in the stack of channels (In Design Patterns terms, this is the “Decorator Pattern”) ◦ This allows for a mechanism of allowing state transitions to propagate through the state without having any one Communication. Object having knowledge of the entire stack. The Transitions

IN THE CHANNEL LAYER (cont. ) � Channel Flavors ◦ Transport Channels � Channels used to implement transport protocols such as TCP/IP, UDP, HTTP(S) ◦ Protocol Channels � Channels used to implement messaging protocols like the WS-* specifications –for example: � WS-Reliable. Messaging � WS-Atomic. Transaction � WS-Secure. Conversation ◦ Shaping Channels � Channels that allow for a means of changing “shape” within the channel stack � These are “custom” channels

IN THE CHANNEL LAYER (cont. ) �Channel Managers (both are “Factories” in terms of Design Patterns) ◦ Channel Factories –Types used by senders to create channels �Create channels on demand �Created by a binding type and used to create Channel types �Stacked just like channels ◦ Channel Listener –Types used by receivers to create channels (really is a “factory” too) �Listen for incoming connections �Idea borrowed from the Berkley Sockets API �Returns channel types used for listening for messages �Stacked just like channels

CONCLUSION WCF is Microsoft’s flavor of a web-servicing framework. It’s communication’s functionality is exposed to user code via the service model layer while it’s mechanisms are abstracted away from the API and hidden in the Channel Layer. In the channel layer, the channel stack is responsible for sending & receiving messages between the sender and receiver participants while the service model layer is responsible for translating those messages to/from service method calls. The channel stack is where WCF gets a lot of it’s power and versatility. It’s similar to the traditional OSI model in that there are clearly separated layers with each layer using the services of the next layer down. It’s also very different from the OSI model in that there aren’t well defined layers each with their specific role –i. e. there is not a one-size-fits-all channel (or layer) since there are different requirements for different problem domains across a wide range of organizations, and it continues to change.

REFERENCES � [1] Microsoft Corporation ©. Channel Model Overview. 2009. http: //msdn. microsoft. com/enus/library/ms 729840. aspx. � [2] Smith, Justin. Inside Microsoft Windows® Communication Foundation. Microsoft Press. 2007 � [3] Wikipedia, The Free Encyclopedia. http: //en. wikipedia. org/wiki/Windows_Communicati on_Foundation. � [4] Yasser Shohoud. ”Yasser's personal space on the Web”. Meet the WCF Channel Model - Part 1. http: //blogs. msdn. com/yassers/archive/2005/10/12/ 480175. aspx.

QUESTIONS “Thank You!”