Serviceorientierte Architektur

Im Softwareentwicklung, Soa (Serviceorientierte Architektur) ist ein architektonischer Stil, der sich auf diskrete Dienste anstelle eines monolithischen Designs konzentriert.[1] Infolgedessen wird es auch im Bereich von angewendet Software-Design wo Dienste für die anderen Komponenten von zur Verfügung gestellt werden Anwendungskomponenten, durch ein Kommunikationsprotokoll über ein Netzwerk. Ein Dienst ist eine diskrete Funktionseinheit, auf die aus der Ferne zugegriffen und unabhängig voneinander aktualisiert und aktualisiert werden kann, z. B. online abzurufen. SOA soll auch unabhängig von Anbietern, Produkten und Technologien sein.[2]

Serviceorientierung ist eine Denkweise in Bezug auf Dienstleistungen und dienstleistungsbasierte Entwicklung sowie die Ergebnisse von Dienstleistungen.[1]

Ein Dienst hat vier Immobilien nach einer von vielen Definitionen von SOA:[3]

  1. Es stellt logischerweise eine wiederholbare Geschäftstätigkeit mit einem bestimmten Ergebnis dar.
  2. Es ist in sich geschlossen.
  3. Es ist ein Flugschreiber Für seine Verbraucher muss der Verbraucher die innere Funktionsweise des Dienstes nicht bewusst sein.
  4. Es kann aus anderen Diensten bestehen.[4]

Verschiedene Dienste können in Verbindung als Service -Netz die Funktionalität eines großen bereitstellen Computerprogramm,[5] ein Prinzip, das SOA teilt mit Modulare Programmierung. Service-orientierte Architektur integriert verteilte, separat gepflegte und bereitgestellte Softwarekomponenten. Es wird durch Technologien und Standards aktiviert, die die Kommunikation und Zusammenarbeit der Komponenten über ein Netzwerk, insbesondere über ein IP -Netzwerk, erleichtern.

SOA bezieht sich auf die Idee einer API (Programmierschnittstelle) Ein Schnittstellen- oder Kommunikationsprotokoll zwischen verschiedenen Teilen eines Computerprogramms, mit dem die Implementierung und Wartung von Software vereinfacht wird. Eine API kann als Dienst und die SOA der Architektur betrachtet werden, die es dem Dienst ermöglicht.

Überblick

In SOA verwenden Dienste Protokolle, die beschreiben, wie sie passieren und analysieren Sie Nachrichten mit der Beschreibung Metadaten. Diese Metadaten beschreibt sowohl die funktionalen Eigenschaften des Service als auch die Eigenschaften der Servicequalität. Serviceorientierte Architektur zielt darauf ab, dass Benutzer große Funktionen der Funktionalität kombinieren können, um Anwendungen zu bilden, die nur aus vorhandenen Diensten hergestellt werden und sie auf Ad-hoc-Weise kombinieren. Ein Dienst präsentiert eine einfache Schnittstelle zum Antragsteller, die die zugrunde liegende Komplexität, die als Black Box fungiert, abstrahiert. Weitere Benutzer können auch auf diese unabhängigen Dienste zugreifen, ohne dass ihre interne Implementierung bekannt ist.[6]

Konzepte definieren

Das verwandte Schlagwort Serviceorientierung fördert lose Kopplung zwischen Dienstleistungen. SOA trennt Funktionen in verschiedene Einheiten oder Dienste.[7] Welche Entwickler über ein Netzwerk zugänglich machen, damit Benutzer diese in der Produktion von Anwendungen kombinieren und wiederverwenden können. Diese Dienste und ihre entsprechenden Verbraucher kommunizieren miteinander, indem sie Daten in einem gut definierten, gemeinsam genutzten Format übergeben oder eine Aktivität zwischen zwei oder mehr Diensten koordinieren.[8]

Ein Manifest wurde im Oktober 2009 für die serviceorientierte Architektur veröffentlicht. Dies kam mit sechs Grundwerten, die wie folgt aufgeführt sind:[9]

  1. Geschäftswert wird mehr Bedeutung als technische Strategie.
  2. Strategische Ziele haben mehr Bedeutung als projektspezifische Vorteile.
  3. Intrinsische Interoperabilität wird mehr Bedeutung als benutzerdefinierte Integration erhalten.
  4. Geteilte Dienstleistungen werden mehr Bedeutung als spezifische Implementierungen erhalten.
  5. Flexibilität wird mehr Bedeutung als Optimierung.
  6. Evolutionäre Verfeinerung wird mehr Bedeutung als anfänglicher Perfektion verfolgt.

SOA kann als Teil des Kontinuums gesehen werden, das vom älteren Konzept von reicht verteiltes Computer[7][10] und Modulare Programmierung, durch SOA und weiter zu Praktiken von Mashups, Saas, und Cloud Computing (was manche als Nachkommen von SOA betrachten).[11]

Prinzipien

Es gibt keine Branchenstandards in Bezug auf die genaue Zusammensetzung einer dienstleistungsorientierten Architektur, obwohl viele Branchenquellen ihre eigenen Prinzipien veröffentlicht haben. Einige davon[12][13][14] füge folgendes hinzu:

Standardisierter Servicevertrag[15]
Die Dienste halten sich an einen Standard-Kommunikationsvertrag, wie sie durch eine oder mehrere Dienstleistungsdokumente innerhalb eines bestimmten Dienstes zusammengefasst sind.
Service -Referenz -Autonomie (ein Aspekt der losen Kopplung)
Die Beziehung zwischen Dienstleistungen wird bis zu dem Niveau minimiert, dass sie sich nur ihrer Existenz bewusst sind.
Transparenz des Service Ort (ein Aspekt der losen Kupplung)
Dienste können von überall innerhalb des Netzwerks aufgerufen werden, in dem es sich befindet, unabhängig davon, wo es vorhanden ist.
Service Langlebigkeit
Dienstleistungen sollten so konzipiert werden, dass sie lange gelebt werden. Wenn mögliche Dienstleistungen vermeiden sollten, die Verbraucher zu ändern, wenn sie keine neuen Funktionen benötigen, sollten Sie morgen einen Service anrufen, um denselben Service morgen anzurufen.
Service -Abstraktion
Die Dienste fungieren als schwarze Kisten, dh ihre innere Logik ist den Verbrauchern verborgen.
Service Autonomie
Dienste sind unabhängig und kontrollieren die Funktionen, die sie zusammenfassen, aus der Designzeit und einer Laufzeitperspektive.
Servicemittel Staatenlosigkeit
Services sind staatenlos, dh entweder den angeforderten Wert zurückgeben oder eine Ausnahme abgeben, wodurch die Verwendung von Ressourcen minimiert wird.
Service -Granularität
Ein Prinzip, um sicherzustellen, dass Dienstleistungen eine angemessene Größe und einen angemessenen Umfang haben. Die vom Dienst an den Benutzer bereitgestellten Funktionen müssen relevant sein.
Service -Normalisierung
Die Dienstleistungen werden zerlegt oder konsolidiert (normalisiert), um Redundanz zu minimieren. In einigen kann dies nicht getan werden. Dies sind die Fälle, in denen Leistungsoptimierung, Zugang und Aggregation erforderlich sind.[16]
Serviceverbindlichkeit
Services können verwendet werden, um andere Dienste zu komponieren.
Service -Entdeckung
Die Dienste werden mit kommunikativen Meta -Daten ergänzt, nach denen sie effektiv entdeckt und interpretiert werden können.
Service -Wiederverwendbarkeit
Die Logik wird in verschiedene Dienste unterteilt, um die Wiederverwendung von Code zu fördern.
Service Verkapselung
Viele Dienstleistungen, die zunächst nicht unter SOA geplant wurden, können eingekapselt oder Teil von SOA werden.

Muster

Jeder SOA -Baustein kann eine der drei Rollen spielen:

Dienstleister
Es schafft einen Webdienst und bietet seine Informationen für die Serviceregistrierung. Jeder Anbieter debattiert über eine Menge von Hows und Whys, welchen Service sie aussetzen sollen, was für mehr Bedeutung ist: Sicherheit oder einfache Verfügbarkeit, welchen Preis für und viele weitere für viele weitere Anbieter anbieten.. Der Anbieter muss auch entscheiden, in welcher Kategorie der Service für einen bestimmten Broker -Service aufgeführt sein sollte[17] Und welche Art von Handelspartnervereinbarungen sind zur Nutzung des Dienstes erforderlich.
Service Broker, Service Registry oder Service Repository
Seine Hauptfunktionen besteht darin, die Informationen zum Webdienst einem potenziellen Antragsteller zur Verfügung zu stellen. Wer den Broker implementiert, entscheidet den Umfang des Brokers. Öffentliche Makler stehen überall und überall zur Verfügung, aber private Makler stehen nur einer begrenzten Menge an öffentlichem Umfang zur Verfügung. Uddi war ein frühes, nicht mehr aktiv unterstützter Versuch, zu versorgen Entdeckung von Webdiensten.
Serviceanforderer/Verbraucher
Es findet Einträge in der Broker -Registrierung mit verschiedenen Suchvorgängen und bindet dann an den Dienstanbieter, um einen seiner Webdienste aufzurufen. Welchen Service die Service-Verbraucher benötigen, müssen sie in die Makler einnehmen, ihn mit dem jeweiligen Service binden und dann verwenden. Sie können auf mehrere Dienste zugreifen, wenn der Dienst mehrere Dienste anbietet.

Die Beziehung zwischen dem Dienst für Verbraucher und des Dienstes unterliegt a standardisierter Servicevertrag,[18] Dies hat einen Geschäftsteil, einen funktionalen Teil und einen technischen Teil.

Service -Kompositionsmuster Haben Sie zwei breite, hochrangige architektonische Stile: Choreografie und Orchestrierung. Die Integrationsmuster auf niedrigerer Ebene, die nicht an einen bestimmten architektonischen Stil gebunden sind, sind weiterhin relevant und berechtigt im SOA -Design.[19][20][21]

Implementierungsansätze

Service-orientierte Architektur kann mit implementiert werden Internetdienste oder Microservices.[22] Dies wird durchgeführt, um die funktionalen Gebäudeblocke über Standard-Internetprotokolle zugänglich zu machen, die unabhängig von Plattformen und Programmiersprachen sind. Diese Dienste können entweder neue Anwendungen oder nur Wrapper in bestehenden Legacy-Systemen darstellen, um sie netzwerkfähiger zu machen.[23]

Implementierer erstellen üblicherweise SOAs mithilfe von Web -Services -Standards. Ein Beispiel ist SEIFE, was nach Empfehlung von Version 1.2 aus dem W3C eine breite Akzeptanz der Branche erlangt hat[24] (World Wide Web Consortium) im Jahr 2003. Diese Standards (auch als als bezeichnet als als Webdienstspezifikationen) bieten auch eine größere Interoperabilität und einen gewissen Schutz von Lock-In zu proprietären Anbieter-Software. Man kann jedoch auch SOA mithilfe einer anderen Service-basierten Technologie implementieren, wie z. Jini, Corba, Internetkommunikation Engine, SICH AUSRUHEN, oder GRPC.

Architekturen können unabhängig von bestimmten Technologien arbeiten und daher mit einer Vielzahl von Technologien implementiert werden, darunter:

Implementierungen können einen oder mehrere dieser Protokolle verwenden und beispielsweise einen Dateisystemmechanismus verwenden, um Daten nach einer definierten Schnittstellenspezifikation zwischen Prozessen zu kommunizieren, die dem SOA-Konzept entsprechen. Der Schlüssel sind unabhängige Dienste mit definierten Schnittstellen, die aufgefordert werden können, ihre Aufgaben auf Standard -Weise auszuführen, ohne dass ein Dienst vor Kenntnis der aufrufenden Anwendung und ohne Kenntnis der Anwendung über die Ausführung seiner Aufgaben erledigt wird. SOA ermöglicht die Entwicklung von Anwendungen, die durch kombiniertes locker gekoppelte und Interoperable Dienstleistungen.

Diese Dienste interpretieren basierend auf einer formalen Definition (oder einem Vertrag, z. B. WSDL), das unabhängig von der zugrunde liegenden Plattform und der Programmiersprache ist. Die Schnittstellendefinition versteckt die Implementierung des sprachspezifischen Dienstes. SOA-basierte Systeme können daher unabhängig von Entwicklungstechnologien und Plattformen (wie Java, .NET usw.) funktionieren. Services, die in C# auf .NET -Plattformen und -Diensten geschrieben wurden, die in Java geschrieben wurden Java ee Plattformen können beispielsweise beide von einer gemeinsamen Verbundanwendung (oder Client) konsumiert werden. Anwendungen, die auf beiden Plattform ausgeführt werden, können auch Dienste als Webdienste konsumieren, die die Wiederverwendung erleichtern. Managierte Umgebungen können auch Cobol -Legacy -Systeme einwickeln und sie als Softwaredienste darstellen..[25]

Hochrangige Programmiersprachen wie zum Beispiel BPEL und Spezifikationen wie z. WS-CDL und WS-Koordination Erweitern Sie das Servicekonzept, indem Sie eine Methode zur Definition und Unterstützung der Orchestrierung feinkörniger Dienste in grobkörnigeren Geschäftsdiensten bereitstellen, die Architekten wiederum in Workflows und Geschäftsprozesse einbeziehen können zusammengesetzte Anwendungen oder Portale.

Service-orientierte Modellierung ist ein SOA-Framework, der die verschiedenen Disziplinen identifiziert, die SOA-Praktiker leiten, um ihre serviceorientierten Vermögenswerte zu konzipieren, zu analysieren, zu entwerfen und zu architekten. Das Service-orientiertes Modellierungsrahmen (SOMF) Bietet eine Modellierungssprache und eine Arbeitsstruktur oder "Karte", die die verschiedenen Komponenten darstellt, die zu einem erfolgreichen Service-orientierten Modellierungsansatz beitragen. Es zeigt die Hauptelemente, die die Aspekte eines Dienstleistungsentwicklungsschemas identifizieren. Das Modell ermöglicht es Praktizierenden, a zu erstellen Projektplan und die Meilensteine ​​einer serviceorientierten Initiative zu identifizieren. SOMF bietet auch eine gemeinsame Modellierungsnotation, um die Ausrichtung zwischen Geschäfts- und IT -Organisationen zu beheben.

Elemente von SOA, von Dirk Krafzig, Karl Banke und Dirk Slama[26]
SOA Meta-Model, The Linthicum Group, 2007

Organisationsvorteile

Etwas Enterprise Architects Glauben Sie, dass SOA Unternehmen helfen kann, schneller und kostengünstiger auf sich ändernde Marktbedingungen zu reagieren.[27] Dieser Stil von die Architektur Fördert die Wiederverwendung auf Makro- (Service-) Ebene anstelle von Micro (Klassen). Es kann auch die Verbindungsverbindung zu - und die Verwendung von - sie (Vermächtnis-) Vermögenswerte vereinfachen.

Bei SOA ist die Idee, dass eine Organisation ein Problem ganzheitlich betrachten kann. Ein Unternehmen hat mehr allgemeine Kontrolle. Theoretisch würde es keine Masse von Entwicklern geben, die die Werkzeugsätze verwenden, die ihnen gefallen könnten. Sondern sie würden nach einem Standard codieren, der im Geschäft festgelegt ist. Sie können auch eine unternehmensweite SOA entwickeln, die eine geschäftsorientierte Infrastruktur zusammenfasst. SOA wurde auch als Autobahnsystem veranschaulicht, das den Autofahrern Effizienz bietet. Der Punkt ist, dass, wenn jeder ein Auto hätte, aber nirgendwo Autobahn gab, die Dinge begrenzt und unorganisiert sein würden, um schnell oder effizient irgendwohin zu gelangen. Der IBM Vice President von Web Services Michael Liebow sagt, dass SOA "Autobahnen baut".[28]

In gewisser Hinsicht könnte SOA eher als architektonische Entwicklung als als Revolution angesehen werden. Es erfasst viele der der empfohlene Vorgehensweise von früheren Software -Architekturen. In Kommunikationssystemen hat beispielsweise nur wenige Entwicklung von Lösungen, die wirklich statische Bindungen verwenden, um mit anderen Geräten im Netzwerk zu sprechen. Durch die Einführung eines SOA-Ansatzes können sich solche Systeme positionieren, um die Bedeutung gut definierter, stark interoperabler Schnittstellen zu betonen. Andere Vorgänger von SOA sind eingeschlossen Komponentenbasierte Software-Engineering und objektorientierte Analyse und Design (OAD) von Remote-Objekten beispielsweise in Corba.

Ein Dienst umfasst eine eigenständige Funktionseinheit, die nur über eine formell definierte Schnittstelle verfügbar ist. Dienstleistungen können eine Art "Nano-Enterprises" sein, die leicht zu produzieren und zu verbessern sind. Es können auch "Mega-Corporations" sein, die als koordinierte Arbeit der untergeordneten Dienste errichtet werden.

Gründe für die Behandlung der Umsetzung von Diensten als getrennte Projekte aus größeren Projekten umfassen:

  1. Die Trennung fördert das Konzept für das Unternehmen, dass Dienstleistungen schnell und unabhängig von den größeren und langsameren Projekten in der Organisation erbracht werden können. Das Unternehmen beginnt mit dem Verständnis von Systemen und vereinfachten Benutzeroberflächen, die Dienste aufrufen. Dieser Befürworter Beweglichkeit. Das heißt, es fördert geschäftliche Innovationen und beschleunigt die Zeit zu Markt.[29]
  2. Die Trennung fördert die Entkopplung von Dienstleistungen aus dem Verzehr von Projekten. Dies fördert ein gutes Design, sofern der Service konzipiert ist, ohne zu wissen, wer seine Verbraucher sind.
  3. Dokumentations- und Testartefakte des Dienstes sind nicht in das Detail des größeren Projekts eingebettet. Dies ist wichtig, wenn der Service später wiederverwendet werden muss.

SOA verspricht, das Testen indirekt zu vereinfachen. Die Dienste sind autonom, auf Stauro, mit vollständig dokumentierten Schnittstellen und von den Übergängen der Umsetzung getrennt. Wenn eine Organisation entsprechend definierte Testdaten besitzt, wird ein entsprechender Stub erstellt, der auf die Testdaten reagiert, wenn ein Dienst erstellt wird. Für den Dienst wird auch ein vollständiger Satz von Regressionstests, Skripten, Daten und Antworten erfasst. Der Dienst kann als "Black Box" unter Verwendung vorhandener Stubs getestet werden, die den von ihm aufgerufenen Diensten entsprechen. Testumgebungen können konstruiert werden, in denen die primitiven und außerhalb des SCOPE-Dienste Stubs sind, während der Rest des Netzes Testbereitstellungen für vollständige Dienste sind. Da jede Schnittstelle vollständig mit ihrer eigenen vollständigen Reihe von Regressionstestdokumentation dokumentiert ist, wird es einfach, Probleme in Testdiensten zu identifizieren. Die Tests entwickeln sich, um lediglich zu validieren, dass der Testdienst gemäß den Dokumentationen funktioniert, und findet Lücken in den Dokumentations- und Testfällen aller Dienste innerhalb der Umgebung. Verwaltung des Datenzustands von idempotent Dienstleistungen sind die einzige Komplexität.

Beispiele können sich als nützlich erweisen, um einen Dienst auf der Ebene zu dokumentieren, auf der er nützlich wird. Die Dokumentation einiger APIs innerhalb des Java -Community -Prozesses liefert gute Beispiele. Da diese erschöpfend sind, verwenden das Personal normalerweise nur wichtige Teilmengen. Die Datei "Ossjsa.pdf" innerhalb JSR-89 Vorspielhaft eine solche Datei.[30]

Kritik

SOA wurde mit in Verbindung gebracht Internetdienste;[31] Webdienste sind jedoch nur eine Option, um die Muster zu implementieren, aus denen der SOA -Stil besteht. In Ermangelung von nativen oder binären Formen des Remote -Verfahrensaufrufs (RPC) könnten Anwendungen langsamer ausgeführt werden und mehr Verarbeitungsleistung erfordern und die Kosten erhöhen. Die meisten Implementierungen entstehen diesen Gemeinkosten, aber SOA kann mithilfe von Technologien implementiert werden (z. B., Java Business Integration (JBI), Windows Communication Foundation (WCF) und Datenverteilungsdienst (Dds)), die nicht von Remote -Prozeduraufrufen oder Übersetzung über XML oder JSON abhängen. Gleichzeitig entstehende Open-Source-XML-Parsing-Technologien (wie z. VTD-XML) und verschiedene XML-kompatible binäre Formate versprechen, die SOA-Leistung erheblich zu verbessern.[32][33][34]

Nach staatlichen Diensten müssen sowohl der Verbraucher als auch der Anbieter denselben konsumentenspezifischen Kontext teilen, der entweder in Nachrichten enthalten ist oder durch die zwischen dem Anbieter und dem Verbraucher ausgetauschte Nachrichten verwiesen wird. Diese Einschränkung hat den Nachteil, dass sie das Gesamt verringern könnte Skalierbarkeit des Dienstanbieters, wenn der Service-Anbieter den gemeinsam genutzten Kontext für jeden Verbraucher behalten muss. Es erhöht auch die Kopplung zwischen einem Dienstleister und einem Verbraucher und erschwert den Wechsel von Dienstanbietern.[35] Letztendlich sind einige Kritiker der Ansicht, dass SOA -Dienste immer noch durch Anwendungen, die sie vertreten, zu eingeschränkt sind.[36]

Eine primäre Herausforderung für die serviceorientierte Architektur ist die Verwaltung von Metadaten. Auf SOA basierende Umgebungen umfassen viele Dienste, die untereinander kommunizieren, um Aufgaben auszuführen. Aufgrund der Tatsache, dass das Design möglicherweise mehrere Dienste umfasst, die in Verbindung arbeiten, kann eine Anwendung Millionen von Nachrichten generieren. Weitere Dienstleistungen können zu verschiedenen Organisationen oder sogar konkurrierenden Unternehmen gehören, die ein großes Vertrauensproblem verursachen. So kommt SOA Governance in das Schema der Dinge.[37]

Ein weiteres wichtiges Problem, mit dem SOA konfrontiert ist, ist das Fehlen eines einheitlichen Testrahmens. Es gibt keine Tools, die die erforderlichen Funktionen für das Testen dieser Dienste in einer serviceorientierten Architektur bereitstellen. Die Hauptursachen für Schwierigkeiten sind:[38]

  • Heterogenität und Komplexität der Lösung.
  • RIESIGE TEST -Kombinationen aufgrund der Integration autonomer Dienste.
  • Einbeziehung von Diensten von verschiedenen und konkurrierenden Anbietern.
  • Plattform ändert sich aufgrund der Verfügbarkeit neuer Funktionen und Dienstleistungen kontinuierlich.

Erweiterungen und Varianten

Ereignisgesteuerte Architektur

Hauptartikel: Ereignisgesteuerte Architektur

Anwendungsprogrammierschnittstellen

Hauptartikel: Anwendungsprogrammierschnittstellen

Anwendungsprogrammierschnittstellen (APIs) sind die Frameworks, in denen Entwickler mit einer Webanwendung interagieren können.

Web 2.0

Tim O'Reilly prägte den Begriff "Web 2.0"Um eine wahrgenommene, schnell wachsende Reihe webbasierter Anwendungen zu beschreiben.[39] Ein Thema, das umfangreiche Berichterstattung erlebt hat, umfasst die Beziehung zwischen Web 2.0 und Service-orientierten Architekturen.[die?]

SOA ist die Philosophie, die Anwendungslogik in Diensten mit einer einheitlich definierten Schnittstelle zu verkörpern und diese über Entdeckungsmechanismen öffentlich verfügbar zu machen. Der Begriff der Komplexitätsbeugung und Wiederverwendung, aber auch das Konzept der lose Kopplungsdienste hat die Forscher dazu inspiriert, Ähnlichkeiten zwischen den beiden Philosophien SOA und Web 2.0 und ihren jeweiligen Anwendungen zu erläutern. Einige argumentieren, dass Web 2.0 und SOA signifikant unterschiedliche Elemente haben und daher nicht als "parallele Philosophien" angesehen werden können, während andere die beiden Konzepte als komplementär betrachten und Web 2.0 als die globale SOA betrachten.[40]

Die Philosophien von Web 2.0 und SOA erfüllen unterschiedliche Benutzerbedürfnisse und enthüllen somit Unterschiede in Bezug auf das Design und auch die Technologien, die in realen Anwendungen verwendet werden. Ab 2008 jedochDie Anwendungsfälle zeigten das Potenzial, Technologien und Prinzipien von Web 2.0 und SOA zu kombinieren.[40]

Microservices

Hauptartikel: Microservices

Microservices sind eine moderne Interpretation von diensten orientierten Architekturen, die zum Aufbau verwendet werden verteilte Softwaresysteme. Dienste in einer Microservice -Architektur[41] sind Prozesse das kommunizieren miteinander über die Netzwerk um ein Ziel zu erreichen. Diese Dienste nutzen Technologie agnostisch Protokolle,[42] die dazu beitragen, die Auswahl von Sprache und Frameworks zu verkörpern und ihre Wahl zu einem internen Bedenken des Dienstes zu machen. Microservices sind ein neuer Realisierungs- und Implementierungsansatz für SOA, der seit 2014 (und nach der Einführung von DevOps) und die auch den kontinuierlichen Einsatz und andere agile Praktiken betonen.[43]

Es gibt keine einzige vereinbarte Definition von Microservices. Die folgenden Eigenschaften und Prinzipien finden Sie in der Literatur:

  • feinkörnige Schnittstellen (zu unabhängig einsetzbaren Diensten),
  • Geschäftsbetriebene Entwicklung (z. Domänengetriebenes Design),
  • Ideale Cloud -Anwendungsarchitekturen,
  • Polyglot -Programmierung und Persistenz,
  • Leichte Container -Bereitstellung,
  • dezentrale kontinuierliche Lieferung und
  • DevOps mit ganzheitlicher Serviceüberwachung.

Service-orientierte Architekturen für interaktive Anwendungen

Interaktive Anwendungen, die Echtzeit-Antwortzeiten erfordern, beispielsweise interaktive 3D-Anwendungen mit geringer Latenz, verwenden spezifische serviceorientierte Architekturen, die die spezifischen Anforderungen solcher Anwendungen entsprechen. Dazu gehören beispielsweise niedrig latenz optimierte verteilte Berechnungen und Kommunikation sowie Ressourcen- und Instanzmanagement.[44][45][46]

Siehe auch

Verweise

  1. ^ a b "Soa Quellbuch - Was ist SOA?". collaboration.opengroup.org. Abgerufen 30. März, 2021.
  2. ^ "Kapitel 1: Serviceorientierte Architektur (SOA)". msdn.microsoft.com. Archiviert von das Original am 7. Juli 2017. Abgerufen 21. September, 2016.
  3. ^ "Service -orientierte Architekturstandards - die offene Gruppe". www.opengroup.org.
  4. ^ "Was ist SOA?". www.opengroup.org. Archiviert von das Original am 19. August 2016. Abgerufen 21. September, 2016.
  5. ^ Velte, Anthony T. (2010). Cloud Computing: Ein praktischer Ansatz. McGraw Hill. ISBN 978-0-07-162694-1.
  6. ^ "Migration zu einer serviceorientierten Architektur, Teil 1". 9. Dezember 2008. Archiviert aus dem Original am 9. Dezember 2008. Abgerufen 21. September, 2016.{{}}: CS1 Wartung: Bot: Original -URL -Status unbekannt (Link)
  7. ^ a b Michael Bell (2008). "Einführung in serviceorientierte Modellierung". Service-orientierte Modellierung: Serviceanalyse, Design und Architektur. Wiley & Söhne. p.3. ISBN 978-0-470-14111-3.
  8. ^ Michael Bell (2010). SOA-Modellierungsmuster für Service-orientierte Entdeckung und Analyse. Wiley & Söhne. p.390. ISBN 978-0-470-48197-4.
  9. ^ "SOA Manifesto". www.soa-Manifesto.org. Abgerufen 21. September, 2016.
  10. ^ Thomas ERL (Juni 2005). Über die Prinzipien. Serviceorientation.org
  11. ^ "Anwendungsplattformstrategien Blog: SOA ist tot; lange Live -Dienste". Apsblog.burtongroup.com. 5. Januar 2009. archiviert von das Original am 15. Januar 2009. Abgerufen 13. August, 2012.
  12. ^ Yvonne Balzer Verbessern Sie Ihre SOA -Projektpläne, IBM, 16. Juli 2004
  13. ^ Microsoft Windows Communication Foundation Team (2012). "Prinzipien des dienstleistungsorientierten Designs". msdn.microsoft.com. Abgerufen 3. September, 2012.
  14. ^ Prinzipien von Thomas Erl von SOA Systems Inc. Acht spezifische Service-Orientierungsprinzipien
  15. ^ "4.4 Richtlinien für die Verwendung von Web -Service -Vertragstechnologien - Anatomie eines Web -Service -Vertrags". Informit. 11. Juni 2021. Abgerufen 9. September, 2021.
  16. ^ Tony Shan (2004). "Bauen eines serviceorientierten e Bankgeschäft Plattform". IEEE International Conference on Dienstleistungen Computing, 2004. (SCC 2004). Verfahren. 2004. S. 237–244. doi:10.1109/scc.2004.1358011. ISBN 978-0-7695-2225-8. S2CID 13156128.2004
  17. ^ Duan, Yucong; Narendra, Nanjangud; Du, Wencai; Wang, Yongzhi; Zhou, Nianjun (2014). "Erforschen von Cloud -Service -Brokern aus einer Schnittstellenperspektive". 2014 IEEE International Conference über Webdienste. IEEE. S. 329–336. doi:10.1109/ICWs.2014.55. ISBN 978-1-4799-5054-6. S2CID 17957063.
  18. ^ Duan, Yucong (2012). "Eine Umfrage zum Servicevertrag". 2012 13. ACIS International Conference für Software -Engineering, künstliche Intelligenz, Netzwerk und paralleles/verteiltes Computing. IEEE. S. 805–810. doi:10.1109/snpd.2012.22. ISBN 978-1-4673-2120-4. S2CID 1837914.
  19. ^ Olaf Zimmermann, Cesare Pautasso, Gregor Hohpe, Bobby Woolf (2016). "Ein Jahrzehnt von Unternehmensintegrationsmustern". IEEE -Software. 33 (1): 13–19. doi:10.1109/ms.2016.11.{{}}: Cs1 montiert: Mehrfachnamen: Autorenliste (Link)
  20. ^ Rotem-Gal-Oz, Arnon (2012). SOA -Muster. Manning Publikationen. ISBN 978-1933988269.
  21. ^ Julisch, Klaus; Suter, Christophe; Woitalla, Thomas; Zimmermann, Olaf (2011). "Compliance durch Design - Überbrückung der Kluft zwischen Wirtschaftsprüfern und IT -Architekten" (PDF). Computer & Sicherheit. 30 (6–7): 410–426. Citeseerx 10.1.1.390.3652. doi:10.1016/j.cose.2011.03.005.
  22. ^ Brandner, M., Craes, M., Oellermann, F., Zimmermann, O., Web Services-orientierte Architektur in der Produktion in der Finanzbranche, Informatik-Spektrum 02/2004, Springer-Verlag, 2004
  23. ^ "www.ibm.com". Abgerufen 10. September, 2016.
  24. ^ "SOAP Version 1.2 の 公開 について (W3C 勧告)" (auf Japanisch). W3.org. Abgerufen 13. August, 2012.
  25. ^ Okishima, Haruhiru (2006). "." Fallstudie der Systemarchitektur, die COBOL -Assets verwenden "" (PDF).
  26. ^ Enterprise SOA. Prentice Hall, 2005
  27. ^ Christopher Koch Eine neue Blaupause für das Unternehmen, CIO -Magazin, 1. März 2005
  28. ^ Elizabeth Millard (Januar 2005). "Einen besseren Prozess bauen". Computerbenutzer. Seite 20.
  29. ^ Brayan Zimmerli (11. November 2009) Geschäftsvorteile von SOA, Universität für angewandte Wissenschaft der nordwestlichen Schweiz, School of Business
  30. ^ JSR-000089 OSS Service Activation API Spezifikation 1.0 Endveröffentlichung. sun.com
  31. ^ Joe McKendrick. "Bray: SOA zu komplex; 'Just Vendor BS'". ZDNET.
  32. ^ Jimmy Zhang (20. Februar 2008) "Index XML-Dokumente mit VTD-XML" Archiviert 4. Juli 2008 bei der Wayback -Maschine. XML Journal.
  33. ^ Jimmy Zhang (5. August 2008) "Itechnologie Standpunkt: Die Performance-Wehung des binären XML". Microservices Journal.
  34. ^ Jimmy Zhang (9. Januar 2008) "Manipulieren Sie den XML -Inhalt auf den Ximple -Weg". devx.com.
  35. ^ "Der Grund, warum SOA keine nachhaltige Software liefert". jpMorgenthal.com. 19. Juni 2009. Abgerufen 27. Juni, 2009.
  36. ^ "SOA -Dienste, die immer noch zu beschränkt durch Anwendungen, die sie vertreten". Zdnet.com. 27. Juni 2009. Abgerufen 27. Juni, 2009.
  37. ^ "Governance -Schicht". www.opengroup.org. Abgerufen 22. September, 2016.
  38. ^ "Wie man effizient testet -orientierte Architektur | WSO2 Inc" testet ". wso2.com. Abgerufen 22. September, 2016.
  39. ^ "Was ist Web 2.0". Tim O'Reilly. 30. September 2005. Abgerufen 10. Juni, 2008.
  40. ^ a b Christoph Schroth; Bis Janner (2007). "Web 2.0 und SOA: Konvergierende Konzepte, die das Internet der Dienste ermöglichen". Computerspezialist. 9 (3): 36–41. doi:10.1109/Mitp.2007.60. S2CID 2859262. Abgerufen 23. Februar, 2008.
  41. ^ Dragoni, Nicola; Giallorenzo, Saverio; Alberto Lluch Lafuente; Mazzara, Manuel; Montesi, Fabrizio; Mustafin, Ruslan; Safina, Larisa (2016). "Microservices: Gestern, heute und morgen". Arxiv:1606.04036v1 [cs.se].
  42. ^ James Lewis und Martin Fowler. "Microservices".
  43. ^ Balalaie, a.; Heydarnoori, a.; Jamshidi, P. (1. Mai 2016). "Microservices Architecture ermöglicht DevOps: Migration zu einer Cloud-nativen Architektur" (PDF). IEEE -Software. 33 (3): 42–52. doi:10.1109/ms.2016.64. HDL:10044/1/40557. ISSN 0740-7459. S2CID 18802650.
  44. ^ Frank Glinka; Allaithy Raed (2009). "Eine Service-orientierte Schnittstelle für hoch interaktive verteilte Anwendungen". Europäische Konferenz zur parallele Verarbeitung. Vorlesungsnotizen in Informatik. 6043: 266–277. doi:10.1007/978-3-642-14122-5_31. ISBN 978-3-642-14121-8. Abgerufen 9. Februar, 2021.
  45. ^ Dieter Hildebrandt; Jan Klimke (2011). "Service-orientierte interaktive 3D-Visualisierung von massiven 3D-Stadtmodellen für dünne Kunden". Com.Geo '11: Verfahren der 2. Internationalen Konferenz über Computer für Geospatial Research & Applications. Com.geo '11: 1. doi:10.1145/1999320.1999326. ISBN 9781450306812. S2CID 53246415. Abgerufen 9. Februar, 2021.
  46. ^ Mahy Aly; Michael Franke (2016). "Service -orientierte interaktive Medien (SOIM) -Motoren, die durch optimierte Ressourcenfreigabe aktiviert wurden". 2016 IEEE Symposium on Service-oriented System Engineering (SOSE): 231–237. doi:10.1109/sose.2016.47. HDL:1854/LU-7215326. ISBN 978-1-5090-2253-3. S2CID 9511734. Abgerufen 9. Februar, 2021.