Als wir uns im Jahre 2000 dazu entschlossen haben, neue Software in Java zu entwickeln, sind wir von vielen belächelt worden. Java galt damals vielen als langsam und umständlich.
Die Vorteile einer plattformunabhängigen Lösung sah man nicht so recht und selbst der objektorientierte Ansatz
in Java galt vielen als suspekt.

Heute ist Java eine der am meisten verbreiteten Programmiersprachen und Microsofts C# basiert als Konkurrenzprodukt
(mit dem wir übrigens ebenfalls seit geraumer Zeit entwickeln) auf demselben Denkansatz.

Als wir 2002 die ersten Gehversuche mit WebServices machten…
Heute sind WebServices – auch mit den Begriffen der „service-orientierten Architektur (SOA)“ und dem „Enterprise-Service-Bus (ESB)“ betitelt - in fast allen großen Unternehmen im Einsatz. Vielleicht noch nicht überall als Kernarchitektur, aber zumindest in einigen wichtigen Bereichen.

Die Art, Software zu entwickeln hat sich seit der Jahrtausendwende ebenso radikal weiterentwickelt wie die Architektur moderner Unternehmens-Software.

Dabei geht es gar nicht darum, ob eine Software jetzt „im Internet-Browser“ läuft. Das ist für einige Applikationen wünschenswert – insbesondere wenn sie sich an eine unbestimmte Zahl von Anwendern in unterschiedlichen Unternehmen oder Organisationszweigen wenden – für andere vielleicht auch nicht. Da die Präsentationsebene ohnehin nur eine Schicht der Geschäftsapplikation ist, kommt es auch gar nicht wesentlich darauf an. Es gibt in jedem Projekt gute Gründe für oder gegen browserbasierte Lösungen. Die einfache Faustregel „browserbasierte Software ist modern“ stimmt nicht. Auch eine browserbasierte Software kann schlecht oder altmodisch oder unkomfortabel sein. Es kommt viel mehr auf die Gesamtarchitektur einer Lösung an.

Wir haben heute die Chance – auch wenn das noch nicht immer perfekt funktioniert -, die Kerntätigkeit eines Unternehmens in einer für die Fachabteilung und die Softwareentwickler verständlichen Form zu formulieren (UML2) und die erforderlichen Geschäftsprozesse so als granulare Services zur Verfügung zu stellen, dass wir im Prinzip eine Unternehmenssoftware bauen können wie ein Lego-Modell. Mit dem Unterschied, dass wir die Steine nicht komplett einkaufen können. Wir müssen sie teilweise selbst entwickeln oder wir modifizieren die vorhandenen so, dass wir etwas mit ihnen anfangen können.

Der große Vorteil liegt dabei noch nicht einmal unbedingt in dem Legostein-Bild („standardisierte Schnittstellen = Bausteine unterschiedlicher Hersteller lassen sich miteinander auf gleichartige Weise verbinden).

Er liegt in der Art, wie diese „Legosteine“ miteinander kommunizieren: über eine einheitliche Geschäfts-Prozess-Sprache: BPEL (Business Process Execution Language – es gibt auch noch andere Ansätze) und Serverprodukte, die sie implementieren.

Damit wird eine lose Kopplung zwischen einzelnen Services möglich, ohne den Geschäftsprozess als solches aus dem Auge zu verlieren. Und das – wo nötig – über alle Grenzen von Hardware, Applikationen und Unternehmen hinweg.
Die Kommunikation ist dabei asynchron, der empfangende Service muss also das Kommando nicht zur gleichen Zeit zurückgeben zu der er es empfängt, sondern kann es durchaus in einem Puffer zwischenspeichern. Ganz ähnlich wie ein eMail.

Welche Möglichkeiten das in der Praxis eröffnet, wird vielfach erst klar wenn man die entsprechenden Projekte startet.
Der Wechsel von DOS nach Windows Anfang der 90er Jahre war ein Wechsel der Darstellungsweise von Daten.

Der Wechsel von monolithischen Applikationen zu kombinierbaren Services ist ein Wechsel der gesamten Sichtweise
auf die Erzeugung und Verarbeitung von Daten.

Wir sind ein wenig stolz darauf, diese Richtungen jeweils frühzeitig erkannt und entsprechendes Knowhow aufgebaut zu haben, auch wenn es dafür nicht in jedem Fall sofort Abnehmer gab.

Natürlich gibt es auch andere Wege der Integration von Applikationen und natürlich sind wir diese gegangen und gehen diese heute noch. Der einfachste und sicherste Weg dürfte in vielen Bereichen die Integration über Datenbank-Tabellen sein.

Solides Fachwissen in den Bereichen SQL und Datenbankadministration ist und bleibt daher unverzichtbar. Es gibt leistungsfähige Werkzeuge, die beispielsweise beim Mapping von Datenbanktabellen zu Objekten eine große Hilfe darstellen. Wir entwickeln unsere Lösungen aber - wo immer dies möglich ist - unabhängig von einem bestimmten Datenbank-Produkt. Damit bleibt es wichtig, das Verhalten bestimmter Produkte bei bestimmten Abfragen zu kennen
und die Software dahingehend zu optimieren. Und letztlich setzt auch ein Service auf einer Datenbank auf.

Und wenn Sie jetzt von den meisten Dingen nur „Bahnhof“ verstanden haben sollten, können Sie zwei Aussagen mitnehmen:

1. EXSO. entwickelt für Sie eine moderne, zukunftssichere und benutzerfreundliche Lösung,
die genau das kann was Sie haben möchten.

2. EXSO. integriert neue Lösungen in Ihren vorhandenen Applikationsbestand,
so weit dies möglich und gewünscht ist.

Das ist doch was.