Advantages of using an EventBus in vert.x

[Per Weinberger]

Hi,

How would I do an executive summary of the advantages of using an events to pass information along different modules (verticals) within the same process (localConsumer)? This is in contrast with just calling functions defined in different modules.

My bullet points would be:

• Decouples the different components. Can add a new subscriber without changing the publisher.
  
• Doesn't bock operating system threads
• API becomes clearer

Are there any other good reasons compared to just calling functions?

Cheers,

Per

 

[ad...@cs.miami.edu]

Hi,

Within the same verticle, I almost never use the eventbus.  I think it adds complexity that is not necessary, but it is a design opinion, not a rule (of course)

Decouples the different components.
>>  A good OO api can do the same

Doesn't bock operating system threads

>> this has little to do with the eventbus and more to do with the event-loop, I think

>>API becomes clearer
I doubt that would ever be the case  :)

No, if you want a design that might span several JVMs in the future, then using the EB is a great design.

Best,

-Adam

[Per Weinberger]

Hi,

> Within the same verticle, I almost never use the eventbus. 

The events isn't used within the same verticle.

But anyways, I'm looking for advantages, not disadvantages or alternatives.

Cheers,

Per

[ad...@cs.miami.edu]

Hi,

You are right, I actually meant to say within the same JVM.  As such, if I am going to use one JVM, I typically only use on verticle, but may deploy N instances of that verticle.  There may be benefits if having multiple verticles in the same JVM from a design perspective... future scale is one such reason, if ever need more than one JVM spanning multiple servers  :)

Best,

-Ada,

[Arnaud Estève]

As such, if I am going to use one JVM, I typically only use on verticle, but may deploy N instances of that verticle.  There may be benefits if having multiple verticles in the same JVM from a design perspective... future scale is one such reason, if ever need more than one JVM spanning multiple servers  :)

This is my rule of thumb.

When I first design my application I ask myself that question : are these two classes always gonna be tight (i.e. "it's the same service", i.e. "both classes have the same release cycle, the same scalability needs, etc."

If the answer is "yes", then I go with two classes, communicating in an "OO" way.

If the answer is "no". Here are the main reasons leading me to think "these are separated (micro-)services" :

- they have different business purposes (handling HTTP traffic vs. sending emails for instance)

- they are losely-coupled

- they have different release cycle (one could be released twice a day, the other one once a month)

- they have different scalability needs (handling HTTP traffic means high scalability, sending an email once a day doesn't require many event-loops)

- one service could be targeted in different ways (from my service #1 obviously, from an admin's browser, from a REST API, etc.)

- they have different "technical needs" (high-availability for one, not for the other, etc.)

Then I tell myself : "Maybe not today, but in a near future, both services will run in separated JVM". And then, I expose service #2's API through the event-bus (either by writing my own message protocol, or by using Vertx's service proxy).

For me this is the main advantage of the event-bus : having the flexibility to deploy services :

- same JVM, different JVM

- same server, different servers

- use 8 evebt-loops vs. use only 1 event-loop.

- shutdown one service, while the other one will still be running for other clients.

Hope this helps.

[javadevmtl]

You can also follow the vertx service proxy pattern. Which bassically you start with OO model and can expose over event buss if needed.

http://vertx.io/docs/vertx-service-proxy/java/

[javadevmtl]

So bassically you define your service with an interface and also provide an implementation...

And when ever you are ready you just anotate it and voila...

[Nicolas Le Bas]

Hi Per,

There are two aspects to your question:
- the advantages of event-based message-driven programming, compared to
traditional function calls: I find those are best summarized in the
reactive manifesto (http://www.reactivemanifesto.org/)
- the advantages of an event bus as opposed to remote
procedure/SOAP/REST calls: it's a bit like the distributed version of
the above. Mostly it integrates better with a message-driven programming
infrastructure, and extends the Reactive benefits from the single-node
resources (CPU, Disk...) to the networking resources (sockets, ports,
...) of your architecture.

Hope this helps,
Nick

On 2017-06-22 15:39, Per Weinberger wrote:
> Hi,
>
> How would I do an executive summary of the advantages of using an events
> to pass information along different modules (verticals) within the same
> process (localConsumer)? This is in contrast with just calling functions
> defined in different modules.
>
> My bullet points would be:
>

> * Decouples the different components. Can add a new subscriber without
> changing the publisher.
> * Doesn't bock operating system threads
> * API becomes clearer

>
>
> Are there any other good reasons compared to just calling functions?
>
> Cheers,
> Per
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to vertx+un...@googlegroups.com
> <mailto:vertx+un...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/vertx.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/vertx/8f7e5eb2-ed65-4620-b555-d82d17d61ef6%40googlegroups.com
> <https://groups.google.com/d/msgid/vertx/8f7e5eb2-ed65-4620-b555-d82d17d61ef6%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.