Multiple Event Busses

[Marius Bergmann]

Hi,

I wondered whether there is a way of using multiple event busses in one vert.x instance. For example a server-side-only event bus spanning across all database servers and business logic machines and one server-to-client-side bus for exchanging data with the clients. The goal of this would be to eliminate the need for authentication across the server-side-only bus; all client requests are checked by one connecting instance, which would of course need to access both event busses.

I already read through the hazelcast docs and it seems to be possible to define multiple groups in one configuration file, however vert.x seems to access only one of them as _the_ event bus.

Maybe someone has some thought on this?

Marius

[Tim Fox]

Marius-

I'm not sure that I understand what you mean by "multiple event busses".
Do you mean the notion of a logical event bus where one logical event
bus is "isolated" from the other and not able to see messages from the
other.

If so, how is this functionally different from just having a single
event bus and prefixing all addresses on eventbus1 with GUID1 and on
eventbus2 with GUID2, where GUID1 and GUID2 are hard to guess prefixes
(guids)?

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/vertx/-/RxsUW23Sz6sJ.
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.

[Marius Bergmann]

Tim-

You're right. I mean two logical event busses, isolated from each other.

Functionally (given the GUID can not be retrieved) there shall be no difference – I'm just wondering whether it is also possible to create two isolated busses, which would (as far as I could get from the Hazelcast docs) also communicate on different ports.

This way the only way from the "outside" to the business logic/internal event bus would be through the gatekeeper instance managing both event busses (external and internal). The internal event bus port would not have to be exposed to the Internet, being accessible only from the LAN. Otherwise if anyone was successful stealing the internal GUID prefix, he could circumvent the gatekeeper (including auth and logging) and talk directly to the business logic.

Correct me if there's a mistake in my thoughts?

[Tim Fox]

What I don't understand here is why you would want to do what you describe? How is what you describe any more secure than having a GUID prefix?

[Marius Bergmann]

Well, you're probably right. I'm relatively new to distributed systems, so just asking. Something new to learn every day ;).

> To view this discussion on the web, visit https://groups.google.com/d/msg/vertx/-/SZvJlHPSxBEJ.

[Marius Bergmann]

Thank you for your reply btw!

[Daryl Teo]

If you have someone able to execute malicious code on your application server, you have a whole lot more trouble than just stealing GUID codes. =)

Daryl