Kapitel 1

Um eine der allerhäufigsten Fragen vorab zu beantworten: Die neue transObjects®’s-Generation 5 wird zwar manchmal schon als die „Vista-Generation“ bezeichnet, dennoch bedeutet es nicht, dass das „Vista“ eine Voraussetzung für den Betrieb neuesten transObjects® bildet. Vielmehr wird die 5. „Symphonie“ strikt abwärtskompatibel sein, zumindest zu der vorherigen Generation 4, so dass Sie wie gewohnt Ihren Arbeitsalltag werden praktizieren können, mit den gewohnt komfortablen High-End-Tools. So werden Sie wie insbesondere Ihr operatives und administratives Geschäft transObjects®-technisch begleiten können – vom Dokument-Management über die elektronische Warenabfertigung via transObjects®-Clearing Center bis hin zur Integration mit anderen Systemen via loggPRO®. Durch die Anschaffung des neuesten Windows und/oder eines neuen 64-Bit’ers wird Ihre Arbeitsumgebung gewiss noch einen Tick komfortabler, moderner und performanter, aber zwingend erforderlich ist dies – um es ganz klar zu sagen – keineswegs.

Die transObjects®’s-Generation 5 setzt die Tradition einer beispiellosen Erfolgsstory fort, die im Jahre 1996 ihren Anfang nahm. Seinerzeit, nach einer erfolgreichen Umstrukturierung der Führungsriege der K&S GmbH, gaben die Urheber der transObjects®-Technologie den Startschuss für die Entwicklung von ersten durchgehend objektorientierten und auf Windows basierenden Branchenapplikationen für die Bereiche Speditionslogistik und Warenabfertigung.

Die Resonanz auf das „Transware++“, wie sich die damals neu konzipierte Technologie (in offensichtlicher Affinität zu C++) fortan nannte, war anfangs eher verhalten. Neben einiger Neugier überwog doch mehr die Skepsis in Bezug auf die Machbarkeit eines solchen Vorhabens, aber auch in Bezug auf die Zukunftschancen von einer Technologie, die sich immerhin in einer von AS400/UNIX dominierten Branche zu behaupten hatte. So tat sich das branchenweit erste Zoll’90 in der typischen Windows-Oberfläche, das Transware++ §Zoll’90, nicht auf Anhieb leicht.

Allerdings liessen sich bereits damals viele Anwender von all den Problemen eines Quasi-32-Bit-Betriebssystems „Windows 95“ nicht entmutigen sondern vertrauten auf die ehrgeizigen Pläne der K&S GmbH und investierten so in die Zukunft, Die Ankündigung der nunmehr fünften (!) Generation von transObjects®-Applikationen Anfang 2006 ist auf ein überwiegend positives Echo gestossen. Allerdings wären die User nicht „unsere“ User, wenn sie uns nicht mit unzähligen Fragen hierzu überhäuft hätten, etwa „Schon wieder was neues…“, „Muss ich denn meine lieb gewordene Hardware rausschmeissen“, „Muss ich denn zwingend auf Vista umsteigen“ etc. Auf diese wie auf andere häufig gestellte Fragen zur transObjects®’s 5-ten sollte im vorliegenden FAQ-Artikel eingegangen werden.

Kapitel 2

Im Kapitel 1 unserer technischen Charakterisierung der 5. transObjects®-Generation haben wir einen Rückblick auf technische Innovationen zwischen den einzelnen Generationen gegeben und… damit insofern den Sinn und Zweck eines FAQ-Artikels verfehlt, als dass wir an einer bestimmten Stelle mehr Fragen aufgeworfen denn beantwortet haben… Von daher wollen wir nun auf die Fragestellungen rund um die „VM“’s genauer eingehen.

Um vorab einem möglichen Missverständnis vorzubeugen: Mit „VM“ bzw. „virtual machine“ ist hier keineswegs die Hardware-Virtualisierung gemeint, wie wir sie in Form von VMWare® oder MS Hyper-V® kennen. Hierbei handelt es sich vielmehr um typische Interpreter-Schichten, die zwischen dem User-API und dem eigentlichen Betriebssystem angesiedelt sind, wie die Abbildung aus TransObjects® vs. VM oder „Ist Euer TransObjects® plattformunabhängig?“ zeigt.

Bereits in dem obigen FAQ-Artikel haben wir auf das grundlegende Problem der VM’s und deren prinzipielle Unverträglichkeit mit der transObjects®-Philosophie hingewiesen. Zitat: „Was ist dann so ungünstig an diesen VM’s, wenn sie doch offenbar sogar von Microsoft erkannt worden sind? Nun, zum einen ist es die Zwischenschicht (zwischen der Applikation und dem Betriebssystem s. Abb.), die mit der Grundphilosophie von transObjects® schlicht unvereinbar ist. Eine transObjects®-Applikation arbeitet nämlich stets direkt mit dem Betriebssystem zusammen (Windows® versteht sich). Das und nur das kann ein Maximum an Performance und Stabilität gewährleisten. Alles andere stellt einen Kompromiss dar, den Sie bekanntlich den anderen überlassen können. Im Übrigen versucht gerade Microsoft in dessen .Net/CLR/CIL mittels JIT (just-in-time compiling) dem Maschinencode möglichst nahe zu kommen, was doch nur beweist, dass klassische VM’s ein gewaltiges Performance- und Stabilitätsproblem haben müssen.“ Und weiter heisst es: „Allerdings haben die VM’s (und die entsprechenden Applikationen) einen nicht zu unterschätzenden Vorteil. Die Plattform-Unabhängigkeit eröffnet ihnen den Weg, eine Vielzahl von Benutzern und unterschiedlichsten Systemen erschließen zu können. Aber auch diese „Massenproduktion“, ist etwas, was der transObjects®-Philosophie zuwiderläuft…“

Soweit so gut. Man kann also der Grundidee von Microsoft zumindest das Ansetzen an der richtigen Stelle bescheinigen, genau da, wo der Schuh drückt. Denn in der Tat wirken die übers .Net-Framework laufenden Applikationen bei weitem nicht so behäbig, wie dies sonst häufig zu beobachten und nicht selten auch akustisch warhzunehmen ist… Gleichzeitig sind aber die Portabilität, Geräte- und Plattformunabhängigkeit etc. zweifelsohne auf der Haben-Seite zu verbuchen – man vergleiche bloß diejenigen transObjects®-Applikationen, die mitunter für die PDA’s (also Pocket-PC’s) gedacht sind: loggPRO.tom.

Dennoch, das Ei des Columbus ist der VM-Trick von Microsoft sicherlich nicht. Der Grund liegt im Ansatz selbst, nämlich dem JIT (just-in-time) – Compiling. Diese Compilierung muss – im Gegensatz zur klassischen Kompilierung – in einer kurzen Zeitspanne zwischen dem Laden der Applikation in den Speicher und der eigentlichen Programmausführung ihren Job verrichten, d.h. den ausführbaren Maschinencode bereitstellen. In der Kürze der Zeit ist wiederum die Effizienz dieses JIT-Codes bei weitem nicht so, wie sie mit optimierten Tools in algorithmisch ausgefeilten Abläufen generiert werden kann.

Ob man diesen Unterschied merkt? Ja, man merkt zunächst mal schon, dass die Screens nicht mehr so „flutschen“ wie früher und dass die Aufbereitung eines Prints dem PC zunächst mal unübersehbar (und teils unüberhörbar) etwas mehr abverlangt, als es vorher noch, z.B. beim transObjects® der 4. Generation, der Fall war.

Wie soll man also diesen Widerspruch auflösen? Nun, wie so häufig, liegt die Lösung irgendwo dazwischen, also in einer guten Balance zwischen diesen beiden Welten, dem „managed code“ und dem „unmanaged Code“ (was nichts anderes ist als der gute alte „native Code“). Oder anders herum gefragt, gibt es vielleicht bestimmte Applikationen oder deren Teilbereiche (nennen wir sie „Sections“), wo der eine Code mehr Sinn macht als der andere?

Auch hier ist der Blick auf den Branchenführer hilfreich. Die neuesten Entwicklungen aus dem Hause Microsoft weisen nämlich exakt diese Balance auf, mancher mag es eine „Melange“ nennen. Der MS Exchange-Server 2007 der MS SQL-Server 2008 etc. – überall ist das .Net-Framework unabdingbar, um diese Instanzen überhaupt installieren und betreiben zu können. Auf der anderen Seite fällt sofort auf, dass zwischen den 32-Bit- und 64-Bit-Editions strikt unterschieden wird; innerhalb der letzteren werden noch die „x64’er“ und „IA64’er“ strikt auseinander gehalten.

Was ist der Hintergrund? Eigentlich ist es ganz plausibel: Man hat schlicht bestimmte Sections für „mission critical“ befunden und andere wiederum nicht. Während die typischen User-Interfaces (z.B. Management-Konsolen) nicht unbedingt in höchster Performance abgewickelt werden müssen, ist es bei den Datenbank-Engines beispielsweise ein Muss. Genau von dieser Prämisse haben sich die Entwickler der K&S GmbH beim Konzipieren der 5. Generation von transObjects® leiten lassen. Für die bereits erwähnte PDA-Applikation ist die grafische Performance des „managed Code“ vollkommen irrelevant und unter modernen PC’s wird sie immer weniger spürbar. Beim Datenaustausch zwischen dem Server und dem Client hingegen ist sie von allerhöchster Relevanz, s. Neues DSCE-Verfahren.

Die Antwort der K&S-Entwickler hierauf ist dann allerdings genauso kompromisslos, wie Sie es von früher kennen. Die Performance- bzw. Sicherheits-relevanten Abschnitte der 5. Generation werden nach wie vor strikt im nativen Code abgewickelt. Die nachfolgende Abbildung zeigt diejenigen DLL’s (dynamik link libraries), die diesen nativen (und nach wie vor in C++ implementierten !) Code beinhalten. Logischerweise wird für jede Plattform ein kompatibler und hierfür optimierter native Code benötigt, was zu den Wortschöpfungen wie „TransObjects.x64.dll“, TransObjects.win32.dll“ etc. führt. Nur da, wo eine solche Relevanz nicht besteht, erhält der managed Code nach und nach Einzug. Dies ist etwa bei den UI‘s (user-interfaces) der Fall, also bei dem „sichtbaren“ Teil einer transObjects®-Applikation, wo wir von den neuesten Entwicklungen im .NET-Bereich gerne mit profitieren möchten. Es findet jedoch bei jedem Start eine Prüfung der Umgebung (insbesondere der Plattform!) statt und der richtige „Turbolader“ wird jeweils „zugeschaltet“. Das ist das Wesen von transObjects® der 5. Generation.

Dynamic Link Libraries (DLL’s) der 5. Generation von transObjects®
„TransObjects.IA64.dll“ ist beispielsweise die native DLL für Itanium® 64-Bit-Plattform

Kapitel 3.

Die beiden ersten Kapitel technischen Charakterisierungen der 5. transObjects®-Generation „Was ist und was bringt die transObjects®’s 5-te Symphonie“ setzen wir vorliegend mit der Beleuchtung der immer wichtiger werdenden Sicherheitsaspekte fort. Ferner gehen wir (vgl. Kapitel 4) auf Fragen der praktischen Verfügbarkeit, Vielseitigkeit etc. ein und zwar vor dem Hintergrund der Einführung von „Web-Access“-Clients.

Fragestellungen rund um die Sicherheit von transObjects®, insbesondere in der inzwischen weit verbreiteten Application-Service-Providing Variante (ASP) via loggPRO.net, gehören zu den sich am meisten häufenden Fragen überhaupt, was angesichts der jüngsten Fälle von Datenmissbrauch einerseits sowie der deutschen Gesetzgebung in Puncto Vorratsdatenspeicherung anderseits nicht sonderlich verwundert. Dabei betreffen die Fragen gleichermassen den „ruhenden“ Datenbestand – also die Datenbankdateien, die theoretisch auch von Unbefugten gelesen werden könnten – als auch den „fliessenden“ Datenverkehr, d.h. die zwischen dem (transObjects®-) Client und dem Server ausgetauschten Daten. Auch diese könnten theoretisch „mitgeschnitten“ werden und somit in falsche Hände geraten.

Diese Problematik ist alles andere als neu; neu mag allenfalls der neuerliche Problemdruck sein und die rasant zunehmende Relevanz. Jedenfalls versuchen Software- und Datenbankhersteller seit langem insbesondere den Hostern (also Providern, denen Sie Ihre Daten anvertrauen, etwa im Zuge des ASP) ein probates Mittel in die Hand zu geben, damit diese einen wirkungsvollen Datenschutz gewährleisten können. Das SSL (Secure Socket Layer) gehört seit langem zu den bekanntesten Verschlüsselungstechniken, die sich – in dem per se unsicheren Internet – sowohl auf die ruhenden wie auch die fliessenden Daten anwenden lassen.

Die transObjects®-Technologie greift ebenfalls auf die SLL-Techniken der jeweiligen Datenbank-Hersteller zurück. So gehören beispielsweise diverse Verschlüsselungstechniken fest zum Repertoire von Caché dazu, dem in transObjects® immer noch bevorzugten Datenbankserver. Insbesondere die „ruhenden Daten“, also die Datenbank-Files, sind strikt verschlüsselt und somit wären sie als solche, in deren „nackter“ Form, vollkommen nutzlos für die „Langfinger“. Denn sollten diese „falschen Hände“ an die Datenbank-Files wirklich herankommen, würde die Aufgabe sie zu lesen das Knacken der Rosenholz-Akte trivial erscheinen lassen.

Was die Sicherheit des Client/Server-Datenstroms anbelangt, so wartet die transObjects® Gen5 mit einem Feature auf, das wie kein anderes das Prädikat „most advanced“ verdient. Die Rede ist von dem neusten eigens für die Bedürfnisse von transObjects® implementierten DSCE-Verfahren (Data Stream Compression & Encryption). Das transObjects®-DSCE bedeutet eine Abkehr von Standard-Verschlüsselungstechniken á la SSL zugunsten eines proprietären Verfahrens und zwar aus folgendem Grund: SSL-verschlüsselte Daten „vergrössern“ sich gegenüber deren Ursprung, also vor der Verschlüsselung, um – je nach Verfahren – bis zu 250% (!).

Während dieser „Aufblähungseffekt“ im Falle von ruhenden Daten von nur minderer Relevanz ist, sieht es bei den fliessenden Daten schon mal ganz anders aus. Gerade bei der Client/Server-Topologie von Kaliber transObjects®, wo die Client/Server-Performance und die Optimierung (insbesondere Minimierung !) des Datenflusses ein nicht wegzudenkendes technologisches Merkmal darstellt, wäre dessen Vergrösserung – und sei es in einem so hehren Namen wie dem der Datensicherheit – ein Widerspruch in sich.

Vor diesem Hintergrund kann man durchaus von einem Geniestreich der K&S-Entwickler sprechen. Denn durch den Einsatz eines hocheffizienten DSCE-Algorithmus gelang es dem finnischen Team der K&S den Datenstream zwischen dem Client und dem Datenbankserver um bis zu 50% zu verkleinern und das bei gleichzeitiger Verschlüsselung!

Es ist klar, das ein solches Verfahren einen enormen Rechenaufwand impliziert. Man muss sich hierbei nur vergegenwärtigen, dass jeder Datenaustausch mit dem Datenbankserver eine Verschlüsselung und Komprimierung vor dem Senden der Daten erfordert und gleichermassen eine Entschlüsselung und Dekomprimierung nach deren Empfang, bevor mit denen weitergearbeitet werden kann! Von daher bedurfte es einer höchst effizienten Implementierung, sowohl auf Seiten der Clients als auch auf der des Datenbank-Servers. Die Lösung der K&S-Entwickler konnte deshalb nur so aussehen, dass auf beiden Seiten der Client/Server-Barrikade maschineneffizienteste native Techniken zum Einsatz kommen mussten. Es gibt wohl kaum eine bessere Antwort auf die häufig gestellte Frage, wozu man in der Ära von managed-Code noch den native Code braucht…

Kapitel 4.

Im Teil IV der technischen Charakterisierung von transObjects®’s Gen. 5 erläutern wir den Sinn und Zweck von Browser-Clients (im Folgenden nennen wir sie LWA’s, was schlicht „loggPRO Web Access“ bedeuten soll), wie sie zunächst für elektronische Verzollungsverfahren zusätzlich zu den üblichen transObjects®-Clients zum Zuge kommen sollten.

Die Ankündigung von LWA’s beginnend mit dem neuen IDEE-Verfahren (ideale elektronische Exporteurlösung) hat zwar nicht gerade eine Lawine von Fragen ausgelöst, jedoch wurden wir schon des Öfteren nach der Sinnhaftigkeit von „Browser-Applikationen“ ausgerechnet noch zusätzlich zu den „normalen“ Clients-Werkzeugen gefragt, gerade vor dem Hintergrund der sonst üblichen technologischen Züge von transObjects®. Die Frage nach Sinn und Zweck von solchen LWA’s zu beantworten fällt dann auch nicht sonderlich schwer. Denn der Vergleich zu Microsoft’s Exchange/ Outlook/ OWA (Outlook Web Access) drängt sich nahezu von alleine auf. Wir kennen die Vorzüge der aktiven Serverinstanz (MS Exchange-Server) ebenso, wie die des mächtigen Windows-basierten Clients (MS Outlook), wobei wir gleichermassen den universell einsetzbaren Outlook Web Access, gerade auf Auslandsreisen, sehr zu schätzen gelernt haben. Wir wissen, dass das „Webmail“, wie manche den Outlook Web Access auch nennen, nicht all das bietet, was wir am stationären Arbeitsplatz gerne anwenden, aber die Grundfunktionen, wie Mails-, Kontakte-, Termine- etc. verwalten können wir damit allemal und dies ist für das Internet-Café auf einer Schilfgras-Insel des Titicacasee beispielsweise völlig alternativlos.

All das lässt sich ebenso auf die transObjects®-Technologie übertragen. Auch hier spielt zunächst einmal eine „most advanced“ Serverinstanz eine zentrale Rolle, dann gibt es – wie es sich bei einer typischen Client/Server-Topologie gehört – die transObjects®-Clients, die sehr direkt auf dem Betriebssystem aufsetzen und so all dessen Vorzüge, Features etc. mit höchstmöglicher Performance ausreizen. Dennoch: Auf einer Uros-Insel, um im Beispiel zu bleiben, würde es nicht nicht viel nutzen; zumindest nicht auf Anhieb, erst nach einigen Downloads und sonstigen Setups.

Um dies zu umgehen, führt die K&S Informatik GmbH die LWA’s („loggPROWeb Access“) ein. Die LWA’s werden – ähnlich dem OWA – durchaus die essentiellen Grundfunktionen aufbieten. So wird es im Falle des neuen LWE-Tools fürs „IDEE“ möglich sein, Deklarationen zu erfassen, zu plausibilisieren und anschliessend zum Zoll zu übermitteln, es wird möglich sein, Fehlersuche zu betreiben, Zollbescheide zu verwalten; kurzum, man wird auch übers LWA durchaus „verzollen“ können, wenn gleich nicht mit dem Komfort und Performance eines gewohnten transObjects®-Clients.

Durch die Einführung von LWA’s erhöht die K&S GmbH noch weiter die praktische Verfügbarkeit von transObjects®-Applikationen und hebt damit die Connectivity sowie Reliability auf den derzeit technisch höchstmöglichen Stand. Und die K&S sorgt erneut für ein branchenweites Novum. Im Jahre 1996 kam das erste Windows-Interface für das Verfahren „Zollmodell’90“ ebenfalls aus dem Hause K&S, nun ist es dieselbe K&S, die als erster aller Anbieter ein „duales“ Interface, also sowohl Windows- als auch Web-basiert, einführt.

Um noch abschliessend auf einige Fragen zu den LWA’s einzugehen:

Die transObjects®-LWA-Clients wurden für eine grösstmögliche Verfügbarkeit und universelle Einsetzbarkeit entwickelt und beinhalten somit keinerlei Browser-Plugins. Weitergehende Features, wie z.B. Drag & Drop-Technik, MS Office-OLE, bleiben somit den Windows-basierten transObjects®-Clients vorbehalten. Aus diesen Gründen bleiben auch die letzteren nach wie vor die empfohlenen Client-Tools, während LWA’s eher als die Ultima Ratio gelten. Auf diese sollte grundsätzlich nur dann zurückgegriffen werden, wenn die Installation von transObjects®-Clients nur schwer oder gar nicht möglich sein sollte. Das Fehlen des Windows, überaus starke System-Restriktionen oder eben eine nur temporär genutzte Umgebung (Internet-Café) können beispielsweise ein solches Szenario bilden.

Die transObjects®-LWA-Clients vollführen eine Interaktion mit denselben Server-seitigen Vorrichtungen, wie es die Windows-basierten Clients ebenso tun. Daher bestehen in Puncto Datenstrukturen, aber auch beim Plausibilisieren oder Transferieren einer Zolldeklaration keinerlei Unterschiede bei der Nutzung beider Client-Varianten. Die mit dem LWA (vor-) erfassten Deklarationen können mit dem „normalen“ transObjects®-Client vervollständigt und anschliessend zum Zoll übermittelt werden, wie auch umgekehrt.