Skip to content

A simple example of a distributed "pipe" in python using zmq

License

Notifications You must be signed in to change notification settings

Endeios/synapse

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

6 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

#The complexity of realty

This post will be dedicated to a strange app that came to my mind: the specs are easy but the solution was not obvious to me so i decided that was worth a post; I hope that my errors will save someone's else time.

The problem is known as federation and the solution is known as federated architecture. This is an high level pattern, but can also apply to small things. In small things is usually called bus. In my case i will have a federation of boxes that may have or not knoledge about something (we will call this thing resource). We will just say that these knoledge fragments are accesible via a command line interface, and that an application exsists that can translate the fragments from the native format to a syndacation format. A small scheme follows, to keep things clear; the drawing will get layers as the architecture grows. This first one does not look much like the wikipedia's one.

Single Service

But we already said that there are multiple sources of information, so we will have many services. We will have to interconnect all of hteese services, so we will put on each one there an interface that will be the trait d'union with the system at large. Note that the interfaces, do the same thing: they call the local magic app and serve the result back to the syndacation

Multiple services

We also want a static entity (and by static i mean that is a fixed point ) that we can query for the whole lot of information that we can get on the resource (at any given time). But let's update our drawing

Proper federated architecture

That's a lot more like the drawing i saw on wikipedia. We know that patterns are good ideas that we know work quite well in solving a problem, although a couple of things are missing in their universality.

I'd also throw in another requirement

we want the services to scale, but we dont want to have the system fail if one of them fails and goes down.

in other words the services should be able to got up and down at any time, and we should call all the services active this added requirement creates a problem with this following phrase

the whole lot of information we can get on the resource at any given time

how do we know that we got the whole information? we need a way to keep track of the services, a register. we need this other component then! we also need that the services announce themself at startup, and that they deannunce themself at shutdown.

About

A simple example of a distributed "pipe" in python using zmq

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages