Messaging Terms

My understanding of SOA was helped with knowledge of some higher level messaging terms.

One way messaging.

  • Send a message, you may get 0, 1, + responses.
  • Don’t tie up resources waiting for the answer.

Command

  • A request to do something.
  • Owned by the destination system.
  • Present tense.
  • Not sent between services
  • Open Door

Event

  • A notification that something has happened.
  • Owned by the source system.
  • Past tense.
  • Riased by one Service, Consumed by another Service
  • Door Opened

Advertisements

What does an Architect do ?

In the software world, any process that can be automated gets automated.

Compilers are an example of this. The build process for a software system is now effectively zero, because compilers do the build for us. We get build for free.

Too enable this process, we need to provide the compiler with an unambiguous specification. This is the function of a programming language. Where the English language was too ambiguous, programming languages have been designed to allow a person to provide an set of instructions to a computer that can be followed without question.

So what does a software team do? They find and interpret requirements, to provide a detailed specification that can be turned into a software system.

As the number of people involved in a build process increases, they will inevitably split into teams. Each of these teams then focuses on designing their part of the system.

So what does an Architect do? They make sure that the detailed specifications of the teams can be brought together into a software system.

Approachs such as layering, n-tier, and SOA, are simply attempts to structure software to allow independent teams of people to develop these specifications to be built as parts, and brought together to form a working system.

Where from, where to

The ultimate goal of any system is to provide maximum value for minimum outlay.

The principles to achieve this are Autonomy and Loose Coupling. Coupling is the degree to which each program module relies on each of the other modules. Coupling can be measured by observing the flow on effect when changing a module. Autonomy can be measured by how many different points of contact need to be made in order to affect a change.

Taking a simplistic view of a system, people see the separation between the horizontal layers of UI, Business, and Data and incorrectly assume that Autonomy and Loose Coupling can be achieved by separating on these horizontal layers. It does not; they come from minimizing the impact of change, which is generally achieved by keeping the impacts of a change within reach of the team making the change.

So, as the size of the system increases we retain Autonomy and Loose Coupling by maximizing the likelihood that a change remains within reach of the team making the change, and minimizing the impact on other teams.

If we separate on horizontal layers, any change to data will require teams from all layers to be engaged and coordinated. As an example, a name field would need a size limit implemented in multiple layers, therefore multiple teams. If the size changes, these teams would need to be re-engaged and re-coordinated. With multiple teams involved in the change, it is hard to determine who is in charge of the change. So, if we separate on horizontal layers, increasing the number of layers between the database and the UI increases the impact of change, and reduces autonomy.

Autonomy and Loose Coupling are achieved by analyzing the underlying model of the business in question, and aligning the system to the naturally occurring contours of that model. These contours outline the pieces of the puzzle that make up the business model. Each of these pieces is a service, and is assigned to a business unit owner. Each service can then be assigned to a cross-functional team of people. A guideline for finding these pieces – While the data may be similar, does it need to be consistent?

Given that each service is aligned with a business unit, questions of cost and priority can and should be made at a business level. Each service contains UI, Business, and Data layers and will evolve independently of other services, in line with business objectives. As such, extra capacity, or special performance requirements are dealt with as concerns internal to the service. For example, requirements such as increased disk capacity, data replication, or increased cpu can be dealt with to address specific circumstance, and at a business level. Investment can be attributed to business importance.

Interactions between services are realized as events. These events are what make up the external contract of the service. A guideline for defining events – Events are business level interactions, and should be recognized by business people.

Given that services have been designed around the level of consistency between the data, external events would generally only need only contain id’s, and occasionally dates. This has the benefit of reducing the surface area of change, which reduces both the likelihood and impact of change across multiple services.

There are two services that are exceptions to this rule – Branding, and ItOps. In essence, Branding is the interface to the human world, and ItOps is the interface to the machine world. Either of these two services can call in to other services, and can allow other services to call through to them.

Branding will provide a thin veneer within which other services can inject their UI. It will provide things like theming.

ItOps provides a similar thing for machines. A WebApi is an implementation within this service boundary.

This architecture allows for Auditing, Security, and Logging.

As an example, auditing can be accomplished by storing commands and events that are running through the system, as these are business related by their nature. A definition of messaging terms, in the context of this approach, can be provided on demand.

In line with this approach, a conscious decision has also been made to reduce interactions via the network where appropriate. Taking the attempt to impose a horizontal data services layer, it should now be evident that it will increase Coupling, and reduce Autonomy – going against the very things we are trying to achieve. Over and above this, it increases the surface area of the system in production, which increases the potential for operational issues. For example, contending with unreliable networks, network saturation, changes in topology, etc. A further discussion on this can be provided on demand.

Further reading,

·      Four tenets of Service Orientation

·      Fallacies of Distributed Computing

One Liners

Self scaling, Self healing

Real time reporting is a contradiction, it’s about how out of date we can get

Don’t solve infrastructure problems in your application

SLA’s can be monitored, and reacted to in message driven code

Why am I doing this ? How will this fail ?

Done, Done, Done – Backward compatible solution in prod, with users using it

High Level Catch Phrases

Make Roles Explicit – Given the the Single Responsibility principle, one thing should have a single responsibility. Make the one thing explicit in code, with the help of Marker Interfaces.

Just Good Enough – Tied up with You Aren’t Going to Need It, we don’t need to gold plate every part of our system.

Incremental Change – Make small changes, testing and releasing frequently.

Evolutionary Design – Modifying the design of a system as it is developed.

Convention over Configuration – Allow people to configure the framework, but if sensible defaults are provided, they probably wont change them.