Chapter 23. Services


  • Defining service contracts

  • Hosting F# services

  • Implementing contracts

  • Consuming services

It is amazing to see that, even at the time of publication in 2010, most applications currently in production tend to interface with other systems through mechanisms that create extraneous coupling. It is still common to see mechanisms such as file polling (system A polls an FTP server until system B drops a file in the right place) and shared databases. The former is wasteful, and the latter presents all sorts of pain as systems grow and evolve. Shared databases are particularly bad because they present what is often an "unprotected door" through which data can enter without any sort of validation or business rules applied. They also effectively become a giant API, with every table, every column, and every row adding to the surface area of what must be tested when changes are made.


To avoid this fate and to provide a better alternative for interoperation, Service Oriented Architecture (SOA) was invented. Services are developed that provide interfaces between platforms so that we can open the functionality of a system to other systems, while preserving the integrity of those systems. Services can take the form of web services, but they do not always need be served up via the web, an idea that has deep support in the Microsoft Windows Communication Foundation. The form of the service is less important than what it does, and making sure it is written ...

Get Professional F# 2.0 now with the O’Reilly learning platform.

O’Reilly members experience live online training, plus books, videos, and digital content from nearly 200 publishers.