Method Overloading in WCF

[ServiceContract]
public interface IGetEmployee
{
    [OperationContract(Name = "GetEmployeeDetailsById")]
    List GetEmployeeDetails(int id);

    [OperationContract(Name = "GetEmployeeDetailsByName")]
    List GetEmployeeDetails(String name);
}

     we can achive the method overloading through the name attribute of the operation contract set the alias name for the method .method name will appear based on the proxy class generation If you use the proxy class that is automatically generated by svcutility.exe, the alias method names will be used. However, you can manually edit the generated proxy class to achieve the appearance of overloaded methods on the client as well.This can be accomplished by applying the same attributes to the methods defined in the interface that is used by the proxy class.

Difference between BasicHttpBinding and WsHttpBinding

If we want to summarize in one sentence, the difference between WsHttpBinding and BasicHttpBinding is that WsHttpBinding supports WS-* specification. WS-* specifications are nothing but standards to extend web service capabilities.

Below is a detailed comparison table between both the entities from security, compatibility, reliability and SOAP version perspective.

Criteria	BasicHttpBinding	WsHttpBinding
Security support	This supports the old ASMX style, i.e. WS-BasicProfile 1.1.	This exposes web services using WS-* specifications.
Compatibility	This is aimed for clients who do not have .NET 3.0 installed and it supports wider ranges of clients. Many of the clients like Windows 2000 still do not run .NET 3.0. So older version of .NET can consume this service.	As its built using WS-* specifications, it does not support wider ranges of client and it cannot be consumed by older .NET version less than 3 version.
Soap version	SOAP 1.1	SOAP 1.2 and WS-Addressing specification.
Reliable messaging	Not supported. In other words, if a client fires two or three calls you really do not know if they will return back in the same order.	Supported as it supports WS-* specifications.
Default security options	By default, there is no security provided for messages when the client calls happen. In other words, data is sent as plain text.	As WsHttBinding supports WS-*, it has WS-Security enabled by default. So the data is not sent in plain text.
Security options	None Windows – default authentication Basic Certificate	None Transport Message Transport with message credentials

One of the biggest differences you must have noticed is the security aspect. By default, BasicHttpBinding sends data in plain text while WsHttpBinding sends it in encrypted and secured manner.

Transactions

    Transactions provide a way to group a set of actions or operations into a single indivisible unit of execution. A transaction is a collection of operations with the following properties:

• Atomicity. This ensures that either all of the updates completed under a specific transaction are committed and made durable or they are all aborted and rolled back to their previous state.
  
  
• Consistency. This guarantees that the changes made under a transaction represent a transformation from one consistent state to another. For example, a transaction that transfers money from a checking account to a savings account does not change the amount of money in the overall bank account.
  
  
• Isolation. This prevents a transaction from observing uncommitted changes belonging to other concurrent transactions. Isolation provides an abstraction of concurrency while ensuring one transaction cannot have an unexpected impact on the execution of another transaction.
  
  
• Durability. This means that once committed, updates to managed resources (such as a database record) will be persistent in the face of failures.

WCF Binding

There are multiple aspects of communication with any given service, and there are many possible communication patterns: messages can be synchronous request/reply or asynchronous fire-and-forget; messages can be bidirectional; messages can be delivered immediately or queued; and the queues can be durable or volatile. There are many possible transport protocols for the messages, such as HTTP (or HTTPS), TCP, P2P (peer network), IPC (named pipes), or MSMQ. There are a few possible message encoding options: you can chose plain text to enable interoperability, binary encoding to optimize performance, or MTOM (Message Transport Optimization Mechanism) for large payloads. There are a few options for securing messages: you can choose not to secure them at all, to provide transport-level security only, to provide message-level privacy and security, and of course there are numerous ways for authenticating and authorizing the clients. Message delivery might be unreliable or reliable end-to-end across intermediaries and dropped connections, and the messages might be processed in the order they were sent or in the order they were received. Your service might need to interoperate with other services or clients that are only aware of the basic web service protocol, or they may be capable of using the score of WS-* modern protocols such as WS-Security and WS-Atomic Transactions. Your service may need to interoperate with legacy clients over raw MSMQ messages, or you may want to restrict your service to interoperate only with another WCF service or client.
If you start counting all the possible communication and interaction options, the number of permutations is probably in the tens of thousands. Some of those choices may be mutually exclusive, and some may mandate other choices. Clearly, both the client and the service must be aligned on all these options in order to communicate properly. Managing this level of complexity adds no business value to most applications, and yet the productivity and quality implications of making the wrong decisions are severe.
To simplify these choices and make them more manageable, WCF groups together a set of such communication aspects in bindings. A binding is merely a consistent, canned set of choices regarding the transport protocol, message encoding, communication pattern, reliability, security, transaction propagation, and interoperability. Ideally, you would extract all these "plumbing" aspects out of your service code and allow the service to focus solely on the implementation of the business logic. Binding enables you to use the same service logic over drastically different plumbing.
You can use the WCF-provided bindings as is, you can tweak their properties, or you can write your own custom bindings from scratch. The service publishes its choice of binding in its metadata, enabling clients to query for the type and specific properties of the binding because the client must use the exact same binding values as the service. A single service can support multiple bindings on separate addresses.

WCF defines nine standard bindings:

• Basic binding Offered by the BasicHttpBinding class, this is designed to expose a WCF service as a legacy ASMX web service, so that old clients can work with new services. When used by the client, this binding enables new WCF clients to work with old ASMX services.

• TCP binding Offered by the NetTcpBinding class, this uses TCP for cross-machine communication on the intranet. It supports a variety of features, including reliability, transactions, and security, and is optimized for WCF-to-WCF communication. As a result, it requires both the client and the service to use WCF.

• Peer network binding Offered by the NetPeerTcpBinding class, this uses peer networking as a transport. The peer network-enabled client and services all subscribe to the same grid and broadcast messages to it.

• IPC binding Offered by the NetNamedPipeBinding class, this uses named pipes as a transport for same-machine communication. It is the most secure binding since it cannot accept calls from outside the machine and it supports a variety of features similar to the TCP binding.

• Web Service (WS) binding Offered by the WSHttpBinding class, this uses HTTP or HTTPS for transport, and is designed to offer a variety of features such as reliability, transactions, and security over the Internet.

• Federated WS binding Offered by the WSFederationHttpBinding class, this is a specialization of the WS binding, offering support for federated security.

• Duplex WS binding Offered by the WSDualHttpBinding class, this is similar to the WS binding except it also supports bidirectional communication from the service to the client .

• MSMQ binding Offered by the NetMsmqBinding class, this uses MSMQ for transport and is designed to offer support for disconnected queued calls.

• MSMQ integration binding Offered by the MsmqIntegrationBinding class, this converts WCF messages to and from MSMQ messages, and is designed to interoperate with legacy MSMQ clients.

WCF Architecture

MSDN Link

http://msdn.microsoft.com/en-us/library/ms733128(classic).aspx