Service contracts

Something around great architecture:

Solution driven development can save tons of time. What’s the difference between project driven and solution driven development them?

In solution driven development paradigm one machine can build one solution consisting of all your projects, that is: applications, services and components. One solution, one build means that all references between different projects can be checked and reconciled rather than being built and maintained in complete separation.

This is a major difference, because traditionally different services around your solution live totally independent from each other. That means that iterating on their builds can be done with a total separation of progress being made with other projects, even if in reality they’re tightly coupled and are designed to interact with each other according to a strict specification.

With solution driven architecture driving your projects at different speeds is still possible, however by investing in solution driven architecture means that occasionally you can build and release the whole system: yes: build the front end, back end and all services at once ensuring that interfaces between them are not broken and that different parts of the system will keep on “talking” to each other, even if they’re significantly changed.

How do you ensure the communication? This is implemented via so-called contracts. Contracts are the very special glue that have to be attached and exposed by different services and components. This can take some time to implement consistently but there are many frameworks to aid with that task. By investing in such frameworks company can rely on automatic generation and maintenance of service contracts.

Different services can be spread across different servers and geographic locations, however by specifying contracts between services one can make sure that changes of one service maintained by one team don’t break the interface of another service that can live miles away and be maintained by a completely different team. It is also easier to build new services by attaching them to already exposed contracts.

Introduction of solution driven architecture and strong contracts between services means that it is impossible to change one service so dramatically that it breaks interface of another. Introduction of contracts saves hundreds of hours developers being frustrated with changes to one system breaking another. Your solution can automatically generate contract code and resolve them automatically.

Strong contracts mean that each service is defined by a set of end-points (in multi-server farm), type of protocol and formatting, but most importantly contracts define types of data being sent end received at each end where two or more different services interact with each other. This ensures simply that whatever change occurs within the service, it keeps exposing the same type of data for consumption of all interested parties.

Contracts between services are often criticised for implementing another layer between logic of different services and components and therefore reducing performance. This might be true in case of some slower architectures and where performance might degrade dramatically with over-use of data with additional layer between different systems. There’s a special case: you cannot imagine a web browser building a contract with your server for each JavaScript request as different browsers have different capabilities and in some cases overhead would just not be bearable.

In case of SOA within same organisation there are huge performance gains to be had with solution driven architecture because automatic generation of service contracts can occur as early as on developer’s machine even before the code is released. This means developers are more likely to change code with confidence and therefore proceed faster. In addition this can be delegated to your build machine so that with every change of code it’s never possible to release a component that breaks the contract with all existing services that are part of well defined solution.