How to make it better

  • Article

This post is part of Issue 5’s answer

The previous post demonstrated that we have to care about the messages we pass around. At the end, it’s always about the process of defining contracts. Let’s think about the way we’re defining the following contracts:

  • A private method/property of a class

  • A public method /property of a public class

  • An internal interface definition

  • A public interface definition

  • An application architecture model

  • A Web Services contract

  • An enterprise architecture

Do we treat them all the same? I don't hope so. The more exposure the interfaces get the more restricted are the guidelines for defining them. In addition, different levels of contracts may use different expression languages.

Coming back to Web Services, they’re best described in XML schemas and WSDL. By doing so, you get the guarantee that you know what’s on the wire. There are several tools available to support your contract-first approach.

In the future, the Whitehorse service designer will be the preferred tool for defining service contracts:

At the end, it’s all about the message…