Was ist Musterprotokoll

Dienste, die unterschiedliche Kommunikationsprotokolle oder verschiedene Versionen desselben Protokolls verwenden, können keine Daten austauschen. Eine typische Protokollschicht-Schnittstellen mit einer oberen und einer unteren Ebene des Protokolls. In den meisten Designs besteht eine große Abhängigkeit zwischen verschiedenen Ebenen des Protokolls. Dadurch wird die Protokollstapelimplementierung starr und unflexibel. Änderungen in einer Schicht perkolaten häufig zu anderen Layern. Das Protokollschicht-Entwurfsmuster behebt diese Einschränkungen, indem die einzelnen Protokollebenen entkoppelt werden. Die Überbrückungslogik wird eingeführt, um die Kommunikation zwischen verschiedenen Kommunikationsprotokollen zu ermöglichen, indem ein Protokoll zur Laufzeit dynamisch in ein anderes konvertiert wird. Anstatt sich direkt miteinander zu verbinden, stellen Consumerprogramme und -dienste eine Verbindung zu einem Broker her, der eine Überbrückungslogik bereitstellt, die die Protokollkonvertierung durchführt. Die Anwendung dieses Entwurfsmusters erfordert die Auswahl einer Technologiearchitektur, die ein gemeinsames Kommunikationsframework bereitstellt, sodass alle Dienste in einem Inventar über dasselbe Kommunikationsprotokoll miteinander kommunizieren können. Dies hängt davon ab, wie die Dienste innerhalb eines Serviceinventars verwendet werden.

Wenn die Dienste nur Teil von Dienstzusammensetzungen sein werden, die immer ein bestimmtes Kommunikationsprotokoll verwenden (aus Effizienz- und Sicherheitsgründen), können alle Dienste innerhalb dieses Dienstinventars auf einem solchen Kommunikationsprotokoll aufbauen, auch wenn es nicht das am häufigsten verwendete Protokoll ist. Um den Status der Kommunikation (z.B. den aktuellen Protokollbefehl) beizubehalten: en.wikipedia.org/wiki/State_pattern Für einen Protokollstapel fließen Daten (Paket) von oben nach unten in Senderseite und gegenüber in der Empfängerseite, wie unten gezeigt. Bei der Wahl eines Kommunikationsrahmens müssen die Reife, die Skalierbarkeit und die Lizenzkosten berücksichtigt werden, da Gebäudedienste mit einem Protokoll, das in naher Zukunft veraltet sein wird, die Wiederverwendbarkeit solcher Dienste beeinträchtigen und erhebliche Zeit und Anstrengungen erfordern würden, um den Dienst neu zu gestalten. Verschiedene Ebenen des Protokolls sind strukturiert, wie in der Abbildung auf der linken Seite dargestellt. Die Kommunikation zwischen Ebenen erfolgt über Standardschnittstellen, die von der Basisklasse der Protokollschicht definiert werden. Alle Implementierungen der Protokollschicht erben von dieser Klasse. Die erbenden Layerklassen sollten die Standardschnittstellen implementieren. Die Standardschnittstellen lauten: Wie kann ein Dienst Daten mit Verbrauchern austauschen, die unterschiedliche Kommunikationsprotokolle verwenden? Canonical Protocol ist ein Entwurfsmuster, das innerhalb des Entwurfsparadigmas für die Serviceausrichtung angewendet wird, das versucht, Dienste innerhalb eines Dienstinventars[1] interoperabel miteinander zu machen, indem die von den Diensten verwendeten Kommunikationsprotokolle standardisiert werden. Dadurch entfällt die Notwendigkeit, Kommunikationsprotokolle zu überbrücken, wenn Dienste unterschiedliche Kommunikationsprotokolle verwenden. [2] Einer der ausgereiftesten und am weitesten verbreiteten Kommunikationsmechanismen wird vom Webdienst-Framework bereitgestellt. Neben der Wahl eines Kommunikationsframeworks müssen auch die eigentlichen Nachrichtenprotokolle standardisiert werden.

Zum Beispiel, ob Webdienste mithilfe von SOAP über HTTP oder einfach mithilfe von RESTful-Diensten erstellt werden.

Share