FRAGE 10

Unser Dienstinventar enthält die folgenden drei Dienste, die Zugriffsmöglichkeiten auf rechnungsbezogene Daten bieten: Invoice, InvProc und Proclnv. Diese Dienste wurden zu unterschiedlichen Zeiten von verschiedenen Projektteams erstellt und mussten keinen Designstandards entsprechen. Daher hat jeder dieser Dienste ein anderes Datenmodell für die Darstellung von Rechnungsdaten.
Derzeit hat jeder dieser drei Dienste einen anderen Service Consumer: Service Consumer A greift auf den Dienst Invoice (1) zu, Service Consumer B (2) greift auf den Dienst InvProc zu und Service Consumer C (3) greift auf den Dienst Proclnv zu. Jeder Service Consumer ruft eine Datenzugriffsfunktion eines rechnungsbezogenen Dienstes auf, so dass dieser Dienst mit der gemeinsamen Rechnungsdatenbank interagieren muss, die von allen rechnungsbezogenen Diensten verwendet wird (4, 5, 6).
Darüber hinaus wurde Service Consumer D so konzipiert, dass er direkt auf Rechnungsdaten aus der gemeinsamen Buchhaltungsdatenbank zugreift (7). (Im Kontext dieser Architektur wird Service Consumer D als Service Consumer bezeichnet, da er auf eine Ressource zugreift, die mit den dargestellten Servicearchitekturen in Verbindung steht). Angenommen, der Invoice-Dienst, der InvProc-Dienst und der Proclnv-Dienst sind Teil desselben Dienstinventars, welche Schritte wären dann erforderlich, um das offizielle Endpunktmuster vollständig anzuwenden?

FRAGE 11

Dienstverbraucher A sendet eine Nachricht an Dienst A. Derzeit gibt es drei doppelte Implementierungen von Dienst A (Implementierung 1, Implementierung 2 und Implementierung 3). Die vom Dienstverbraucher A gesendete Nachricht wird vom Dienstagenten A (1) abgefangen, der zur Laufzeit bestimmt, an welche Implementierung von Dienst A die Nachricht weitergeleitet werden soll. Alle drei Implementierungen des Dienstes A befinden sich auf demselben physischen Server.
Es wurde Ihnen mitgeteilt, dass trotz der Tatsache, dass es doppelte Implementierungen von Dienst A gibt, die Leistung zuweilen immer noch schlecht ist. Sie sind auch darüber informiert, dass Service A bald um eine neue Servicefähigkeit erweitert werden muss, um eine Funktionalität einzuführen, die den Zugriff auf eine gemeinsame Datenbank erfordert, die von vielen anderen Clients und Anwendungen im IT-Unternehmen genutzt wird. Es wird erwartet, dass dies zu weiteren Leistungsanforderungen an Dienst A führen wird.
Wie kann diese Service-Architektur geändert werden, um die Leistung in Vorbereitung auf die Hinzufügung der neuen Service-Funktion zu verbessern?

FRAGE 12

Die Dienste A, B und C sind nicht-agnostische Aufgabendienste. Dienst A und Dienst B verwenden die gleiche gemeinsame Zustandsdatenbank, um ihre Zustandsdaten zur Laufzeit zu verschieben.
Eine Bewertung der drei Dienste zeigt, dass jeder von ihnen einige agnostische Logik enthält, die nicht zur Wiederverwendung zur Verfügung gestellt werden kann, weil sie mit nicht-agnostischer Logik gebündelt ist.
Bei der Bewertung wird außerdem festgestellt, dass die Remote-Kommunikation, die für die Interaktion von Dienst A und Dienst B mit der gemeinsamen Zustandsdatenbank erforderlich ist, zu einer unangemessenen Verringerung der Laufzeitleistung führt, da sich Dienst A, Dienst B und die gemeinsame Zustandsdatenbank jeweils in räumlich getrennten Umgebungen befinden.
Wie kann diese Architektur durch die Anwendung des Orchestrierungsmusters verbessert werden?

FRAGE 13
Siehe Exhibit.

Dienst A ist ein SOAP-basierter Webservice mit einem funktionalen Kontext, der für die rechnungsbezogene Verarbeitung bestimmt ist. Dienst B ist ein REST-basierter Dienst, der einen generischen Datenzugriff auf eine Datenbank bietet.
In dieser Servicekompositionsarchitektur sendet Service Consumer A eine SOAP-Nachricht mit einem Rechnungs-XML-Dokument an Service A (1). Dienst A sendet dann das Rechnungs-XML-Dokument an Dienst B (2), der das Rechnungsdokument in eine Datenbank schreibt (3).
Das Datenmodell, das von Service Consumer A zur Darstellung des Rechnungsdokuments verwendet wird, basiert auf XML Schema A.
Der Dienstleistungsvertrag von Dienst A ist so konzipiert, dass er Rechnungsdokumente auf der Grundlage von XML-Schema B akzeptiert. Der Dienstleistungsvertrag für Dienst B ist so konzipiert, dass er Rechnungsdokumente auf der Grundlage von XML-Schema A akzeptiert. Die Datenbank, in die Dienst B den Rechnungsdatensatz schreiben muss, akzeptiert nur vollständige Geschäftsdokumente in einem proprietären CSV-Format (Comma Separated Value).
Aufgrund der Inkompatibilität der von den Services verwendeten XML-Schemata kann das Senden des Rechnungsdokuments von Service Consumer A an Service B nicht mit den Services, wie sie derzeit existieren, durchgeführt werden. Welche Schritte können unternommen werden, um das Senden des Rechnungsdokuments von Service Consumer A an die Datenbank zu ermöglichen, ohne Logik hinzuzufügen, die die Anforderungen an die Laufzeitleistung erhöht?

FRAGE 14
Siehe Exhibit.

Dienst A ist ein Aufgabendienst, der an Dienst B eine Nachricht (2) sendet und den Dienst B auffordert, Daten in einer Antwortnachricht (3) an Dienst A zurückzusenden. Je nach der erhaltenen Antwort muss Dienst A möglicherweise eine Nachricht an Dienst C senden (4), für die er keine Antwort benötigt.
Bevor er mit Dienst B Kontakt aufnimmt, muss Dienst A zunächst eine Liste von Codewerten aus seiner eigenen Datenbank abrufen (1) und diese Daten dann in seinen eigenen Speicher stellen. Wenn sich herausstellt, dass er eine Nachricht an Dienst C senden muss, muss Dienst A die Daten, die er von Dienst B erhält, mit den Daten aus der Codewerteliste kombinieren, um die Nachricht zu erstellen, die er an Dienst C sendet. Wenn Dienst A den Dienst C nicht aufrufen muss, kann er seine Aufgabe durch Verwerfen der Codewerte erledigen.
Dienst A und Dienst C befinden sich im Dienstinventar A. Dienst B befindet sich im Dienstinventar B.
Sie erfahren, dass die Dienste in Dienstinventar A mit Dienstverträgen entworfen wurden, die auf anderen Designstandards und Technologien basieren als die Dienste in Dienstinventar B. Daher ist Dienst A ein SOAP-basierter Webdienst und Dienst B ein REST-Dienst, der JSON-formatierte Nachrichten austauscht. Daher können Dienst A und Dienst B derzeit nicht miteinander kommunizieren. Darüber hinaus ist Dienst C ein agnostischer Dienst, auf den viele gleichzeitige Dienstnutzer zugreifen. Dienst C erreicht häufig seine Nutzungsschwellenwerte, während derer er nicht verfügbar ist und an ihn gesendete Nachrichten nicht empfangen werden.
Welche Schritte können unternommen werden, um diese Probleme zu lösen?

FRAGE 15
Siehe Exhibit.

Service Consumer A und Service A befinden sich in Service Inventory A. Service B und Service C befinden sich in Service Inventory B. Service D ist ein öffentlicher Dienst, auf den über das World Wide Web offen zugegriffen werden kann. Der Dienst ist auch käuflich zu erwerben, so dass er in IT-Unternehmen unabhängig eingesetzt werden kann. Aufgrund der konsequenten Anwendung des Serviceabstraktionsprinzips innerhalb von Service Inventory B sind die einzigen Informationen, die über Service B und Service C verfügbar sind, die veröffentlichten Serviceverträge. Für Service D werden der Servicevertrag und ein Service Level Agreement (SLA) zur Verfügung gestellt. Aus der SLA geht hervor, dass Service D jede Nacht von 23:00 Uhr bis Mitternacht einen geplanten Ausfall hat.
Sie sind Architekt in einem Projektteam, das Dienste für Dienstinventar A erstellt. Sie erfahren, dass die Eigentümer von Dienstinventar A und Dienstinventar B im Allgemeinen nicht kooperativ oder kommunikativ sind. Inventarübergreifende Servicekomposition wird zwar toleriert, aber nicht direkt unterstützt. Infolgedessen sind keine SLAs für Service B und Service C verfügbar und Sie wissen nicht, wie verfügbar diese Services sind. Anhand der Serviceverträge können Sie feststellen, dass die Services im Service-Inventar B andere Datenmodelle und ein anderes Transportprotokoll verwenden als die Services im Service-Inventar A. Darüber hinaus haben die jüngsten Testergebnisse gezeigt, dass die Leistung von Service D aufgrund der hohen Anzahl gleichzeitiger Zugriffe von Service-Konsumenten aus anderen Organisationen sehr unvorhersehbar ist. Man hat Ihnen auch mitgeteilt, dass man sich Sorgen darüber macht, wie lange Service-Konsument A seinen Zustand beibehalten muss, während er auf eine Antwort von Service A wartet.
Welche Schritte können unternommen werden, um diese Probleme zu lösen?

FRAGE 16

Dienst A ist ein SOAP-basierter Webservice mit einem funktionalen Kontext, der für die Verarbeitung von Rechnungen bestimmt ist.
Dienst B ist ein REST-basierter Dienst, der einen allgemeinen Datenzugriff auf eine Datenbank ermöglicht.
In dieser Servicekompositionsarchitektur sendet Service Consumer A eine SOAP-Nachricht mit einem Rechnungs-XML-Dokument an Service A (1). Dienst A sendet dann das Rechnungs-XML-Dokument an Dienst B (2), der das Rechnungsdokument in eine Datenbank schreibt (3).
Das Datenmodell, das von Service Consumer A zur Darstellung des Rechnungsdokuments verwendet wird, basiert auf XML Schema A.
Der Dienstleistungsvertrag von Dienst A ist so konzipiert, dass er Rechnungsdokumente auf der Grundlage von XML-Schema B akzeptiert. Der Dienstleistungsvertrag für Dienst B ist so konzipiert, dass er Rechnungsdokumente auf der Grundlage von XML-Schema A akzeptiert. Die Datenbank, in die Dienst B den Rechnungsdatensatz schreiben muss, akzeptiert nur vollständige Geschäftsdokumente in einem proprietären CSV-Format (Comma Separated Value).
Aufgrund der Inkompatibilität der von den Services verwendeten XML-Schemata kann das Senden des Rechnungsdokuments von Service Consumer A an Service B nicht mit den Services, wie sie derzeit existieren, durchgeführt werden. Welche Schritte können unternommen werden, um das Senden des Rechnungsdokuments von Service Consumer A an die Datenbank zu ermöglichen, ohne Logik hinzuzufügen, die die Anforderungen an die Laufzeitleistung erhöht?

FRAGE 17

Wenn Dienst A eine Nachricht von Dienstverbraucher A (1) erhält, wird die Nachricht von Komponente A verarbeitet. Diese Komponente ruft zunächst Komponente B (2) auf, die anhand von Werten aus der Nachricht die Datenbank A abfragt, um zusätzliche Daten zu erhalten. Komponente B gibt dann die zusätzlichen Daten an Komponente A zurück. Komponente A ruft dann Komponente C (3) auf, die mit der API eines Altsystems interagiert, um einen neuen Datenwert abzurufen.
Komponente C sendet dann den Datenwert zurück an Komponente A.
Anschließend sendet Komponente A einen Teil der gesammelten Daten an Komponente D (4), die die Daten in eine Textdatei schreibt, die in einem bestimmten Ordner abgelegt wird. Komponente D wartet dann, bis diese Datei über einen regelmäßig geplanten Batch-Import in ein anderes System importiert wird. Nach Abschluss des Imports gibt Komponente D einen Erfolgs- oder Misserfolgscode an Komponente A zurück. Komponente A sendet schließlich eine Antwort an Service Consumer A (5), die alle bis dahin gesammelten Daten enthält, und Service Consumer A schreibt alle Daten in Datenbank B (6).
Die Komponenten A, B, C und D gehören zur Servicearchitektur von Service A. Die Datenbank A, das Legacy-System und die Dateiordner sind gemeinsame Ressourcen innerhalb des IT-Unternehmens.
Dienst A ist ein Entitätsdienst mit einer Dienstarchitektur, die in den letzten Jahren gewachsen ist. Als Ergebnis eines Projekts zur Neugestaltung des gesamten Servicebestands werden Sie gebeten, die Servicearchitektur von Service A zu überarbeiten, um die von den Komponenten B, C und D bereitgestellte Logik in drei verschiedene Utility-Services aufzuteilen, ohne das Verhalten von Service A in Bezug auf Service Consumer A zu unterbrechen.
Welche Schritte können unternommen werden, um diese Anforderungen zu erfüllen?

FRAGE 18

Dienst A ist ein Dienstprogramm, das eine allgemeine Datenzugriffslogik für eine Datenbank bereitstellt, die Daten enthält, die in regelmäßigen Abständen aus einer gemeinsam genutzten Datenbank repliziert werden (1). Da bei der Entwicklung von Dienst A das Prinzip des standardisierten Dienstvertrags angewandt wurde, ist sein Dienstvertrag vollständig standardisiert worden.
Auf die Dienstarchitektur von Dienst A wird von drei Dienstkonsumenten zugegriffen. Dienstkonsument A greift auf eine Komponente zu, die Teil der Implementierung von Dienst A ist, indem er sie direkt aufruft (2). Dienstkonsument B ruft Dienst A auf, indem er auf dessen Dienstvertrag zugreift (3). Dienstkonsument C greift direkt auf die replizierte Datenbank zu, die Teil der Implementierung von Dienst A ist (4).
Man hat Ihnen gesagt, dass der Grund dafür, dass die Servicekonsumenten A und C den veröffentlichten Servicevertrag von Service A umgehen, darin liegt, dass es ihnen aus Sicherheitsgründen nicht gestattet ist, auf eine Teilmenge der Fähigkeiten in der API zuzugreifen, die den Servicevertrag von Service A umfasst. Wie kann die Architektur von Dienst A geändert werden, um diese Sicherheitsbeschränkungen durchzusetzen und gleichzeitig negative Formen der Kopplung zu vermeiden?

FRAGE 19
Siehe Exhibit.

Wenn Dienst A eine Nachricht von Dienstverbraucher A (1) erhält, wird die Nachricht von Komponente A verarbeitet.
Diese Komponente ruft zunächst Komponente B (2) auf, die anhand von Werten aus der Nachricht die Datenbank A abfragt, um zusätzliche Daten zu erhalten. Komponente B gibt dann die zusätzlichen Daten an Komponente A zurück. Komponente A ruft dann Komponente C (3) auf, die mit der API eines Altsystems interagiert, um einen neuen Datenwert abzurufen. Komponente C gibt den Datenwert dann an Komponente A zurück.
Anschließend sendet Komponente A einen Teil der gesammelten Daten an Komponente D (4), die die Daten in eine Textdatei schreibt, die in einem bestimmten Ordner abgelegt wird. Komponente D wartet dann, bis diese Datei über einen regelmäßig geplanten Batch-Import in ein anderes System importiert wird. Nach Abschluss des Imports gibt Komponente D einen Erfolgs- oder Misserfolgscode an Komponente A zurück. Komponente A sendet schließlich eine Antwort an Service Consumer A (5), die alle bis dahin gesammelten Daten enthält, und Service Consumer A schreibt alle Daten in Datenbank B (6).
Die Komponenten A, B, C und D gehören zur Servicearchitektur von Service A. Die Datenbank A, das Legacy-System und die Dateiordner sind gemeinsame Ressourcen innerhalb des IT-Unternehmens.
Dienst A ist ein Entitätsdienst mit einer Dienstarchitektur, die in den letzten Jahren gewachsen ist. Als Ergebnis eines Projekts zur Neugestaltung des gesamten Servicebestands werden Sie gebeten, die Servicearchitektur von Service A zu überarbeiten, um die von den Komponenten B, C und D bereitgestellte Logik in drei verschiedene Utility-Services aufzuteilen, ohne das Verhalten von Service A in Bezug auf Service Consumer A zu unterbrechen.
Welche Schritte können unternommen werden, um diese Anforderungen zu erfüllen?

FRAGE 20
Siehe Exhibit.

Dienst A sendet eine Nachricht an Dienst B (1). Nachdem der Dienst B den Inhalt der Nachricht in die Datenbank A (2) geschrieben hat, sendet er eine Antwortnachricht zurück an den Dienst A (3). Dienst A sendet dann eine Nachricht an Dienst C (4). Nach Erhalt dieser Nachricht sendet der Dienst C eine Nachricht an den Dienst D (5), der den Inhalt der Nachricht in die Datenbank B (6) schreibt und eine Antwortnachricht an den Dienst C (7) zurückschickt.
Service A und Service D befinden sich im Service-Inventar A. Service B und Service C befinden sich im Service-Inventar B.
Sie erfahren, dass in dieser Servicekompositionsarchitektur alle vier Dienste rechnungsbezogene Daten im XML-Format austauschen. Die Dienste in Service Inventory A sind jedoch so standardisiert, dass sie ein anderes XML-Schema für Rechnungsdaten verwenden als die Dienste in Service Inventory B. Außerdem kann Datenbank A nur Daten im CSV-Format (Comma Separated Value) und daher keine XML-formatierten Daten akzeptieren. Datenbank B akzeptiert nur XML-formatierte Daten. Es handelt sich jedoch um eine Legacy-Datenbank, die ein proprietäres XML-Schema zur Darstellung von Rechnungsdaten verwendet, das sich von dem XML-Schema unterscheidet, das von den Services in Service-Inventarisierung A oder Service-Inventarisierung B verwendet wird.
Welche Maßnahmen können ergriffen werden, um den geplanten Datenaustausch zwischen diesen vier Diensten zu ermöglichen?

FRAGE 21
Siehe Exhibit.

Die Dienste A, B und C sind nicht-agnostische Aufgabendienste. Dienst A und Dienst B verwenden die gleiche gemeinsame Zustandsdatenbank, um ihre Zustandsdaten zur Laufzeit zu verschieben.
Eine Bewertung der drei Dienste zeigt, dass jeder von ihnen einige agnostische Logik enthält, die nicht zur Wiederverwendung zur Verfügung gestellt werden kann, weil sie mit nicht-agnostischer Logik gebündelt ist.
Bei der Bewertung wird außerdem festgestellt, dass die Remote-Kommunikation, die für die Interaktion von Dienst A und Dienst B mit der gemeinsamen Zustandsdatenbank erforderlich ist, zu einer unangemessenen Verringerung der Laufzeitleistung führt, da sich Dienst A, Dienst B und die gemeinsame Zustandsdatenbank jeweils in räumlich getrennten Umgebungen befinden.
Wie kann diese Architektur durch die Anwendung des Orchestrierungsmusters verbessert werden?

FRAGE 22

Bei den Diensten Client und Vendor handelt es sich um agnostische Dienste, die beide derzeit Teil mehrerer Dienstkompositionen sind. Infolgedessen sind diese Dienste manchmal dem gleichzeitigen Zugriff durch mehrere Dienstnutzer ausgesetzt.
Der Client-Dienst bietet in erster Linie Datenzugriffslogik für eine Kundendatenbank, koordiniert aber auch mit anderen Diensten, um die Kreditwürdigkeit eines Kunden zu ermitteln. Der Vendor-Dienst bietet eine gewisse Datenzugriffslogik, kann aber auch verschiedene dynamische Berichte auf der Grundlage spezieller Geschäftsanforderungen erstellen.
Nach der Überprüfung historischer Statistiken über die Laufzeitaktivität der beiden Dienste wird festgestellt, dass der Client-Dienst eine ständig wachsende Anzahl von Dienstnutzern bedient. Es kommt regelmäßig zu Zeitüberschreitungen, was wiederum die Aufrufrate erhöht, da die Servicekunden ihre Anfragen erneut versuchen. Der Vendor-Dienst hat gelegentlich Schwierigkeiten, seine Service-Level-Vereinbarung (SLA) einzuhalten, und wenn dies der Fall ist, werden Vertragsstrafen verhängt.
Kürzlich wurde der Verwahrer des Client-Dienstes davon in Kenntnis gesetzt, dass der Client-Dienst neuen Dienstleistungsnehmern außerhalb seines Dienstleistungsbestandes zur Verfügung gestellt wird. Der Kundendienst wird jedem Kunden, der sich über das Internet mit dem Dienst verbindet, kostenlose Kreditwürdigkeitsprüfungen zur Verfügung stellen. Der Dienst des Anbieters bleibt intern im Dienstbestand und wird nicht für den externen Zugriff freigegeben.
Welche der folgenden Aussagen beschreibt eine Lösung, die diese Probleme und Anforderungen berücksichtigt?

FRAGE 23

Die in der Abbildung dargestellte Architektur für Dienst A zeigt, wie die Kernlogik von Dienst A im Laufe der Zeit erweitert wurde, um eine Verbindung zu einer Datenbank und einem proprietären Altsystem (1) herzustellen und zwei separate Dienstverträge (2) zu unterstützen, auf die verschiedene Dienstnutzer zugreifen.
Die Dienstverträge sind vollständig von der Dienstlogik entkoppelt. Die Servicelogik ist daher an die Serviceverträge und an die zugrunde liegenden Implementierungsressourcen (die Datenbank und das Legacy-System) gekoppelt.
Dienst A hat derzeit drei Servicekunden. Dienstkonsument A und Dienstkonsument B greifen auf die beiden Dienstverträge von Dienst A zu (3, 4). Service Consumer C umgeht die Serviceverträge und greift direkt auf die Servicelogik zu (5).
Ihnen wurde mitgeteilt, dass die Datenbank und das Altsystem, die derzeit von Dienst A verwendet werden, durch andere Produkte ersetzt werden sollen. Die beiden Serviceverträge sind vollständig von der Kerndienstlogik entkoppelt, aber es besteht immer noch die Sorge, dass di