Es stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über https (Hypertext Transfer Protocol) und TCP (Transmission Control Protocol). Man kann SOAP auch über das SMTP (Simple Mail Transfer Protocol) oder JMS (Jakarta Messaging) verwenden.

Die mit der Nachricht übermittelten Nutzdaten man nicht zwingend in XML senden. Andere Formate wie Base64 oder CSV sind ebenfalls möglich. Seit Version 1.2. nutzt man die Abkürzung SOAP offiziell nicht mehr als Akronym, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.

Kurze Zeitreise

SOAP entstand aus der Weiterentwicklung der Spezifikation für XML-RPC im Jahr 1998. Hauptverantwortlicher Software-Entwickler damals Dave Winer und seine Firma UserLand Software in engem Austausch mit Microsoft. Dave Winter ist übrigens auch für RSS 2.0 verantwortlich. Einen Beitrag über RSS findet man hier.

Im Jahr 1999 fand die Veröffentlichung der Version 1.0 von SOAP statt. Dies stellt unter Anderem den Zeitpunkt dar, an dem die Entwicklung mehr Unterstützung fand. Vor allem hat sich IBM im Jahr 2000 der Entwicklung angeschlossen, was dazu führte, dass IBM, Microsoft, DevelopMentor (Don Box) und UserLand Software (Dave Winer) die Spezifikation von SOAP 1.1 beim World Wide Web Consortium (W3C) einreichten. Dabei hat man das Ziel verfolgt, eine Arbeitsgruppe zu gründen, die SOAP weiterentwickeln sollte. Das Ergebnis dieser Arbeitsgruppe ist SOAP Version 1.2, empfing im Juni 2003 die Anerkennung als recommendation (Empfehlung).

Wie zu Beginn des Beitrags erwähnt, hat man SOAP nicht mehr als gebräuchliche(s) Akronym bzw. Abkürzung verstanden. Der Hauptgrund dafür ist die Tatsache, dass sämtliche Deutungen für SOAP, wie Simple Object Access Protocol oder Service Oriented Architecture Protocol, nicht mehr den vollständigen Sinn von SOAP trafen. Dies ermöglichte die Anmeldung von SOAP als Markennamen in den USA.

Wie funktioniert SOAP?

SOAP ist wie zuvor beschrieben, ein Protokoll zum Austausch XML-Information-Set-basierter Nachrichten über ein Rechnernetz und hat den Status einer W3C-Empfehlung. Es stellt Regeln für das Nachrichtendesign auf. Regelt, wie Daten in der Nachricht abzubilden und zu interpretieren sind. Es gibt eine Konvention für entfernte Prozeduraufrufe mittels SOAP-Nachrichten vor. SOAP macht keine Vorschriften zur Semantik applikationsspezifischer Daten, die man gegebenenfalls versendet möchte, sondern stellt ein Framework (Siehe meinen Beitrag) zur Verfügung, welches erlaubt, dass man beliebige applikationsspezifische Informationen übertragen kann.

Man kann SOAP für entfernte Prozeduraufrufe ebenso nutzen wie für einfache Nachrichtensysteme. Zum Senden von Nachrichten kann man beliebige Transportprotokolle verwendet. Dazu gehören beispielsweise FTP, SMTP, https oder auch JMS. Aus Gründen der Kompatibilität nutzt man in der Praxis hierzu gängige Netzwerk-Architekturen. Auch ist mittels https die verschlüsselte Übertragung von SOAP-Nachrichten möglich. Das ermöglicht jedoch keine End-to-End-Verschlüsselung. Dies kann man durch WS-Security erreichen. Die Einbindung erfolgt lediglich auf der Ebene der Nachrichten und nicht auf der des unterliegenden Transportprotokolls. Folglich ist es so, dass man das XML Information Set der SOAP-Anfrage bei Nutzung von https(S) im Body eines https POST Requests als XML an eine gegebene URL schickt.

In der Regel setzt man SOAP da ein, wo der direkte Zugang fremder Systeme zu einer Informationsquelle nicht sinnvoll erscheint. Dies kann sowohl an Kompatibilitätsproblemen zwischen verschiedenen Anwendungsarchitekturen liegen aber auch an diversen Sicherheitsaspekten. So kann man einen (partiellen) Zugriff auf eine Datenbank ermöglichen, ohne dem Anwenderprogramm den direkten Zugang zu ermöglichen. Die Menge der ausführbaren Methoden reglementiert und definiert man über die SOAP-Schnittstelle.

Die Kommunikation mit SOAP ermöglicht die Kopplung von Systemen. Der offene Entwurf ermöglicht jedoch lediglich den Aufbau schwach gekoppelter Systeme. Die Flexibilität des Konzeptes erkauft man sich durch die Nachteile beim Übertragungsvolumen und Rechenaufwand. Dies kann teuer werden, da man das XML-Dokument beim Sender zunächst aufbaut und anschließend validiert. Das Konzept verfolgt eigentlich das Ziel eines leichtgewichtigen Protokolls.

Doch durch den flexiblen Einsatzbereich führt die zu übertragende Datei eine Reihe von Metadaten mit sich, die bei der Konstruktion des XML-Dokuments weiter anwächst. So führt beispielsweise das einfache Versenden von „Wahr“ oder „Falsch“ zu einem Datenvolumen von mehreren hundert Bytes. In einem stark gekoppelten System sollte dafür theoretisch ein Bit reichen.

Durch die Möglichkeit des flexiblen Aufbaus des Dokuments kann man jedoch auch komplexe Transaktionen in einer Anfrage atomar zusammenfassen, während man in stark gekoppelten Systemen hierzu oftmals mehrere Anfragen erstellen muss. Dies verbessert das Nutzlastverhältnis (Nutzdaten zu Meta-Daten) und den Kommunikationsaufwand (für den Aufbau einer Verbindung, nur ein Senden/Empfangen).

SOAP unterscheidet zwischen dem endgültigen Empfänger und den Zwischenempfängern. Dies ermöglicht es, eine Nachricht über verschiedene „Hops“ zu schicken, bei denen man sogar verschiedene Transportprotokolle verwendet. Beispielsweise kann man zum ersten Hop die Nachricht mittels Java Message Service schicken, im Anschluss über E-Mail und schließlich dem Empfänger mittels https weitergeben. Der Absender muss über die Zwischenhops keine Information haben, die Middleware jedoch schon.

Wie ist eine SOAP-Nachricht aufgebaut?

Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element, dem man einen lokalen Namen zuweisen muss. Dieses Element referenziert mittels eines Namensraum-Attributes auf https://www.w3.org/2003/05/soap-envelope. Child dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem kann man Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zu Transaktionsidentifizierung, unterbringen. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Dies sieht dann folgendermaßen aus:

<?xml version="1.0"?>
<s:Envelope xmlns:s="https://www.w3.org/2003/05/soap-envelope">
    <s:Header>
    </s:Header>
    <s:Body>
    </s:Body>
</s:Envelope>

Innerhalb des Body-Elements können sowohl Informationen zum Datenaustausch als auch Anweisungen für einen entfernten Prozeduraufruf stehen. Dies ist vom Empfänger entsprechend zu interpretieren.

Im Header gibt man den nächsten Hop (intermediary) und den endgültigen Empfänger (ultimate recipient) an. Ein intermediary kann beispielsweise die Nachricht verschlüsseln, sie loggen oder die Nachricht aufteilen. Ersteres erlaubt es, dass die Anwendungslogik sich nicht um die Sicherheit der Nachricht kümmern muss. Darum kümmert sich die Middleware. Was eine Middleware ist, erkläre ich in einem anderen Beitrag. Die Möglichkeit, dass Intermediaries beliebige Dinge tun können, ermöglicht EAI (Enterprise Application Integration).

Fazit

Viele Altsysteme verwenden möglicherweise noch SOAP. In der Vergangenheit war es auch die Lösung schlechthin. Heute ist es eher REST, welches zum Einsatz kommt und in webbasierten Szenarien häufig als die schnellere Alternative gilt.

Zusammengefasst kann man sagen, dass REST aus einer Reihe von Richtlinien für eine flexible Implementierung besteht und SOAP ein Protokoll mit spezifischen Anforderungen wie XML-Messaging ist.

REST-APIs sind schlank und daher ideal für moderne Anwendungen geeignet, wie das Internet of Things (IoT), mobile Anwendungen und Serverless Computing. SOAP-Webservices bieten zwar integrierte Sicherheit und Transaktions-Compliance, die vielen Unternehmensanforderungen entspricht, doch die Erstellung und Wartung ist wesentlich aufwändiger. Darüber hinaus folgen auch viele öffentlich zugängliche APIsheutzutage, den REST-Richtlinien.

Der Beitrag SOAP – Effiziente Möglichkeit, um Daten zwischen Systemen zu übertragen erschien zuerst auf CEOsBay.

Kurze Zeitreise

Eclipse ist im Grunde genommen der Nachfolger von IBM Visual Age for Java 4.0. Der Quellcode dafür wurde im Jahr 2001 von IBM freigegeben. Im Jahr 2004 beschloss das von IBM geführte Eclipse-Konsortium die Ausgründung der rechtlich eigenständigen Eclipse Foundation, die seitdem für die Entwicklung von Eclipse verantwortlich ist. Es unterstützt die Java-Version 5 ab Version 3.1 und Java 6 ab Version 3.2. Ab dem Jahr 2006 wurden die Veröffentlichungstermine neuer Versionen der wichtigsten Eclipse-Komponenten harmonisiert, um Versionskonflikte zu vermeiden und Eclipse-Anwendern die Nutzung zu erleichtern. Man hat den Veröffentlichungszyklus ab der Version 2018-09 auf Quartalsaktualisierungen verkürzt, da ab Java 9 nicht mehr alle 3 Jahre, sondern alle 6 Monate eine neue Java Version erscheint. Es folgt nun einem Rolling Release Modell.

Rolling Release

(„rollen“ und „veröffentlichen“. Sinngemäß handelt es sich dabei um die kontinuierliche Aktualisierung der Software und ist ein Begriff aus der Softwareentwicklung. Bei einem Betriebssystem, dass das Rolling-Release-Prinzip anwendet, gibt es keine Betriebssystem-Versionen, bei denen bei einem Versions-Upgrade eine große Menge an Software auf einmal aktualisiert wird. Die einzelnen Software-Pakete werden vielmehr immerfort aktualisiert. Dies schließt sogenannte Releases, also Veröffentlichungen des Betriebssystems, aber nicht aus. Im Gegensatz zu einem Betriebssystem ohne Rolling Releases sind die Veröffentlichungen jedoch keine Versionen, sondern sogenannte Snapshots. Dies bedeutet, eine Kopie aller im Moment im Repository liegenden Software-Versionen. Diese Snapshots dienen meistens auch als Installations-Medien.

Die Projektnamen waren bisher nach den Jupitermonden (Callisto, Europa und Ganymede), den Raumsonden Galileo und Helios, die Version 3.7 nach der für Eclipse typischen Farbe Indigo benannt. Die Anfangsbuchstaben der Projektnamen werden ab Version 3.5 in alphabetischer Reihenfolge vergeben. Die Version 3.8 erschien gleichzeitig mit der Version 4.2. Um mit dem schnelleren Release-Zyklus von Java mitzuhalten, hat man 2018 von einem jährlichen Release auf vier Releases pro Jahr umgestellt. Damit hat man auch das Namensschema der Release-Versionen auf „{Jahreszahl}-{Monat}“ vereinfacht, also beispielsweise „2018-09“. Die einzelnen Versionen werden jeweils als Grundversion oder als Zusammenstellung aus verschiedenen Programmpaketen veröffentlicht. Einzelne Programmpakete kann man jedoch auch später noch nachinstallieren. Die Benutzeroberfläche von Eclipse ist standardmäßig englischsprachig. Es gibt jedoch zu jeder Version Babel-Language-Packs, die man sich in den entsprechenden Sprachen als Plugin installieren kann.

Darauf gehe ich so explizit ein, da ich mich in den letzten Tagen mit Kollegen über Eclipse ausgetauscht und in einem Quellcode verweise auf „Jupiter“ entdeckt habe. In der jüngsten Vergangenheit habe ich mich mit Jupyter beschäftigt. Daher auch hier ein Verweis auf den Beitrag damit es zu keiner Verwechslung der Themen kommt. Beides von Grund auf verschiedene Themen bzw. Dinge 😉

Architektur

Bis einschließlich zur Version 2.1 ist Eclipse als erweiterbare IDE konzipiert gewesen. Ab Version 3.0 ist es selbst nur der Kern, der die einzelnen Plug-ins lädt, die dann die eigentliche Funktionalität zur Verfügung stellt. Diese Funktionalität basiert, wie bereits erwähnt, auf Equinox. Sowohl Eclipse als auch die Plugins sind vollständig in Java implementiert. Zur Erstellung der GUI (grafischen Benutzeroberfläche) wurde SWT verwendet. Zur Darstellung der GUI-Komponenten basiert SWT ähnlich wie AWT auf den nativen GUI-Komponenten des jeweiligen Betriebssystems. Eclipse steht für 14 verschiedene Systeme und Architekturen zur Verfügung und gilt somit als plattformunabhängig. Die Plugins lassen sich direkt von einem Update-Server, über den „Market Place“, oder durch Entpacken einer Installationsdatei installieren.

Das frei verfügbare Eclipse SDK umfasst die Eclipse-Plattform, Werkzeuge zur Java-Entwicklung (Java Development Tools, JDT) und die Umgebung zur Entwicklung von Eclipse-Plugins (Plugin Development Environment, PDE).

Rich Client Platform

Eclipse bietet eine Rich Client Platform, welche es Anwendungsentwicklern ermöglicht, basierend auf dem Eclipse-Framework, von der Eclipse-IDE unabhängige Anwendungen zu schreiben. Die folgenden Komponenten (Plugins) werden typischerweise mindestens für eine Eclipse-Rich-Client-Platform-Anwendung verwendet:

• Eclipse Core Platform – steuert den Lebenszyklus einer Eclipse-Anwendung
• Eclipse Platform UI – stellt die Workbench mit den Konzepten Sichten, Editoren, Perspektiven, Menüs und Toolbars zur Verfügung
• Standard Widget Toolkit (SWT)
• JFace

Weitere Eclipse-Komponenten, wie das Hilfesystem oder das automatische Aktualisierungssystem, kann man ebenfalls einsetzen. In der Regel nutzt man das Eclipse-OSGi-Framework Equinox zum Kombinieren (bundling) der Komponenten.

Das UI (User Interface)

Eclipse ist in Komponenten (parts) gegliedert, die in Sichten (views) und Editoren (editors) gegliedert sind. Wobei die Unterscheidung in view und editor sich an der Nutzung orientiert und nicht technischer Natur ist. Diese Fenster kann man durch Drag and Drop beliebig anordnen oder minimieren.

Sichten

Mit Hilfe der views kann man Daten direkt bearbeitet und darunterliegende Datenstrukturen verändern.

Beispiele für views sind die auch aus den meisten anderen Editoren bekannte Navigator-View, die im Projektverzeichnis enthaltene Dokumente anzeigt, der Klassenexplorer, der baumartig strukturiert Symbole für die Klassen, Funktionen, Variablen und Importe eines geöffneten Quelltextes anzeigt oder das Suchfenster, dass die Ergebnisse einer Suche auflisten kann.

Editoren

Editoren sind Komponenten, die nur das jeweils geöffnete Datenelement bearbeiten und in denen der Nutzer explizit speichern muss, um Daten zu verändern. Beispiele sind Fenster, die meist den Quelltext mit Syntaxhervorhebung anzeigen, wobei es für viele Programmiersprachen einen eigenen Editor gibt. Beispielsweise für Java, C, PHP, Python, HTML, aber auch einen einfachen Texteditor. Genauso gibt es auch visuelle Editoren (beispielsweise UML-Editoren, GUI-Builder) oder solche, die Baumstrukturen anzeigen (etwa der XML-Editor). Editoren nehmen normalerweise den meisten Raum des Programmfensters in Anspruch. Mehrere geöffnete Quelltexte kann man als Reiter öffnen, die man dann über Tabs am oberen Rand in den Vordergrund bringen kann. Außerdem kann man Tabs fixieren, damit man beispielsweise den zugehörigen Quelltext nicht versehentlich schließt. Auch kann man die Editoren weitestgehend frei per Drag and Drop anordnen. Davon abgesehen ist es möglich, eine Datei in mehreren Editoren gleichzeitig zu öffnen.

Perspektiven

Perspektiven sind vollständige Anordnungen von parts. Ein editor bleibt beim Perspektivwechsel erhalten. Perspektiven sind weitestgehend frei konfigurierbar und man kann benutzerdefinierte Konstellationen speichern sowie laden. Meistens stellen Plugins, die man nachinstalliert, vorkonfigurierte Perspektiven zur Verfügung, diese passt man dann meisten den eigenen Wünschen und Vorlieben an.

Plugins und Erweiterungen

Es gibt zahlreiche Erweiterungen für Eclipse. Teils proprietär, teils frei verwendbar bzw. Open Source. Primär verwendet man es als Java IDE. Dabei kommen vor allem die in den Java Development Tools zusammengefassten Plugins zum Einsatz. Es existieren aber etliche Plugins für andere Sprachen, die ich bereits unter Editoren erwähnt habe. Hinzu kommt noch die Entwicklung von OSGi-Bundles. Dazu zählt vor allem das CDT-Projekt, welches C und C++ unterstützt und unter Anderem die GNU Compiler Collection sowie die LLVM (-Clang und -GCC) abdeckt. Darüber hinaus gibt es auch Plugins für Perl, PHP, ColdFusion, Ruby, Python, C#, Fortran, Ada2005, Scala usw. Diese kann man über ein Menü in Eclipse einbinden. Neben Plugins für konkrete Programmiersprachen gibt es auch solche, die allgemeine Entwicklungsprozesse unterstützen, wie beispielsweise Mylyn für „aufgabenorientierte Entwicklung“ oder Saros für Verteilte Paarprogrammierung auch Distributed Pair Programming, DPP oder Pair Programming, PP genannt. Oft sind diese Ergänzungen – anders als das Kernprogramm – ausschließlich in der englischen Sprache erhältlich.

Neben den Java Development Tools gibt es viele weitere Projekte, die man ebenfalls auf der Eclipse-Website koordiniert. Ein solches Projekt ist das Eclipse Tools Project, dass verschiedene Hilfsmittel entwickelt, die Entwickler erweitern können. Weitere Projekte sind das Eclipse Modeling Framework (EMF), das Graphical Editing Framework (GEF) und die eingestellte Eclipse Riena Platform (Riena). Mit EMF lässt sich ein Datenmodell erstellen, das zum Beispiel auf UML basieren kann. GEF ist ein Projekt, dass es Entwicklern erlaubt, mit Hilfe eines existierenden Datenmodells schnell einen grafischen Editor zu erstellen. Riena unterstützt Entwickler bei der Ausstattung einer Anwendung mit einem benutzerfreundlichen Interaktionskonzept und ansprechenden Oberflächenelementen.

Basierend auf diesen Erweiterungen und dem modularen Aufbau von Eclipse selbst, lassen sich für Projekte spezifische Eclipse-Bundles erstellen. Diese enthalten alle für ein bestimmtes Projekt notwendigen Teile und Erweiterungen von Eclipse, ohne mit unnötigen Teilen Hauptspeicher und Rechenleistung zu verbrauchen.

Inzwischen gibt es auch Open Source-Erweiterungen, die eine automatisierte Bereitstellung und Konfiguration erheblich erleichtern. Dazu zählen oasp4j-ide, Oomph und Yatta Profiles, von denen ich einige in zukünftigen Beiträgen thematisiere.

Fazit

Durch den quelloffenen Ansatz und der kostenfreien Nutzungsmöglichkeit ist Eclipse neben IntelliJ eines der beliebteren IDEs. Man kann durch Plugins und Erweiterungen viele Programmiersprachen bedienen. Der Programmkern von Eclipse stellt in dem Zusammenhang die einzige versionsübergreifende Konstante dar. Jede Aktualisierung führt Neuerungen in den Kern ein und die integrierten Plugins bzw. Erweiterungen erfordern dadurch meist eine Anpassung an die neue Version.

Die grafische Oberfläche von Eclipse ist auf eine effiziente Arbeitsweise ausgerichtet. Der konzeptionelle Aufbau durch Views, Editoren und Perspektiven sorgt für eine anpassbare Optik und eine bequeme Arbeitsweise mit und in der IDE. Man kann sowohl die Funktionalitäten als auch die GUI von Eclipse durch die manuelle oder automatische Installation von Plugins bzw. Erweiterungen anpassen. Entsprechende Möglichkeiten finden sich in dem standardmäßig integrierten Market Place von Eclipse.

Der Beitrag Eclipse – Die flexible Entwicklungsumgebung erschien zuerst auf CEOsBay.