WCF - Introduction

Microsoft offers several technologies for developing distributed applications. Each is geared to a specific need, and among these technologies are: ASP.NET Web Services , WSE - Web Services Enhancements , NET Remoting , COM + - Enterprise Services and MSMQ - Message Queue . Each has its own API, with several types that should be studied so that we can develop an application that expose or consume resources of these technologies. When initiated the creation of the NET Framework 3.0, one of four major pillar inside him was the Indigo which later received the name of Windows Communication Foundation , or WCF simply. The unified the various technologies WCF programming distributed on the Microsoft platform in a single model, based on the service oriented architecture (SOA). This new API considerably facilitates learning and development, since WCF is fully decoupled from the business rules that will be exposed by the service. The purpose of this article is an introduction to WCF, building step-by-step a simple example of how to create and consume a service. To start making use of WCF, all we need in our application is referencing the assembly System.ServiceModel dll . This assembly has the most types needed for the construction of a service or a client. There are other assemblies that complement the WCF, such as the support for REST-based services, but that will be addressed in specific articles. structure The structure of a WCF service is not very complex, because we use pure concepts .NET programming for the creation of the contract and the class that represents the service. In addition, WCF also supports the use of complex types like classes that we created to meet a particular need. 's first step in the creation of the service is the definition of the contract. It is the contract that determines which operations are exposed, what information these operations need to be performed and also what will be the return type. The contract is nothing more than one interface which, in turn, must have methods (only your signature) that will be exposed. The interface that will serve as the contract shall be mandatorily decorated with the attribute ServiceContractAttribute , otherwise, an exception of type InvalidOperationException will be triggered before opening the host . Not always all the members exposed by the interface must be exposed to the service and, precisely because Therefore, all transactions will be made ​​available should be decorated with the attribute OperationContractAttribute . Remember that WCF requires at least one terms defined with this attribute, since it makes no sense to publish a service that has no operation to perform operation. If the interface does not have any operations defined with this attribute, an exception of typeInvalidOperationException also be triggered before opening the host . The code below displays an interface simple, which will serve as an example for the article:

using System; using System.ServiceModel; [ServiceContract] public interface IContrato { [OperationContract] User RecuperarUsuario (string name); }

For purposes of example, this interface will have only a single member, but it may contain several others and, as said above, you control the visibility of these members through the attribute OperationContractAttribute . As we can see, the method RecuperarUsuario returns an instance of class User . At this time two new attributes come into play:DataContractAttribute and DataMemberAttribute , both contained in System.Runtime.Serialization namespace , provided by System.Runtime.Serialization.dll assembly . 's date contracts are a way that you have to publish possible data structures that can be exchanged for sending and receiving a message. The use of the attribute DataContractAttributedetermines that a class can be exposed through a WCF service, and must be applied to all classes that are referenced as a parameter or return type in a contract ( interface ). Already primitive types like String , DateTime , Int32 , do not need it, since it can be serialized directly. Already attribute DataMemberAttribute should be applied in the fields and properties that have and the type that must be exposed through the service. This attribute will control the visibility of the field or property to customers who consume the service, regardless of access modifier ( public , private , etc.) you have. The following code defines a class User :

using System; using System.Runtime.Serialization; [DataContract] // Optional with NET 3.5 + SP1 public class User { [DataMember] // Optional with NET 3.5 + SP1 public string Name {get; set; } }

Note: As of Service Pack 1 .NET Framework 3.5 this behavior was changed. Aiming to support POCO ( Plain Old C # Objects ), Microsoft became more flexible use of data contracts in WCF services, not forcing the classes, properties and fields are decorated with the attributes mentioned above. Thus, only properties of type writing / reading will be serialized. From the moment you decorate the class with the attribute DataContractAttribute , you must also specify, viaDataMemberAttribute , which fields should be serialized. Remember also that the attribute XmlSerializableAttribute (System.Xml.Serialization namespace ) and the IXmlSerializable Interface ( namespace System .Xml.Serialization ) andISerializable ( System.Runtime.Serialization namespace ) also continue to be supported, allowing you to customize how the object is serialized / deserializados by WCF or any other feature provided .NET Framework. Once the contract of service is defined and the possible types that it exposes are also properly configured, the next step is to create the class that represents the service. This class must implement all the members exposed by the interface that defines the service contract, including those that are not marked with the attribute OperationContractAttribute , noting that the implementation of an interface in a class is an imposition of language, and not WCF. A implementation of methods may contain the very business rule and can serve as a wrapper for some other component or service. Moreover, the classes that represent the service can also configure some other features provided by WCF and are accessible via behaviorssuch as for example transactions, sessions, security, etc., but will see it more detail below. WCF fully decouples the rule of its API business, and rightfully so, that it is possible to notice in the code below that the class that represents the service has no configuration of WCF:

using System; public class Serve: IContrato { RecuperarUsuario public User (string name) { return new User () {Name = name}; } }

By itself this class does not work as it should be consumed by WCF. But after all, as it is determined that this class is responsible for meeting requests? This is accomplished through the host , or rather the class ServiceHost . Logo in the constructor of this class, you must pass an instance of the class Type , pointing to the class that represents the service and, necessarily, must implement all possible contracts that are exposed through endpoints . The configuration of thehost for this example will be discussed in the next section. Much of the attributes that we saw in this section provide several properties that allow us to interact with the serializer / deserializer message and, moreover, allow we specify some rules that will be validated before the opening the host and, if not met, an exception will be thrown. How these properties influence the various features exposed by the WCF, they will be addressed in detail in the articles that match your use. To know the available items, see the listing in the section Exploring other features . Hosting One of grandiosidades WCF is the ability to use any type of application as host , ie it does not have a dependency on some software, such as IIS ( Internet Information Services ), as was the case with ASP.NET Web Services . WCF can expose services to be accessed through various types of protocols, eg:. HTTP, TCP, IPC and MSMQ currently have three alternatives for hosting : self-hosting , IIS and the WPAS. As there are many details in creating and managing thehosting , would be too extensive to publish every detail, advantages and disadvantages to each of the technical features. For more details, see this article that explores each exposed by WCF to interact with the features hosting . 'shost is represented by the class within the WCF ServiceHost or one of its variations, and through it we make various settings, such as endpoints , security, etc. In its constructor, she hopes the class that represents the service, and may be defined by its type (class Type ) or through an instance of the same class previously created ( Singleton ). For the example used in this article, the partial configuration host is as follows:

using System; using System.ServiceModel; using (ServiceHost host = new ServiceHost (typeof (service) new Uri [] {new Uri ("net.tcp: // localhost: 9393")})) { // Endpoints host.Open (); Console.ReadLine (); }

Endpoints 
The endpoints are one of the most important characteristics of a service, as it is where all communication is performed because it provides access to customers WCF service that is being provided. To compose an endpoint , basically we need to define three properties that necessarily need to be able to work: address (A) binding (B) and contract (C) and optionally define some behaviors , which we will discuss further. The figure below illustrates the structure of endpointsand where they are located:

Figure 1 - Structure of an endpoint .

The address is to define a single address that will allow customers to know where the service is published. The address is usually defined through a class instance Uri . This class provides a constructor that takes a string containing the protocol, server, port, and the service address (used to differentiate between many services on the same site), having the following form: scheme: // host [: port] / [path] . Each of these configurations are represented respectively by the following properties of the class Uri : Scheme , Host , Port and AbsolutePath . protocol indicates in which of the protocols supported by WCF service is exposed. Currently we have the following protocols: HTTP (http: //), TCP (net.tcp: //), CPI (net.pipe: //) and MSMQ (net.msmq: //). The host refers to the machine where the service will be executed, and may also refer to the localhost . The port allows we specify a different port value will pattern?, And when omitted, it always assumes the default port specified by the protocol. And finally, we have the path that is used when we want to differentiate between various services exposed under the same protocol, host and port. 's binding indicates how communication will take place with that endpoint , such as transport which will be used (HTTP, TCP, etc.), which the encoding used ( Binary or Text ) to serialize the message, security, transaction support, etc. WCF provides severalbindings , and through the table below we analyze the characteristics of each of them (with the options the default setting in bold):

Binding Features BasicHttpBinding Transport: HTTP. Security: None , Transport , Message and Mixed . Support for Transactions: Not. Duplex : Not. Sessions : Do not. Encoding : Text . Transfer Modes: Streaming and Buffered . WebHttpBinding Transport: HTTP. Security: None and Transport . Support for Transactions: Not. Duplex : Not. Sessions : Do not. Encoding : Text and MTOM. Transfer Modes: Streaming and Buffered . WSHttpBinding Transport: HTTP. Security: None , Transport , Message and Mixed . Support for Transactions: Yes. Duplex : Yes. Sessions : Yes. Encoding : Text and MTOM. Transfer modes: Buffered . WSDualHttpBinding Transport: HTTP. Security: None , Message and Mixed . Support for Transactions: Yes. Duplex : Yes. Sessions : Yes. Encoding : Text and MTOM. Transfer modes: Buffered . WSFederationHttpBinding Transport: HTTP. Security: None and Message . Support for Transactions: Yes. Duplex : Not. Sessions : Yes. Encoding : Text and MTOM. Transfer modes: Buffered . NetTcpBinding Transport: TCP. Security: None , Transport , Message and Mixed . Support for Transactions: Yes. Duplex : Yes. Sessions : Yes. Encoding : Binary . Transfer Modes: Streaming and Buffered . NetPeerTcpBinding Transportation: Peer. Security: Transport . Support for Transactions: Not. Duplex : Yes. Sessions : Do not. Encoding : -. Transfer modes: Buffered . NetNamedPipeBinding Transportation: IPC. Security: None and Transport . Support for Transactions: Not. Duplex : Yes. Sessions : Yes. Encoding : Binary . Transfer Modes: Streaming and Buffered . NetMsmqBinding Transportation: MSMQ. Security: None , Transport and Message . Support for Transactions: Yes. Duplex : Not. Sessions : Yes. Encoding : Binary . Transfer modes: Buffered . MsmqIntegrationBinding Transportation: MSMQ. Security: Transport . Support for Transactions: Yes. Duplex : Not. Sessions : Do not. Encoding : -. Transfer modes: Buffered .

Note: In the list of bindings we saw above, we still have the class CustomBinding which, as its name implies, enables the creation of a binding custom, defining what means of transport, coding, support or not the transactions, etc. Finally the latter feature a endpoint is the contract. As we have seen above, the contract is represented by an interface and since it is defined as a contract of service are those members who will be available to customers in the form of operations, defining the input parameters and the return type and the format of the message ( request-reply , one-wayor duplex ). What differentiates one interface of a standard interface that will be used as the service contract. The attributes that should be decorated in the same ( ServiceContractAttribute ) and also those members who will be part of the service ( OperationContractAttribute ) and should also pay attention to the types that are exposed as complex types must also be marked with a special attribute ( DataContractAttribute ), and properties that he will expose must be decorated with the attribute DataMemberAttribute , all as explained above. After knowing each of the characteristics of an endpoint , you must understand how to create and configure an endpoint . Each endpoint is represented by a class called ServiceEndpoint ( System.ServiceModel.Description namespace ) and has several properties that expose exactly the settings of an endpoint as Address , Binding and Contract . The creation can be performed in two ways: one by creating and setting the class instance ServiceEndpoint and adding it to the collection of Endpoints of the host , and the second and more conventional way is through the method AddServiceEndpoint class ServiceHost . The code below illustrates the configuration of an endpoint :

using System; using System.ServiceModel; using System.ServiceModel.Description; using (ServiceHost host = new ServiceHost (typeof (service) new Uri [] {new Uri ("net.tcp: // localhost: 3933")})) { host.AddServiceEndpoint (typeof (IContrato), new NetTcpBinding (), "srv"); host.Open (); Console.ReadLine (); }

Among the various overloads of the method there are AddServiceEndpoint , one accepts an instance of the class Typerepresenting the contract, the instance of one of the bindings available and finally the address, in turn, may be absolute or relative. Another important detail is that we need to have an address ( base address ) set in the constructor of the class ServiceHost with the same protocol used by binding it in the above case, should be net.tcp. And finally, you can create as many endpoints you want, even with different protocols. Behaviors By the time we created the contract types that are part of it and also the class that represents the service. With the exception of the configuration host and attributes, no other functionality was added to the WCF service. As the example is very simple, no additional configuration is required, but what about when services need the support of sessions, transactions, security features, etc.? Through behaviors can modify how the message is processed by WCF, and much of the WCF features are exposed through behaviors such as security, transactions, throttle , metadata, etc. Because behaviors are aspects of implementing the WCF, inserting or removing them does not affect the communication between the parties. Currently we have three different scopes of behaviors : operation behavior , behavior endpoint and service behavior . The first affects only the execution of a specific operation. The endpoint behaviors are used exclusively for one endpoint .Finally, the service behaviors makes possible something valid for the service as a whole, regardless of how manyendpoints any. WCF already has several behaviors created and ready to use, allows also creating our own behaviors , only implementing the IOperationBehavior Interfaces , IEndpointBehavior or IServiceBehavior . The behaviors will be addressed customized in a future article. Certain behaviors are implemented in the form of attribute and can be applied directly to the type or member where it should influence. An example of this are the attributesOperationBehaviorAttribute and ServiceBehaviorAttribute , where the first one can be applied in one operation and customizes security-related information and transactions. Already attribute ServiceBehaviorAttribute provides a multitude of service-related details, such as: instance management mode, synchronization, transactions, etc. These settings are not related to the contract, but the class that represents the service and exactly why the behaviors are to be applied to it, as is shown below:

using System; using System.ServiceModel; [ServiceBehavior (InstanceContextMode = InstanceContextMode.PerCall)] public class Serve: IContrato { [OperationBehavior (TransactionScopeRequired = true)] RecuperarUsuario public User (string name) { return new User () {Name = name}; } }

Still other behaviors that are not exposed as attributes, such as the ServiceMetadataBehavior which is a behavior that is applied to the service as a whole, as exposing managing metadata (more details on it below). To create a behaviors of service, you must instantiate it and add in the collection of Behaviors class ServiceHost , collection that is exposed through the property Description . Declarative form (via attributes) to add the behaviors is not just that. WCF allowsbehaviors to be added from the configuration files, which makes this process much more flexible. We will see more details about this technique below. Metadata - WSDL metadata play an important role within the WCF and any web service . Governed by world-known standards such as WSDL ( Web Services Description Language ) or WS-Policy / WS-MetadataExchange , using XML / XSD language to describe a service by specifying its operations and data types it supports. By default, the WCF does not publish metadata, having to do this explicitly just to reduce the attack surface.To make this publication basically added a behavior called ServiceMetadataBehavior that is contained in the namespace System.ServiceModel.Description the collection of behaviors of the service. This behavior has a Boolean property calledHttpGetEnabled that, when set to True , allows you to access the WSDL from a browser, or better, an HTTP address.This technique is widely used for publication of this document, since many times the service is exposed from a protocol that is inaccessible due to the policies of firewall . When we define the property HttpGetEnabled as True , we must have a base address with an HTTP address specified otherwise, an exception of type InvalidOperationException will be triggered before opening the host , stating the absence of an HTTP address. An alternative to this is to use the propertyHttpGetUrl class ServiceMetadataBehavior , specifying an absolute address for the WSDL document. The following code shows how to perform this configuration:

using System; using System.ServiceModel; using System.ServiceModel.Description; using (ServiceHost host = new ServiceHost (typeof (service) new Uri [] {new Uri ("net.tcp: // localhost: 3933")})) { host.Description.Behaviors.Add ( new ServiceMetadataBehavior () { HttpGetEnabled = true, HttpGetUrl = new Uri ("http: // localhost: 9393 /") }); host.AddServiceEndpoint (typeof (IContrato), new NetTcpBinding (), "srv"); host.Open (); Console.ReadLine (); }

In the above example, the WSDL will be available from the address http: // localhost: 9393 / , ie, we are publishing the WSDL in a different protocol from which the service will be available. Importantly, the metadata does not necessarily need to be exposed via HTTP. Service providers may provide their description from TCP or IPC. The only exception is when we use the Message Queue that, in turn, does not allow publishing metadata, forcing us to choose a different protocol such as HTTP. Yet another way to publish the WSDL document, which is creating a Endpoint specific to this, known as Metadata Exchange Endpoint or simply MEX Endpoint . Like any other endpoint , this type also requires special address, contract and binding and, except for the address, the two other features have some considerations. The first, the contract should always be IMetadataExchange Interface which, in time, is also contained in the namespace System.ServiceModel.Description . The members of this interface are irrelevant to the developer of the service, since it will be used exclusively by the runtime WCF. Importantly, even if it is part of the service, it should not be implemented in the class that represents it, but even using this technique, it is necessary that the behavior ServiceMetadataBehavioralso be added. To expose the metadata is also necessary to make some changes in binding . To avoid setting thebinding to each endpoint that we created metadata, Microsoft released a static class called MetadataExchangeBindings , which has several methods that return bindings properly configured to support the publication of metadata. Among these methods are: CreateMexHttpBinding , CreateMexHttpsBinding , CreateMexNamedPipeBinding andCreateMexTcpBinding , and choosing one will depend on the protocol where you want to publish the document. The code below illustrates how to perform the configuration of a MEX Endpoint :

using System; using System.ServiceModel; using System.ServiceModel.Description; using (ServiceHost host = new ServiceHost (typeof (service) new Uri [] {new Uri ("net.tcp: // localhost: 3933")})) { host.Description.Behaviors.Add (new ServiceMetadataBehavior ()); host.AddServiceEndpoint (typeof (IContrato), new NetTcpBinding (), "srv"); host.AddServiceEndpoint ( typeof (IMetadataExchange) MetadataExchangeBindings.CreateMexTcpBinding () "Mex"); host.Open (); Console.ReadLine (); }

Note: Both forms of publishing metadata can also be configured declaratively, ie, through the configuration file. We'll see more on this in the next section of this article. vs. Declarative Configuration Imperative Much of the settings that we have seen throughout this article can be done in two ways: declarative or imperative, where each of the two has its advantages and disadvantages. With the declarative way we have greater flexibility, since any change in level of service configuration can be performed without the need to recompile the application. We can open and edit the configuration file using a text editor, but that is conducive to errors, since it is not strongly typed. To circumvent this problem, we use a software provided by Microsoft itself, called Microsoft Service Configuration Editor , which provides an interface for this graphics. Already in the imperative mood, all creation and manipulation of any configuration, whether the binding , endpoints or behaviors will performed directly via code (C # or VB.NET). Among the advantages we have with this mode is the ability to mount the settings dynamically, these settings can come from any repository, perform conditional, etc., situations that does not support the declarative mode. Since this technique does not put any information in the configuration file, accidental settings do not damage your system. Like any example was based on the configuration imperatively, this section shows how to perform the configuration of bindings , behaviors andendpoints from a configuration file ( App.config or Web.config ). The fact that using it does not eliminate the need to create and open a host ( ServiceHost ); to detect if a file containing the settings of the service, they will be loaded from it. This "tying" is made ​​from the attribute name of the element service , as we see below:

<? Xml version = "1.0" encoding = "utf-8"?> <Configuration> <System.serviceModel> <Services> <Service name = "Host.Servico" behaviorConfiguration = "srvBehaviorConfig"> <Host> <BaseAddresses> <Add baseaddress = "net.tcp: // localhost: 9393 /" /> </ BaseAddresses> </ Host> <Endpoint name = "Srv" address = "srv" contract = "Host.IContrato" binding = "netTcpBinding" bindingConfiguration = "bindingConfig" /> <Endpoint name = "Mex" address = "mex" contract = "IMetadataExchange" binding = "mexTcpBinding" /> </ Service> </ Services> <Bindings> <NetTcpBinding> <Binding name = "bindingConfig"> <Security mode = "None" /> </ Binding> </ NetTcpBinding> </ Bindings> <Behaviors> <ServiceBehaviors> <Behavior name = "srvBehaviorConfig"> <ServiceMetadata httpGetEnabled = "true" httpGetUrl = "http: // localhost: 2322 /" /> </ Behavior> </ ServiceBehaviors> </ Behaviors> </system.serviceModel> </ Configuration>

* .Config

In the above, we should note that after the element system.serviceModel there is a sub-element called services which is a collection of services, and each service is represented by the element service . This element has an attribute calledname should reflect the full name of the class that represents the service, including the namespace . Following define the possible base address of the service and as such is related to a specific service configuration, it should be within the element service . yet element within the service there is a sub-element called endpoint where we can define eachendpoint ( address , binding and contract ), and may add as needed. Beyond the ABC configuration, the elementendpoint has an attribute called bindingConfiguration we can point to another section within the same configuration file, containing the configuration of binding , such as security, transfer modes, etc. In the above example, the endpoint "srv" attribute defines the bindingConfiguration as bindingConfig . element service provides an attribute calledbehaviorConfiguration and that lets you point to a section within the same configuration file, containing the possiblebehaviors of service and endpoint which, in the example above, we enable the publication of metadata. The purpose of setting the bindings and behaviors to be out of the element service is just for the sake of reuse, since we have the same configuration for various services that run in the same application. As stated previously, the creation of the class is still necessary ServiceHost but with little change. The class that represents the service should remain informed, while the second parameter, an array of objects of type Uri , should be entered as one array empty, otherwise, an exception of type ArgumentNullException will be thrown. We can notice through the code below which there is no longer any need to configure the endpoints or behaviors , they are loaded from the configuration file.

using System; using System.ServiceModel; using (ServiceHost host = new ServiceHost (typeof (service), new Uri [] {})) { host.Open (); Console.ReadLine (); }

Client configuration 
so we can make use of the service in client applications, it is necessary to make reference of this service. The reference is to create a class that will encapsulate all access to the service, which is also known as proxy . This process will read the metadata of the service, creating the proxy with the same members exposed, giving the impression to the consumer that is calling a local but, at runtime, the request will be forwarded to the remote service class. , we can make the creation of Proxy three different ways. The first is through the referral service through the IDE Visual Studio NET which, in turn, provides an option called Add Service Reference which requires reference to the service. The second option is to make use of utility svcutil.exe that given a URL to the service, it is also able to generate a class that will represent theproxy . Both options also automate the creation of the configuration file, which provides a declarative way all service settings. In making the reference, a local representation of the contract (will be created Interface ) as well as complex types that are part of the service. Furthermore, the class that represents the proxy inherits directly from abstract and generic class ClientBase <TChannel> which provides all the necessary implementation to allow customers to communicate with their service. This class will configure at run time necessary to perform the request properties, extracting such information from the configuration file. It is from this class that we begin to create the client code to make the request:

using System; using Client.Servico; using (ContratoClient ContratoClient = new proxy ()) { User User = proxy.RecuperarUsuario ("Israel ECSA"); Console.WriteLine (usuario.Nome); }

Note: If you engage the proxy in a block using (remember that it will be transformed into try / finally ), it is necessary to take some care. Not because the method Dispose will not be called, but where the execution of this method will affect the client application. Let's assume that an error occurs during the execution of the transaction and, as was to be expected, the block finally be triggered by calling the Dispose the proxy . In this case, the method Dispose does nothing more than to invoke the method Close . The problem here is that the method Close may require some extra activities, need to do some further communication with the service and if this time an error occurs, an exception of typeCommunicationObjectFaultedException is triggered, masking the real problem. Finally, the option to work around this potential problem is the method call Abort , who immediately closes the communication between the client and the service, as is demonstrated in this address . A third and final way that exists to make the communication between the client and the service is to perform all the configuration manually. This requires knowing exactly binding and their respective settings, which the address where the service is published and especially the interface of the contract and the types it exposes should be shared between the client and the service. Despite this sharing be simple to perform, because just isolate types in one assembly (DLL), the problem is when the number of clients increases considerably, making it difficult to distrubuição. In any event, given below is an example of how to perform this configuration:

using System; using System.ServiceModel; using (ChannelFactory <IContrato> srv = new ChannelFactory <IContrato> (new NetTcpBinding (), new EndpointAddress ("net.tcp: // localhost: 9393 /"))) { User u = srv.CreateChannel () RecuperarUsuario ("ECSA Israel."); Console.WriteLine (u.Nome); }

Exploring other features 
WCF provides several features that aim to performance, security, availability, and others that we can incorporate into our services to make them more rich, flexible and easy to handle. Each of the major features provided by it has an exclusive article that will address each of them in full. To access these articles, see the listing below:

• Messaging Types : Traditionally, in any type of application, we can create a method that does some task.When creating it, we can consume it in the same application to even reference the class in which it is contained and also consume them in various projects. To make a call to this method, we should expect its implementation and, when completed, we continue in the program. When creating an operation in a WCF service, it also behaves the same way. But this is not the only alternative provided by WCF. The focus of this paper is to explore such alternatives and how they influence the configuration and deployment and execution of service.
• Hosting : As we already know, WCF - Windows Communication Foundation - is an integral part of the NET Framework 3.0. It provides a set of classes for building and hosting services based on SOA (Service Oriented Architecture) architecture, which can expose such services to be accessed through various types of protocols such as: HTTP, TCP, IPC and MSMQ. Currently there are three types of hosts for services built on WCF self-hosting (through the ServiceHost class), IIS (Internet Information Services) and WAS (Windows Activation Services - Windows Vista), and this is exactly what this article will address, namely , how to configure each of these hosts to expose services built on WCF.
• Error Handling : No matter what type of application we are creating, mistakes can always happen. The same goes for services and are not exempt from that. In the case of services, the errors can be as varied as possible, with problems in transport (protocol), delivery / receipt of the message at runtime or even (and most common) in the execution of the operation (method ). WCF provides several techniques to analyze and treat the possible errors that occur during the execution of the service. The challenge here is how to make this problem (error) is passed to the client that consumes regardless of platform, giving it the ability to know what happened and how to bypass it, keeping the client application and stable proxy. This article will address how we should proceed to throw errors, notify the customer and how it can do to handle errors that occur.
• Instances Management : The instance management is a technique that is used by WCF or any other technology of distributed computing that determines how and by whom the client requests will be met. The choice of the management mode of instances directly affects the scalability, performance and transactions of a service / component, besides having some changes to the level of implementation of the contract, we need to pay attention to ensure that it operates under the management model chosen . The purpose of the article is basically to show each of the three techniques available for WCF but also addressing their respective benefits and some techniques that surround this process and that somehow are connected and influence the choice and / or implementation. The article will also address the care we should have the choice and implementation of each of the techniques provided.
• Synchronization : By exposing a service so that it is consumed, we must look to the possibility of this service being accessed simultaneously. This occurs when multiple requests (threads) try to access the same resource at the same time. The possibility of simultaneous accesses may occur depending on the type chosen for instance management service. The purpose of this paper is to show the three options provided by the WCF to treat competition and moreover, showing some of the various synchronization techniques provided by NET Framework and may be used in conjunction with WCF.
• Transfer and Data Encryption : One of the biggest benefits of Web services has in relation to distributed communication technologies is the use of XML as the basis for coding, thus allowing interoperability between various platforms. However, the choice of the coding standard and how to transfer this information to be adopted by service greatly influence the performance and interoperability of the same and also those who consume it. WCF provides some techniques and alternatives that we can take when setting up or creating a service. The purpose of this article is to show how to implement such a configuration / design and analyze the impacts (including the level of contract), benefits and limitations of each of these techniques.
• Asynchronous calls : Many times we developed a method to perform some task and after properly coded, invoke the same from any point in the application. Depending on what this method does, it can take some time to run and, if time is considerably high, we can begin to have problems in applying, because as the call is always performed synchronously, while the method does not return, the execution of system that makes use of it will freeze, awaiting the return of the method to follow up on implementation. The purpose of this article is to show how to implement asynchronous processing both client side ( proxy ) and server side (contract) in WCF services.
• Throttling and Pooling : Through the management of a service instance can define what form of creating an instance to serve a given request. This setting we make the level of service through a behavior , imposes no restriction on the amount of instance and / or concurrent executions are carried out, depending on the volume of requests that the service has or even the amount of resources it uses, can significantly degrade performance.The Throttling allows restricting the amount of sessions, concurrent instances and calls that are made ​​to a service. Besides throttling , there is another feature that can be used in a service which is the pooling of objects.This article will explain how to proceed to make configuration of Throttling and its implications; supercialmente also talk about the structure of the Pooling and how to implement it.
• Transactions : An existing need in many applications is to ensure data consistency during handling. When performing a task, we need to ensure that if a problem occurs, the data back to its initial state. In computing this is guaranteed by the use of transactions. Transactions have been around for some time, and the purpose of this article is to show the alternatives we have to incorporate them into services and clients that make use of WCF as a communication medium.
• Reliable Messages : When consuming a WCF service can interact with it through different mechanisms, such as request-reply or one-way . We know that regardless of which type you use, the message travels between the client and the service over the network, using the protocol specified by the binding . Thus, a major concern we have is with respect to guaranteed delivery of the message to its recipient because network problems can occur, causing the message to be intercepted or simply lost. The purpose of this paper is to present a technique provided by WCF to prevent problems like these undermine the consistency and execution of a service.
• Message Queue : When placing a call to an operation of a particular service, we wish it to be always executed. But there is not always as ensuring that, as the service that meets the requests, for some reason, is unavailable at the moment. This will make the requests are rejected and the customer will be able to run it only when the service is back on the air. To ensure message delivery and asynchronous processing of the transaction (even when the service is offline ), WCF uses the Microsoft Message Queue . This article will explore the features and especially the benefits provided by this integration.
• RESTFul Services : Version 3.5 Windows Communication Foundation introduced a new way of exposing and consuming services. This new model, also known as Web Programming Model allows the use of these services through various clients, such as web browsers. The purpose of this article is to explore the types that are available to make this possible.
• Syndication : Web syndication is a form popularly known we have to publish a content of a particular website to other websites or people. This technique provides its consumers a short summary or, sometimes, in its entirety, content that has been recently added to the site. From version 3.5, WCF provides an API to support the creation of services that expose your content in one of known formats for syndication API and this will be addressed throughout this article.
• Tracing : Any kind of application always requires a way to store any errors that may occur during execution.This will help immensely to diagnose problems that occur and consequently facilitate its solution. This is no different in WCF services. This article aims to demonstrate the integration WCF services that allow for the capture and persistence of errors for later analysis.
• Know Types : It is very common in any object-oriented language, create a base class and, from it, create derived classes. In addition, one of the great benefits we have with object orientation is the possibility to declare a variable of type base class and assign it an instance of a concrete class, and similarly, we have a function that in their parameters their types are specified with the type of the base class and, consequently, we can also pass instances of derived classes. Unfortunately does not work the same way when talking about services that are exposed from the WCF. In this scenario, by default, you can not use a derived rather than a base class. It is precisely this feature provided by WCF which we will review in this article.
• Security : One of the major challenges of software is its safety. In any software security today is not only to authenticate a user, but also that it has rights in the software. Things get more complicated when we talk about a distributed environment, making the process of authentication and authorization slightly more complex and, to top it off, we have to worry about the protection of requests traveling between the client and the server. The purpose of this article is to display all the possibilities we have to handle security in WCF services.
• Integration with MembershipProvider and RoleProvider : By default, WCF services use the identities and Windows groups for authentication and authorization, respectively. A major problem we have is when it is made ​​available through a web application, it would require that all clients accessing via web were properly registered within Windows; Furthermore, there is the problem with respect to groups of users, as they often do not have access to register them, and when it is not a problem, we have an additional problem when we are running on different servers cultures. With this, hardly an application or services that are exposed to the internet using the accounts and Windows groups. The solution is fortunately ASP.NET 2.0 provides a complete infrastructure for managing authentication and authorization, called the Provider Model . This integration is the subject of this article.
• Custom Authentication and Authorization : The WCF provides several possibilities to manage authentication and authorization within the services. One such possibility is to customize the WCF will authenticate and authorize the client, analyzing their credentials by checking whether these are valid in a given repository, determine what rights the customer has the service and ultimately grant or deny access to any operation relying on their privileges. The purpose of this article is to analyze the necessary steps for this customization.
• Partial Trust : The first version of WCF - NET Framework 3.0 - it was not supported in environments that were under Partial Trust, which forced many customers to grant more rights than necessary to be able to run / invoke a WCF service written in. After many requests, Microsoft has decided to loosen the security with the release of the NET Framework 3.5, enabling (with several restrictions) that services are invoked from a partially trusted environment. The purpose of this article is to show how to create a proxy for a service that exposes an endpoint not supported in this environment.
• Consuming services in AJAX : One of the great parts of the NET Framework 3.0 is WCF. When he was released, several ways to access the WCF services are also available. Among the forms, known as endpoints , we can mention some, such as HTTP, TCP and MSMQ. With the coming of ASP.NET AJAX, the need to consume WCF services directly within this type of application arose. Through Visual Studio NET 2008 and the NET Framework 3.5, Microsoft bothered with the need to consume WCF services in AJAX and took this opportunity to create abinding . This binding , called WebHttpBinding , it is a new type of binding that allows the creation of anendpoint to be consumed by AJAX applications that will be discussed in this article.
• Exposing COM + component : With the advent of WCF, one unified communications platform, Microsoft has not forgotten the legacy, ie large and complex components hosted in COM + and allows the use of WCF to expose this component via HTTP ( or otherwise). Contrary to what was previously with Web Services, we need not resort to Component Services for this. Along with the SDK NET Framework 3.x, Microsoft provides a tool called Microsoft Service Configuration Editor that among all features available, one of them is the possibility of integrating a COM + component to a WCF service, which will be the subject of this article.

Conclusion: The WCF provides a lot of functionality that can be easily added services. Moreover, most of these features can be configured declaratively through configuration files that in most cases, brings tremendous flexibility.The paper shows the basic necessary for creating and consuming a WCF service concepts that are important to give information after reading the above articles, which explore each of the major features.