OOP vs SOA @CODEKICKER

OOP vs SOA

Da das Thema bei einer anderen Frage aufkam:
Mit welchem "Design Pattern" programmiert ihr eure Anwendungen und welche Programmiersprache/Framework verwendet ihr dafür.
Welche Vor- und Nachteile hat für euch objektorientierten Programmierung (OOP) und eine serviceorientierte Architektur (SOA)?

Edit:
Der Frage ein "versus" mitzugeben war vielleicht etwas zu provokativ.
Aber gerade in Bezug auf "stateless" Programmierung widerspricht sich meiner Meinung nach OOP mit dem serviceorientierten Gedanken. OOP bedeutet doch in der Regel, dass das Objekt z.B. eine "Save"- oder "Insert"-Methode erhält. Oft habe ich den Spruch gehört: "Das Objekt verwaltet sich selbst.". Verbunden damit ist auch ein Status, ob das Objekt gelöscht, eingefügt oder geändert werden soll.
Das OOP-Modell besitzt damit z.B. die Methode Product.Insert().
Der serviceorientierte Ansatz würde folgendermaßen aussehen: ProductService.Insert(Product)
Dabei kann es sich bei ProductService um einen "Service" des Dataaccesslayers, Businesslayers oder um einen WebService handeln.
Der entscheidende Unterschied ist, dass bei SOA ein Objekt zu einem Entity verkümmert, das weder weiß, wie es gespeichert wird noch in welchem Status es sich befindet.

Hier noch die Seite, die ich bereits bei der anderen Frage verlinkt habe: Service-Orientation vs. Object-Orientation: Understanding the Impedance Mismatch

19.12.2011

Jürgen Luhr

6,9k ● 1 ● 8

Editiert 19.12.2011

Jürgen Luhr

6,9k ● 1 ● 8

1		Vll als Ergänzung weil mich das Thema auch interessiert: Ich frage mich ab wann SOA wirklich sinnvoll ist. Sprich: Brauch ich wirklich ein Datenbank Service und ein Email Service wenn ich eine Anwendung schreiben will die aus Datenbank Inhalten E-mails generiert. Sprich: Lohnt es sich für die kleine Anwendung oder aber erst ab größe N? – Nicolai Schönberg 19.12.2011
		@Nicolai: Guter Hinweis für eine Diskussion. – Jürgen Luhr 19.12.2011
		Und mir ist noch was eingefallen: Ein Service läuft autark. Das bedeutet er arbeitet für sich selbst - Und wenn er grade viel zu tun hat muss man halt ein wenig warten bis man eine Antwort bekommt. Wie sind eure Erfahrungen in diesem Punkt? – Nicolai Schönberg 19.12.2011
		@Nicolai: magst Du das nicht lieber als eigene Frage stellen? Sonst wird es hier vielleicht zu unübersichtlich. – Matthias Hlawatsch 19.12.2011
		@Matthias Ja ok habe ich gemacht – Nicolai Schönberg 19.12.2011
		@Jürgen: "bei der anderen Frage" - welche meinst Du? – Matthias Hlawatsch 19.12.2011
		@Matthias: http://codekicker.de/fragen/PHP-OOP-OOP-Frage#a23376 – Jürgen Luhr 19.12.2011

2 Antworten

Hallo Jürgen,

mich irritiert ehrlich gesagt die Fragestellung, und insbesondere das "vs".

Mal stark vereinfacht und verkürzt meine Sicht der Dinge:

OOP ist ein Thema für den Programmierer. Der wesentliche Anwendungsbereich ist die konkrete Implementierung einzelner Komponenten bzw. Anwendungen. Und da Du danach gefragt hast: am liebsten nutze ich .NET mit C#, komme aber bei Bedarf auch mit Java zurecht. Vorteile: mal etwas sarkastisch und Churchill variierend ausgedrückt ist OOP die ungeeignetste Methode, Dave Parnas' "teile und herrsche" umzusetzen, mit Ausnahme aller anderen, die schon ausprobiert wurden. Nachteile: es richtig gut und konsequent zu machen, ist verdammt schwer.

SOA ist ein Thema für den Architekten, und zwar vom Schwerpunkt her ein fachliches im Sinne von: wie verteile ich die Gesamtfunktionalität unter Berücksichtigung der Geschäftsprozesse und der Unternehmensorganisation auf einzelne Dienste? Hier steht also eindeutig nicht die einzelne Komponente oder Anwendung im Blickpunkt, sondern eine Vielzahl davon - im realen Leben gerne auch mit unterschiedlichen Verantwortlichkeiten, Release-Zyklen usw. Jeder einzelne Dienst kann dabei mit OOP implementiert werden oder auch anders. Vorteile: richtig verstanden lenkt es den Blick auf die fachlichen und organisatorischen Aufgabenstellungen, die das Unterstützen von Geschäftsprozessen durch mehrere Anwendungen mit sich bringt, und liefert eine Anleitung, damit umzugehen. Nachteile: wird gern falsch verstanden als "wir nutzen Web-Services".

Zum Schluss noch zwei Links: Ich finde den Wikipedia-Artikel zu SOA recht gut gelungen, und ich kann ein Buch einiger Ex-Kollegen empfehlen, in dem SOA mMn sehr kompetent und auf Praxis-Erfahrung gegründet behandelt wird.

19.12.2011

Matthias Hlawatsch

8,4k ● 2 ● 8

		Meiner Meinung nach kann man OOP und SOA nicht so einfach in die Themenbereiche Programmierer und Architekt trennen. Ich habe meine Frage dazu erweitert. – Jürgen Luhr 19.12.2011
1		Ich finde, Du verwechselst SOA und SOP. http://en.wikipedia.org/wiki/Service-oriented_programming – Matthias Hlawatsch 19.12.2011
		Also ich bin übriegens dafür das sich dotnetpro mal ein mehrseitigen Artikel schreiben lässt. SOA, SOP, verteilte Anwendung, Wann, Wieso und überhaupt. Wäre Golo nicht ein Kandidat? Oder du Matthias – Nicolai Schönberg 19.12.2011
1		Zugegeben, ich werfe beides in einen Topf, da sich bei mir aus SOA SOP ergibt. Von daher ist die Frage schlecht gestellt. Schade. Ändern kann ich die Frage nicht mehr, da die bisherigen Antworten nicht mehr dazu passen würde. Das nächste Mal denke ich länger über die exakte Fragestellung nach. – Jürgen Luhr 19.12.2011
		@Jürgen: Ich fände es schön, wenn "das nächste Mal" bald wäre. Schließlich spricht nichts dagegen, die Frage neu formuliert nochmal zu stellen. Danke, dass Du darauf verzichtest, diese Frage hier umzuformulieren! – Matthias Hlawatsch 19.12.2011
		@Nicolai: Danke für die Blumen :-) Ich denke ja seit längerem darüber nach, mich zur Blogger-Herde hinzuzugesellen. Vielleicht wird das ja mein erster Post. Reine Architekturthemen ohne .NET-Bezug sind in der dotnetpro ja eher selten. – Matthias Hlawatsch 19.12.2011
		@Matthias Ja das Stimmt - Aber ich meine mich zu erinnern das du sogar am liebsten C# Code schreibst? :) Aber ein eigener Blog evt. mit Verlinkung auf Codekicker ist auch schick! – Nicolai Schönberg 19.12.2011

                    Da so mancher Kunden gerne Schlagwortorientiert handelt, musste (mittlerweile darf) ich mich mit SOA rumschlagen ;)

Ich find die Frage etwas verwirrend. OOP und SOA schließen sich keineswegs aus. Die einzelnen Dienste sind ja "nur" klassische Programmteile (ob Batch-Datei oder komplexes Programm in mehreren Schichten ist egal. Wobei man zwecks Wiederverwendbarkeit eher zu "kleinen" Services für die große Orchestration tendieren sollte (was aber vor allem bei fremden Modulen nicht immer geht)).

Hauptproblem ist dabei (IMO) die Orchestrierung der einzelnen Services. Hierfür gibt es keine (mir bekannte) zufriedenstellende Lösung. Lässt sich zwar alles schön zusammenstellen, aber das ist nicht unbedingt schnell und bei komplexeren Orchestrations auch nicht gerade übersichtlich..

BizTalk-Server und WCF sind recht komplex (für den Kunden. Der will aber, weil man alles ja so schön designen kann). Nach der Orchestrierung steht meist noch die Anbindung an den ESB an - spätestens dann wird es verworren.

Die Wartezeiten eines Dienstes sind durch dessen Aufgabe definiert - das wird auch in anderen Umgebungen nicht schneller. Nur die Nachrichtenübermittlung kann (muss nicht) asynchron verlaufen (z.B. über ESB).

19.12.2011