CategoryPresentation

This blogpost is part of a larger blog post series. Get the overview of the content here. I briefly mentioned that the message has a body. The body carries on the payload or the actual business data identified by the message. Furthermore a message can contain metadata on its header. This allows the message to carry on additional information which can be consumed by the receiver side. Message forwarders need to make sure that the headers remain intact during the communication process. This means...

This blogpost is part of a larger blog post series. Get the overview of the content here. In the beginning, RPC style communication seems to be better performing than messaging. But when the load on the systems increases and no more threads are available the RPC performance decreases. One cause of the RPC performance decrease is the need to acquire threads from the thread pool and to allocate memory for the parameters of each request. A messaging infrastructure can deterministically assign a...

This blogpost is part of a larger blog post series. Get the overview of the content here. Messaging can help to reduce coupling in your system. It also addresses some of the fallacies of distributed computing. But messaging is no silver bullet. You have to carefully choose according to your non-functional requirements, risk analysis, fallacies and more whether it makes sense to use messaging. Messaging can take place inside the same process boundaries (i.e. with Event Aggregators) or over...

This blogpost is part of a larger blog post series. Get the overview of the content here.
Now that we are aware of the fallacies of distributed computing let us step back and look into a traditionally built distributed system.

This blogpost is part of a larger blog post series. Get the overview of the content here.

Coupling is a measure of dependencies. If a component X depends on Y, then there is coupling between them. There are two kinds of coupling: Afferent and Efferent coupling.

This blogpost is part of a larger blog post series. Get the overview of the content here. Interoperability is easier when you only have two similar platforms like .NET and Java. Today we have a variety of languages, platforms and tools such as Ruby, NoSQL and more. Sooner or later your systems needs to interop with other platforms and tools. Interoperability does work but is usually hard and the costs involved should not be underestimated. It is important to plan for interoperability and budget...

This blogpost is part of a larger blog post series. Get the overview of the content here. Unless you’re on a separate network that will never, ever be connected to anything else… Well, not even then. Viruses, Trojans, etc. can still be brought in by users on CDs, DVDs, DOKs, etc. You can’t be 100% safe from everything Never underestimate security risks. Perform a thread model analysis and after that balance costs against risks. What is the risk involved when a security breach occurs, how much...

This blogpost is part of a larger blog post series. Get the overview of the content here.
The fallacies of distributed computing describe common assumptions that are made by developers and architects in distributed systems. In 1994 Peter Deutsch wrote down seven fallacies. In 1997 James Gosling added another fallacy. These fallacies are known as “The eight fallacies of distributed computing”. In the year 2006 Ted Neward added three more fallacies which are not so widely known.

This blogpost is part of a larger blog post series. Get the overview of the content here. The word service oriented architecture, known under the abbreviation SOA, is often misunderstood or wrongly applied. A common misbelief is that service oriented architecture automatically means having multiple web services talking to each other. Let us call this way of applying SOA the classical remote procedure or request /response style. This quickly leads to unmaintainable distributed big ball of muds...