SOA und Objektorientierung

[Patrick89]

Hallo,
Ich beschäftige mich momentan innerhalb eines Praktikums das erste Mal mit SOA und habe nun auch schon einiges dazu gelesen. Was ich mich aber frage:
Ist das Ziel von SOA nicht grob vergleichbar mit Objektorientierter Architektur in Java?

Beispielsweise sollte es bei der Java Programmierung doch auch das Ziel sein, wiederverwendbare Klassen zu schreiben, die lose gekoppelt über Interfaces miteinander kommunizieren.
Ist es bei SOA Anwendungen nicht ähnlich? Sicher wird hier über den ESB kommuniziert wird und ein Service Repository verwaltet die einzelnen Services, aber Ähnlichkeiten zwischen beiden existieren doch oder?

Immer wenn ich SOA Artikel lese, schwiert mir dieser Vergleich im Kopf rum - von daher wollte ich mal nachfragen ob ich den Grundgedanken irgendwie missverstehe.

 

[Marco13]

Ganz subjektiv sehe ich das auch so. Hatte da mal einen sehr schönen Artikel in der Informatik Spektrum gelesen, und mich am Ende gefragt, was daran denn neues ist: Die ganzen Anforderungen, die man auch an Klassen stellt (Korrektheit, Unabhängigkeit und Modularität, klare öffentliche Schnittstelle, und (im algebraischen Sinne) "Vollständigkeit und Abgeschlossenheit" etc...) werden dabei auf Softwaremodule übertragen.

Mit etwas "gutem Willen" könnte man sagen: "Jaaa, bei SAO kommt aber noch der Gedanke dazu, dass Services nachgeladen werden können (sie wie Klassen mit dem Classloader) und sie Sprachunabhängig sind (wie Klassen, die JNI verwenden) und außerdem und überhaupt...".

Mit etwas "bösem Willen" könnte man sagen, dass irgendwelche Fachjournalisten mal wieder was haben wollten, worüber sie schreiben können - und andere das ganze verkaufen. (Computer Zeitung 12.03.07: "Merkel forciert Serviceorientierung" :shock: na, dann muss SOA ja was tolles sein - DIE muss ja schließlich wissen, wovon sie redet ... :wink: ).

Aber wie gesagt: Alles subjektive, erste Eindrücke. In Wirklichkeit haben wir beide die tiefgreifende Bedeutung dieses revolutionär-neuen Konzepts nur noch nicht richtig verstanden... :wink:

 

[Gast]

Ich hätte auch mal eine Frage zu SOA.. und zwar etwas grundlegendes:

Woher weiß ein Service bei aktuellen SOA Implementationen, welcher aufzurufende Service der richtige ist?

Soweit ich verstanden habe, werden im Service Repository services verwaltet und katalogisiert, wie in einern Art gelbe Seiten System. Allerdings besteht die Beschreibung der Services mehr oder weniger nur aus der Methodensignatur.

Woher weiß ein Service dann konkret welchen anderen Service er aufrufen soll? Könnten in einem Repository katalog nicht Services mit identsichen Signaturen aber leicht unterschiedlicher Funktionalität liegen?

Ich weiß, dass an Semantik gearbeitet wird, um Services "intelligenter" auswählen zu lassen, aber das ist ja Zukunftsmusik. Wie wird das Problem aktuell gelöst?

 

[Niki]

Diese Frage wird immer wieder gestellt. Ich bin jedoch der Meinung dass Web-Services nicht einfach so angeboten werden. In der Praxis schaut es so aus, dass du bereits weißt dass du ein WebService für einen gewissen Anwendungsfall benötigst. Das heißt, es kommt eine konkrete Anforderung.
Genau das steht auch in einem Java-Artikel drin (hab ihn in pdf). Wenn du willst kann ich ihn dir schicken.

 

[Guest]

Es wäre sehr nett, wenn du mir den Artikel an olimario@wms24.com schicken könntest.
Also rufen Services andere Services momentan direkt auf und suchen sich nicht den passenden in einem Repository raus?

 

[lhein]

Am Beispiel ServiceMix ESB:

Alle Services sind registriert. Einen Service sprichst Du an, indem Du entweder einen Servicenamen oder ein zu implementierendes Interface angibst. Aus diesen Infos sucht der Bus dann einen in Frage kommenden Service raus und leitet deine Anfrage dorthin weiter. Es kann durchaus sein, dass kein oder mehrere Services in Frage kommen. Im "kein" Fall würde es zu einem Fehler kommen und wenn mehrere in Frage kommen, greifen verschiedene Policies, die nach einem bestimmten Prinzip auswählen...z.B. Random, RoundRobin oder FirstChoice

Hoffe das hilft ein wenig weiter.

lhein

 

[Guest]

Ich versuche gerade einen Verarbeitungsserver nach eigenem Verständins (ich denke eine Art
SOA :wink: ) zu entwickeln jedoch ohne hilfsmittel. Der Grund ist dass mich der Gedanke schon fasziniert. Eigenständige Services die eine eigene Aufgabe haben und nicht mit anderen Services kommunizieren.
Das ist meiner Meinung nach echte Modularität...

Mich für meinen Teil stört es immer wieder sehr dass ich manchmal nicht entscheiden kann welche
Klassen genau welche Zuständigkeiten haben...
(Soll meine Klasse "Auto" nun fahren können oder soll der "Motor" das Auto zum fahren bringen)

ich versuche immer reine Datenklassen
in Bean-Form zu schreiben und die Logik "Controllerklassen" zu überlassen. Aber selbst das stellt
mich nicht wirklich zufrieden weil es irgendwo doch wieder dem Sinn der OOP wiederspricht.

Drum finde ich die Idee dahinter gar nicht schlecht wobei Sie vermutlich keines des oben genannten
Probleme lösen wird sondern einfach nur eine Sichtweise eines größeren Rahmens ist. Nämlich
genau dem was OOP eigentlich von Grundauf können sollte aber praktisch so (im Detail) nicht möglich
ist.

Das ist meine Meinung

:wink:


Grüße Alex!

 

[lhein]

Wenn Du Deinen eigenen Mini-ESB, trotz vieler vorhandener ESB's, schreiben willst, dann schau Dir mal OSGi an. Damit kannst Du (zumindest auf einem Rechner) gut was anfangen.
Ich würde Dir jedoch eher empfehlen, Dir eine vorhandene ESB Software zu installieren und diese zu verwenden. So simpel ist das Thema dann nämlich doch nicht.

lhein