Jaszeer’s Weblog

Inside WCF

Posted on May 25, 2011. Filed under: Uncategorized | Tags: .SVC, ASMX, FaultContract, ServiceDebug, WCF |

The Revolution of WCF

Obviously
the limitations of ASMX have led the revolution of WCF. So what are those limitations
for ASMX?

The revolution of ASMX came into existence
when you had to talk to get data from other service providers before the ASMX
companies used to have their own common standard mechanism to converse the
trade in the between the companies like EDI or calling a asp  pages. A company would publish their
application as ASMX only if it was really distributed or enterprise
application, so enterprise or distributed application is usually built on ASMX
along with WSE extensions, MSMQ, COM and .NET and as we know from our
experience that there were countless successful apps built on these concepts so
Microsoft realized they have too many layers.

The
limitations of ASMX

1. RPC calls
2. Dependent on
   HTTP/IIS
3. Classic XmlSerializer

So,
Microsoft realized lets upgrade ASMX so that it can serve for other protocols
and later realize why can’t we do the same for HTTP protocol which evolve WCF –
basicHTTP

Let’s look into the difference between ASMX
and WCF

ASMX

• Uses XmlSerializer
• Serializes only Public methods
• Soap Extentions, Customized SOAP Messages
• Requires HTTP transportation with IIS
• .asmx
• Role-based security
• Unhandled exceptions are handled as SOAP Faults
• Soap Exception is generic exception to handle errors
• Uses HTTPContext Object for state storage

WCF

• Uses DataContractSerialzier
• Serializes all methods including private methods
• However it does support XmlSerialization
• Soap Extentions arent supported
• Transportation protocols HTTP. TCP, MSMQ, named pipes
• .svc
• You can still use asmx for WCF just to support asmx client apps
  just by adding handler on the app.config
• Supports Claims based security model  and doesn’t depend on WSE mechanism
• Unhandled exception thorws a SOAP Faults but you override this behavior
  by adding a servicedebug element
• Faultexception<T> where T is the datacontract , you can use
  DataContract to define FaultContract
• ·
  You can use HTTPContext Object and as well
  implement System.ServiceModel.IExtensibleObject<T>
  interface (ServiceHostBased and InstanceContext)
• ServiceHostBased allows access to
  all the service instances in the same host to access the same state data. The instancecontext
  allows only in one instance

Code Samples
for WCF

         <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>

<configuration>
    <system.serviceModel>
        <services>
            <service name="Service ">
                <endpoint
                    address="EmployeeService"
                    binding="basicHttpBinding"
                    contract="IEmployeeService "/>
            </service>
        </services>
    </system.serviceModel>
</configuration>

 

[DataContract]

public
class FindEmployeeFault

{

[DataMember]

public string Request;

[DataMember]

public string Description;

}

[ServiceContract]

public
interface IEmployeeManager

{
[OperationContract(Action = "FindEmployeeByLastName")]
[FaultContract(typeof(EmployeeService.FaultContracts.FindEmployeeFault))]
EmployeeService.DataContracts.Employee FindEmployeeByLastName(string request);

}

 

 

Make a Comment