Vert.x vs JEE App Servers

[Steven mccarthy]

Is Vert.x designed as a complete replacement for traditional JEE App Servers like JBoss and Weblogic ?

If it isn't designed as a replacement, how does it fit in to this ecosystem ?

Thanks.

[bytor99999]

Vert.x does NOT implement JEE. So a replacement for an App Server would have to provide JEE APIs or very similar. JEE is a high level specification. So not really even closely related to Vert.x

Vert.x is low level. Now you could, in theory, if you want pain and punishment create an App Server JEE Implementation that sits way on top of Vert.x

It is like comparing the Collections API to the Play Framework. They are completely unrelated. Not saying that you wouldn't use Collections in a Play application, but you can't compare them or say one is a replacement for the other. Exactly the same way you can't compare or say Vert.x and JEE are related or a replacement.

Hope that helps.

Mark

[bytor99999]

Wait. I am sorry, I thought we already completely went over this in the JSP thread you created. And thought you understood after all the replies. Vert.x is LOW LEVEL. It doesn't force you into any particular type of application.

Mark

[Jez P]

I think you should see vert.x more as a platform. On this platform you could build a technology aimed at competing with or replacing JEE app servers. Equally you might build just those elements of a stack you need for your particular use-case.

For example, the yoke module turns it into a convenient dynamic content web server, into which you can embed business logic, and connectivity to other systems, so you could if you wanted replace a JEE app server with it. Whether it's worthwhile doing so kind of depends on your own use case, scalability requirements etc. However, that is just one use for vert.x. You could use it as essentially an actor infrastructure within another application, for example.

As Mark says, it's at a lower level than the app server. Like all platforms, it's what you choose to make of it.

[Michael Bischoff]

Hi,
despite all the differences, there are some similarities, such as providing a scalable platform for applications.

I am currently porting a small application from Java EE 6 to vertx as a pilot.
The application uses CDI, JPA, JTA, JMS. I'm looking to replace JMS by the vert.x eventbus (need to spend some thoughts on detection of lost messages), which would
make JTA obsolete as well in my case.
I'm currently fighting to get JPA working (started with Hibernate, now trying EclipseLink). I don't yet got the weaving to work, and also have some issues with usertypes.
I hope after those obstacles are overcome, I will get a very lightweight and fast platform, providing a portion of the Java EE API.

Best regards,
   Michael

[Steven mccarthy]

Yes, they are both similar in that their purpose is to run applications - that can not be argued.

[bytor99999]

On Sunday, October 13, 2013 3:27:26 PM UTC-7, Steven mccarthy wrote:

Yes, they are both similar in that their purpose is to run applications - that can not be argued.

Just like then you say Java JVM's purpose is to run applications. or OSX's purpose is to run applications, or Windows purpose is to run applications, or App Launcher's purpose it to run application, but I wouldn't compare any of them to Vert.x or JEE. They are just different granularities OS to Platform to Framework to API to Server to Tool.

You are still trying to compare Apples to Oranges and it just doesn't work.

As a matter of fact " I'm looking to replace JMS by the vert.x eventbus"

That statement then would make you say OH then Vert.x is built to replace JMS. NO it isn't. You can use the Eventbus as a way to send asynchronous messages from a sender to a receiver via point to point or publish subscribe, which is similar to JMS, so then similar but still at different levels. And one of the many choices of what you can use Vert.x for.

Mark

[Tim Fox]

Cool, if you get JPA/other JavaEE stuff working would be great to have
this in the form of modules so others can benefit too. Integration with
JavaEE is going to be important for some Vert.x users.

> --
> 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.
> For more options, visit https://groups.google.com/groups/opt_out.

[Michael Bischoff]

Hi,
@Mark: I'm well aware of the differences of JMS and the eventbus ;-)  and among the reasons I'm doing this exercise is also to get a direct asynchronous fast communication channel from a UI running in some browser into the backend.

@Tim: I'm still in early stages of experiments, but once it's stable I will provide this is modular form.

This is my current status:
- my current setup components are vert.x 2.0.2-final, weld-se 2.1.0.CR1, Eclipselink 2.5.1, with a Postgresql 9.2 database.
- I've just managed to read and write first rows
- user types (to persist jodatime fields) work
- weaving is not yet working (so all relationships fall back to eager loading)
- entity listeners are working if I hack some JNDI provider (Eclipselink wants to look up "java:comp/BeanManager" as entity listeners are CDI-enabled since JPA 2.1)
- I've put a NetServer and HttpServer into one Verticle (initial module), and this deploys 4 instances of worker verticles (another module, with multithreaded setting) running the JPA queries.

Next step is to get the weaving operable, then to clean up the code.
I'll keep you updated.

Best regards,
   Michael

[bytor99999]

On Monday, October 14, 2013 2:24:44 PM UTC-7, Michael Bischoff wrote:

Hi,
@Mark: I'm well aware of the differences of JMS and the eventbus ;-)  and among the reasons I'm doing this exercise is also to get a direct asynchronous fast communication channel from a UI running in some browser into the backend.

Sorry, I was just using it as a good example to the Original Poster, that the comparison he is trying to make just isn't the way to think about Vert.x 

You can, and in my opinion should, use Vert.x's eventBus instead of JMS. For instance, we got rid of RabbitMQ for part of our application, specifically because it was one less cog, and easier to code to eventBus send and receiving than we had with RabbitMQ and Spring Integration.

Mark

[Josh Lowery]

Michael, I'm very interested in this approach. What's your status?