Um das, was in unserem
Fallbeispiel dargelegt ist, leisten zu können, muss loggPRO eine Unmenge Daten mit den unterschiedlichsten Clients austauschen, also per se muss es eine Vielzahl von Standards und Formaten beherrschen. Dennoch wurde bereits zu Zeiten des FAQ-Artikels FAQid=18, als es um die Kopplung ans TransObjects® ging (demnach lange vor loggPRO), eine Empfehlung zugunsten von XML und SOAP ausgesprochen. Warum?
TransObjects® war und ist eine objektorientierte Technologie und als solche favorisiert sie diejenigen Standards, die der „oo“-Sicht der Dinge möglichst nahe kommt; SOAP bedeutet immerhin „Simple Object Access Protokoll“, scheint also einer ähnlichen Sicht der Dinge entsprungen zu sein. Und nicht nur entsprungen: mittlerweile setzen sich XML und SOAP unübersehbar durch, mindestens im Gleichschritt mit der Objektorientierung im Allgemeinen. Dass der Schweizer Zoll beispielsweise das Verfahren „e-dec“ genau daran angelehnt hat, kommt da sicherlich nicht von ungefähr. |
|
Natürlich sind XML und SOAP nicht die einzigen Standards, die das loggPRO bieten muss, denn damit wäre beispielsweise der Datenaustausch im Rahmen des Verfahrens „Atlas“ bis dato nicht möglich gewesen. Aber - um eine der Ausgangsfragen aufzugreifen - es ist schon von Bedeutung, wie eine Plattform konzipiert ist; erinnert sei an dieser Stelle nur an die seinerzeit „umgeschriebenen“ 16 Bit’er oder an die angebliche „Objektorientierung“ bei einem bekannten ERP-Anbieter, der dies seinem von „Uralt“ herüber gezogenen System aus Marketinggründen gerne andichtet. Wer ist es wohl… J?
Wie dem auch sei. Nachfolgend wollen wir das Besondere am loggPRO ausarbeiten, indem wir dessen Funktionsweise ausführlich charakterisieren und uns dadurch der Ausgangsfrage nach dem loggPRO-API (hoffentlich) gut nähern. Wie die nachfolgende Abbildung zeigt, weist loggPRO eine 2-stufige Topologie auf, bestehend aus einem Backend- und einem Frontend-Bereich (letzteres ist nicht mit der Firewall zu verwechseln, die es noch anderweitig gibt).
|
|
Eine unübersehbar zentrale Rolle spielt hierbei der im Backend befindliche 64-Bit-Cluster, der - bestehend aus 4 Hewlett-Packard Itanium-Maschinen - mit hinlänglich hoher Rechenleistung aufwartet. In diesem Cluster werden künftig die allermeisten Rechenoperationen durchgeführt, sei es durch den Caché-Server selbst, sei es durch TransObjects®-Services, die speziell für eine Cluster-Umgebung konzipiert worden sind oder sei es schließlich durch andere Instanzen, die dort künftig aktiv werden.
Das Wesen einer solchen Frontend/Backend-Topologie besteht nun darin, dass all die Instanzen, von denen wir soeben sprachen, nicht direkt von außen „angesprochen“ werden können. Vielmehr führt der Weg dorthin stets über die Frontend-Maschinen. Die sind auch diejenigen Instanzen, die jede Anfrage zunächst entgegen nehmen, diese dann entsprechend verifizieren und dann evtl. entscheiden, welche Transaktionen mit dem Backend-Cluster einzuleiten sind. Das erhöht entsprechend den Schutz des „Herzstücks“ des loggPRO!
|
|
FAQ’s zu loggPRO: Funktionsweise, loggPRO-API.
Was sind die Unterschiede zu anderen "Integrations"-Plattformen?
|
