Moving from webservices to wcf services

Binu Bhasuran
Microsoft MVP Visual C#
Facebook http://facebook.com/codeno47
Blog http://proxdev.com/

Migrating a ASP.net web service to WCF service
and understanding the difference between
these two technologies.

WCF provides tools that can be used when software
entities must be made to communicate with one another
This will reduce the number of technologies that
developers are required to know in order to
accommodate different
software communication scenarios, which in turn will
reduce the cost of software development resources, as
well as the time to complete software development
projects.

WCF supports more Web service protocols than
ASP.NET Web services support.
These additional protocols provide for more
sophisticated solutions involving, amongst other
things, reliable sessions and transactions.

ASP.NET Web services only support sending messages by using the
Hypertext Transfer Protocol (HTTP).
WCF supports sending messages by using HTTP, as well as the
Transmission Control Protocol (TCP), named pipes, and Microsoft
Message Queuing (MSMQ).
More important, WCF can be extended to support additional
transport protocols. Therefore, software developed using WCF can be
adapted to work together with a wider variety of other software,
thereby increasing the potential return on the investment.

WCF provides much richer facilities for deploying
and managing applications than ASP.NET Web
services provides.
WCF offers a configuration editor, activity tracing
from senders to receivers and back through any
number of intermediaries, a trace viewer, message
logging, a vast number of performance counters,
and support for Windows Management
Instrumentation.

Continue to use ASP.NET Web services, and forego the
benefits proffered by WCF.
Keep using ASP.NET Web services with the intention of
adopting WCF at some time in the future.
Adopt WCF for new development, while continuing to
maintain your existing ASP.NET Web service applications.
Adopt WCF and migrate existing ASP.NET Web service
applications to WCF.

Windows Communication Foundation (WCF)
has an ASP.NET compatibility mode option to
enable WCF applications to be programmed and
configured like ASP.NET Web services, and
mimic their behaviour.

ASP.NET Web services was developed for building
applications that send and receive messages by using the
Simple Object Access Protocol (SOAP) over HTTP.
The structure of the messages can be defined using an
XML Schema, and a tool is provided to facilitate
serializing the messages to and from .NET Framework
objects.
The technology can automatically generate metadata to
describe Web services in the Web Services Description
Language (WSDL), and a second tool is provided for
generating clients for Web services from the WSDL.

Moving from webservices to wcf services

WCF is for enabling .NET Framework applications to
exchange messages with other software entities.
SOAP is used by default, but the messages can be in any
format, and conveyed by using any transport protocol.
The structure of the messages can be defined using an
XML Schema, and there are various options for serializing
the messages to and from .NET Framework objects.
WCF can automatically generate metadata to describe
applications built using the technology in WSDL, and it
also provides a tool for generating clients for those
applications from the WSDL.

Data Representation
Service Development
Hosting
Client Development
Message Representation
Service Description
Exception Handling
State Management
Security
Globalization

The development of a Web service with ASP.NET typically begins with
defining any complex data types the service is to use.
ASP.NET relies on the XmlSerializer to translate data represented by
.NET Framework types to XML for transmission to or from a service
and to translate data received as XML into .NET Framework objects.
Defining the complex data types that an ASP.NET service is to use
requires the definition of .NET Framework classes that
the XmlSerializer can serialize to and from XML. Such classes can be
written manually, or generated from definitions of the types in XML
Schema using the command-line XML Schemas/Data Types Support
Utility, xsd.exe

Only the public fields and properties of .NET Framework objects are
translated into XML.
Instances of collection classes can be serialized into XML only if the
classes implement either the IEnumerable or ICollection interface.
Classes that implement the IDictionary interface, such as Hashtable,
cannot be serialized into XML.
The great many attribute types in
the System.Xml.Serialization namespace can be added to a .NET
Framework class and its members to control how instances of the
class are represented in XML.

WCF application development usually also begins with
the definition of complex types. WCF can be made to use
the same .NET Framework types as ASP.NET Web
services.
The
WCF DataContractAttribute and DataMemberAttribute
can be added to .NET Framework types to indicate that
instances of the type are to be serialized into XML, and
which particular fields or properties of the type are to be
serialized, as shown in the following sample code.

//Example One:
[DataContract]
public class LineItem
{
[DataMember]
public string ItemNumber;
[DataMember]
public decimal Quantity;
[DataMember]
public decimal UnitPrice;
}

//Example Two:
public class LineItem
{
[DataMember]
private string itemNumber;
[DataMember]
private decimal quantity;
[DataMember]
private decimal unitPrice;
public string ItemNumber
{
get
{
return this.itemNumber;
}
set
{
this.itemNumber = value;
}
}
………. continues
}

The DataContractAttribute signifies that zero or
more of a type’s fields or properties are to be
serialized.
The DataContractAttribute can be applied to a
class or structure.
Instances of types that have
theDataContractAttribute applied to them are
referred to as data contracts in WCF. They are
serialized into XML using DataContractSerializer.

The DataMemberAttribute indicates that a
particular field or property is to be serialized.
The DataMemberAttribute can be applied to a
field or a property, and the fields and properties
to which the attribute is applied can be either
public or private.

The XmlSerializer and the attributes of
the System.Xml.Serialization namespace are designed to
allow you to map .NET Framework types to any valid type
defined in XML Schema, and so they provide for very
precise control over how a type is represented in XML.
The DataContractSerializer,DataContractAttribute and
DataMemberAttribute provide very little control over
how a type is represented in XML. You can only specify
the namespaces and names used to represent the type
and its fields or properties in the XML, and the sequence
in which the fields and properties appear in the XML:

By not permitting much control over how a type is to be represented in XML,
the serialization process becomes highly predictable for
theDataContractSerializer, and, thereby, easier to optimize. A practical
benefit of the design of the DataContractSerializer is better performance,
approximately 10% better performance.
The attributes for use with the XmlSerializer do not indicate which fields or
properties of the type are serialized into XML, whereas
theDataMemberAttribute for use with the DataContractSerializer shows
explicitly which fields or properties are serialized. Therefore, data contracts
are explicit contracts about the structure of the data that an application is to
send and receive.
The XmlSerializer can only translate the public members of a .NET object into
XML, the DataContractSerializer can translate the members of objects into
XML regardless of the access modifiers of those members.

As a consequence of being able to serialize the non-public members of types
into XML, the DataContractSerializer has fewer restrictions on the variety of
.NET types that it can serialize into XML. In particular, it can translate into
XML types like Hashtable that implement the IDictionary interface.
TheDataContractSerializer is much more likely to be able to serialize the
instances of any pre-existing .NET type into XML without having to either
modify the definition of the type or develop a wrapper for it.
Another consequence of the DataContractSerializer being able to access the
non-public members of a type is that it requires full trust, whereas
theXmlSerializer does not. The Full Trust code access permission give
complete access to all resources on a machine that can be access using the
credentials under which the code is executing. This options should be used
with care as fully trusted code accesses all resources on your machine.

The DataContractSerializer incorporates some support for versioning:
The DataMemberAttribute has an IsRequired property that can be
assigned a value of false for members that are added to new versions
of a data contract that were not present in earlier versions, thereby
allowing applications with the newer version of the contract to be able
to process earlier versions.
By having a data contract implement
the IExtensibleDataObject interface, one can allow
the DataContractSerializer to pass members defined in newer
versions of a data contract through applications with earlier versions
of the contract.

ASP.NET 2.0 introduced the option of adding the
attribute WebService and WebMethodAttribute to an interface rather than
to a class, and writing a class to implement the interface:
[WebService]
public interface IEcho
{
[WebMethod]
string Echo(string input);
}
public class Service : IEcho
{
public string Echo(string input)
{
return input;
}
}

The service contract defines the operations that the service can
perform.
The service contract is usually defined first, by
adding ServiceContractAttribute and OperationContractAttribute to an
interface
[ServiceContract]
{
[OperationContract]
string Echo(string input);
}

The ServiceContractAttribute specifies that the
interface defines a WCF service contract, and
the OperationContractAttribute indicates
which, if any, of the methods of the interface
define operations of the service contract.
Once a service contract has been defined, it is
implemented in a class, by having the class
implement the interface by which the service
contract is defined:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<services>
<service name="Service "> <endpoint
address="EchoService"
binding="basicHttpBinding" contract="IEchoService "/>
</service>
</services>
</system.serviceModel>
</configuration>
The system-provided binding, BasicHttpBinding, incorporates the set
of protocols supported by ASP.NET Web services.

ASP.NET Web services are compiled into a class
library assembly. A file called the service file is
provided that has the extension .asmx and
contains an @ WebService directive that
identifies the class that contains the code for
the service and the assembly in which it is
located.

Compile the service type into a class library
assembly.
Create a service file with a .svc extension with
an @ ServiceHost directive to identify the
service type:
Copy the service file into a virtual directory, and
the assembly into the bin subdirectory of that
virtual directory.
Copy the configuration file into the virtual
directory, and name it Web.config.

string httpBaseAddress = "http://www.contoso.com:8000/";
string tcpBaseAddress = "net.tcp://www.contoso.com:8080/";
Uri httpBaseAddressUri = new Uri(httpBaseAddress);
Uri tcpBaseAddressUri = new Uri(tcpBaseAddress);
Uri[] baseAdresses = new Uri[] {
httpBaseAddressUri,
tcpBaseAddressUri};
using(ServiceHost host = new ServiceHost(
typeof(Service), //”Service” is the name of the service type baseAdresses))
{
host.Open();
[…] //Wait to receive messages
host.Close();
}

WCF applications can also be configured to use .asmx as the extension for their service files rather than
.svc.
<system.web>
<compilation>
<compilation debug="true">
<buildProviders>
<remove extension=".asmx"/>
<add extension=".asmx"
type="System.ServiceModel.ServiceBuildProvider,
Systemm.ServiceModel,
Version=3.0.0.0,
Culture=neutral,
PublicKeyToken=b77a5c561934e089" />
</buildProviders>
</compilation>
</compilation>
</system.web>

Clients for ASP.NET Web services are generated
using the command-line tool, WSDL.exe, which
provides the URL of the .asmx file as input.
The corresponding tool provided by WCF
is ServiceModel Metadata Utility Tool (Svcutil.exe).
It generates a code module with the definition of
the service contract and the definition of a WCF
client class. It also generates a configuration file
with the address and binding of the service.

In programming a client of a remote service it is
generally advisable to program according to an
asynchronous pattern. The code generated by the
WSDL.exe tool always provides for both a
synchronous and an asynchronous pattern by
default.
The code generated by the ServiceModel Metadata
Utility Tool (Svcutil.exe) can provide for either
pattern. It provides for the synchronous pattern by
default. If the tool is executed with
the /async switch, then the generated code
provides for the asynchronous pattern

The headers of the SOAP messages sent and
received by ASP.NET Web services can be
customized. A class is derived
from SoapHeader to define the structure of the
header, and then the SoapHeaderAttribute is
used to indicate the presence of the header.

public class SomeProtocol : SoapHeader
{
public long CurrentValue;
public long Total;
}
[WebService]
{
SomeProtocol ProtocolHeader
{
get;
set;
}
[WebMethod]
[SoapHeader("ProtocolHeader")]
string PlaceOrders(PurchaseOrderType order);
}

public class Service: WebService, IEcho
{
private SomeProtocol protocolHeader;
public SomeProtocol ProtocolHeader
{
get
{
return this.protocolHeader;
}
set
{
this.protocolHeader = value;
}
}
string PlaceOrders(PurchaseOrderType order)
{
long currentValue = this.protocolHeader.CurrentValue;
}
}

The WCF provides the attributes,
MessageContractAttribute,
MessageHeaderAttribute, and
MessageBodyMemberAttribute to describe the
structure of the SOAP messages sent and
received by a service.

[DataContract]
public class SomeProtocol
{
[DataMember]
public long CurrentValue;
[DataMember]
public long Total;
}
[DataContract]
public class Item
{
[DataMember]
public string ItemNumber;
[DataMember]
public decimal Quantity;
[DataMember]
public decimal UnitPrice;
}
[MessageContract]
public class ItemMesage
{
[MessageHeader]
public SomeProtocol ProtocolHeader;
[MessageBody]
public Item Content;
}
[ServiceContract]
public interface IItemService
{
[OperationContract]
public void DeliverItem(ItemMessage itemMessage);
}

In ASP.NET Web services, unhandled exceptions are returned
to clients as SOAP faults. You can also explicitly throw
instances of the SoapException class and have more control
over the content of the SOAP fault that gets transmitted to
the client.
In WCF services, unhandled exceptions are not returned to
clients as SOAP faults to prevent sensitive information being
inadvertently exposed through the exceptions. A
configuration setting is provided to have unhandled
exceptions returned to clients for the purpose of debugging.
To return SOAP faults to clients, you can throw instances of
the generic type, FaultException, using the data contract type
as the generic type. You can also
addFaultContractAttribute attributes to operations to specify
the faults that an operation might yield.

[DataContract]
public class MathFault
{
[DataMember]
public string operation;
[DataMember]
public string problemType;
}
[ServiceContract]
public interface ICalculator
{
[OperationContract]
[FaultContract(typeof(MathFault))]
int Divide(int n1, int n2);
}

try
{
result = client.Divide(value1, value2);
}
catch (FaultException<MathFault> e)
{
Console.WriteLine("FaultException<MathFault>: Math
fault while doing "
+ e.Detail.operation
+ ". Problem: "
+ e.Detail.problemType);
}

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

Moving from webservices to wcf services

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to Moving from webservices to wcf services (20)

More from Binu Bhasuran (10)

Recently uploaded (20)

Moving from webservices to wcf services