SOA
-
was ist das tolle an einer service orientierten architektur?
-
Dieser Thread wurde von Moderator/in CStoll aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Wiederverwendbarkeit.
Man geht grundsätzlich davon aus, dass so gut wie alle Funktionen (Services) schon implementiert sind. Um eine neue Applikation zu schreiben, muss man im Idealfalle nichts weiter tun, als die entsprechenden Services zusammen zu packen (orchestrieren) und mit einer Programmsteuerung zu koppeln. Hierdurch sinken die Entwicklungskosten, da sehr häufige Anwendungsfälle nur einmal beschrieben und immer wieder verwendet werden.
Inzwischen gibt es verschiedene Ansätze, die sogar unterschiedliche Technologien (RCP, SOAP, CORBA, proprietäres, .NET) miteinander verbindet (ESB).
Im Kleinen ist das Ganze unsinnig, aber wenn man an große Applikationen und Unternehmen denkt, wird das Ganze äußerst Attraktiv..
Außerdem kann man endlich überbezahlte Programmierer degradieren und hat dann Geld, überbezahlte Analysten und Designer einzustellen..
-
was ist wenn die funktionen/framework alle neu implementiert werden und später erst wiederverwendet werden?
-
Dann hast du deine Einsparungen später..
-
Ich würde statt Wiederverwendbarkeit eher die Entkopplung als Hauptvorteil sehen. Statt großer "Klopsprogramme" hat man eine größere Zahl kleiner Programme, die in verschiedenen Sprachen und auch Plattformen implementiert sein können. Dadurch macht man sich auch Pflege und Wartung leichter, da man nicht gezwungen ist, alle Pakete zu migrieren, wenn es zu Plattform- oder Systemänderungen kommt.
-
und man kann einen service von mehreren UIs aus nutzen.
-
der vorteil einer service orientierten architektur spielt sich erst dann aus, wenn kern funktionalitäten (business logic) an vielen unterschiedlichen stellen, in diversen sprachen verwendet werden. wenn sich eine software beispielsweise in ein third party plugin, eine administrative konsole und eine webanwendung splittet. da treffen möglicherweise drei unterschiedliche sprachen aufeinander und in eine lib ausgelagerte funktionalität ist womöglich nur sehr umständlich für java, c++ und asp anwendungen zur verfügung zu stellen. aber alle drei müssen dieselbe programmlogik zur verfügung stellen. und genau da setzt die service architektur an. im idealen fall muss in einer beliebigen sprache lediglich ein UI gecodet werden und die gesamte logik kann aus den services zusammengekratzt werden. das spart unglaublich viel zeit und vor allem bugs in erneut implementierter logik, die zu inkonsistenzen führen kann.
-
Beispielsweise können Banken, deren Programme auch heute noch vielfach in COBOL geschrieben sind, auf Java EE umsteigen, ihr Webangebot verbreitern und das, ohne ihre schon existierenden Logik-Module neu zu implementieren..