Pub - Sub model on beckn

[ravi-prakash-v]

Can we include a pub-sub model in the beckn protocol specification? i.e Event-driven over the usual message-driven approach.

Each network participant can implement a BAP message queue with topics for search, select, init etc; and BPPs can subscribe to these topics. similarly BPPs can publish their responses on a BPP message queue with topics for on_search, on_select, on_init etc and BAPs can subscribe to them.

Supported technologies could be MQTT, AMQP, Cloud Events.

It would be nice if someone can publish an architecture and reference implementation for such a network.

[gamemaker1]

Hi @core-wg-admin,

I am interested in contributing to this. I could do the following:

1. Create an Async API specification for the Beckn Protocol.
2. Create (or extend the current one) a reference implementation for a pub sub network following the event-driven Beckn Protocol.

I'll keep posting the updates to this thread so everyone can contribute/provide comments.

Thanks,
Vedant

[Vedsaga]

I would love to volunteer in this😇 if I get opportunity...

[Vedsaga]

Hii I am really excited to contribute to this,

I will be able to share architecture digram specially based around AMQP & MQTT

However, I have qurey which is to create pub-sub model based on MQTT it does involve broker and I am gussing is that there can two kind of MQTT model one which is Open MQTT which can be accessed by any BPPs [this will come handy when it comes to implementing or building GIN(Global Inventory Network)] another would be closed MQTT which can created by networks by collectively coming together. So, my question is in case of close MQTT network participant will have to pay for its maintenance however.

So in open MQTT who will be responsible broker (it can one ore more) to maintain the open MQTT?

[venkatramanm]

I imagine it will closed to begin with and be opened when ripe enough. Open broker is most inclusive and useful in the long run.. yes who will maintain, fees etc are valid questions. May be, it could become fees added to your broadband bill at some point. Any thing is possible. Love beckn for opening up these transformational possibilities.

Lets brainstorm more.

[Vedsaga]

yee, surely :D

[venkatramanm]

I can volunteer in this project to crystalize spec, network policy and building the reference implementation.

It is a great initiative.

[gamemaker1]

Hi @Vedsaga @venkatramanm,

I would love to collaborate on you with this :D

I have created a repository (https://github.com/gamemaker1/beckn-async-api-spec) where we can collaborate on the Async API specification for the event-driven version of the Beckn Protocol and invited you as collaborators.

Once we get a draft of the Async API ready, we could proceed to create a reference implementation. Does that sound good?

Looking forward to collaborating with you :D

[Vedsaga]

Sounds Good to me 😇

[sujitrs]

Possible Pub-Sub with current Beckn Protocol. This was done using Solace in Mind. But its costly. Hence i can collaborate to design it with FOSS tech.

Here Producer (A) can be BAP and Consumer (F) be BPP for search
And for on_search reverse.

[Vedsaga]

pub-sub model is only suppose to act as broker that hold on the messages and pass on to the right BPPs and rest of the other job have to done by BPPs themselves?

[gamemaker1]

Hi @sujitrs,

Thanks for taking the time to create and share this architecture diagram, it is quite helpful!

A few questions that I had:

• What if we removed the Beckn Application's call to the API gateway (B) and instead allowed it to directly publish a message to the queue which the Beckn Providers will be subscribed to? The same could go for F - the BA is already subscribed to the topic and can listen continuously for responses.
• Could D be treated as the Beckn Provider - it will receive the request from the action channel and then publish the response on the on_action channel (where action can be search, init, confirm, etc.). I believe @Vedsaga had the same question (Pub - Sub model on beckn #189 (reply in thread))
• Instead of creating topics on the fly, what if we had only a predefined set of topics, i.e., action and on_action (where action can be search, init, confirm, etc.). The BAs will publish requests on the action channel, and the BPs will respond to them on the on_action channel. The BP can use the same context.message_id while responding so the BA knows that the message is in response to its request.

Please let me know your thoughts on the above.

I have also invited you as a collaborator to the https://github.com/gamemaker1/beckn-async-api-spec repository where we are building the spec and implementation. Looking forward to collaborating with you on this :D

[Vedsaga]

* Instead of creating topics on the fly, what if we had only a predefined set of topics, i.e., `action` and `on_action` (where `action` can be `search`, `init`, `confirm`, etc.).

I prefer the idea of having pre define topic because it will enable subscriber to reach out to the exact broker for it's messages instead of query having to going to alot of searches.

[Vedsaga]

idea

Two-more beckn networks share & exchange data on occurrence of an event using pub-sub model

Key Elements in a MQ pub-sub model

1. publisher - one who publish the message
2. principal broker - one who distribute the publisher messages between the event broker
3. event broker - one who is responsible to manage topics of an event
4. topic - used to classify the message
5. subscriber - one who consume messages
6. message - contain the event description

prerequisite(proposal)

1. subscriber identity would be it’s protocol ID which was assign during creation of network which is stored in registery so, that while making query it can bind that query with it's identity so that correct messages can be delivered.
   2. messages should have status (delivered/failed/partially-distributed) so that, in case message was o2m(one to many network) & on first attempt message didn't get deliver to all the subscriber then it can be marked as partially-distributed .
   3. message should have time-out period so, that during that period re-attempt can be performed.
2. message should have defined re-attempt that a distributor will try, if all the attempt is consumed and subscriber don't send with acknowledgement then distributor will mark the message status to failed if in case message type was o2o(one to one network), in case o2m(one to many network) then status will be marked as partially-distributed ; and then acknowledgement will be to the publisher
3. message should have defined type (all/group/binded).

• message with type all will be shared with/accessible by all subscribers of that topic.
• message with type group will be shared with/accessible by only those subscriber who are member of that group.
• message with type binded will be only accessible by subscriber that matching id mentioned in that message.

6. message should only be deleted if message status changes to delivered or message timeout period is over.

diagram

Note: below diagram just only represent distribution of binded messaged.

I have attached the PDF of diagram in case image not clear.

direct-binded-messages-diagarm-white.pdf
direct-binded-messages-diagarm-black.pdf

[gamemaker1]

This is a great implementation architecture, thanks for sharing!

A few questions that I had:

• "A message with type group will be shared with/accessible by only those subscriber who are member of that group": How are groups different from topics?
• "A message with type binded will be only accessible by subscriber that matching id mentioned in that message.": How would you send messages to a particular Beckn Application?
• How would an acknowledgment be sent to the entity in a pub sub implementation?
• How would the status of the message be changed and who would change it?

I think the last two questions would be partly answered if we chose how we want to implement pub-sub, i.e., using Webhooks, Websockets, MQTT, or something else?

Please let me know your thoughts on this.

[Vedsaga]

How are groups different from topics?

I would to like answer this but, I think I have to make diagram to explain the reason for having groups and what is the difference between the topics & groups. Please allow me some time I will answer about that in depth. Because to understand it I think we have deep dive into the type relationship between entities. Reason for having groups is because this way we can have form connection between the networks . Just like how internet work as there are different of network topology which enable data sharing between different computers same way if can have groups then we can allow networks to constantly exchange data with each other. Which will enable grater possibility instead of just mare having discovery base system. I have open discussion on this idea #181. I am still working on that idea.

How would you send messages to a particular Beckn Application?

In PR which you propose in meta data sender have to attach the binding key of that specific receiver. That binding key could be the same key unique key which is currently provided by registery. Now, whenever reader want to check with pub-sub either there is any messages or not for them they have to attach their private key so, that verifier can make sure that it is valid query so, if it is valid then distributor will check the DB and if there is any message for that entity then it will forward those messages to that entity. Now, here we have make sure that whenever message is forwarded it can't interpreted in between. Similar to how SMTP. When a user of Gmail send email to outlook user it only receive by outlook user and not by anyone in between.

* How would an acknowledgment be sent to the entity in a pub sub implementation?

So, each message which is send by sender they will attach their signature that are the one who published it. So, there is something call save which will read the meta data and able to extract the signature of the sender and then it will pass the request to database maintainer to save the message and as soon as sender receive the confirmation it will send the ACK to that signature address. So, what I am trying say is that signature of sender will refer as sender address.

* How would the status of the message be changed and who would change it?

These have to be done by the topic-broker who is responsible to manage topic's events. I want clarify one thing that is Each topic such as Shipment can have multiple events (here event means any message which an entity wants to share with another). For e.g. when there is order for long distance delivery like From Delhi To Chennai a logistic BPP truck can be stop at multiple points. And because it is long distance delivery there could be chance of having multiple logistic BPP involve in this. One logistic BPP for inter city transportation like DELIVERY - India's biggest fulfillment startup & another BPP such as DUNZO - operate at city level for city level delivery. Now, first logistic BPP might want to share data with Buyer BAP, Seller BPP & another Logistic BPP at the same time. Now, for a moment imagine that DELIVERY company truck stop at warehouse which is in Indore. Now, this have to share with all the stakeholder which is involved in the order right? and so DELIVERY company sent the message to the pub-sub which is suppose to distribute the copy of the message with all the stakeholder. Now, what will happen is pub-sub will create copy of the message and then will try to send the message to the all the stakeholder. But due to some reason Seller BPP server is down or for some reason pub-sub is not getting ACK from that them. That means pub-sub can't discard the message from the db either TTL of message is over or till it does not receive ACK from all the stakeholder and so, due to that reason we need to keep track of message status so that when messages are discarded from the DB sender can know exactly what happen with it's messages. Either it is even read by stakeholder or not.

I think the last two questions would be partly answered if we chose how we want to implement pub-sub, i.e., using Webhooks, Websockets, MQTT, or something else?

The above model is similar is to RabbitMQ but, with few enhancement because we are tying to implement it in open environment where multiple independent sever will communicate, as currently RabbitMQ is being used by companies to handle MQ but in close environment.

[gamemaker1]

Hi @Vedsaga @venkatramanm @sujitrs,

I have opened a draft pull request (gamemaker1/beckn-async-api-spec#1) on the Async API specification repo to add the search and on_search channels to the spec. Please do review it and provide your feedback.

Thanks,
Vedant

[AnshulMalik]

Hi @core-wg-admin

If I have understood correctly, we are trying to bring one central dependency of a message broker in this decentralised network.

And I can see few concern if we go this route:

1. This is adding a single point of failure.
2. How are we going to handle the scale?
   2.1 When someone subscribes to a topic, will it get ALL the events? when in reality, it only needs just one.
3. What advantages are we trying to gain with this approach?

[rahul101001000]

Agree with the points @Vedsaga

How do we handle scale?

If at all it needed to be done, it's fairly common to scale message brokers. Do take a look at how it is done with Netflix device management platform and in the AdTech world at AdsDax.

With Beckn as @Vedsaga mentioned, just like there will be multiple regional instances of Beckn gateways, so will there be multiple instances for message brokers.

And yes @AnshulMalik all great questions - that's exactly why we can together try and solve for them. @Vedsaga @gamemaker1 @sujitrs @venkatramanm have good ideas in there to make this work. Once we have a prototype, we can try out a few use cases / test cases and evaluate it. If all good, we could add it to the core spec.

[AnshulMalik]

Beckn is a protocol, not a platform. It adopts a decentralized architecture that obviates the need for creating a centralised platform in order to integrate services from multiple providers simultaneously ensuring privacy and security by design by enabling secure, encrypted iteractions.

This is something I found in the readme. I feel like we are moving away from our goal here, we were trying to make a decentralised system. And additionally, this change would restrict people on ONE pub-sub implementation.

[rahul101001000]

Let me phrase the question in different ways -

1. How would we implement Beckn with AsyncAPI without a message broker?
2. How would we enable this use case in Beckn without pubsub - "Every order placed, with user consent, is viewed by a pool of OCEN providers that see the order, determine credit worthiness, and publish an event viewable by the BAP (and the BPP where purchase is being made) that indicates that they (OCEN provider) are willing to offer an EMI option for that user for that purchase"
3. Why do you say message broker is centralized. Message brokers will be as decentralized as Beckn gateway.

[AnshulMalik]

Hey @rahul101001000

How would we implement Beckn with AsyncAPI without a message broker?

I am assuming that the idea of migrating to AsyncAPI spec came because we don't want to be limited to HTTP, but if there is no other good way of implementing AsyncAPI then it's one and the same thing again no? Earlier it was HTTP that was fixed, now it's the broker protocol that's fixed, we have just changed the fixed constraints to be some other constraints.

How would we enable this use case in Beckn without pubsub?

I am assuming BPP publishes the event on order creation to relevant stakeholders. I can also see security and privacy concerns here if a message is visible to some entity where it shouldn't be and how are we going to achieve this control in broker based architecture?
How do we currently handle this case?

Why do you say message broker is centralized. Message brokers will be as decentralized as Beckn gateway.

Sorry, I am not able to visualize this, Could you help me visualize how would a search and order operation would work with this decentralized broker?

[Vedsaga]

I am assuming BPP publishes the event on order creation to relevant stakeholders.

Not just BPP but, BAP can also be publisher here. Idea is that both BAP & BPP can be publisher as well subscriber at the same time.

I can also see security and privacy concerns here if a message is visible to some entity where it shouldn't be and how are we going to achieve this control in broker based architecture? How do we currently handle this case?

It is a valid concern, however to tackle that we can take inspirational approach which RabbitMQ have it. That is it first classify the message into access type --

1. Fanout(can be access by every subscriber)
2. Binded(can access by only that subscriber who have been refer into that message by publisher)
3. Partial Bindied (message that have publish for a group of networks that means we will have system which will keep trace of groups and group memeber will be assigned with a unique key which they can use to access the group messages)

Why do you say message broker is centralized. Message brokers will be as decentralized as Beckn gateway.
Sorry, I am not able to visualize this, Could you help me visualize how would a search and order operation would work with this decentralized broker?

It will not be completely decentralized because there will be multiple entity who will be responsible to maintain each event-broker however because a event-broker not working 1 network but, for all the network that is why it is not completely centralized. it is a mix of decentralized & centralized system.