Ist der Begriff „Service Oriented Architecture“ zu einem bedeutungslosen Jargon geworden? [geschlossen]

Ich wurde heute gefragt, ob ich Erfahrung mit "Service Oriented Architecture" habe und obwohl ich glaube, dass ich dies tue. Das Konzept scheint mir so durcheinander, dass ich nicht mehr weiß, wie man diese Frage ehrlich beantworten kann.

Ich habe den Begriff gegoogelt, um eine präzise Definition des Konzepts und der Unterschiede zu anderen Architekturen zu erhalten. Nachdem ich eine Reihe von Artikeln darüber gelesen habe, scheint ich nur ein System mit mehreren Komponenten zu finden, die über eine Art Schnittstelle miteinander kommunizieren, wobei XML / SOAP vielleicht leicht bevorzugt wird.

Fast jede Anwendung könnte als SOA definiert werden, insbesondere eine Webanwendung. Ist dieser Begriff in die "Web 2.0" -Falle geraten und zu einem Begriff geworden, der bedeutet, was immer Sie wollen?

Bin ich hier weg von der Basis? Wenn ihr den Begriff hört, bedeutet das irgendetwas Spezielles für euch? Wenn ja, würde ich eine prägnante Definition lieben, die klar zeigt, was SOA ist und was NICHT SOA ist.

Ich glaube, die ursprüngliche Bedeutung von SOA basierte auf Diensten mit genau definierten Schnittstellen, die programmgesteuert genutzt werden können . Der Fokus lag eher auf Service-Schnittstellen als auf UI-Terminals, Kommunikationen oder Datenbanken. Der wichtigste Teil waren Dienste, die andere Dienste in Anspruch nehmen. Service A kann Service B anrufen, das Ergebnis abrufen und Service C oder D anrufen. Sie können eine Reihe spezialisierter Services einrichten und daraus eine Lösung erstellen, indem Sie diese so kombinieren, dass das Kundenproblem gelöst wird.

SOA wird häufig mit SaaS (Software as a Service) verwechselt. Hierbei handelt es sich um das Preismodell, bei dem der Benutzer für die Nutzung des von ihm abonnierten Service bezahlt, anstatt eine Lizenz für eine Kopie des Softwareprodukts zu erwerben. Um den dritten Absatz Ihrer Frage zu beantworten, handelt es sich bei einer Webanwendung wahrscheinlich nicht um SOA, sondern um SaaS.

Der Begriff hat definitiv einen Teil seiner Bedeutung verloren. In der Organisation, in der ich arbeite, wird der Begriff SOA häufig synonym mit SaaS verwendet. Er bezieht sich auf ein Team von IT-Experten ( Informationstechnologie im Gegensatz zur Softwareproduktentwicklung ), die Server und Router konfigurieren und Softwareprodukte für deren Ausführung installieren. Einige von ihnen tragen Titel wie "SOA Architect", aber keiner hat etwas mit dem Entwerfen, Implementieren oder Testen der Software zu tun.

Ich habe das gleiche getan, um SOA zu googeln, um zu sehen, was es wirklich ist, und ja, es wird ziemlich oft missbraucht. Wenn ich an SOA denke, denke ich an Folgendes:

1. Ein auffindbares kopfloses Programm ...
2. Das nutzt zustandslose Konnektivität (ala HTTP) ...
3. Kommunikation in plattformunabhängigen Formaten

SOA kann mit der Client-Server-Architektur (einer Stateful-Service-Architektur) und Bibliotheken verglichen werden, bei denen es sich um Module handelt, die über einen Linker mit Programmen verbunden sind.

Wenn die Leute darüber reden, nehme ich es normalerweise mit einem Körnchen Salz. Ich neige auch dazu, es einfach "Webdienste" zu nennen. Bei Webservices wird die Architektur impliziert.

Die strengen Definitionen von SOA gehen in vielen Fällen weit über die Kosten-Nutzen-Grenze hinaus.

Sofern Ihr Produkt nicht die Dienstleistung selbst ist, benötigen Sie häufig eine andere Sichtweise.

Eine USABLE-Definition von SOA bedeutet, dass Ihre Gesamtarchitektur servicefreundlich ist. Ein System, das vollständig aus atomaren Diensten aufgebaut ist, ist normalerweise nicht der richtige Plan, und einige Dienste werden funktional organisiert, während andere die alleinige Verantwortung tragen. Ich habe möglicherweise Blackboxes und Offline-Prozesse, aber wenn es eine erkennbare Sammlung von Diensten gibt, mit denen ich eine sinnvolle Menge an Arbeit erledigen kann, ist dies meine Mindestdefinition.

Abgesehen von der Debatte darüber, was es tatsächlich bedeutet, hat das Konzept (was auch immer es bedeutet) in vielen Kreisen gelitten, indem es auf Orte angewendet wurde, die einfach nicht passen.

Wenn ich zum Beispiel etwas baue, das als Black-Box-Prozess gedacht ist und sich durch Parallelität und nicht durch Segmentierung und Verteilung skalieren lässt, kann ich einen Dienst anbieten, mit dem ich mit der Black-Box sprechen kann Box.

Als strenge technische Definition war es immer undefiniert, aber die Idee ist nicht unbegründet, wo es passt.

Ich hatte das Pech, an einigen Unternehmenssystemen zu arbeiten, bei denen das Management über SOA verkauft wurde. Als Entwickler schaue ich mir die Systeme an und sehe eine Menge Software hinter einem Webservice, der Sachen macht. Es könnte in einer Vielzahl von Sprachen und Architekturen geschrieben worden sein, die für die Kunden, die die Dienste aufrufen, keine Rolle spielen oder relevant sind und deren Abkürzung "SOA" an keiner Stelle in ihrer Dokumentation steht.

Aber das Management will "SOA" !!! Sie haben also wirklich teure Server von einer bestimmten großen Firma gekauft, auf denen "SOA" -Aufkleber über den vorherigen "Web Service" -Aufklebern angebracht sind, die über den vorherigen "JEE" -Aufklebern angebracht waren .... Du hast die Idee. Aus diesem Grund sitzen wir als Entwickler da und ziehen und legen kleine Symbole auf einem Bildschirm ab, um "SOA" - "KOMPONENTEN" zu erstellen, die halb so gut funktionieren, als hätten wir es mit einfachen Dingen wie EBJ3 - Bohnen, Federkomponenten usw. Gemacht .

Mein Rat ist also, wenn Sie nach SOA gefragt werden: "Ja, ich habe SOA durchgeführt, ich habe viele Systeme geschrieben, die eine serviceorientierte Architektur verwenden, um Dinge zu tun. Nach welcher SOA-Technologie fragen Sie?". Und wenn sie anfangen, mit leuchtenden Augen und wehmütigen Blicken über SOA COMPONENTS, DRAG AND DROP und wie es die Entwicklung erleichtert, zu sprechen. Ziehen Sie sich langsam zurück und vermeiden Sie Augenkontakt!

Ich denke, es könnte ein bisschen sinnvoll sein: Eine Sache ist, wenn "Slave" -Module bei Bedarf aufgerufen werden, und eine andere, wenn Service- / Daemon-Prozesse unabhängig ausgeführt werden und auf Ihre Anforderungen reagieren, möglicherweise miteinander sprechen und deren Bedingungen erfüllen eigenes Leben mit anderen Worten. Mit diesem Ansatz können Sie ein riesiges, skalierbares, physisch verteiltes System haben. Ich habe zum Beispiel einige im Bereich der Mobiltelefonie gesehen. Aber das ist nur eine Vermutung.

(Nun wollen wir mal sehen, was Wikipedia über SOA sagt ... Whoa.)