Motivation für verteilte Systeme

Der Flaschenhals bei der Programmierung ist längst nicht mehr die Hardware sondern der menschliche Programmierer. Genauer gesagt seine geringe Produktivität. Die Gemeinsamkeit von Microsoft, den Linux Kernel Developern und Spieleprogrammierern ist, dass sie es nicht schaffen über die magische Grenzen von 10 Zeilen Code pro Tag und Mann hinauszuwachsen. Anders gesagt, selbst wenn man objektorientierte Programmierung und ein Versionscontrol-System wie git verwendet und wirklich Elite-Programmierer hat die motiviert dabei sind ist die Menge an Codezeilen die ein 10 Mann Team im Jahr erzeugen kann streng limitiert. Sie liegt bei rund 365*10*10 = 36500 Zeilen, was umgerechnet 1,5 MB an Sourcecode sind. Für ein selbstfahrendes Auto ist das zuwenig.

Gleichzeitig ist die geringe Produktivität von Programmierern nicht wirklich ein Problem, weil es weltweit sehr viele Programmierer gibt. Schätzungen gehen von 40 Mio Developern aus, und wenn die nur 10 Zeilen Code am Tag schreiben kommt im Jahr ordentlich was zusammen. Das Problem liegt woanders. Nehmen wir mal an, die Code schließen sich über github zusammen. Die drei wichtigsten Programmiersprachen dort sind Java, C# und Python. Allesamt technisch hochentwickelte Systeme die auf einer Virtuellen Maschine aufbauen. Aber, gemeinsames Programmieren wird nicht unterstützt. Selbst die Python Sprache welche sich laut Selbstdefinition als Glue-Sprache versteht ist nicht im Stande mal eben so auf eine Java-Klasse zuzugreifen. Das Problem ist, dass die oben genannten Programmiersprachen desktop zentriert sind. Was man eigentlich bräuchte um die weltweiten Programmierer zu verbinden ist eine Systemübergreifende Sprache. Auch in dieser wird die Produktivität bei maximal 10 Zeilen Code am Tag liegen, es besteht jedoch Hoffnung, dass der einmal geschriebene Code auch von anderen verwendet werden kann. Ein Ansatz in diese Richtung ist der REST Standard, eine API für verteilte Systeme. Technisch gesehen ist das eher unspektaktakulär, sondern der Vorteil besteht darin, dass vorhandener Code leichter weiterverwendet werden kann. In der Theorie kann man damit Systeme bauen, die per Default kompatibel sind, wo es also nur noch eine Programmiersprache gibt.

Meist wird REST und die “Web_Application_Description_Language” technisch beschrieben. Das es also ein Protokoll wäre um Maschine-to-Machine Kommunikation zu unterstützen. Doch eigentlich geht es um den eingangs beschriebenen menschlichen Flaschenhals. An neu erzeugtem Sourcecode gibt es keinen Mangel, bei github gibt es geschätzt mehrere Millionen von Accounts die allesamt mit neuem Code bestückt werden. Die Schwierigkeit liegt darin, dass es isolierte Projekte sind. Wenn zu einem Repository mehr als 1 Person Commits erstellen, nennen sich die Verantwortlichen bereits stolz Team. Doch was wäre, wenn man den Code nicht nur ins Internet hochlädt sondern ihn dort auch ausführbar macht? Angenommen man benötigt einen Primzahlalgorithmus. Dann kann man entweder anfangen bei github ein Python oder Java Projekt zu suchen was den realisiert. Sich den Sourcecode rauskopieren und umfortieren, oder aber man sucht sich eine REST Ressource die das gleiche kann. Hinter dieser API verbirgt sich irgendwo natürlich ebenfalls manuell erstellter Code, im Worst-Case sogar nichts anderes als schlecht programmierte Python Scripte, der Vorteil ist jedoch, dass die Programmiersprache keine Rolle spielt. Man greift aus seiner Anwendung auf die API zu und schon fließen die Primzahlen auf den Bildschirm, so jedenfalls die Theorie.

Semantic Web wird manmchal als erweitertes Internet bezeichnet. Doch eigentlich hat es mit dem Internet nicht viel zu tun. Worum es eher geht ist es ein Medium bereitzustellen indem Programmierer aktiv werden. Vergleichbar mit dem github Portal nur interaktiv.

Eine konkrete Realisierung von REST wäre ASP.net Das ist ein Standard von Microsoft um verteilte Anwendungen zu erstellen. ASP.net wiederum steht in Konkurrenz zu PHP. PHP ist üblicherweise als Backend zum Schreiben von Webseiten bekannt wenn man jedoch unterstellt dass PHP die Realisierung von Semantic Web ist, kann man damit noch einiges mehr anstellen. Genau genommen ist es also keine “another programming language”, sondern die Idee lautet eine Sprachenunabhängige online-API bereitzustellen auf der andere Anwendungen andocken können.

Hier https://blog.axxg.de/php-soap-web-service-client/ gibt es ein einführendes Beispiel. Gezeigt wird wie über SOAP, PHP und Web_Application_Description_Language ein Mini-Script online gebracht wird. Es berechnet den Umfang für ein Rechteck ist also algorithmisch eher simpel aufgebaut. Das besondere ist, dass nachdem der Dienst Online ist, ca. 7 Milliarden Menschen Zugriff nehmen könne auf diese Funktion.

In dem Paper “Razieh Safaripour: A RESTful Architecture for the Development and Deployment of
Companion Robots Applications, 2013” https://spectrum.library.concordia.ca/977496/1/Safaripour_MSc_F2013.pdf wird das Konzept auf das Thema Robotik übertragen.

Ich will mal versuchen zu beschreiben wo die Vorteile liegen. Wenn man die weltweit 40 Mio Softwareentwickler programmieren lässt, erzeugen sie zwar unglaublich viel Sourcecode, aber leider ist dieser inkompatibel zueinander. Der eine Programmiert in Java, der nächste nimmt Python. Und selbst wenn zwei Leute beide in C# programmieren heißt das nicht automatisch dass man den Code kombinieren könnte. Vielmehr ist der eine in Projekt 1 involviert und der zweite macht in Projekt 2 etwas ähnliches. Durch OpenSource lässt sich ein Großteil der doppelt ausgeführten Arbeit reduzieren. Es gibt heute nur noch ein Linux Projekt und wer irgendwas in diese Richtung vorhat wird seinen Patch zu Red hat senden. Aber OpenSource allein ist nicht die Antwort, weil nach wievor sehr viele Projekte sich überschneiden. Man schaue sich nur mal die zigtausenden Spieleprogrammierprojekte an, in denen jedesmal der A* Algorithmus von neuem implementiert wird. Was es braucht ist also ein Koordinierungsmechanismus, damit die 40 Mio Programmierer als Team zusammenarbeiten, das also nur jeder den Code schreibt der wirklich relevant ist.

Der Einstieg in REST ist eigentlich simpel. Man programmiert dort eine Klasse wie in Java oder Python auch. Der Unterschied ist nur der Aufruf. Bei Python würde man auf die Python Commandline wechseln, das Module mittels import enbinden und dann die Klasse starten. Bei REST hingegen sented man einen Reqest an eine URL und dort wird dann auf dem Server die Klasse ausgeführt. Die technische Leistungsfähigkeit ist identisch: bis man eine Anwendung einer bestimmten Größe programmiert vergeht die selbe Zeit, ja ich würde schätzen dass eine REST Appikation etwas aufwendiger ist, weil das Thema noch neu ist. Ferner ist der Aufruf direkt über das WWW langsamer als vom eigenen PC. Die Idee ist vielmehr, dass man darüber die Programmierer besser interagieren lassen kann. Das heißt, REST muss man sich eher unter organisatoren Aspekten vorstellen, vergleichbar mit git vielleicht, was ja primär ein Projektmanagement Tool ist und keine Programmiersprache.

REST in der Praxis
Um die Sache ein wenig realistischer zu machen suchen wir nach einer REST API um Primzahlen zu berechnen. Auf https://www.programmableweb.com/category/all/apis?data_format=21190 findet sich eine Suchmachine für RESTful APIs, dort geben wir ein “Prime” und finden eine Seite namens “Cascade API”, https://www.programmableweb.com/api/caascade Laut Beschreibung kann man dort Anfragen senden an ein Computeralgebra System namens Maxima. Wie man das genau macht, keine Ahnung. Aber in der Theorie müsste man jetzt einen Curl-Befehl auf der Commandline eingeben und würde dann die Primzahlen von 1 bis 100 auf dem Bildschirm sehen. Das ganze ist vergleichbar mit github, nur ohne Sourcecode.

Weitere interessante Projekte sind beispielsweise NAOqi (eine RESTful API um einen Nao Roboter zusteuern) oder Dronesmith (REST API für Dronensteuerung). Beides sind keine klassischen Softwareprojekte die als C++ Bibliothek erstellt wurden und die man in eigene Projekte einbindet, sondern es sind REST API, also über das Internet erreichbare Services. Das heißt, man kann dort per Default drauf zugreifen, selbst wenn man eine komplett andere Programmiersprache nutzt.

EXKURS ZU PYTHON
Die Python Programmiersprache ist bereits relativ mächtig. Sie unterstützt das objektorientierte Paradigma und ist eine Interpreter-Sprache was bedeutet, dass sie auf jedem Betriebssystem läuft. Programmieren muss man jedoch noch selber, will man einen Roboter steuern braucht man dafür sehr viel Code. Es gibt zwar Libraries für Python um die Entwicklung zu beschleunigen wovon pygame eine sehr bekannte ist, aber auch damit benötigt man viel Zeit bis ein Projekt fertig ist. Die nächst bessere Programmiersprache nach Python ist meiner Recherche nach REST. Also ein Meta-Standard der mehrere Programmiersprachen kombiniert und der über das Internet zugänglich ist. Es gibt auf Youtube ein Demovideo zu “NAOqi API” was zeigt wie sich mit wenigen Zeilen Code ein Nao Roboter steuern lässt. Mit Python Programmierung hat nichts mehr zu tun, sondern stattdessen sendet man eine Remote API Befehle und führt so den Code aus. Meiner Meinung nach ist REST nach der objektorientierten Programmierung die logische Weiterentwicklung.

Im obigen Video wird NAOqi in Aktion gezeigt. Mit einem Python Script was aus 5 Zeilen Code besteht wird eine Sprachausgabe realisiert. Natürlich nicht direkt in dem Python Script und vermutlich funktioniert die Sprachausgabe durch eine andere Sprache, sondern das Geheimnis liegt im verteilten System. Das man also die Library mit den Robotik-Algorithmen via Internet zugänglich hat und darauf nur noch zugreift. Der Clou ist, dass alle Programmierer die sich mit Sprachsynthese beschäftigen, jetzt ihre isolierten Projekte einstellen können und stattdessen Code für die obige API schreiben. Wodurch dann User weltweit darauf Zugriff haben.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s