Service-Orientierung vs. Objekt-Orientierung - können sie nebeneinander existieren?

Question

Es gibt ein großes Interesse an Service-orientierte Architektur (SOA) in meinem Unternehmen vor kurzem. Immer wenn ich versuche, mir vorzustellen, wie wir sie nutzen könnten, stoße ich auf eine mentale Blockade. Grob gesagt:

• Die Objektorientierung besagt: "Daten und Methoden, die Daten manipulieren (Geschäftsprozesse), zusammenhalten";

• Die Serviceorientierung besagt: "Behalte den Geschäftsprozess im Dienst und leite Daten an ihn weiter".

Frühere Versuche, eine SOA zu entwickeln, endeten mit der Umwandlung von objektorientiertem Code in Datenstrukturen und separaten Prozeduren (Diensten), die diese manipulieren, was ein Rückschritt zu sein scheint.

Meine Frage ist: Welche Muster, Architekturen, Strategien usw. ermöglichen das Zusammenspiel von SOA und OO?

---

Editar: Die Antworten "OO für Interna, SOA für Systemgrenzen" sind großartig und nützlich, aber das ist nicht ganz das, worauf ich hinauswollte.

Angenommen, Sie haben eine Account Objekt, das einen Geschäftsvorgang namens Merge das es mit einem anderen Konto kombiniert. Ein typischer OO-Ansatz würde wie folgt aussehen:

Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);

mainAccount.mergeWith(lesserAccount);

mainAccount.save();
lesserAccount.delete();

Das SOA-Äquivalent, das ich gesehen habe, sieht hingegen so aus:

Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);

accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service

Im OO-Fall sind die Geschäftslogik (und das Bewusstsein für Entitäten dank eines ActiveRecord-Musters) in die Account Klasse. Im Fall der SOA wird die Account Objekt ist eigentlich nur eine Struktur, da alle Geschäftsregeln im Dienst verankert sind.

Kann ich reichhaltige, funktionale Klassen und wiederverwendbare Dienste gleichzeitig haben?

Answer 1

Meiner Meinung nach kann SOA auf einer Makroebene nützlich sein, aber jeder Dienst wird wahrscheinlich immer noch groß genug sein, um mehrere interne Komponenten zu benötigen. Die internen Komponenten können von einer OO-Architektur profitieren.

Die SOA-API sollte sorgfältiger definiert werden als die internen APIs, da es sich um eine externe API handelt. Die auf dieser Ebene übergebenen Datentypen sollten so einfach wie möglich sein und keine interne Logik enthalten. Wenn es eine Logik gibt, die zum Datentyp gehört (z. B. Validierung), sollte es vorzugsweise einen Dienst geben, der für die Ausführung der Logik auf dem Datentyp zuständig ist.

Answer 2

SOA ist eine gute Architektur für die Kommunikation zwischen Systemen oder Anwendungen.

Jede Anwendung definiert eine "Dienst"-Schnittstelle, die aus den zu bearbeitenden Anfragen und den erwarteten Antworten besteht.

Die wichtigsten Punkte hierbei sind gut definierte Dienste mit einer gut definierten Schnittstelle. Wie Ihre Dienste tatsächlich implementiert werden, ist im Hinblick auf SOA irrelevant.

Es steht Ihnen also frei, Ihre Dienste mit den neuesten und besten OO-Techniken zu implementieren, oder mit jeder anderen Methode, die Ihnen zusagt. (Ich habe extreme Fälle gesehen, in denen der "Dienst" von Menschen implementiert wurde, die Daten auf einem Bildschirm eingegeben haben - und trotzdem war alles eine SOA wie aus dem Lehrbuch).

Answer 3

Meiner Meinung nach ist SOA nur für externe Schnittstellen sinnvoll (im Allgemeinen für Personen außerhalb Ihres Unternehmens), und selbst dann nur in Fällen, in denen die Leistung keine Rolle spielt und Sie keine geordnete Zustellung von Nachrichten benötigen.

Angesichts dessen denke ich, dass sie nebeneinander bestehen können. Lassen Sie Ihre Anwendungen nach der OO-Philosophie arbeiten und kommunizieren, und nur wenn externe Schnittstellen (zu Dritten) benötigt werden, stellen Sie diese über SOA zur Verfügung (dies ist nicht unbedingt erforderlich, aber eine Möglichkeit).

Ich habe wirklich das Gefühl, dass SOA überstrapaziert wird, oder dass zumindest Architekturen mit SOA zu oft vorgeschlagen werden. Ich kenne eigentlich keine großen Systeme, die SOA intern nutzen, und ich bezweifle, dass sie das könnten. Es scheint eher eine Sache zu sein, die man nur für Mashups oder einfache Wettervorhersagen verwendet und nicht, um ernsthafte Systeme darauf aufzubauen.

Answer 4

Ich glaube, dass dies ein Missverständnis der Objektorientierung ist. Selbst in Java sind die Methoden im Allgemeinen nicht Teil der Objekte sondern von ihren Klasse (und selbst diese "Zugehörigkeit" ist für die Objektorientierung nicht notwendig, aber das ist ein anderes Thema). Eine Klasse ist nur eine Beschreibung eines Typs, sie ist also wirklich ein Teil des Programms, nicht der Daten.

SOA und OO widersprechen sich nicht. Ein Dienst kann Daten entgegennehmen, sie intern in Objekten organisieren, sie bearbeiten und sie schließlich in einem beliebigen Format zurückgeben.

Answer 5

Ich habe James Gosling sagen hören, dass man SOA in COBOL implementieren kann.

Wenn Sie Alan Kays eigene Beschreibung der Ursprünge von OOP lesen, dann beschreibt er einen Haufen kleiner Computer, die zusammenarbeiten, um etwas Nützliches zu tun.

Beachten Sie diese Beschreibung:

Ihr X sollte sich aus Ys zusammensetzen. Jedes Y sollte für ein einzelnes Konzept verantwortlich sein und vollständig durch seine Schnittstelle beschrieben werden können. Ein Y kann ein anderes Y auffordern, etwas zu tun, und zwar durch den Austausch von Nachrichten (über die von ihnen festgelegten Schnittstellen).

In einigen Fällen kann ein X durch ein Z implementiert werden, das es entsprechend seiner Schnittstelle verwaltet. Kein X darf direkt auf die Z eines anderen X zugreifen.

Ich denke, dass die folgenden Ersetzungen möglich sind:

Term      Programing       Architecture
----    ---------------    ------------
  X         Program           System
  Y         Objects          Services
  Z      Data structure      Database
----    ---------------    ------------
result        OOP              SOA

Wenn Sie in erster Linie an Kapselung, Information Hiding, lose Kopplung und Blackbox-Schnittstellen denken, gibt es eine Menge Ähnlichkeiten. Wenn man sich in Polymorphismus, Vererbung usw. verzettelt, denkt man IMHO eher an Programmierung/Implementierung als an Architektur.