Was sind die Unterschiede zu anderen Integrations-Plattformen, „Datendrehscheiben“ etc.?

Um das, was in unserem Fallbeispiel dargelegt ist, leisten zu können, muss loggPRO^®.net 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^® und erst recht loggPRO^®.net), 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^®.net 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… 😉 ?

Wie dem auch sei. Nachfolgend wollen wir das Besondere am loggPRO^®.net ausarbeiten, indem wir dessen Funktionsweise ausführlich charakterisieren und uns dadurch der Ausgangsfrage nach dem loggPRO^®.net-API (hoffentlich) gut nähern. Wie die nachfolgende Abbildung zeigt, weist loggPRO^®.net 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 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 schliesslich 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 aussen „angesprochen“ werden können. Vielmehr führt der Weg dorthin stets über die Frontend-Maschinen. Diese 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^®.net!

E-Mail-Archivierung ist sowohl in der Schweiz als auch in Deutschland Pflicht!

.
Sachlage Deutschland: Continue reading „E-Mail-Archivierung: die Rechtslage“ →

Die erste Frage ist relativ einfach zu beantworten: Die technologischen Vorzüge von transObjects^® Gen.5/R2 sind so gewaltig, dass sie auch und gerade für das Dokument- und Archivmanagement handfeste Vorteile bieten. Bei dem loggPRO^®.dms hingegen bedarf das „nomen est omen“ allerdings einer genaueren Erläuterung.

Archivierung und Management von Dokumenten („dms“ steht für document management system) gehören zu denjenigen branchenübergreifenden IT-Bereichen, die in naher Zukunft einen der stärksten Wachstumsschübe erfahren dürften. Der Grund liegt dabei klar auf der Hand: Die Fortschritte der letzten Jahre auf dem Gebiet der Speicherungstechnik haben es möglich gemacht, in Puncto Kapazitäten ganze Aktenberge auf einige wenige Datenträger speichern zu können (!). Das, was früher ganze Archive mit mehreren Räumen, Etagen oder gar ganzen Gebäuden gefüllt hat, passt heutzutage in der Tat auf ein kleines NAS-System mit einem Volumen von einigen Kubikzentimetern. Der Gewinn für Mensch und Umwelt, die Schonung natürlicher Ressourcen etc. müssen hierbei nicht sonderlich erwähnt werden.

Auf der anderen Seite ist ein solches Potential der modernen elektronischen Dokumentspeicherung sehr verlockend – ja, man könnte sagen, es weckt Begehrlichkeiten. Denn wenn man schon eine derart mächtige Archivierungstechnik hat, so möchte man damit doch nicht nur Platz (und Zeit, etwa beim Wiederauffinden der Dokumente) einsparen, sondern auch und insbesondere den gesetzlichen Aufbewahrungspflichten gleich mit begegnen. Der Gesetzgeber ist ja auch längst auf den Plan getreten (alles andere wäre mehr als seltsam 😉 ) und hat – je nach Land bzw. Steuerrecht – ein mehr oder minder kompliziertes Regelwerk vorgegeben. Die sog. „rechtskonforme Archivierung“ hat leider mit derjenigen, die sonst relativ einfach zu haben gewesen wäre, praktisch nichts mehr zu tun…

So ist die elektronische Speicherung von etwas „sensibleren“ Dokumenten (etwa Rechnungen, Veranlagungsverfügungen o.ä.) häufig erst dann rechtskonform, wenn sie fälschungssicher, sicher vor unbefugtem Zugriff bzw. Vervielfältigung etc. gespeichert (denken wir an bestimmte Daten-CD’s der vergangenen Jahre mit „brisantem“ Inhalt 😉 ) und zu guter Letzt auch noch leicht wiederauffindbar ist, da man es dem Prüfer möglichst komfortabel zu machen hat. Darüber hinaus: Diese Vorgaben sind stark volatil, d.h. gilt heute in Deutschland eine Bestimmung „§x“ und in der Schweiz nicht, kann es morgen genau umgekehrt sein.

Gerade um sich dieser Volatilität zu entziehen, arbeiten die Entwickler der K&S GmbH an einer Lösung, die von vorne herein versucht allen rechtlichen Erfordernissen – auch denjenigen, die noch nicht da sind – zu begegnen. So arbeitet loggPRO^®.dms stets auf verteilten und transzendent verschlüsselten Caché-Datenbanken, so dass eine Entwendung der Datenträger völlig nutzlos bleibt. Darüber hinaus wird jedes Objekt (Dokument) mit einem fälschungssicheren Zeitstempel versehen, was es zusammen mit der mitgeführten Chronik de facto nicht fälschbar macht.

Eine etwas andere Sache ist die allseits bekannte Indizierung, womit wir bei der Frage „nomen est omen“ wären. Mit der Indizierung wollen wir es nicht so sehr dem Prüfer erleichtern, sondern allem voran uns selbst. Wir wissen, dass eine Fotoaufnahme eines Dokumentes für sich genommen überhaupt nichts über dessen Inhalt besagt, zumindest nicht für das Wesen mit dem IQ=0 in unserer Nähe. Ein Dokument-Scan ist für den Computer so wie ein Urlaubsfoto vor dem Wegweiser nach Villa O’Higgins: Eine Ansammlung von Punkten mit unterschiedlichen Helligkeiten und Farben, aber der Schriftzug „Villa O’Higgins“ ist als solcher nur für Wesen mit einem höheren IQ ersichtlich. Wir erfassen diesen Schriftzug im Bruchteil einer Sekunde.

Was also tun? Schließlich wollen wir nicht nur die gescannte Rechnung sondern auch deren Nummer, (Teil-) Beträge, buchhalterische Konten etc. mit abspeichern.

Hier kann nur der Mensch mit seinem humanen Einsatz helfen, indem er beim Speichern all die Informationen schlicht eintippt. Oder wir bedienen uns der OCR-Technik. Die Texterkennung, die zuletzt immer mehr verfeinert worden ist, kann hierbei Abhilfe schaffen. Das Problem ist nur der Aufwand und die mehr oder weniger gute Erkennungssicherheit. Und was ist, wenn die Trefferquote eher schlecht als gut ist?

An dieser Stelle nutzt unser loggPRO^®.dms den Informationsvorsprung gnadenlos für sich (und somit für Sie als loggPRO^®-User) aus. Denn die für die sichere Indizierung benötigten Daten sind ja im loggPRO^®-System bekannt. Hat jemand z.B. die Veranlagungsverfügung mit loggPRO^®.edec erzeugt, sind alle Daten, die für die Indizierung benötigt werden, vorhanden und ausserdem über mögliche OCR-Fehler erhaben. Es müssen keine Zahlen erkannt und keine Strichcodes eingelesen werden. Somit kann der User, der im loggPRO^® arbeitet, seine Dokumente automatisch archivieren und das rechtskonform, mit 100% „OCR”-Sicherheit!

Äquivalenz zwischen loggPRO^®– und loggPRO^®.dms-Strukturen

Einem Auftragsdossier mit der Relation „99“, Do-Nr „1001“, Position „0“ (also. Auftrags-Nr. etwa 99/1001/0) wird eine Liste von PDF-Dokumenten hinzugefügt (unten-links).
Diese sind dann im loggPRO^®.dms -Explorer unter dem Thread dossier->99->1001->0 zu sehen (oben-rechts).

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.

Zu den zunehmend wichtigen wenn auch häufig weit unterschätzten Merkmalen einer Computer-Software bzw. einer IT-Vorrichtung überhaupt zählt deren sog. Skalierbarkeit. Der vorliegende Artikel sollte zum einen klären, was es damit auf sich hat und gleichzeitig eine Überleitung zu einem äusserst innovativen Konzept der K&S GmbH liefern: Es handelt sich hierbei um die sog. dynamisch-polymorphen Objektklassen, die demnächst den transObjects^® Applikationen der 5. Generation das Prädikat der äussersten (massiven) Skalierbarkeit verleihen werden.

Insbesondere bei Softwaremodulen aus dem Bereich der Logistik kriegt man im Rahmen von Produktwerbung, sofern diese die up-to-date ist, jede Menge Vielversprechendes zu hören. Immer häufiger heisst es hierbei, die gegebene Software (bzw. technische Vorrichtung, ein Portal etwa) könne jedem Unternehmensprofil und jedem Geschäftsgebaren gerecht werden und sei auf so ziemlich alle Grössenordnungen ausgelegt.

Aber ist es wirklich so? Kann eine Software „vom Einplatzsystem bis zum Grosskonzern“ die goldrichtige Lösung sein, wie eine öfters an uns herangetragene Frage lautet?

Nun, hierauf haben wir zwei Antworten, eine gute und eine schlechte. Die gute zuerst: Ja, ein IT-System und insbesondere ein Softwareprogramm kann – theoretisch – einem breiten Spektrum von Grössenordnungen und Anforderungsprofilen durchaus gerecht werden, vorausgesetzt – und da kommt es schon – es ist eben in hinreichendem Masse skalierbar!

Allerdings gibt es noch die schlechte Nachricht dabei und die wäre schlicht die, dass diese Skalierbarkeit in dem speziellen Bereich der Logistiksoftware kaum auszumachen ist. Denn die Realität, mit der die User konfrontiert werden, ist meistens doch eine ganz andere. Eine Software, die noch bei einer Vorführung durch einfache Bedienbarkeit bestach, zeigt nun auf einmal ihre Grenzen, die schier unüberwindlich scheinen. Oder aber, es kam gar nicht erst zur Anschaffung einer Software, die bei der Vorführung das erstaunte Publikum durch eine exorbitante Komplexität förmlich erschlagen hatte. Meistens jedoch gibt es von beidem ein bisschen, getreu dem Motto, ein Unglück kommt selten allein…

An diesen zwei extremen Beispielen sehen wir das Spannungsfeld, in dem sich ein Softwarehersteller heutzutage bewegt. Denn die Balance zwischen Ergonomie, Übersichtlichkeit etc. auf der einen und Leistungsfähigkeit auf der anderen Seite zu finden, ist wahrlich keine einfache Übung. Und während es hinsichtlich der Quantitäten noch einigermassen machbar erscheint (schliesslich können wir mit modernen Datenbank-Techniken unterschiedlichste Grössenordnungen relativ gut abfangen), sieht es bei den von Fall zu Fall variierenden Anforderungen schon wesentlich düsterer aus.

So verwundert es nicht, dass die Individualsoftware derzeit (um die Jahrtausendwende – nachtr. Anm. d. Verf.) eine echte Renaissance durchlebt und dass die Skalierbarkeit zum Mass aller Dinge wird. Nur so bekommt der Anwender all das, was er wirklich braucht, nämlich eine auf seine Grössenordnung und sein Geschäftsgebaren zugeschnittene Lösung, eine Lösung, die es genau bringt, nicht mehr und nicht weniger!

Die K&S Informatik, eine Softwareschmiede, die für individuelle (und durchaus exklusive!) Lösungen bekannt ist, verstärkt nun die zweite der beiden transObjects^®-stützenden Säulen, nämlich die Skalierbarkeit. Letztere ist schon alleine wegen der Objektorientierung von transObjects^® seit dessen Anbeginn alles andere als ein unbeschriebenes Blatt. Aber nun setzen die K&S-Entwickler noch eines drauf und zwar durch die Einführung von sog. dynamisch-polymorphen Objektklassen. Dieses überaus innovative Konzept, das zunächst im Warehousing-Bereich der 5. Generation von transObjects^® Einzug erhalten wird, verleiht dem loggPRO^® ein Prädikat, das derzeit noch äusserst selten anzutreffen, geschweige denn gerechtfertigt ist: Es handelt sich um sehr hohes Mass an Skalierbarkeit, gewissermassen die „massive Skalierbarkeit“.

Genaueres über die transObjects^® dynamisch-polymorphen Objektklassen, geeignete Datenbank-Modelle, Skalierbarkeit überhaupt etc. findet der Leser in der Hochschul-Abschlussarbeit „Über das multidimensionale Datenbankmodell nicht-relationaler Datenbanken“.

Im Teil 1 unseres FAQ-Artikels zum Thema „Itanium, Opteron, IA64, x64…“ haben wir die technologischen Grundzüge der der beiden 64-Bit-Plattformen kennen gelernt und zwar unter dem Blickwinkel der jeweils zugrunde liegenden Prozessor-Architekturen. In dem vorliegenden zweiten Teil versuchen wir die gewagte Aussage, welche der beiden 64-Bit-Plattformen à la longue die Nase vorn haben wird. Dies ist gerade vor dem Hintergrund der überraschenden Benchmarks von Cachè unter IA64 bzw. x64 für viele transObjects^®-User von Bedeutung, die sich die Frage stellen, welche Plattform für den Server aber auch für die Clients wohl die richtige ist.

Zu den am häufigsten vorhergesagten Szenarien in Sachen x64 vs. IA64 zählt eines wie etwa das hier: x64 sichert sich die Marktführerschaft im Bereich der Workstations bis hin zu den Laptops, während IA64 den Servern vorbehalten bleibt.

Derzeit (Ende 2005 Anfang 2006) gibt es auch einige Indikatoren, die hierfür sprechen. Da ist beispielsweise die Entscheidung von Hewlett-Packard aus dem Jahre 2004, die Itanium®-basierten Workstations der ZX-Reihe abzukündigen und die gesamte Integrity-Modellreihe grundsätzlich den Servern vorzubehalten. Ferner gibt es noch die Entscheidung von keinem geringeren als Intel®, die AMD64’er in Lizenz zu nehmen und als „enhanced memory“ (EM64T) zu vertreiben. Und last but not least gibt es noch die Abwärts- und Aufwärts-Kompatibilität, die den so immens wichtigen Investitionsschutz bietet: Die allermeisten CPU’s, die seit einem knappen Jahr bei der PC-Herstellung verarbeitet werden, sind bereits x64-fähig, d.h. sie könnten bei Bedarf jederzeit ein AMD64/EM64T-basiertes Betriebssystem, insbesondere eine x64’er Edition von Windows, vertragen. Dabei tut der nahezu verlustfreie 32-Bit-Modus das Übrige, so dass derzeit vieles in der Tat für einen Siegeszug von x64 über IA64 zu sprechen scheint, zumindest im Bereich von Workstations bis hin zu den kleineren Servern.

Wir sehen die Sache allerdings ein wenig anders. Zunächst glauben wir nicht an eine Koexistenz von zwei solch unterschiedlich gearteten Plattformen über mehrere Jahre hinweg. Bereits aus der Verhaltensforschung in der Tier- und Pflanzenwelt lernen wir, dass Konstellationen mit etwa gleich starken Mitgliedern zu den instabilsten überhaupt gehören, während eine klare Hierarchie weitaus mehr Stabilität bedeutet. Auf die hier diskutierten 64-Bit’er Plattformen übertragen heisst das, dass eine der beiden durch die andere à la longue verdrängt werden wird. Das muss zwar nicht notwendigerweise das totale Verschwinden einer der beiden bedeuten, aber schon eine gewisse Marginalisierung d.h. Hineindrängen in eine Nische; manche sagen auch „Schmollwinkel“.

Von den Beobachtungen in der freien Wildbahn abgesehen sprechen noch rein ökonomische Gründe für die Konsolidierung im Sinne der klaren Herauskristallisierung einer der beiden Plattformen. Für die Softwarebranche, in der auch die K&S Informatik tätig ist, ist es nämlich auf Dauer zu teuer, Produkte in jeweils zwei Builds, Editions oder was auch immer anzubieten. Und die Unterscheidung zwischen den Clients und den Servern hilft da nur bedingt weiter. So könnte sich beispielsweise die K&S aufs x64 bei den Clients beschränken, während auf den Datenbankservern optional auch Itanium zum Zuge kommen könnte. Allerdings ist nicht zu vergessen, dass auch die transObjects^®-Clients öfters auf den Servern selbst betrieben werden – denken wir da an manche Applikationen, die als Bestandteil der Enterprise-Editions oder des Datacenters auf mächtigen Servern betrieben werden.

Die allermeisten von denjenigen, die unsere Einschätzung hinsichtlich Verdrängung einer der beiden Plattformen teilen, sehen – gefragt nach dem x64 oder IA64 – über kurz oder lang das x64 vorne. Das Szenario dabei: x64 nutzt den Vorteil schon immer da gewesen zu sein. Die Brückenfunktion von 32-Bit zu 64-Bit wird noch über Jahre hinweg sehr entscheidend sein, da die Software-Branche nicht so schnell mitgehen wird. Die Vorteile der IA64-Architektur kompensiert x64 mit den beständig steigenden Taktungen und bei weiterhin moderater Preisentwicklung kommt AMD64 bzw. EM64T insbesondere unter dem Blickwinkel des Investitionsschutzes in immer mehr Servern zum Zuge.

Viel seltener ist da ein dem entgegen gesetztes Szenario. Die Vorteile von x64 in Sachen besseren WOW64 etc. nehmen im Laufe der Zeit ab, da die Softwarebranche und die User goldene Brücken gebaut bekommen, um auf IA64 einzuschwenken. Zudem folgt die Entwicklung bei den Taktungen nicht mehr Murphy’s Gesetzen; vielmehr zeichnet sich bei ca. 5 GHz eine Grenze ab. Die Erhöhung des Cache als Ausgleich hierfür bringt bei dieser Architektur nur ganz begrenzt Vorteile.

Gleichzeitig kann Itanium® seine Stärken voll ausspielen. Bei der Taktung wird die Schere zu „Opteron“ weitgehend geschlossen, so dass die architektonischen Vorteile von IA64 umso mehr zur Geltung kommen; die Nachteile des IA-32-Execution-Layers interessieren kaum noch jemanden. Zudem führt Intel® stets zwei Varianten des Itanium®. Während der eine Itanium® mit mehreren Cores auf dem Die und Schwindel erregendem Cache klar für extrem kritische Serverumgebungen prädestiniert ist, gibt es noch einen „kleineren“ Itanium®, der guten alten Tradition des kleineren McKinley (seinerzeit Codename „Derfield“) folgend. Diese CPU, mit sagen wir nur einem Core auf dem Die, 2 GB L3-Cache, gefertigt auf sagen wir 60 nm und unter 1V laufend, ist dann kompakt und energieextensiv genug, um auch in den Laptops Platz finden zu können.

Welches der beiden Szenarien Realität werden wird, ob nicht vielleicht doch das „sowohl x64 als auch IA64“ uns noch jahrelang begleiten wird, können wir im Moment nicht sagen. Sicher ist nur, dass die K&S und deren transObjects^® auf beide Plattformen schaut und vorerst für beide entsprechende Lösungen anbieten wird. Ob bereits in der 5. Generation von transObjects^® eine Präferenz zugunsten von einer der beiden Plattformen abgegeben wird, war zum Zeitpunkt der Abfassung unklar.

Ein Beispiel? Bitte schön. Betrachten wir den folgenden logistischen Vorgang: Ein Logistikunternehmen XY-Log spediert seltene Pflanzen aus dem Nahen Osten nach Deutschland zum Großabnehmer XY-Flora. XY-Flora tätigt die Bestellung auf der Website von XY-Log und löst damit eine Vorgangsnummer, mit deren Hilfe er sich in den nächsten Tagen nach dem Stand der Order erkundigen wird. Diese Vorgangsnummer kam nicht von ungefähr sondern wurde vielmehr in der loggPRO^®.net-Datenbank errechnet, die der Fa. XY-Log zugewiesen ist. Bei dem nächsten Polling (Abfragen) der loggPRO^®.net-Datenbank wurde dieser Vorgang auf das interne Auftragssystem der XY-Log, das nicht einmal ein transObjects®-System ist, automatisch (!) repliziert und entsprechend zur Verarbeitung weitergeleite.

XY-Log weiss, dass die betr. Ware erst in der Schweiz ankommt, wo ein Transitvorgang initiiert werden muss, um dann in Deutschland entsprechend gelöscht zu werden. Mit der gleich doppelt aufwändigen Transitabfertigung (Schweiz und Deutschland) pflegt XY-Log eine Fa. XY-Zoll zu beauftragen, die ebenfalls ans loggPRO^®.net angeschlossen ist; das geht dann per Knopfdruck.

XY-Zoll ist glücklicherweise mit der transObjects®-Software ausgestattet und somit in der Lage, beide Abfertigungen elektronisch tätigen zu können. Diese Abfertigung wird in Form des veränderten Status aufs loggPRO^®.net repliziert, so dass sowohl XY-Log als auch XY-Flora ihre Informationen just-in-time bekommen. Nach der Entlademitteilung an den Zoll (Atlas-Vorgang) durch XY-Zoll bleibt nur noch die Lieferung an XY-Flora und das war es!

Dieses Beispiel veranschaulicht, welche Probleme loggPRO^®.net eigentlich löst. Denn wäre z.B. XY-Zoll nicht ans loggPRO^®.net angeschlossen, wären die Kontinuität des Vorgangs und auch dessen Verfolgbarkeit unterbrochen und somit nicht gewährleistet – von überflüssigen Datenerfassungen ganz zu schweigen. So aber sind alle Teilnehmer zu jedem Zeitpunkt über den Stand der Dinge informiert, auch dann, wenn sie mit unterschiedlich gearteten und vollkommen getrennten Systemen arbeiten.

Im Rahmen der vorliegenden Fallstudie wollten wir herausfinden, wie sich der Caché-Server unter den beiden Windows® 64-Bit-Plattformen schlägt, also haben wir entsprechend die Betriebssysteme Windows® 2003 -x64 sowie -IA64 auf insgesamt drei Testmaschinen installiert. Bei der Continue reading „Fallstudie: Benchmarks von Caché unter x64 und IA64“ →