Viele Applikationen bieten sogenannte Application Programming Interfaces (kurz API's) an. Diese werden verwendet um das System zu erweitern. Die Möglichkeit Systeme zu erweitern ist im Evaluationsprozess von Software prägend und somit bei der Entscheidung über einen Einsatz in einem bestimmten Umfeld entscheidend.

Ziel des folgenden Textes ist ein kurzer Überblick über die zentralen Funktionen und Eigenschaft einer API mit speziellem Augenmerk bezüglich Auswirkungen auf Wartung und Entwicklung zu geben. Wir legen in diesem kurzen Text kein Anspruch auf Vollständigkeit, sondern beschränken uns im Speziellen auf die unterschiedlichen APIs von PHP und Open Source Software, welche im Webbereich zum Einsatz kommen. Namentlich sind dies: osCommerce, xt:Commerce (und deren Forks), Zen Cart, Magento, PrestaShop, OXID eSales, Joomla und Drupal.

Einleitung – der Programmcode

Ein Stück Programmcode ist immer eine definierte Abfolge von Aktionen. Dies entspricht im Wesentlichen einem Prozess. Alle Programmstücke zusammen bezeichnet man als Software. Bei Programmiersprachen wie Java oder C++ kann aus einem laufenden Prozess einen weiteren Prozess (zum Teil auch als Threads bezeichnet) erzeugt werden. PHP bietet solche Möglichkeiten der Parallelisierung nicht, es wird daher in diesem Artikel nicht vertieft darauf eingegangen.

Bei Standardsoftware wird meist ein Standardprozess vorgeschlagen, wie ein Problem gelöst wird. Diese Prozesse sind meist schon sehr stark ausgereift. Trotzdem haben viele Firmen aufgrund gewachsener Strukturen oder länderspezifischen Spezialanforderungen das Bedürfnis diesen Standardprozess an ihre Abläufe anzupassen.Um die bestehenden Prozesse zu verändern, könnte nun einfach der entsprechende Code direkt im Kernsystem angepasst werden, dies ist aber nicht wünschenswert, weil es in vielen Fällen dazu führen wird, dass keine neuen Updates der Hersteller eingespielt werden können. Hier kommen die Application Programming Interfaces ins Spiel, mit solchen Interfaces ist es möglich genau solche Prozesse zu verändern, ohne den bestehenden Code zu verändern. Neben dem Einspielen von neuen Updates hilft das API auch bei der Einarbeitung von neuen Entwicklern, da diese möglicherweise die Standardsoftware bereits kennen und wissen wie sie funktioniert. Durch die Trennung des Standardprozesses vom individuellen Prozess ermöglicht es Software Entwicklern sich schneller einzuarbeiten, da sie klar erkennen, welche Prozesse wie verändert wurden.

Begriff - Software Wartung

Als Software Wartung wird jene Tätigkeiten bezeichnet, welche nach dem Ausliefern der Software erfolgen. Dies schliesst folgende Tätigkeiten ein:

• Fehlerbeseitigung (korrektive Wartung)
• Verbesserung von Systemattributen (z.B. Performance) (perfektionierende Wartung)
• Anpassung an eine veränderte Umgebung / Umwelt (adaptive Wartung)

Software unterliegt immer einem Veränderungsprozess (Evolutionsprozess), was bedeutet, dass der Code ständig verändert wird. Damit wird die Erweiterung um einzelne Funktionalitäten sehr wichtig. Aus diesem Grund ist die Qualität der API einer Software für die Kostenentwicklung während des Betriebs entscheidend.

Begriff - Application Programming Interface

Eine Software kann in Teilfunktionalität (auch Module genannt) aufgeteilt werden. Ein Modul hat immer zwei Arten von Funktionalitäten:

1. Core-Level-Concerns: Dies sind Kernfunktionalitäten, die klar abgegrenzt sind und meist intern verwendet werden und mit dem Rest des Codes kaum interagieren. Dies könnte zum Beispiel die Berechnung eines Wertes in einer Funktion sein.
2. System-Level-Concerns: entsprechen Funktionalitäten, die nicht an einer Stelle gekapselt werden können. Sie sind im gesamten System verteilt. Typische System-Level-Concerns sind Logging, Zugriffsbeschränkungen oder Transaktionierung von Zugriffen auf eine Ressource.

Die erste Art von Funktionalität lässt sich mit prozeduraler oder objektorientierter Programmierung abbilden. Die zweite Art, die systemweit Auswirkungen hat, ist schwieriger abzubilden. Es gibt verschiedene Ansätze dies zu implementieren zum Beispiel über eine aspektorientierte Programmierung, über das Mixin Pattern (mehrfache Vererbung von unterschiedlichen Klassen) oder über das Observer Pattern.

Auf die aspektorientierte Programmierung wird an dieser Stelle nicht eingegangen, da dies von PHP nicht wirklich unterstützt wird. Das Mixin Pattern soll Klassen erlauben von mehreren anderen Klassen zu erben und dadurch die eigene Funktionalität ergänzen. Zentrales Problem bei der Vererbung von mehreren Methoden stellt dabei die Vererbungstechnik dar. Meist wird versucht den Code zu addieren, d.h. prozedural hintereinander auszuführen. Hier muss dann eine Reihenfolge festgelegt werden, in welcher Sequenz die Methoden ausgeführt werden sollen. Aus unserer Sicht stellt die Vererbungstechnik keine wirkliche Alternative dar, da diese lediglich erlaubt Programmcode zu ergänzen. Das Umschreiben von bestehendem Code ist aber nicht möglich. Weiter kann der Entwickler nicht kontrollieren, wie und wann sein Code durch andere Module erweitert wird.

Beim Observer Pattern gibt es Events; Module können sich für solche Events registrieren. Auf der anderen Seite können die Module auch solche Events auslösen (triggern / dispatchen), dadurch kann das System erweitert werden. Das Ganze wird meist über einen zentralen Verwalter geregelt.

Application Programming Interfaces im Vergleich

Wir haben versucht die verschiedenen API der bekanntesten Open Source Shop Software nach bestimmten Kriterien zu bewerten um Ihnen einen Überblick über die Qualität der einzelnen Interfaces zu geben.
Die API's werden nach folgenden Kriterien bewertet:

1. Core-Level-Concerns Wie werden die Kernfunktionalitäten abgebildet und wird klar zwischen privaten und öffentlichen Methoden (Funktionen) unterschieden.
2. System-Level-Concerns Werden die systemweiten Funktionalitäten berücksichtigt und können damit die meisten Use Cases abgebildet werden.
3. Dokumentation Existiert eine Dokumentation der API und ist diese verständlich.
4. MVC Pattern Wird der Programmcode vom Design getrennt. (Templatesystem)

osCommerce

Der osCommerce Shop ist eine der bekanntesten Open Source Shop Systeme. Das System bietet grundsätzlich für den Versand, Zahlung und Bestelltotal eine API zur Verfügung. Dies ermöglicht in diesen Bereichen Module zu implementieren, ohne dass Programmcode verändert werden muss. Leider existiert weder ein allgemeiner Ansatz für die Erweiterung des Systems noch eine Integration von Triggern. Im Weiteren findet keine Trennung des Inhalts und des Designs statt. Es besteht die Möglichkeit, den Shop nachträglich durch Contributions um ein Templatesystem zu ergänzen, dies stellt allerdings in unseren Augen keine wirkliche Alternative dar, da bei einem Update alle gemachten Änderungen wieder verworfen werden.

1. Core-Level-Concerns: Existiert an gewissen Stellen. (Zahlungsmodule und Versandmodule)
2. System-Level-Concerns: Existiert nicht
3. Dokumentation: Existiert nicht, da auch keine wirklich API existiert
4. MVC Pattern: Existiert nicht

xt:Commerce

Das xt:Commerce Shopsystem ist ein Fork von osCommerce. Gambio und xtcModified sind in vielen Teilen mit xt:Commerce identisch und daher verhalten sich diese Systeme ähnlich wie xt:Commerce. Insbesondere die API wurde bei diesen Systemen nicht wesentlich verändert. Der wichtigste Unterschied zwischen osCommerce und xt:Commerce liegt darin, dass letzteres ein Template System eingeführt hat. Das Template System ermöglicht zumindest Designänderungen unabhängig vom Code durchzuführen.

1. Core-Level-Concerns: Existiert an gewissen Stellen. (Zahlungsmodule und Versandmodule)
2. System-Level-Concerns: Existiert nicht
3. Dokumentation: Existiert nicht, da auch keine wirklich API existiert
4. MVC Pattern: Existiert (Smarty Engine)

Zen Cart

Zen Cart ist ein osCommerce Fork. Der zentrale Unterschied zu osCommerce besteht darin, dass ein einfaches Triggersystem für das Frontend integriert wurde. Im Weiteren wurde wie bei xt:Commerce eine Template Engine integriert.

1. Core-Level-Concerns: Existiert an gewissen Stellen. (Zahlungsmodule, Versandmodule, Einbinden von Files)
2. System-Level-Concerns: Existiert nur im Frontend und nur an wenigen stellen.
3. Dokumentation: Eine sehr knappe Dokumentationen zu den Triggern. (Zen Cart API)
4. MVC Pattern: Existiert

OXID eSales Community Edition

OXID eSales gibt es als kommerzielle und als Open Source Version (Community Edition 4.x). Folgende Einschätzungen beziehen sich auf die Community Version. Die meisten Feststellungen gelten aber auch für die anderen Versionen.
OXID besitzt kein Triggersystem, dafür wird das Mixin Pattern implementiert. Module können beliebige Klassen erweitern und deren Funktionalität auch verändern. Dem Entwickler wird aber nicht die Möglichkeit gegeben Kontrolle über diesen Prozess zugeben. Dies führt dazu, dass Inkompatibilitäten zwischen Modulen auftreten können. Dies geschieht meist bei Klassen, die von vielen Modulen umgeschrieben werden.

1. Core-Level-Concerns: Existiert an gewissen Stellen. (z.B. Admin Menu)
2. System-Level-Concerns: Existiert; wird durch ein Mixin Pattern umgesetzt.
3. Dokumentation: Eine Dokumentationen zum Pattern existiert. (Mixin Pattern Dokumentation)
4. MVC Pattern: Existiert (Smarty Engine)

PrestaShop

PrestaShop wird von einer französischen Firma entwickelt. Das System verfügt über Triggers (sogenannte Hooks). Diese sind mehr oder weniger im System verteilt. Für Versandmodule und Zahlungsmodule gibt es auch andere Implementationswege, welche von der Verwendung von Triggers absehen. Leider gibt es zum Teil Probleme beim Hinzufügen von neuen Menüpunkten im Adminbereich, insbesondere wenn diese mehrsprachig sein müssen. Es werden von PrestaShop standardmässig einige Module mitgeliefert.

1. Core-Level-Concerns: Existiert. (z.B. Admin Menu)
2. System-Level-Concerns: wird durch Hooksystem umgesetzt. Auch Parameter können übergeben werden.
3. Dokumentation: Existiert nicht
4. MVC Pattern: Existiert (Smarty Engine)

Joomla!

Joomla! ist eine bekanntes Content Management System. In Kombination mit VirtueMart können ebenfalls Produkte verkauft werden. Joomla! implementiert ein Trigger System. Die Triggers sind allerdings sehr grob im System verteil. Es ist daher nur schwer spezifische Änderungen an der Funktionalität vorzunehmen. Es werden grundsätzlich drei Typen von Modulen angeboten: Komponenten, Module und Plugins.
All diese Typen haben unterschiedliche Aufgaben, es macht aber nicht immer Sinn einzelne Module in diese Kategorien einzuteilen.

1. Core-Level-Concerns: Existiert. (z.B. Admin Menu)
2. System-Level-Concerns: Existiert; wird durch Triggersystem umgesetzt. Es können keine Parameter übergeben werden.
3. Dokumentation: Existiert nicht
4. MVC Pattern: Existiert mit auch mit Controllern etc.

Magento

Magento ist eines der wenigen Systeme, die wirklich objektorientiert programmiert ist. Magento hat ein sauberes Interface und es werden alle Funktionen konsequent als public oder private (oder auch protected) markiert.
Bei Magento wurde ein Trigger System eingebaut, das recht gut im System integriert ist. Die Events wurden an den richtigen Stellen eingebaut, was den Shop durch seine Anpassungsfähigkeit über das bestehende API sehr attraktiv macht. Das Templatesystem von Magento ist mächtig, wodurch auch beim Design keine unnötigen Code Änderungen anfallen. Ganz allgemein handelt es sich bei Magento um ein sehr umfangreiches und komplettes Shopsystem mit einer sehr mächtigen API, welche auch sehr gut mit anstehenden Updates auskommt. Dies ist einer von vielen Gründen, wieso Magento vor allem für grössere Projekte sehr verbreitet zum Einsatz kommt.

1. Core-Level-Concerns: Existiert in vielen Bereichen.
2. System-Level-Concerns: Existiert; wird durch Trigger System umgesetzt. Parameter können bei den Events übergeben werden.
3. Dokumentation: Existiert. (Allgemeine API Dokumentation, Observer Pattern)
4. MVC Pattern: Existiert; Es wird ein richtiges MVC Pattern mit Controllern, Views und Models.

Drupal

Drupal ist eines der wenigen Systemen, die einen vollständigen prozeduralen Hintergrund haben und keinen objektorientierten. Dafür hat das System gewisse aspektorientierte Bereiche.
Drupal besteht eigentlich nur aus Modulen und einem kleinen Kern von Funktionen, die für das initialisieren der Basisfunktionalität benötigt wird. Drupal hat ein Triggersystem, auch als Hooksystem bezeichnet. Die Integration der Trigger ist sehr gut. Die meisten Veränderungen werden direkt über die sogenannten Hooks gemacht. Module die nicht zu den Kernmodulen gehören, sind ebenfalls sehr gut ausgestattet mit diesen Hooks. Dies führt dazu, dass eigentlich alle Module kompatibel zueinander sind.

1. Core-Level-Concerns: Existiert in vielen Bereichen.
2. System-Level-Concerns: Existiert; wird durch Trigger System umgesetzt. Parameter können bei den Events übergeben werden.
3. Dokumentation: Existiert. (Allgemeine API Dokumentation, Hookliste der Kernmodule, Trigger Dokumentation)
4. MVC Pattern: Existiert; PHP basiertes Template System.

Im Anschluss an oben gelegte Ausführungen und Vergleiche ergibt sich aus unserer Sicht folgende Rangliste bezüglich der API Qualität:

osCommerce

Wir empfehlen unseren Kunden deshalb für grössere Projekte mit Ausbaupotential, oben genannte Punkte in die Analyse miteinzubeziehen.

Zusammenhang zwischen API und den Wartungskosten

Zum Schluss soll noch kurz auf den Zusammenhang zwischen Wartungskosten und der Ausstattung der API eingegangen werden. Bestehen nun bei den Kriterien Core-Level-Concerns, System-Level-Concerns oder MVC Pattern Mängel, muss mit diesen Folgen gerechnet werden:

• Änderungen und Erweiterungen führen dazu, dass Code geändert werden muss. Dies erschwert das Einfügen von Systemupdates.
• Ein „Lock-in-Effekt“ ist unvermeidbar. Da das System durch jede Änderung komplexer wird, wird der Shop Betreiber von der Firma, welche die Änderung durchführt und dem gewählten Shop System abhängig. Oft ist es nicht möglich, dass eine andere Firma die Wartung übernimmt, da diese nicht genau weiss, welche Programmteile geändert wurden.
• Die Kosten für die Wartung der Software werden extrem ansteigen je länger sie im Einsatz ist. Erstens da jede Änderung die Komplexität erhöht und damit den Aufwand um die Änderung durchzuführen und zweitens durch den immer grösser werdenden „Lock-in Effekt“.

Diese Gründe unterstreichen daher umso mehr, die Wichtigkeit einer ausführlichen Analyse und sorgfältigen Auswahl des Shopsystems.

Das Kriterium Dokumentation ist bei Open Source System zwar wichtig für den Entwicklungs- und Wartungsaufwand, sie beeinflusst die Kosten jedoch über die Zeit immer konstant und nicht proportional.

Fazit

Wenn nun davon ausgegangen wird, dass die Wartungsarbeiten etwa zwei Drittel (66%) des gesamten Lebenszyklus der Software ausmachen, dann hat die Qualität der API einen zentralen Einfluss auf die Kostenentwicklung über die Zeit. Bei der Auswahl der richtigen Software sollten nicht nur die funktionalen Anforderungen geprüft werden, sondern auch die Qualität der API.