Plattform Kommunikationsrichtlinie - Versionsgeschichte

FKorb: /* Kommandos */

2018-01-14T16:35:54Z

‎Kommandos

FKorb: /* Kommandos */

2018-01-14T16:35:33Z

‎Kommandos

FKorb: /* Ereignisse */

2018-01-14T16:32:48Z

‎Ereignisse

FKorb: /* Header */

2017-09-07T12:06:11Z

‎Header

FKorb: /* Header */

2017-08-29T12:17:44Z

‎Header

FKorb: /* Header */

2017-08-29T12:17:24Z

‎Header

FKorb: /* Header */

2017-08-29T12:16:54Z

‎Header

FKorb: /* Header */

2017-08-29T12:16:27Z

‎Header

FKorb: /* Header */

2017-08-29T12:16:11Z

‎Header

FKorb: /* Anforderungen */

2017-08-29T12:13:42Z

‎Anforderungen

@@ Zeile 99: / Zeile 99: @@
 ===Kommandos===
-Um einen Dienst zu steuern, werden in der oK-Kommunikation Kommandos mit optionalen Parametern verwendet.
+Um einen Dienst zu steuern, werden in der oK-Kommunikation Kommandos mit Parametern verwendet.
 Die Kommandos werden per http-POST an den jeweiligen Dienst versendet und dort ausgeführt.

@@ Zeile 99: / Zeile 99: @@
 ===Kommandos===
-Ereignisse werden in der oK-Kommunikation als [https://de.wikipedia.org/wiki/Beobachter_%28Entwurfsmuster%29 Observer-Entwurfsmuster] realisiert.
+Um einen Dienst zu steuern, werden in der oK-Kommunikation Kommandos mit optionalen Parametern verwendet.
-Das Kommunikationsmuster für die Ereignisbehandlung besteht aus den folgenden drei Schritten:
+Die Kommandos werden per http-POST an den jeweiligen Dienst versendet und dort ausgeführt.
+Welche Kommandos und Parameter zur Verfügung stehen, ist abhängig vom jeweiligen Dienst.
 ==CIM-Nachricht==

@@ Zeile 97: / Zeile 97: @@
 ====Heartbeat====
 Als sogenannter [https://de.wikipedia.org/wiki/Heartbeat_(Informatik) Heartbeat] wird ein Mechanismus bei der Ereignisbehandlung bezeichnet, der es einem Veröffentlicher (Publisher) ermöglicht zu prüfen, ob ein registrierter Beobachter (Subscriber) noch aktiv ist. Ist diese nicht der Fall, hat der Veröffentlicher (Publisher) die Möglichkeit diesen selbständig abzumelden.
 ==CIM-Nachricht==

@@ Zeile 151: / Zeile 151: @@
 |correlation-id
 |CorrelationID
+|Eindeutige Kennung der Prozess auslösenden Abfragenachricht. Generiert vom Empfänger dieser Nachricht. (nur bei asynchroner Kommunikation)
 |UUID
 |}
 ===Payload===

@@ Zeile 117: / Zeile 117: @@
 |Verb
+|
-|get, create, change, cancel, close, execute, reply
+|get, create, change, cancel, close, delete, execute, reply
 |-
 |noun

@@ Zeile 121: / Zeile 121: @@
 |noun
 |Noun
+|
 |-
 |revision

@@ Zeile 106: / Zeile 106: @@
 Der Nachrichtenkopf (Header) enthält Informationen (Meta-Daten), die für die Weiterleitung und Verarbeitung der jeweiligen Nachricht notwendig sind. Der Aufbau erfolgt gemäß des CIM-Header-Aufbaus (siehe [http://www.iec.ch DIN EN 61968-100]), unabhängig vom konkreten Format des Nachrichteninhalts (Payload).
 verwendete Felder in oK:
 {| class="wikitable sortable"

@@ Zeile 108: / Zeile 108: @@
 <div style="background:#d0d0d0;border-color:#000000;border-radius:5px;border-style:solid;border-width:1px;margin:16px;padding:10px">
 verwendete Felder in oK:
-*Verb (get, create, change, cancel, close, execute, reply)
+{| class="wikitable sortable"
-*Noun
+|-class="hintergrundfarbe6"
-*(Revision)
+!Attribut
-*Timestamp
+!CIM-Attribut
-*Source
+!Beschreibung
-*(AckRequired)
+!Definition
-*User
+|-
-**UserID
+|verb
-*MessageID => UUID
+|Verb
-*CorrelationID => UUID
-*Property
+|get, create, change, cancel, close, execute, reply
-**Name:PayloadVersion
+|-
-**Value:{{CIM-VERSION}}
+|noun
-</div>
+|Noun
 ===Payload===

@@ Zeile 1: / Zeile 1: @@
 ==Anforderungen==
-{{Information|text=Für den Datenaustausch in oK gelten die folgenden Regeln:
+{{Information|text=Für den Datenaustausch innerhalb der oK-Plattform gelten die folgenden Regeln:
-*Es werden ausschließlich CIM-Nachrichten verwendet (der Payload ist hiervon nicht betroffen, muss also nicht zwangsläufig einem CIM-Modell entsprechen)
+*Für die Kommunikation werden ausschließlich CIM-Nachrichten verwendet (der Payload ist hiervon nicht betroffen, muss also nicht zwangsläufig einem CIM-Modell entsprechen).
-*Es wird das REST-Paradigma eingesetzt
+*Für den Datenaustausch wird das REST-Paradigma eingesetzt.
-*Die Kommunikation (innerhalb der oK-Welt) darf nicht abhängig von einer speziellen Messaging-Middleware (z.B. ESB) sein (kein Vendor-Lock-In).<br/>Daraus folgt, dass im der Messaging-Middleware, außer der Nachrichtenweiterleitung, des Routings und einer "Service Disvcovery" keinerlei Funktionalität implementiert sein darf. Insbesondere darf hier kein Mapping zwischen verschiedenen Nachrichtenformaten oder Versionen stattfinden.
+*Die Kommunikation (innerhalb der oK-Plattform) darf nicht abhängig von einer speziellen Messaging-Middleware (z.B. ESB) sein (kein Vendor-Lock-In).<br/>Daraus folgt, dass im der Messaging-Middleware, außer der Nachrichtenweiterleitung, des Routings und einer "Service Disvcovery" keinerlei Funktionalität implementiert sein darf. Insbesondere darf hier kein Mapping zwischen verschiedenen Nachrichtenformaten oder Versionen stattfinden.
-*oK-Komponenten müssen so konzipiert sein, dass der Anwendungskern klar von der Kommunikationsschnittstelle getretnnt ist und diese somit relativ einfach ausgetauscht werden kann.
+*oK-Komponenten müssen so konzipiert sein, dass der Anwendungskern klar von der Kommunikationsschnittstelle getrennt ist und diese somit relativ einfach ausgetauscht werden kann.
-*Zentrale oK-Komponenten (Service Module & Platform Module) sollten prinzipiell so gestaltet sein, dass sie mit mehreren unterschiedlichen Nachrichtenformaten und Versionen umgehen können.}}
+*Zentrale oK-Komponenten (z. B. Domänen-Module) sind prinzipiell so zu gestalten, dass sie mit mehreren unterschiedlichen Nachrichtenformaten und Versionen umgehen können.}}
 ==Informationsaustausch==