Hier ist eine ziemlich theoretische und abstrakte Frage: Wie unterscheidet sich die serviceorientierte Architektur (SOA) vom komponentenbasierten Ansatz? Ist das Konzept der SOA eine Erweiterung des komponentenbasierten Ansatzes?Wie verhalten sich serviceorientierte Architektur und komponentenbasierte Entwicklung zueinander?
Was sind Ihre Gedanken? Vielleicht kennen Sie gute Artikel, die dieses Thema abdecken?
Die beiden Konzepte sind ziemlich orthogonal, weder komplementär noch widersprüchlich. Wenn Sie mir drohten, eine rostige Gabel in mein Auge zu stecken und mich zu verallgemeinern, würde ich sagen, dass die komponentenbasierte Entwicklung eine Technik zum Modellieren und Zusammenbauen einer bestimmten Software war, wobei SOA eine Technik zur Organisation separater Systeme ist sie können miteinander reden.
Wie ich schon sagte, eine krasse Verallgemeinerung, aber es ist alles, was ich werde euch geben, ohne eine spezifischere Frage :)
Man könnte sagen, dass SOA ist eine High-Level-Form von komponentenbasierte Entwicklung, wo Komponenten in wiederverwendbare Funktionsteile umgewandelt wurden, die als Dienste bezeichnet werden.
In this article die Autoren sehen komponentenbasierte Entwicklung als SOA unterstützt - am Ende Ihrer SOA benötigt Dienste umgesetzt werden und Sie Komponenten wie die zu erbringenden Leistungen entwickeln, die die Umsetzung. Ein Teil der Fähigkeit, die Granularität und Kohäsion der Komponenten richtig zu machen.
Ich glaube, dass diese Perspektive eine vernünftige Charakterisierung der SOA ist heute tatsächlich getan wird. Für mich ist der Schlüssel, dass Sie sich zuerst auf Dienstleistungen konzentrieren, was Sie im Geschäftssinn tun müssen, und dann später zu den Bauteilkonstruktionen kommen. [Hier ist ein article über die Identifizierung von Diensten. Disclaimer: Ich bin eine IBM Person, diese Artikel werden von Kollegen geschrieben.]
Allerdings, wenn Sie die Uhr zurück wickeln denke ich, dass Sie feststellen werden, dass Component-Based Development ein Ansatz war, der SOA vorausgeht, und hatte viele von die gleichen Ziele wie SOA. Ich halte die Meinung für übertrieben zynisch, dass SOA nur Marketing-Hype ist und neue Etiketten auf alten Konzepten klebt. Es gibt jedoch erhebliche Überschneidungen zwischen CBD und SOA. Ich betrachte SOA als die beste kollektive Weisheit, die wir bisher kennengelernt haben, wie Integration zu machen ist. Zweifellos lernen wir neue Techniken kennen, bis der gesamte Kitbag wieder einen neuen Namen verdient.
Meine persönliche Meinung ist, dass SOA in Schwung gekommen ist, weil eine Reihe von Technologien entstanden ist, die unterschiedliche technische Teams innerhalb einer Organisation (z. B. eine IBM-Basis und Microsoft-Basis) ermöglichten, Komponenten zu bauen, die die jeweils anderen Dienste nutzen konnten. Mit anderen Worten, es zeigte sich ein Reifegrad bei der Durchführung von Komponenten, so dass ein neues Label (SOA) attraktiv war.
Die komponentenbasierte Entwicklung erforderte ein Repository von Codefragmenten (manchmal vollständige Objektstapel) im Allgemeinen in einer Codesyntax. Um für irgendetwas anderes nützlich zu sein, müßten diese Fragmente über eine gemeinsame Schnittstelle (z. B. Windows API oder COM, COM + ua) zwischen VC++ beispielsweise portiert oder aufgerufen werden. Somit können VC++ - Funktionen von VB6 verwendet und aufgerufen werden. Daher erforderte die Wiederverwendung von Komponenten manchmal eine große Menge an Refactoring, die wiederverwendet werden konnte, was nicht intuitiv war. Es gab auch das Problem der frühen und späten Bindung. Die Repository-Komponenten müssen noch als funktionierender Teil der Codebasis erstellt und bereitgestellt werden, damit sie verwendet werden können. Der Code sollte vor dem Hinzufügen zum Repository in der Einheit getestet worden sein, erforderte jedoch noch Integrationstests, um die Funktionalität zu bestätigen. Sie müssten auch die richtigen Parameter konstruieren, um "die Objektschnittstelle zu kreuzen". Dies erforderte wiederum einen Wrapper-Code.
Diese Code-Repositorys enthalten möglicherweise nicht alles, um wirklich plattformübergreifend zu sein. Eine Plattformunabhängigkeit ist normalerweise erforderlich, wenn Probleme über Domains hinweg segmentiert werden, insbesondere in integrierten Systemen. Die Schnittstelle ist in der eingebauten und implementierten Software enthalten, nicht der eigentliche funktionierende Code.
Was Sie zwischen den beiden fehlt, ist ein Framework. SOA ist weder CBDv2 noch eine Erweiterung dazu, Sie müssen den Rahmen der Service-Implementierung durchlaufen. Frameworks sind auch kein neues Konzept.
Sowohl CBD & SOA letztlich die Wiederverwendung von Code fördern. CBD ist im Allgemeinen enger als SOA! SOA braucht einen Rahmen, um effektiv zu sein, CBD nicht. CBD ist an seine Entwicklungssprache und Zielplattform gekoppelt.