DotNet FrameWork – what an Interface is and how it’s different from a Class – difference between XML Web Services using ASMX and .NET Remoting using SOAP – Serialization and Metadata – Day 25 of 30

Describe what an Interface is and how it’s different from a Class.

An interface is a structure of code which is similar to a class. An interface is a prototype for a class and is useful from a logical design perspective. Interfaces provide a means to define the protocols for a class without worrying about the implementation details. The syntax for creating interfaces follows:

interface Identifier {  InterfaceBody  }

Identifier is the name of the interface and InterfaceBody refers to the abstract methods and static final variables that make up the interface. Because it is assumed that all the methods in an interface are abstract, it isn’t necessary to use the abstract keyword

An interface is a description of some of the members available from a class. In practice, the syntax typically looks similar to a class definition, except that there’s no code defined for the methods — just their name, the arguments passed and the type of the value returned.

So what good is it? None by itself. But you create an interface so that classes will implement it.

But what does it mean to implement an interface. The interface acts as a contract or promise. If a class implements an interface, then it must have the properties and methods of the interface defined in the class. This is enforced by the compiler.

Broadly the differentiators between classes and interfaces is as follows

• Interface should not have any implementation.

• Interface can not create any instance.

• Interface should provide high level abstraction from the implementation.

• Interface can have multiple inheritances.

• Default access level of the interface is public.

What is the difference between XML Web Services using ASMX and .NET Remoting using SOAP?

ASP.NET Web services and .NET Remoting provide a full suite of design options for cross-process and cross-plaform communication in distributed applications. In general, ASP.NET Web services provide the highest levels of interoperability with full support for WSDL and SOAP over HTTP, while .NET Remoting is designed for common language runtime type-system fidelity and supports additional data format and communication channels. Hence if we looking cross-platform communication than web services is the choice coz for .NET remoting .Net framework is requried which may or may not present for the other platform.

Serialization and Metadata

ASP.NET Web services rely on the System.Xml.Serialization.XmlSerializer class to marshal data to and from SOAP messages at runtime. For metadata, they generate WSDL and XSD definitions that describe what their messages contain. The reliance on pure WSDL and XSD makes ASP.NET Web services metadata portable; it expresses data structures in a way that other Web service toolkits on different platforms and with different programming models can understand. In some cases, this imposes constraints on the types you can expose from a Web service—XmlSerializer will only marshal things that can be expressed in XSD. Specifically, XmlSerializer will not marshal object graphs and it has limited support for container types.

.NET Remoting relies on the pluggable implementations of the IFormatter interface used by the System.Runtime.Serialization engine to marshal data to and from messages. There are two standard formatters, System.Runtime.Serialization.Formatters.Binary.BinaryFormatter and System.Runtime.Serialization.Formatters.Soap.SoapFormatter. The BinaryFormatter and SoapFormatter, as the names suggest, marshal types in binary and SOAP format respectively. For metadata, .NET Remoting relies on the common language runtime assemblies, which contain all the relevant information about the data types they implement, and expose it via reflection. The reliance on the assemblies for metadata makes it easy to preserve the full runtime type-system fidelity. As a result, when the .NET Remoting plumbing marshals data, it includes all of a class’s public and private members; handles object graphs correctly; and supports all container types (e.g., System.Collections.Hashtable). However, the reliance on runtime metadata also limits the reach of a .NET Remoting system—a client has to understand .NET constructs in order to communicate with a .NET Remoting endpoint. In addition to pluggable formatters, the .NET Remoting layer supports pluggable channels, which abstract away the details of how messages are sent. There are two standard channels, one for raw TCP and one for HTTP. Messages can be sent over either channel independent of format.

Please read all the post in the Dotnet Framework series.

Reference : Dilip Kumar Jena ( https://mstechexplore.wordpress.com )