Describing the WCF architecture:


Here in this lesson we are going to talk about the contracts layer, the service run time layer that WCF offers us. We will also talk about the messaging layer, how to get messages in and out of the system using the messages and message classes that we have available and some called channel stacks. We will also describe activation in the hosting layer, the ability to actually start up our service and getting the service running and basically the engine or layer that actually maintains the instancing of our service object the actual instantiated service type class. So lets get started.

Contracts layer
What exactly are contracts?
Ans: Contracts are a way in which we can describe data, services, operations, messages, and in some aspect policies. We have 4 basic types of contracts – we have the data contracts, the message contracts, service contracts, and the operations contracts. Let’s first start with the data contracts. Data contracts in WCF help us to describe our data going in and out of a service. Starting with this notion of contract first in a service oriented (SO) world, Contracts force designers/ architects to start with the structure, or actual elements of data that we plan to use through our solution. We model that data in a descriptive way. However, we don't tie ourselves down with a specific technology as to how actually implement that data. This means, we can model the data using Schemas, UML diagrams, Text Files, really anything that explains: "these are the elements of information we need to pay attention to and collect." So that’s the idea of describing the data. There are many different ways in which we can describe the data. We can describe the data in a full fledged structure that might be written down in code like a class or something else. There is however, one caveat to using classes to describe the data. The code implementation somewhat takes us away from platform independence. In otherwords, if you describe the data as a class in .Net, that class can only be used in another .Net application. Thus there needs to be a way take this data and allow it to communicate with other platforms. We can do this through serialization.

Serialization is a way in which we can get from one form of the data to another that allows cross platform communication. Technically it allows your .Net class object populated with values to turn into a string or stream of bytes. The WCF model supports a new serializer called the XMLFormatter. This formatter makes it very easy to convert your class into a XML stream, based off of XML Elements. WCF, also allows us to represent our populated class using the .Net XML Serializer, and Serialization Surrogates. Enought of Data Contracts.

Message Contracts
Let's talk a little bit about message contracts. Message contracts give us the ability of describing the XML Soap message that is sent/received into a service. Said another way, it's a little bit different from being just the data contract. The data contract allows us to use very specific descriptions of the elements we plan to use while Message contracts allow us to specify transport protocol information, unique namespaces, security, transaction, coordination, metadata on message attachments, and any Custom
metadata that you need to send or receive. Message may also contain the data contract as well. So when we talk about message concepts we are really talking about that SOAP message. We are talking about the specific look and feel of the SOAP header and the SOAP body.

Service Contracts
Service contracts are again help us describe another mechanism. It allows us to describe the external interface that our service supports. It helps to expose the Methods/Operations that our service provides. It also allows us to describe the service instancing settings, such as if we need to maintain state between our service calls, sessions. Service contracts contain operation contracts. So think of service contracts as a way for you to mark an interface or a class that basically says, hey this class or interface contains all the basic functionality of what my service is going to contain, any transaction, session and instancing requirements or options.

Operation COntract
Last but not the least we have something called operation contracts. Operation contracts fine tune your function, your method. They allow you to be very specific about the method parameters, and the return types. They allow to do things like say if the method is a one way method, in other words, is this method just a setting where you just send me data I do not send you response or is this method more like a two way method or a method that actually returns some value. We can be very specific with operation contracts.

See Posts on BizTalk Exam 70-235:
See Posts

Dwight's first post