Applications & Services


Address, Binding and Contract Defines Endpoint


Where is the service hosted, e.g., URL, MQ address, etc.


How is the service exposed, e.g., http, https, tcp, etc.

  • basicHttpBinding
  • wsHttpBinding
  • netNamedPipeBinding
  • netTcpBinding
  • netPeerTcpBinding
  • netmsmqBinding
  • webHttpBinding (for REST services)

It defines the following elements:

  • Transaction flow
  • Reliability
  • Security – authentication, authorization, etc.
  • Encoding – text, binary, MTOM
  • Transport – TCP, MQ, Named Pipes, etc.


What all does the service expose, e.g., what methods and operations does it expose. Data and message contracts are structural contracts, while service, operation and fault contracts are behavioral contracts

Data Contract

exposes the data types and objects that the service uses

Message Contract

exposes the structure of the message sent to and received from the service

Service Contract

exposes what methods are exposed

Operation Contract

exposes the signature of the method. Overloading is not allowed, and if we want to implement overloading, two different method names have to be used

Fault Contract

exposes exception handling in the service



REST -> Representational State Transfer

Four characteristics:

  1. All data and resources are accessed through a URL
  2. CRUD (Create [put], Read [get], Update [post], Delete [delete]) happens through simple http requests
  3. Service is stateless, and all requests are statefull (i.e., they carry full context in every request)
  4. Representation is decoupled from the resources, and the service can be consumed equally by variety of formats, XML, Json, PDF, etc.


Both threads and processes and they are time sliced with other threads and processes. The key differences are

1. All threads within a single application are logically contained within a process.
2. Processes are fully isolated from each other but threads share the heap memory with other threads running in the same process\application.