Nunja ein Warenwirtschaftssystem schreibt man auch nicht mal so nebenbei, weswegen die wenigsten sowas schon mal gemacht haben dürften.
Generell sind WWS meist in C, C++ und Cobol programmiert. Kleinere Systeme sind nur in einer Sprache gehalten, während größere auch schon mal hybrid sind, d.h. eine Mischung aus mehreren Sprachen und Technologien enthalten. SAP z.B. ist mit Sicherheit in C oder C++ gehalten, allerdings werden viele Erweiterungen und Anpassungen in einer SAP-eigenen Sprache geschrieben so daß man letztendlich einen Mischmasch hat. I.d.R. wird zwischen Backend und Frontend unterschieden und da kann es vorkommen, daß das Frontend z.B. in Visual Basic gehalten ist (weil man da so schön einfach und schnell GUIs mit zaubern kann), während das Backend, welches die komplette DB Kommunikation und die eigentliche Business Logik abbildet, in Java, C++ oder gar C realisiert ist.
Meist gibt es (zumindest von den großen Anbietern) entsprechende Module, die ein Frontend auf Web-Basis zur Verfügung stellen, d.h. das Web-Modul greift bei Anfragen eines Browsers auf die gleichen Funktionen zu, wie ein entsprechendes VB Pendant, generiert aber eben HTML Code aus den Ergebnissen. Da beide Frontends die gleiche Funktionalität abbilden und beide auf die gleichen Funktionen und Datenbestände zugreifen, können sie parallel laufen.
Warum PHP nur bedingt geeignet ist:
Generell kann man ein WWS auch mit PHP programmieren. Und wenn man auf eine reine Weblösung hinauswill, dann ist das auch eine akzeptable Lösung. Zieht man das Projekt und die Realisierung objektorientiert auf, dann hat man später auch gute Chancen das Ganze zu erweitern oder gar als eigenständiges Produkt für seine Branche oder gar Branchenübergreifend zu verkaufen.
Will man allerdings auch z.B. Windows Clients unterstützen, oder zielt man gleich auf eine Lösung die größer ausgelegt ist, dann wird man mit PHP nicht unbedingt weit kommen. Der Grund liegt zum einen in den beschränkten Möglichkeiten zur OOP in PHP, und zum anderen sicherlich auch darin, daß PHP generell einen schlechten Ruf in den wirklich professionellen Bereichen genießt (aka Big Business, Banken, Großkonzerne, usw.), aber vor allem in der mangelnden Umsetzbarkeit des Konzeptes "Middleware". Das Feld Middleware wird heutzutage hauptsächlich von EJB (Enterprise Java Beans) und .NET angeführt. Etwas im Hintertreffen ist CORBA. Middleware bedeutet grob gesagt zunächst einfach mal alles was nicht Frontend und nicht Datenbank ist (
), d.h. im Grunde wird in der Middleware die komplette Business Logik abgebildet. Dabei wird auf OOP gesetzt und die einzelnen Objekte sind durch eindeutige, vorher definierte Schnittstellen verbunden. Die Schnittstellen erlauben es ein Objekt (z.B. Kunde) als Black Box anzusehen. Dieses Kundenobjekt hat dann Funktionen, um z.B. die Stammdaten zu ändern, es hat eine Liste mit Ansprechpartnern, man kann alle Aufträge zu diesem Kundenobjekt abrufen, usw.
Dadurch, daß die Schnittstellen klar definiert und von außen abrufbar sind, kann ich die einzelnen Objekte auch nach dem Kompilieren immer wieder neu gruppieren und miteinander verbinden, um so geänderten Anforderungen zu entsprechen.
Außerdem ist es nicht erforderlich, daß alle Objekte lokal verfügbar sind, sondern diese können beliebig über mehrere Rechner und Netze verteilt sein.
Webservices passen ansatzweise in diese Middleware hinein, aber sind eben nicht ganz das gleiche.
