Contract-first design and development is not something new. It was formally introduced by Bertrand Meyer as a part of his Eiffel Programming Language design and has appeared in various technical publications since 19861,2. Therefore, understanding contracts from an old-school tool/technology perspective might be helpful to grasp why it it's useful.
Although computers today can do a lot of things from simple arithmetic to controlling the satellites orbiting our earth, the fundamental idea of an input-output machine hasn't changed since adding machines invented in 19th century. Consequently, software engineers still write functions that take some input and perform some work and output something. These functions are then used from other places. A contract of a function defines the expectations and commitments of that function. In other words, input parameters to a function can be thought as its expectations and the return values can be considered as its commitment. Users of the function only need to know about the contract to use it. A classic example for this is a C++ header file. When you want to invoke a function in another C++ library, you are not interested in looking at the implementation -- in fact, most of the time, you would not have access to the implementation. The plain text header file tells you and your compiler enough about what you need to invoke that function and what you will get at the completion of it.
Type library files in COM and ActiveX, and interfaces in C#, are commonly seen as other forms of contracts. Because a contract is a way of defining formal, accurate, verifiable interface specifications based on abstract data types for software components, there's a natural tendency to create the contracts first. That's why almost every C/C++ programmer starts a program by first writing the header file.
Contracts in WS are no exception. As a WS developer, your intention is to share your input/output system as a Web service -- potentially across platform boundaries. We are sure you've heard many times before that the users of your Web service should not be worrying about your implementation details. Having access to your contract should be sufficient for someone else to consume it. Because Web services are platform-independent, we use interoperable, standards-based constructs like Web Service Definition Language (WSDL) and XML Schema (XSD) to define contracts. ing a contract involves ing data, messages and the interface of your Web service.
First, you your data contracts (that is, data structures) that are used to pass data between the clients and the service. Data contracts could either be simple or primitive types such as string, integer, double or complex, or domain-specific types such as Product, Employee or Itinerary.
Read On..
http://msdn.microsoft.com/en-us/magazine/ee335699.aspx