5.3 Vergleich der beiden Modelle

• Beiden Modellen gemeinsam ist das Vorhandensein von Event-Producern und Event-Consumern als Quellen und Senken von Events.
• Während die Weiterleitung von Events beim Notification Service mittels Event Channels erfolgt, wird eine vergleichbare Rolle bei JMAPI von den Event Dispatchern übernommen.
• Der Notification Service unterscheidet sowohl auf Supplier- wie auch auf Consumer-Seite zwischen Push Model und Pull Model. Es ist auch ein Mischen beider Modelle möglich. Im Gegensatz dazu gibt es beim JMAPI Event Model nur eine Push-Semantik. Die Events werden vom Producer an den Event Dispatcher gesandt, welcher dann die Weiterleitung an die entsprechenden Consumer übernimmt.
• Grundlegend für die Registrierung von Event Consumern für bestimmte Events im Rahmen von JMAPI ist der Event Tree, welcher Events in ein baumartiges Schema einordnet. Der Notification Service kennt keine baumartige Gliederung von Events. Die Registrierung erfolgt mittels der in den Constraints der Filterobjekte angegebenen Event-Typen.
• JMAPI Events sind den strukturierten Events des Notification Service ähnlich. Die VecList-Daten des JMAPI Events können auf die Filterable Body Fields eines Structured Events abgebildet werden.
• Sowohl der Notification Service als auch das JMAPI Event Model bieten die Möglichkeit des Event Filtering. Die JMAPI Filter sind mit Forwarding Filtern des Notification Services vergleichbar. Mapping Filter haben in JMAPI kein Äquivalent.
• Die Konfigurierbarkeit von Quality-of-Service-Parametern beim JMAPI Event Model ist gegenüber der beim Notification Service sehr eingeschränkt. Insbesondere kennt JMAPI keine priorisierten Events. Die Reliability kann bei JMAPI Events grob über die Parameter RetryCount und RetrySleep beeinflußt werden. Eine Expiry Time ist ebenfalls bei beiden Diensten vorhanden. Eine Earliest Delivery Time kann bei JMAPI Events nicht angegeben werden. Ebenso fehlt die Möglichkeit, Policies für die Auslieferung zwischengespeicherter Events festzulegen.