Lobster Loading
Lobster Loading

SOA

SOA (Service Oriented Architecture)

SOA meint eine Architektur von Software-productsn bzw. IT-Systemen, die darauf ausgerichtet ist, Dienstleistungen zu erbringen.

Welche Dienste das sein können, ist vielfältig. Wichtig ist, dass jedes beteiligte System, ob im Intra- oder Internet, eine Schnittstelle bereitstellt, über die man seine Dienste in Anspruch nehmen kann. Wie genau dieser angesprochen wird, ist nicht allgemein festgelegt – für jedes einzelne System muss nur klar definiert sein, wie es kommuniziert.

Und natürlich kann – das ist das Gute an SOA – ein Dienst existieren, der selbst mehrere andere Dienste aufruft. Ganz egal, ob diese vom selben System bereitgestellt werden oder irgendwo am anderen Ende der Welt von einem vollkommen anderen Unternehmen.

An sich kann ein Dienst eine bestimmte Berechnung ausführen, im einfachsten Falle a+b rechnen. Man füttert ihn mit den beiden Werten und er liefert die Summe zurück.
Ein sinnvollerer Einsatz könnte sein, zu zwei Postleitzahlen die Entfernung und übliche Fahrzeit zu ermitteln.
Ein weiterer Dienst kann z.B. zu einer Adresse die passenden Geokoordinaten liefern.
Wieder ein anderer nimmt ebenfalls eine Adresse entgegen und macht eine Bonitätsprüfung aufgrund der Wohnlage.

Alles eher Beispiele für öffentliche Dienste, aber natürlich kann so ein Dienst auch innerhalb eines Unternehmens eingesetzt werden, um z.B. den Lagerbestand zu einem bestimmten Artikel auszugeben. Dann muss man nicht mehr wissen, welche Datenbank man wie abzufragen hat, sondern ruft einfach den passenden Dienst auf und bekommt den Bestand zurück.

Hat man nun mehrere solcher Dienste, kann man sie mit einem neuen, komplexeren Dienst „überdachen“, der eine ganze Folge von Einzeldiensten aufruft und am Ende ein Gesamtresultat liefert. Es entsteht ein ganzes Geflecht von Diensten – komplexen, die einfachere aufrufen und selbst von noch komplexeren genutzt werden. Und dieses Netz kann sich über die ganze Welt erstrecken, ohne, dass derjenige, der am Ende irgendwo eine Abfrage am Bildschirm eingibt, überhaupt etwas davon merkt.

Es gibt gewisse Anforderungen an einen Dienst, der Teil einer SOA ist. Er muss:

  • eine bestimmte Funktionalität zur Verfügung stellen
  • von außen (also über ein Netz) erreichbar sein
  • als eine Einheit nutzbar sein, also auch zustandslos
  • über eine klar definierte, vollkommen von der Art des Nutzers unabhängige Schnittstelle ansprechbar sein
  • seine eigene Implementierung nach außen hin kapseln, sie darf bei der Benutzung keine Rolle spielen
  • und zumindest in der Theorie noch ein paar andere Punkte erfüllen, die in der Praxis nicht unbedingt von Bedeutung sind (siehe auch Wikipedia).

Diese Anforderungen, ganz besonders die Kapselung und die klar definierte Schnittstelle, bringen einige Vorteile mit sich:
Nehmen wir an, es existiert im Unternehmen ein Dienst, der z.B. über eine WebService-Schnittstelle (eine der vielen Möglichkeiten, SOA-Dienste anzusprechen) den Lagerbestand zu einer Artikelnummer ermittelt. Momentan ist er einfach eine kleine Hülle um eine Datenbank-Abfrage. Er nimmt die Artikelnummer entgegen, führt ein Select-Statement auf eine bestimmte Datenbank aus und liefert den Bestand zurück. Nun ändert sich die Lagerverwaltung, SAP wird eingeführt, und wir können nicht mehr einfach so in die Tabellen schauen. Stattdessen können wir nun aber über die RFC-Schnittstelle von SAP gehen und uns dort den Lagerbestand zur Artikelnummer holen.

Hätten wir überall, wo wir eine solche Abfrage durchführen müssen, direkt die Datenbank angebunden und ein Statement abgesetzt, würde es viel Arbeit bedeuten, alles auf SAP/RFC umzustellen. So dagegen müssen wir nur den Dienst neu implementieren. Der Code wird komplett ausgetauscht, doch die Schnittstelle nach außen bleibt, wie sie ist. Und siehe da, durch eine einzige Änderung an zentraler Stelle, von der sonst nicht einmal jemand etwas merkt, haben wir alle Abfragen sauber vom alten LVS auf das neue SAP umgestellt.

Auf Seiten des Dienste-Nutzers sieht es genau so aus. Hat er bisher noch mit alten, selbstprogrammierten C++-Programmen den Service abgefragt und steigt nun auf eine moderne Standardsoftware um, muss diese lediglich in der Lage sein, WebServices abzufragen, und schon kann er die alte Schnittstelle wie gewohnt weiternutzen. Da Dienste in einer SOA normalerweise Standard-Protokolle wie z.B. SOAP verwenden, sind sie mit einer breiten Palette von Software-productsn ansprech- und nutzbar.

Die EDI-Software Lobster_data erlaubt die Verarbeitung aller gängigen Datenformate wie EDIFACT, XML, ANSI X.12, SAP IDoc, CSV, FixRecord, VDA, binäres Excel, BMECat etc. Eine Übersicht und Erklärung der Datenformate finden Sie hier.

Über 4.000 Vorlagen für Schnittstellen zu ERP-Systemen sowie alle wichtigen Industriestandards (EDIFACT, SAP IDoc, VDA, Fortras, ANSI X.12, etc.) sind kostenfrei in Lobster_data enthalten.

Als EDI-Software unterstützt Lobster_data alle gängigen Protokolle zum elektronischen Datenaustausch. Darunter FTP(S), OFTP, OFTP2, SMTP, HTTP(S), SMS, SAP-ALE, IBM-Data-Queue, Datenbanken, AS2, X.400, WebDAV, SCP, SSH sowie WebServices. Eine Übersicht und Erklärung der Datenkommunikationswege, Datenquellen und Datensenken finden Sie hier.

Über 4.000 Vorlagen für Schnittstellen zu ERP-Systemen sowie alle wichtigen Industriestandards (EDIFACT, SAP IDoc, VDA, Fortras, ANSI X.12, etc.) sind kostenfrei in Lobster_data enthalten.

Fazit:

Da Dienste in einer SOA normalerweise Standard-Protokolle wie z.B. SOAP verwenden, sind sie mit einer breiten Palette von Software-productsn ansprech- und nutzbar. Das bietet zum Beispiel den Vorteil, bei Software-Umstellungen nicht alles umstellen zu müssen. Stattdessen muss lediglich der Dienst neu implementiert werden. Der Code wird komplett ausgetauscht, doch die Schnittstelle nach außen bleibt, wie sie ist. Durch eine einzige Änderung an zentraler Stelle, werden alle Abfragen sauber vom alten auf das neue System umgestellt.

 

Informieren Sie sich auch über Lobster_data – die Datenmangement-Software für effizientes EDI und EAI – oder lassen Sie sich telefonisch beraten unter +49.8157.590 99-0.

We use cookies to ensure that we provide you with the best possible service on our homepage. If you continue to use the site, we will assume that you agree. Detailed information about the use of cookies on our website and how to contradict is found under the section “data protection”. More information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close