Hi,
the TMF688 Event API is a resource based API like all other API's. It is a generic wrapper for Event (streaming) plattform supporting the PUB/SUB pattern.
The Interface ist currently defined as a REST Interface. (/event OP: POST, GET ,PATCH, DELETE, /hub POST, DELETE CallBack POST for Notifications).
Because of the simplicity of the API description by swagger/OAS.
If your Event platform (HUB) implementation supports the PUB/SUB pattern, then you can use other IF protocols than REST e.g. MQTT,.
For the future it is planed to define for the Event API additional IF protocols by a meta language e.g. AsynchAPI 2.0.
But keep in mind the important usage of the event API is not the definition of an Interface but the usage of the different resources (Topic/Evnet/Hub) to support the Pub/Sub pattern for Event notifications. (@ sourcing & storing & notification pattern (Martin Fowler)).
KR Thomas
------------------------------
Thomas Braun
Deutsche Telekom AG
------------------------------
Original Message:
Sent: Jun 17, 2021 05:57
From: Anu Aulakh
Subject: TMF 688 logic
Hi All,
We have similar questions here at Telstra.
We are looking to adopt TMF688 to broadcast event notifications from multiple domains (in response to TMF6xx API requests) to multiple consumers.
The TMF688 user guide release 4.0 implies that the HTTP/REST operations are a wrapper around the message broker technology. In this situation, the event management platform still needs to translate from REST/HTTP to the messaging protocol. The message producer and subscriber (consumer) may not be able to completely leverage all the benefits of the queues/topic as they are not directly binding themselves to the messaging technology (what ever it may be, kafka, rabbitmq, jms).
Is TMF planning to update the TMF688 user guide with a standard for API operations in a messaging protocol (non HTTP/REST) format?
Thanks,
Anu
------------------------------
Anu Aulakh
Telstra Corporation
Original Message:
Sent: Jun 17, 2021 05:25
From: David Whitfield
Subject: TMF 688 logic
Hi All,
We are also looking to use 688 in our implementation and are a bit confused.
The user guide seems to suggest that such an implementation can be satisfied by technology such as Kafka or RabbitMQ.
The diagram seems to suggest that you can use the schema registry of the determined product and then expose the topcis to the producers and consumers that live within your application eco system.
What i find strange is that you would have to also have an database alongside something like kafka to facilitate event streaming. This will mean the event is being stored twice.
For this reason we are considering using the TMF688 data model but not implementing the API endpoints.
It would be fantastic to get some thoughts on this
------------------------------
David Whitfield
TalkTalk Group
Original Message:
Sent: Jun 02, 2021 08:25
From: Frederic Thise
Subject: TMF 688 logic
Hi,
I'm investigating TMF 688 and finished reading the current version of the API reference documentation. The API and data model is quite clearly described but nearly nothing is said on how it should behave thus I would like to clarify some points with you.
Let's assume for the sake of example that the event bus is a JMS implementation with which I am very familiar.
As I see it:
- TMF 688 application can be seen as a TMF wrapper around the Event Bus
- In a cloud based environment, multiple instances of TMF688 application may run in // on the same event bus.
This is how I understand how things will happen before and behind the scenes:
- An event producer application will create a topic using POST /topic (if it does not exist yet). The topic details will be stored in a database and trigger the creation of a topic/queue at JMS level. A JMS consumer will be created on the topic to receive the events.
- Event consumer applications will register to the topic using POST /topic/{topicId}/hub. The listeners details will be stored in the database attached to the topic.
- The event producer application will send events when needed using POST/topic/{topicId}/event. This will use a JMS producer to post the event on the JMS topic/queue. The events may be stored in the database attached to the topic (see last section).
- The JMS consumer will receive the events, read the database to retrieve the list of listeners and send the events to each listener (if needed depending on the query part) using POST /listener/listenToXXX TMF REST call (similar to the one used in the classic TMF 630 Notification).
I'm considering using JMS queues instead of topics because multiple instances of TMF688 can run. If JMS topics were used, each event would be delivered to the corresponding consumer in each instance and each consumer would send the event to all registered listeners ending in the event being sent multiple times to the same listener (once per TMF 688 instance).
According to the documentation, the presence of GET operations on /topic/{topicId}/event suggests that the events can/should be stored in the database as well and thus TMF 688 could support pull in addition to the default push way of accessing events (event bus implementations could use internal storage as well but usually events are stored only until delivered to all consumers).
Am I correct in my understanding?
Best regards,
------------------------------
Frederic Thise
Proximus SA
------------------------------