Finally Microsoft is bringing their hodgepodge of communication technologies under one umbrella.

Perhaps things will get easier in the near future so developers don't have to worry about transport/messaging related plumbing (SOAP, MSMQ, .NET Remoting, etc.).

The Windows Communication Foundation: A Primer

"The WCF is an incremental, yet evolutionary technology that brings all the formerly distinct and separate Microsoft connectivity technologies together under a single umbrella within the System.ServiceModel namespace. Included in WCF are Web services (ASMX), the Web service Extensions (WS*), Microsoft Message Queuing (MSMQ), Enterprise Services, COM+, and .NET Remoting."


Get Connected

"Windows Communication Foundation is built from the ground-up to combine and extend the capabilities of existing Microsoft distributed systems technologies, including Enterprise Services, System.Messaging, .NET Remoting, ASMX, and WSE to deliver a unified development experience."

"The Windows Communication Foundation takes Web services to the next level. Support for the WS-* protocols means that Web services can easily take advantage of interoperable security, reliability, and transaction support required by businesses today. Developers can now focus on business logic and leave the underlying plumbing to Windows Communication Foundation."


Introduction to Building Windows Communication Foundation Services
.NET Remoting just didn't seem like it would fit into the SOA world. Even Microsoft seems to say this. WCF's programming model lets you write your services in a single approach, regardless of the underlying transport.


"If you want to write services that look and behave similar to "traditional" components, you can do so and don't worry too much about how WCF turns method calls into messages under the surface. WCF services also support sessions and allow very detailed control over the lifetime of service instances. Services built on WCF are therefore not limited to a particular architectural style of "stateless" services as it is the case with ASMX, but you can build services where instances are created and released for each call or a defined sequence of calls, where instances exist for the duration of a session, or you can even build singletons where one service instance is shared by all callers.

What you cannot do, and this is the great difference to RPC technologies like DCOM or Remoting, is to pass objects by reference or pass callback delegates. The reason for this restriction is that a service-oriented technology cannot make as many assumptions about the network as the local area network technologies DCOM or Remoting. Callbacks and object references require a callback path from the server to the client whereby the server can contact the client whenever needed. In an environment where we have to assume that services are distributed across platforms, trust boundaries and wide area networks, this sort of bi-directional connectivity very often does not exist. Clients may reside behind firewalls, or network address translation (NAT) services, or simply don't actively listen for messages. And even if they do, security restrictions typically mandate that any sender, including those returning calls, will have to authenticate and be authorized at any endpoint. Therefore, implicit backchannels such as those established by callbacks and object references simply don't work in a services world. Instead, such backchannels must be explicitly established using so-called "duplex" conversations, which is a topic that deserves a dedicated article altogether. "


Related Resources:
WCF Security Model

Microsoft on the Enterprise Service Bus (ESB) : Seems more of a 'response' than a solution.

Introduction to Building Windows Communication Foundation Services