We Keep Coding

What is the best way to communicate between microservices in vertx, by web client or some middleware?

I have not done much in vert.x microservices, but I ran into the doubt of knowing the best way to communicate with each other miscroservices vert.x, using some middleware or web client, I do not know, or any other way that vert.x allows me.

There's an infinite of possibilities to allow vert.x microservices to communicate between them, each with pros and cons and with more or less relevance depending on the context.
Here is 3 common ways :
1) Using the native vert.x eventBus (
asynchronous logic) : https://vertx.io/docs/vertx-core/java/#event_bus (and you can use the Hazelcast Cluster Manager using the -cluster option when you need to handle communication between different JVM pids : https://vertx.io/docs/vertx-hazelcast/java/ ).
2) Using a messages broker system like Apache Kafka (
sometimes you need persistent message queues with replay mechanisms, which I think is more powerful than the vert.x's event bus, sometimes you need to communicate with multiple languages written microservices and the vert.x event bus is not relevant to do that) or an old fashion JMS compliant system like ActiveMQ, RabbitMQ & cie.
3) Sometimes it's more relevant to expose simple Restful api, so you can use the vertx-web extension to do that : https://vertx.io/docs/vertx-web/java/

Can we create asynchronous REST service with Restlet framework?

I am trying to understand the asynchronous component of Restlet framework[2.3].
From official site
Fully multi-threaded design with per-request Resource instances to reduce thread-safety issues when developing applications.
Supports asynchronous request processing, decoupled from IO operations. Unlike the Servlet API, the Restlet applications don't have a direct control on the outputstream, they only provide output representation to be written by the server connector.
Supports non-blocking NIO modes to decouple the number of connections from the number of threads.
so I don't understand the difference between the first and second sentences. For me the requests are handled by some connector(web container? like Jetty or NIO) and if connector is asynchronous, we're done. And finally I don't understand "non-blocking NIO mode", is NIO the same thing that NIO connector?
Maybe somebody can give an example of an asynchronous server based on Restlet(Official site contains a little information about this topic)?
Thanks.

JAX-RS 2.0 (Resteasy client) for server to server communication

This is a rather generic question but would you use use JAX-RS to communicate between two server services running on potentially two different hosts (leveraging the Resteasy client)?
Or would you stick to the more traditional EJB remote invocation?
I'm a bit worried about the following potential issues:
- maintaining a pool of Http connections - will be per client and not global to the application server
- no optimisation if both services are on the same host (EJB invocations would be local in this case)
- authorisation (credentials): managed by the application itself when configuring the RestClient vs. container managed for EJB
- what else?
Any feedback?
Thanks for your help.

Most implementations of JAX-RS have a client API, so the setup should be easy if you share annotated interfaces between the two projects. Communication may be slower than with other solutions because you have to serialize/deserialize all parameters and responses, usually in formats like XML or JSON. I wouldn't worry to much about optimizing inter-process communication as communicating with localhost is still is way faster than with a remote machine. If you expect to have parts of this API public, REST would be the best option, regardless of performance.
If the communication will only be internal, and you really care about performance, you could use a more specialized framework like Protocol Buffers. JAX-RS is a JavaEE Standard and REST are well established though, which might be more important than performance. For more large, complex, JavaEE based systems, a common solution would be to use messaging and integration frameworks like Apache ActiveMQ and Apache Camel, which also support JAX-WS/JAX-RS frameworks like Apache CXF and should have optimization for inter-process communication. For small applications this seems like overkill though.
I never used EJB so I can't really compare it to other solutions. From what I've heard, the whole EJB approach is way to complex and hasn't been adapted very well in the industry. I also would worry a bit about cross platform compatibility.
I would choose a solution that isn't too complex and easy to setup. One last thing: In my experience, when you expect two application to be running on the same machine so often that you want to optimize it, they probably should have been combined in a single server application in the first place, or maybe one of the servers should have been an optional plugin for the other one.

How to avoid network call when REST client and server are on the same server

I have a web application in which two of the major components are the website (implemented in Groovy and Grails) and a backend RESTful web service (implemented using JAX-RS (Jersey) and Spring). Both of these will be running in Glassfish. The website will make calls to the RESTful web service. In many cases, these components will reside on separate servers, so the website will make calls over the network to the RESTful web service. If, however, I run both applications in the same Glassfish server, are there any optimizations that can be made to avoid the network call? In other words, I'm looking for some equivalent of EJB's remote/local interfaces for REST. Thanks!

Don't sweat the network call. Your traffic will generally never leave the local interface so you won't be consuming any bandwidth. You lose a bit of performance from serialization/deserialization, but you'll need to ask yourself if reducing the impact of this is worth developing a complicated proxy architecture. I think it most cases you'll find the answer to be no.

Not sure you will find any trivial solutions: you could of course add your own additional proxy layer, but I really wouldn't worry about it. Local network I/O (localhost or 127.0.0.1) is so heavily optimized anyway that you really won't notice.
Depending on your implementation Spring does support a number of remoting technologies (an old list is at http://static.springsource.org/spring/docs/2.0.x/reference/remoting.html), but you will find that key to all of these is the network transfer: they wrap it up in a variety of different ways but ultimately almost all turnkey remoting technologies drop into the network at some point in time. You may gain SOME efficiency by not having to use HTTP, but you will probably lose some of the loose coupling you gained by using Jersey.
If you are not too afraid to tightly couple maybe you can put the actual objects you are exposing via Jersey into a Glassfish-wide Spring context and invoke the methods directly: much tighter coupling though, so I'd say stick with the HTTP calls.

Yes, you can avoid a network call if your server and client both reside in the same JVM. You should be able to use Jersey Client API to create your own implementation of Connector to override default HTTP calls and handle request/response. Here is the blog that can get you started - http://www.theotherian.com/2013/08/jersey-2.0-server-side-client-in-memory-connector.html
IMHO, an unnecessary network overhead should be avoided at all cost. Even though this overhead would be only a few milliseconds, but while building features for your web application, you would increase such services call and all these milliseconds will add up to a good amount of latency on your application.

Best Java supported server/client protocol?

I'm in the process of writing a client/server application which should work message based. I would like re-use as much as possible instead of writing another implementation and curious what others are using.
Features the library should offer:
client and server side functionality
should work message based
support multi-threading
should work behind load balancer / firewalls
I did several tests with HTTPCore, but the bottom line is that one has to implement both client and server, only the transport layer would be covered. RMI is not an option either due to the network related requirements.
Any ideas are highly appreciated.
Details
My idea is to implement a client/server wrapper which handles the client communication (including user/password validation) and writes incoming requests to a JMS queue:
#1 User --> Wrapper (Check for user/password) --> JMS --> "Server"
#2 User polls Wrapper which polls JMS
Separate processes will handle the requests and can reply via wrapper to the clients. I'd like to use JMS because:
it handles persistence quite well
load balancing - it's easy to handle peaks by adding additional servers as consumer
JMSTimeToLive comes in handy too
Unfortunately I don't see a way to use JMS on it's own, because clients should only have access to their messages and the setup of different users on JMS side doesn't sound feasible either.

Well, HTTP is probably the best supported in terms of client and server code implementing it - but it may well be completely inappropriate based on your requirements. We'll need to actually see some requirements (or at least a vague idea of what the application is like) before we can really advise you properly.

RMI works nicely for us. There are limitations, such as not being able to call back to the client unless you can connect directly to that computer (does not work if client is behind a firewall). You can also easily wrap your communication in SSL or tunnel it over HTTP which can be wrapped in SSL.
If you do end up using this remember to always set the serial version of a class that is distributed to the client. You can set it to 1L when you create it, or if the client already has the class use serialver.exe to discover the existing class's serial. Otherwise as soon as you change or add a public method or variable compatibility with existing clients will break.
static final long serialVersionUID = 1L
EDIT: Each RMI request that comes into the server gets its own thread. You don't have to handle this yourself.
EDIT: I think some details were added later in the question. You can tunnel RMI over HTTP, then you could use a load balancer with it.
I've recently started playing with Hessian and it shows a lot of promise. It natively uses HTTP which makes it simpler than RMI over HTTP and it's a binary protocol which means it's faster than all the XML-based protocols. It's very easy to get Hessian going. I recently did this by embedding Jetty in our app, configuring the Hessian Servlet and making it implement our API interface. The great thing about Hessian is it's simplicity... nothing like JMS or RMI over HTTP. There are also libraries for Hessian in other languages.

I'd say the best-supported, if not best-implemented, client/server communications package for Java is Sun's RMI (Remote Method Invocation). It's included with the standard Java class library, and gets the job done, even if it's not the fastest option out there. And, of course, it's supported by Sun. I implemented a turn-based gaming framework with it several years ago, and it was quite stable.

It is difficult to make a suggestion based on the information given but possibly the use of TemporaryQueues e.g. dynamically created PTP destinations on a per client basis might fit the problem?
Here is a reasonable overview.

Did you tried RMI or CORBA? With both of them you can distribute your logic and create Sessions

Use Spring....Then pick and choose the protocol.

We're standardizing on Adobe's AMF as we're using Adobe Flex/AIR in the client-tier and Java6/Tomcat6/BlazeDS/Spring-Framework2.5/iBATIS2.3.4/ActiveMQ-JMS5.2 in our middle-tier stack (Oracle 10g back-end).
Because we're standardizing on Flex client-side development, AMF and BlazeDS (now better coupled to Spring thanks to Adobe and SpringSource cooperating on the integration), are the most efficient and convenient means we can employ to interact with the server-side.
We also heavily build on JMS messaging in the data center - BlazeDS enables us to bridge our Flex clients as JMS topic subscribers. That is extremely powerful and effective.
Our Flex .swf and Java .class code is bundled into the same .jar file for deployment. That way the correct version of the client code will be deployed to interact with the corresponding middle-tier java code that will process client service calls (or messaging operations). That has always been a bane of client-server computing - making sure the correct versions of the respective tiers are hooked up to each other. We've effectively solved that age-old problem with our particular approach to packaging and deployment.
All of our client-server interactions work over HTTP/HTTPS ports 80 and 443. Even the server-side messaging push we do with BlazeDS bridged to our ActiveMQ JMS message broker.