Difference between ASP.Net Web services and .NET Remoting 1. What are the differences between ASP.

Net Web services and .NET Remoting? S.No 1 Features Protocol ASP.Net Web services It can be accessed only over HTTP .NET Remoting It can be accessed over any protocol (including TCP, HTTP, SMTP and so on) It provides support for both stateful and stateless environments through Singleton and SingleCall objects Using binary communication, .NET Remoting can provide support for rich type system

State Management

Web services work in a stateless environment

Type System

Web services support only the datatypes defined in the XSD type system, limiting the number of objects that can be serialized. Web services support interoperability across platforms, and are ideal for heterogeneous environments Highly reliable due to the fact that Web services are always hosted in IIS

Interoperability

.NET remoting requires the client be built using .NET, enforcing homogenous environment. Can also take advantage of IIS for fault isolation. If IIS is not used, application needs to provide plumbing for ensuring the reliability of the application Very extensible by allowing us to customize the different components of the .NET remoting framework. Complex to program.

Reliability

Extensibility

Provides extensibility by allowing us to intercept the SOAP messages during the serialization and deserialization stages. Easy-to-create and deploy.

Ease-of-Programming

Reference: http://onlydifferencefaqs.blogspot.in/2012/07/difference-between-aspnet-webservices.html Difference between API and WebServices S.No 1 API API returns the output in the form of void,scalar or generic type We need to add references for API WebServices Web Services gives the output in the form of XML or JSON We need to add web references for web-services

Reference: http://onlydifferencefaqs.blogspot.in/2012/08/difference-between-api-andwebservices.html Difference Between SOAP and RESTful webservices Difference between SOAP and RESTful webservices (OR) Difference between SOAP and REST S.No 1 SOAP Developer View: Object oriented 2 Standards Based: Yes . SOAP web services are based on SOAP and WS-* specifications For acquiring security tokens,it uses WS-Trust. For conveying security tokens, it uses WS-Security For defining policy, it uses WSPolicy For suppoting distributed ACID transactions, it uses WSAtomicTransaction and WSCoordination REST Developer View: Resource Oriented Standards Based: No

For acquiring interface definitions, it uses WSMetadataExchange For providing end-to-end reliability, it uses WSReliableMessaging For establishing security context, it uses WSSecureConversation 3 Security: SSL, WS-Security . WS-Security provides end-toend security covering message integrity and authentication 4 Transactions : WS-AtomicTransaction 5 Reliability : WS-ReliableMessaging 6 Performance: Good Transactions : No Reliability : Application specific Performance: Better Caching and lower message payload makes RESTful web services performance efficient and scalable 7 Caching : No 8 Message Size : Caching : GET operations can be cached Message Size : Security: SSL

Heavy, has SOAP and WS-* Lightweight, no extra xml markup specific markup 9 Message protocol : XML Communication Message protocol : Communication

XML, JSON, other valid MIME type . This flexibility of REST makes its

extremely useful in providing consumer need specific message payloads 10 Message Encoding : Yes Message Encoding : No

SOAP Web Services support RESTful encoding is limited to text text and binary encoding 11 Service Description : WSDL Service Description : No formal contract definition In REST, no formal way to describe a service interface means more dependence on written documentation 12 Human intelligible Payload : No 13 Developer Tooling : Yes Human intelligible Payload : Yes Developer Tooling : Minimal or none

Complexity of SOAP Web REST on the other hand due to its Services dictates the need for simplicity can be developed without using frameworks to facilitate any framework rapid application development. 14 Orientation : Wraps business logic 15 Abbreviation: Orientation : Accesses resources/data Abbreviation:

SOAP stands for Simple REST stands for Representational Object Access Protocol State Transfer 16 Who is using SOAP? Google seams to be consistent in implementing their web services to use SOAP, with the exception of Blogger, which uses XML-RPC. You will find SOAP web services in lots of enterprise software as well. Who is using REST? All of Yahoo's web services use REST, including Flickr, del.icio.us API uses it, pubsub, bloglines, technorati, and both eBay, and Amazon have web services for both REST and SOAP.

17

Simplicity: No

Simplicity: Yes Transport protocol support: HTTP

18

Transport protocol support: HTTP, SMTP, JMS Multiple transport protocol support makes SOAP Web Services flexible

Areas where SOAP based WebServices is a great solution: Asynchronous processing and invocation: If application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM WS-Reliable Messaging etc. Formal contracts: If both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction. Stateful operations: If the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing. Areas where RESTful WebServices are a great choice: Limited bandwidth and resources: Remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX. Totally stateless operations: If an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is suitable. Caching situations: If the information can be cached because of the totally stateless operation of the REST approach, this is perfect. Reference: http://onlydifferencefaqs.blogspot.in/2012/08/difference-between-soap-andrestful.html svcutil.exe vs wsdl.exe Difference between svcutil.exe and wsdl.exe S.No 1 SVCUTIL.EXE WSDL.EXE

Svcutil.exe tool is meant to be Wsdl.exe tool is meant to be used used with WCF services and it with ASMX services and generates can translate back and forth only proxy code. between metadata and code.

The default behavior for The default behavior for Wsdl.exe Svcutil.exe is to generate is to generate both synchronous synchronous methods and it and asynchronous methods will generate asynchronous methods only if the /async option is used. Svcutil.exe tool also supports Wsdl.exe does not support policy new features in WCF, such as section feature as like Svcutil.exe. a policy section in a WSDL file that can be used to describe services security requirements. Svcutil.exe tool can be used to Wsdl.exe tool cannot be used to generate metadata. generate metadata. The Svcutil.exe tool can be Wsdl.exe supports attribute-based used only with XML Schema schemas. (XSD) files that support data contracts. If data contracts cannot be generated, we must use the Xsd.exe tool to generate XML-based data types from the XSD file.Therefore,it does not support attribute-based schemas.

4 5

Reference: http://onlydifferencefaqs.blogspot.in/2012/09/difference-between-svcutilexeand.html