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. But wait, we are getting ahead to fast. But before we dive into real service orientation we need to step back to understand what the context in which we operate is. Especially what the differences between applications and systems are is crucial for distributed systems.
When we talk about an application we usually mean a single executable which runs on a single machine. An application often has a single source of information and doesn’t know about connectivity or at least assumes that connectivity to the information source is always available.
In contrast a system has multiple executables which are running on multiple machines. Systems often have multiple sources of information which are aggregated together to provide multiple business capabilities. When you design systems you need to deal with connectivity, furthermore each executable needs to deal with connectivity. Important to notice is that each executable running in the system is not an application.
Therefore systems are not applications.
When comparing applications versus systems we saw that connectivity and therefore network matters. This is the crucial part which decides whether the system will be successful or not. So why care? Can’t we just simply use remote proxies everywhere and put a try / catch block around each proxy call?
No! This is exactly the kind of thinking that leaded to the fallacies of distributed computing. The fallacies of distributed computing describe common assumptions that are made by developers and architects in distributed systems. We will be covering the fallacies in the next posts of this episode.
[…] Next Home / Architecture / Composite UI for Service Oriented Systems […]
RT @planetgeekch: Composite UI for Service Oriented Systems – Systems and Applications http://t.co/2Aq8FZEJ1m
RT @planetgeekch: Composite UI for Service Oriented Systems – Systems and Applications http://t.co/2Aq8FZEJ1m
RT @planetgeekch: Composite UI for Service Oriented Systems – Systems and Applications http://t.co/2Aq8FZEJ1m