Difference between Data Contract and Message Contract in WCF

Data Contracts:

WCF data contracts provide a mapping function between .NET CLR types that are defined in code and XML Schemas Definitions defined by the W3C organization (www.w3c.org/) that are used for communication outside
the service.

Message Contracts:

Message contracts describe the structure of SOAP messages sent to and from a service and enable you to inspect and control most of the details in the SOAP header and body. Whereas data contracts enable interoperability through the XML Schema Definition (XSD) standard, message contracts enable you to interoperate with any system that communicates through SOAP. Using message contracts gives you complete control over the SOAP message sent to and from a service by providing access to the SOAP headers and bodies directly. This allows use of simple or complex types to define the exact content of the SOAP parts.

2. Why is it useful to pass information in SOAP headers with Message contract?

Passing information in SOAP headers is useful if you want to communicate information “out of band” from the operation signature. For instance, session or correlation information can be passed in headers, rather than adding additional parameters to operations or adding this information as fields in the data itself. Another example is security, where you may
want to implement a custom security protocol (bypassing WS-Security) and pass credentials or tokens in custom SOAP headers. A third example, again with security, is signing and encrypting SOAP headers, where you may want to sign and/or encrypt some or all header information. All these cases can be handled with message contracts. The downside with this technique is that the client and service must manually add and retrieve the information from the SOAP header, rather than having the serialization classes associated with data and operation contracts do it for you.

3. Can't mix datacontracts and messagecontracts.

Because message-based programming and parameter-based programming cannot be mixed, so you cannot specify a DataContract as an input argument to an operation and have it return a MessageContract, or specify a MessageContract as the input argument to an operation and have it return a DataContract. You can mix typed and untyped messages, but not messageContracts and DataContracts. Mixing message and data contracts will cause a runtime error when you generate WSDL from the service.

Using Web Services in ASP.NET AJAX

This topic describes how to access Web services from client script in AJAX-enabled ASP.NET Web pages. The services can be either custom services that you create, or built-in application services. The application services are provided as part of ASP.NET AJAX, and include authentication, roles, and profile services.

Custom Web services can be in the form of .ASP.NET Web services (.asmx services), or Windows Communication Foundation (WCF) services (.svc services).
 
ASP.NET enables you to create Web services that can be accessed from client script in Web pages. The pages communicate with the server through a Web service communication layer that uses AJAX technology to make Web service calls. Data is exchanged asynchronously between client and server, typically in JSON format.
 

Client-Server Communication for AJAX Clients

In AJAX-enabled Web pages, the browser makes an initial request to the server for the page, and then makes subsequent asynchronous requests to Web services for data. The client communication elements are in the form of downloaded proxy classes from the server and the core client-script library. The server communication elements are handlers and custom services. The following illustration shows the elements that are involved in the communication between the client and the server.

AJAX Client Architecture

Browsers call Web service methods by using proxy classes. A proxy class is a script that is automatically generated by the server and downloaded to the browser at page-load time. The proxy class provides a client object that represents the exposed methods of a Web service.

To call a Web service method, client script calls the corresponding methods of the proxy class. The calls are made asynchronously, through the XMLHTTP object.

The Web service communication layer contains the library script types that enable the proxy classes to make service calls. For more information, see the classes that are contained in the Sys.Net namespace.

The code in the proxy classes and in the core Web service communication layer hides the complexity of XMLHTTP and the differences between browsers. This simplifies the client script that is required to call the Web service.

There are two approaches to making a Web service request:

Call Web services by using the HTTP POST verb. A POST request has a body that contains the data that the browser sends to the server. It does not have a size limitation. Therefore, you can use a POST request when the size of the data exceeds the intrinsic size limitation for a GET request. The client serializes the request into JSON format and sends it as POST data to the server. The server deserializes the JSON data into .NET Framework types and makes the actual Web service call. During the response, the server serializes the return values and passes them back to the client, which deserializes them into JavaScript objects for processing.

Call Web services by using the HTTP GET verb. This resembles the functionality of a POST request, with the following differences:

The client uses a query string to send the parameters to the server.

A GET request can call only a Web service method that is configured by using the ScriptMethodAttribute attribute.

Data size is limited to the URL length allowed by the browser.

 

AJAX Client Architecture

 

Elements of the client architecture include the Web service communication layer in the core library and the downloaded proxy classes for the services that are used on the page. Individual elements shown in the figure are as follows:

Custom Service Proxy Classes. These consist of client script that is automatically generated by the server and downloaded to the browser. The proxy classes provide an object for each WCF or ASMX service that is used in the page. (That is, they provide an object for each item in the ServiceReferences element of the ScriptManager control in the page.) Calling a proxy method in client script creates an asynchronous request to the corresponding Web service method on the server.

Authentication Proxy Class. The AuthenticationService proxy class is generated by the server authentication application service. It enables the user to log on or log out through JavaScript in the browser without making a round trip to the server.

Role Proxy Class. The RoleService proxy class is generated by the server roles application service. It enables you to group users and treat each group as a unit through JavaScript without making round trips to the server. This can be useful to enable or deny access to resources on the server.

Profile Proxy Class. The ProfileService class is generated by the server profile application service. It makes the current user's profile information available to the client through JavaScript without making round trips to the server.

Page Methods Proxy Class. This provides the scripting infrastructure for client script to call static methods in an ASP.NET page as if they were Web service methods. For more information, see Calling Web Services from Client Script.

Web Service Communication Layer. This is the library that contains the client script types. These types enable the browser (client) to communicate with the services on the server. They also shield client applications from the complexities of establishing and maintaining the asynchronous communication between client and server. They encapsulate the browser XMLHTTP object that provides the asynchronous capability, and enable client applications to be browser independent. The following are the main elements of the Web service communication layer:

WebRequest . This provides client script functionality to make a Web request. For more information, see the WebRequest class.

WebRequestManager . This manages the flow of the Web requests issued by the WebRequest object to the associated executor object. For more information, see the WebRequestManager class.

XmlHttpExecutor . This makes asynchronous network requests by using the browser's XMLHTTP support. For more information, see the XmlHttpExecutor class.

JSON Serialization. This serializes JavaScript objects into JSON format. Deserialization is available by using the JavaScript eval function. For more information, see the JavaScriptSerializer class.

The default serialization format is JSON, but individual methods in Web services and in ASP.NET Web pages can return alternative formats such as XML. The serialization format of a method can be specified with attributes. For example, for an ASMX service, you can set the ScriptMethodAttribute attribute to cause a Web service method to return XML data, as shown in the following example:
 
[ScriptMethod(ResponseFormat.Xml)]

AJAX Server Architecture

Elements of the server architecture include the Web service communication layer with a HTTP handler and serialization classes, custom services, page methods, and application services. Individual elements shown in the figure are as follows:

Custom Web Services. These provide the service functionality that you implement and return the appropriate response to the client. Custom Web services can be ASP.NET or WCF services. The Web service communication layer automatically generates client-script proxy classes that can be called asynchronously from client script.

Page Methods. This component enables a method in an ASP.NET page to be called as if it were a Web service method. Page methods must be defined in the page that is performing the page-method call.

Authentication Service. The authentication service generates an authentication proxy class that enables the user to log on or log out through client JavaScript. This application service is always available and you do not have to instantiate it. For more information, see Using Forms Authentication with ASP.NET AJAX.

Role Service. The role service generates a role proxy class that enables client JavaScript to access roles information for the currently authenticated user. This application service is always available and you do not have to instantiate it. For more information, see Using Roles Information with ASP.NET AJAX.

Profile Service. The profile service generates a profile proxy class that enables client JavaScript to get and set profile properties for the user that is associated with the current request. This application service is always available and you do not have to instantiate it. For more information, see Using Profile Information with ASP.NET AJAX.

JSON Serialization. The server JSON serialization component enables customizable serialization and deserialization of common .NET Framework types to and from JSON format. For more information, see JavaScriptSerializer.

XML Serialization. The Web service communication layer supports XML serialization for SOAP requests to Web services and for returning XML types from a JSON request to a Web service.

reference: http://msdn.microsoft.com/en-us/library/bb515101.aspx

 

How to enable WCF tracing

Open config file in svcconfigeditor, from wizard, you can enable tracing and logging


STEP1:
Open config file in svcconfigeditor

STEP2:
Select Diagnostics option on left side, you will see Different tracing options on right side

STEP3:
If you just want to log soap request and response, you can choose Message Tracing

If you want trace service creation and all other activities, you can enable service tracing

Once you choose one of those options, you can choose, what level of tracing you want

(Like Verbose, or you want trace only error messages)

STEP4:
Click on Message Tracing, you will see different Message logging options, you can choose, you want to log Message at Transport level or Service level.

Reference:

http://msdn.microsoft.com/en-us/library/ms732009.aspx

Ok, Now I got trace file, How to view trace file:

Once you have log file, you can open client side trace and service side trace file in svctraceviewer and you can filter trace by different categories

http://windowssdk.msdn.microsoft.com/en-us/library/ms732023.aspx

Tracing and Logging Sample

http://msdn.microsoft.com/en-us/library/ms751526.aspx

MORE INFO ABOUT WMI AND PERF COUNTERS:

http://msdn.microsoft.com/en-us/library/ms735120.aspx

http://msdn.microsoft.com/en-us/library/ms735098.aspx

http://msdn.microsoft.com/en-us/library/ms751442.aspx
 
http://msdn.microsoft.com/en-us/library/ms751407.aspx
 
MORE INFO:


The Diagnostics tab enables you to turn performance counters on or off, enable or disable Windows Management Instrumentation (WMI), configure WCF tracing, and configure Windows Communication Foundation (WCF) message logging.

To control performance counters and WMI

Click the Diagnostics tab.

To turn on WCF performance counters, select the Enable Performance Counters check box. Clear the box to turn off the counters.

To turn on WMI, select the Enable WMI check box. Clear the box to disable WMI.

Configuring Tracing

You can create a WCF trace file with standard properties or set up a custom trace file.

To create a trace file with standard properties

Click the Diagnostics tab and click Tracing.

In the Diagnostics Tracing window that opens, click Create.

Choose a location for the trace file, and click Save.

Click OK to return to the Service Configuration Editor window.

To create a custom WCF trace file, you must configure both a source and listener.

To create a custom WCF trace file

Click the Diagnostics tab, and then click Tracing.

In the Diagnostics Tracing window that opens, on the Listeners tab, click Add.

Enter the parameters for your trace file. Clicking the TypeName line displays a "…" button. Click the "…" button to open Trace Listener Type Browser, which you can use to find preconfigured trace listeners that are already installed.

Note the Source section. Click Add in this section to open a dialog box with a drop-down menu listing available tracing sources. Select a tracing source and click OK.

To apply your changes, click OK on each window until you return to the main Service Configuration Editor window.

Configuring Message Logging

You can create a WCF message logging file with standard properties or set up a custom logging file.

To create a message logging file with standard properties

Click the Diagnostics tab and click Logging.

In the Message Logging Editor window that opens, click the Create button.

Choose a location for the log file and click Save.

Click OK to return to the Service Configuration Editor window.

To create a custom WCF message logging file, you must configure a source and a listener, as well as certain parameters.

To create a custom WCF message logging file

Click the Diagnostics tab and click Logging.

In the Message Logging Editor window that opens, on the Listeners tab, click Add.

Enter the parameters for your trace file. Clicking the TypeName line displays a "…" button. Click the "…" button to open the Trace Listener Type Browser, which you can use to find preconfigured trace listeners that are already installed.

Note the Source section. Click Add in this section to open a dialog box with a drop-down menu listing available tracing sources. Select a tracing source and click OK.

Click the Logging tab to set logging parameters. For example, you might want to set LogEntireMessage to False to help manage the size of log files.

To apply your changes, click OK on each window until you return to the main Service Configuration Editor window.

WCF Advantages over Web Service

WCF supports more of the WS-* standards than Web Services. You can’t really do streaming or support atomic transactions etc in Web Services. WCF supports multiple binding’s HTTP, WSHTTP, TCP, MSMQ etc. ASP.NET Web Services has only http.



Web Services have no instance management, i.e. you cannot have a singleton web service, or a session-full web service. You can maintain state of web services but we all know how painful that is.



WCF while very similar to Web Services also incorporates many of the features of Remoting and .NET Enterprise Services (COM+ Services Components).



It is flexible and extensible like Remoting only more so.

It is compatible like Web Services only more so.

It is feature rich like Enterprise Services only more so



1) WCF can maintain transaction like COM+ Does

2) It can maintain state

3) It can control concurrency

4) It can be hosted on IIS, WAS, Self hosting, Windows services

5) It has AJAX Integration and JSON (JavaScript object notation) support

References:
http://www.code-magazine.com/article.aspx?quickid=0611051&page=1