Noch vor knappen zwei Jahrzehnten haben wir die Fragen, was denn in technologischer Hinsicht so zwingend fürs transObjects® und gegen etwas anderes sprechen würde, mit dem inzwischen als outdated gekennzeichnetem FAQ- Artikel „Warum denn TransObjects® und nicht etwas anderes?“ beantwortet. In der Neuauflage dieses Artikels wollen wir zunächst die Aussagen von damals auf deren heutige Relevanz überprüfen; schauen, welche der damals vorhergesagten Entwicklungen eingetreten sind und welche nicht und schliesslich die eine oder andere Prognose wagen, was für Wendungen die technologische Entwicklung in der Branche künftig nehmen könnte.
Zunächst gibt unser damaliger Artikel einen recht guten Einblick in das Umfeld, in dem wir uns seinerzeit herumschlagen mussten. Denn wenn ein Softwarehersteller heutzutage, wenige Wochen vor der Einführung des Windows7, immer noch etwas mit „DOS“, „UNIX“, „XENIX“, „MUMPS“, „AS400“ etc. am Hut hat, ist er gut beraten, diese Tatsache tunlichst zu kaschieren. So lässt sich ein geschickter Anbieter von z.B. Atlas- oder e-dec-Software nie auf die Erörterung der dahinter geschalteten Vorrichtung (etwa Datenbank) ein; stattdessen zeigt er seinen Interpreter, Software-Terminal oder auch den Browser umgeben von neuesten Windows-Controls vor lässt das „AS400“ aus dem Spiel…
In Sachen des direkten oder indirekten Windows-Modus sieht die Sache etwas komplizierter aus. Denn die virtuellen Maschinen (damit ist nicht etwa die Hardware-Virtualisierung gemeint, sondern die Software-Interpreter – vgl. transObjects® vs. VM „Ist Euer transObjects® plattformunabhängig?“) sind eindeutig nicht in dem Masse den lupenreinen Windows-Applikationen gewichen, wie wir dies seinerzeit prophezeit haben. Auf der anderen Seite, obwohl die Performance den VM’s eindeutig nicht zum Vorteil gereichen dürfte, hat auch Microsoft durchaus andere Vorteile erkannt und dieses Konzept unter dem Oberbegriff „.Net-Framework“ adaptiert und entsprechend kultiviert.
Dennoch der Grund, der in diesem Zusammenhang mehr denn je fürs transObjects® spricht, ist der Rückgriff auf die .Net-Technologie genau da, wo es Sinn macht und wo es handfeste Vorteile bringt, jedoch unter strikter Beibehaltung der gewohnten transObjects®-Performance (vgl. auch Was ist und was bringt die „transObjects®’s 5-te Symphonie“? (Teil III)). Auch die kürzlich eingeführten Browser-Clients (LoggPRO Web Access, vgl. Was ist und was bringt die „transObjects®’s 5-te Symphonie“? (Teil IV)) sind kein Selbstzweck sondern eine zusätzliche Option, die unter bestimmten schwierigen Bedingungen (etwa das Fehlen von Windows) einzusetzen sind, die aber ansonsten die transObjects®-Clients nicht ersetzen können.
Zu guter Letzt gehen wir noch auf die Entwicklung bei den Datenbankservern ein. Seinerzeit haben wir – und zwar nicht nur in dem besagten FAQ-Artikel – die Hoffnung zum Ausdruck gebracht, dass die namhaften Datenbank-Hersteller sich der objektorientierten Technologie (genauer gesagt, den multidimensionalen Datenstrukturen) irgendwann einmal öffnen werden. Und siehe da, diese Entwicklung ist nun klar zu verzeichnen! Sowohl Microsoft als auch Oracle und andere bieten mittlerweile eine Unterstützung von multidimensionalen Datenstrukturen an! Auch wenn diese Features noch in den Kinderschuhen stecken mögen, ist die Hoffnung nicht ganz unberechtigt, dass es bald möglich sein wird, transObjects®-Klassen auf z.B. Oracle oder MSSQL abzubilden. Allerdings: Ob ein beliebiger Softwareanbieter zwingend von den neuen Features einer per se SQL-orientierten Datenbank Gebrauch macht, steht freilich auf einem ganz anderen Blatt.
Fazit: transObjects® ist seit der Konzipierung in Bereiche vorgerückt, in denen die „Musik“ spielt. Dies alleine möge als Argument hierfür und gegen etwas „anderes“ reichen.