I looked a bit at the initial code yesterday. I think it’d be good to discuss some basic ideas while we’re still in early stage.
Definitely!
As far as I can see, ConnectorClient is the main abstraction that represent the entry point to our system (both southbound and northbound). It’s an API against which folks should write services and adapters. This looks good so far, we can refine it as we go and see what’s missing.
This is only true for the current code base. However, I do not think that the client component should be the driving factor for Hono's external API (also see my comment below).
The one question I have is how did you envision to have multiple implementations of this API and people deploying the one they are interested in? Should we have some kind of discovery mechanism?
I think we should implement a service component exposing an AMQP 1.0 based interface that serves as a facade to the underlying (and exchangable) messaging infrastructure. That could be (as a starting point) ActiveMQ or RabbitMQ (important for Bosch) but I would also like to see Kafka being employed for at least the upstream Telemetry traffic. Clients can then use any AMQP 1.0 client component they see fit but we can also provide a client particularly designed to be used with Hono if that is feasible.
During deployment you can then select and configure the particular messaging provider(s) you want to use for your Hono instance. Does that make sense to you?
Also, I don’t see any support for protocols adapters yet. I assume they would run like a separate services, listening for messages and calling the api to send them further up the stack. Is that right?
That is correct. I see them as separate components/services running (and scaling) independently from the Hono processes. Communication between Protocol Adapters and Hono should then be AMQP 1.0 based.
One more idea we can consider is to provide a protocol API based on AMQP 1.0, where we don’t specify library API, but the message formats that are exchanged with the system. This would give us some additional benefits, like easy support for different languages, security, etc.
This is what we should definitely do! I would like to see our external interface being defined by means of AMQP 1.0 and message formats/exchanges.
Some good resources on this topic
It’s great to have finally started moving things forward on this. I’m looking forward to hear your thoughts on the topics above.
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/hono-dev
