These are the consolidated points from various web links to understand and
remember to understand the main difference between WCF service and SOAP Web Service.
1. WCF: Support multiple protocols (HTTP,TCP, Peer Network, IPC, MSMQ) whereas traditional webservices are limited to HTTP only.
2. WCF: messages are independent of the underlying transport protocol.
3. WCF: maintains the same programming model for the local and remote cases, thus it allows you to switch locations of the service without affecting the client.
4. WCF: services can communicate with non-WCF clients and non-WCF clients can communicate with WCF services.
5. WCF: Supports Multiple Bindings like HTTP, TCP, MSMQ etc whereas web services uses only HTTP
6. WCF: can maintain transaction like com+.
7. WCF: can maintain state.
8. WCF: can be hosted on IIS, Selfhosting, Windows Servies (Windows Application Service) .
9. We Service: The development of webservice with ASP.net relies on defining data and relies on the XMLSerializer to transform data to or from a service. Key Issues of XML Serailizer to serialize .net Types with XML.
10. Web service: Only Public fields and Properties of .net types can be translated to XML
11. Web service: Only the classes which implement IEnumerable Interface can be translated to XML.
12. Web service: Classes implementing IDictionary Interface such as Hash table cannot be serialized.
13. WCF Uses DataContract Attribute and DataMember Attribute to translate .net types to XMl.
14. DataContract Attribute can be used for classes and structures-DataMember Attribute to Field or Property.
15. WCF also supports many of the advanced WS-* Web service standards, which can provide rich Web service communication across platforms.
16. WCF can be extended to use protocols other than SOAP to communicate with Web services, for example, Rich Site Summary (RSS). It is interoperable with WSE 3.0, System.Messaging, .NET Enterprise Services, and ASMX Web services. This means that, with little or no change to code, existing applications that are built with these technologies can interoperate with WCF services. WCF contracts define the behavior of WCF services. They are created in code by service developers, and are exposed to clients in the service metadata. The five types of contracts:
a. Service Contracts
b. Operation Contracts
c. Data Contracts
d. Message Contracts
e. Fault Contracts
Diference between DataContractSerailizer
and XML Serializer is
17. DCS has better performance over XML Serialization
18. XML Serialization doesn't indicate which field or property of the type is serialized
19. DCS Explicitly shows which field or property is serialized
20. DCS can serialize classes implementing IDictionary interface(Hash Table)
Exception Handling
21. Web services: Unhandled exceptions are returned to the client as SOAP faults.
22. WCF: unhandled exceptions are not returned to clients as SOAP faults. A configuration setting is provided to have the unhandled exceptions returned to clients for the purpose of debugging.
1) One way methods are "fire and forget". The client which sends this message does not need to, or want to, receive a reply (at all). While you can _functionally_ achieve the same affect by using more traditional request/reply patterns (or by just making your callback empty as you suggest) -- you are still wasting CPU and network resources sending/receiving what ends up being a null message.
Also, in WCF 'void' methods are actually still Request/Reply (they are synchronous). This means that even though nothing will be returned in the reply, the client will still wait until it has received that reply before continuing on. This is still the case if you apply the Async pattern to the 'void' methods as well -- when you execute your End* method, it will block until it is finished executing etc.
This may be explained better in the conceptual docs for this topic: http://msdn2.microsoft.com/en-us/library/ms730149.aspx
2) Again, there is no reply message at all with one way messages. One would only need to have a CallbackContract IFF your service intends to send information back to a client.
3) If the service host is not alive, that call will still throw with an EndpointNotFound exception for instance or other similiar faults. How does this work? With HTTP when we send the request, even if it's a one-way operation, we still get back a HTTP 200 response (very small, very negligable) -- hence, the client still knows something is wrong if we do not see that HTTP 200 response.
4) WS-RM is primarily targeted at non-point-to-point communication exchanges OR for networks where connections are flakey; i.e. if you have a SOAP router involved you'll probably want WS-RM OR if you want your client to automatically reconnect to the service when that connection suddently dies. Also, WS-RM is not durable, like queues are. So in general, no, you wouldn't want to enable ReliableSessions (WS-RM) on your bindings if you are going to be using Queues -- unless there are intermediaries involved or other network conditions that plain TCP cannot handle.
5) Yes, the various MSDTC's involved (or WebSpheres or Axis's) all need to talk to each other -- and they each have their own port. By default when you configure WS-AT we will use port 443 (the common HTTPS port that is also usually open on server machines).
6) In general WCF does not offer such things. We do have several instancing options and timeouts that can be tweaked to help design for this, but in general, the only deadlock avoidance technique that exists is transaction timeouts.
What is .NET Remoting?
.NET Remoting is an enabler for application communication. It is a generic system for different applications to use to communicate with one another. .NET objects are exposed to remote processes, thus allowing interprocess communication. The applications can be located on the same computer, different computers on the same network, or even computers across separate networks.
.NET Remoting
versus Distributed COM
In the past interprocess communication between applications was handled through Distributed COM, or DCOM. DCOM works well and the performance is adequate when applications exist on computers of similar type on the same network. However, DCOM has its drawbacks in the Internet connected world. DCOM relies on a proprietary binary protocol that not all object models support, which hinders interoperability across platforms. In addition, have you tried to get DCOM to work through a firewall? DCOM wants to communicate over a range of ports that are typically blocked by firewalls. There are a ways to get it to work, but they either decrease the effectiveness of the firewall (why bother to even have the firewall if you open up a ton of ports on it), or require you to get a firewall that allows support for binary traffic over port 80.
.NET Remoting eliminates the difficulties of DCOM by supporting different transport protocol formats and communication protocols. This allows .NET Remoting to be adaptable to the network environment in which it is being used.
