Develop Reference

Spring Boot Microservice With Configurable Communication Method

Consider this scenario: I have N>2 software components (microservices) that can communicate through two different communication protocols depending on how they are deployed. In other words, I have two deployment scenarios:
The components are to be deployed on the same machine. In this case I don't know if it makes sense to use HTTP to communicate these two components, if I think about performance. I understand that there are more efficient ways to communicate two processes on the same machine using java, such as sockets, RMI, RPC ...
The components are to be deployed on N different machines. In this case, it seems to me that it makes sense for me to use HTTP to communicate these components.
In short, what I want to do is to be able to configure the communication protocol depending on the way I perform the deployment: On a single machine, for example, use RMI, but when I deploy on two machines, use HTTP.
Does anyone know how I can do this using Spring Boot?
Many Thanks!

Fundamental building block of protocols like RMI or HTTP is socket communication. If you are not looking for the comfort of HTTP or RMI, and priority is performance, pure socket communication is your choice.
This will raise other concerns like, deployment difficulties. You should know IP address of both nodes in advance.
Another option, is to go for unix -domain socket for within server communication. For that you have to depend on JunixSocket.
If you want to go another route, check all inter process communication options.
EDIT
As you said in comment "It is simply no longer a question of two components but of many". In that scenario, each component should be a micro-service And should be capable to interact with each other. If that is the choice most scalable protocol are REST/RPC both are using HTTP protocol under the hood. REST is ideal solution for an API to be developed against a data source using CRUD operations. RPC is more lean towards action oriented API. You can find more details to identify the difference in between REST and RPC here.

How I understand this is...
if the components (producer and consumer) are deployed on the same host then use an optimized protocol and if on different hosts then use HTTP(s)
Firstly, there must be a serious driver to go down this route. I take it the driver here is performance. You would like to offer faster performance on local deployment and compartively compromised speeds on distributed deployments. BTW, given that we are in a distributed deployment world (or atleast where we are headed) HTTP will be what will survive. Custom protocols are discouraged.
Anyways... I would say your producer application should be in a self healing / discovery mode. On start-up (or periodically) it could check the health of the "optimized" end-point and decide whether it the optimized receiver is around. The receiver would need to stand behind a load-balancer. If the receiver is not up then go towards HTTP(S) and setup this instance accordingly at runtime.
For the consumer, it would need to keep both the gates (HTTP and optimized) open. It should be ready to handle requests from either channel.
In SpringBoot you can have a healthCheck implmented and switch the emitter on/off depending on the health of optimized end-point. If both end-points are unhealthy then surely the producer cannot emit anything. Apart from this the rest is just normal dependency-injection.

STOMP vs WAMP over Spring-WebSockets

I am currently working on a project that needs to work with WebSockets.
The clients will be the browsers only, so not interested in any message broker feature of these two.
Although I don't think that it would be much a difference, but would be interested if I can get a few comments on STOMP vs WAMP as a subprotocol using Spring-WebSockets.
And I might get a few hints that may help choose one over the other.
Cheers,
EDITED (27-02-2014):
As, programming directly with webSockets is low-level, so its suggested in many places (one the spring documentation) to use some sub-protocol.
Also, the use of a sub-protocol over websocket, is a type of native webSocket security; like you can do a sub-protocol validation.
There are many other sub-protocol that can be used instead of STOMP or WAMP like XMPP, AMQP.
I couldn't find much information related to these and webSockets, most of it is related to message brokers only.

The one reason (obvious) that I should use STOMP over any other sub-protocol, is that I am using spring-webSockets so for STOMP I don't need add any additional library at the server side, for others I would need to.
At the clients there are many JS libraries that I can use like socket.io for STOMP and similar JS for WAMP and others.
Since, my main concern is at the server side: So, STOMP it is.
I will update this post if I find out something new while implementing my solution.

What kind of message formats are usually being exchanged in Message Queueing Systems?

I am trying to understand the basics of Message Queues. I see that there are many implementations available as libraries for MQs (ActiveMQ, RabbitMQ, ZeroMQ etc). Also J2EE enabled servers provide such support I think.
What I fail to understand about the topic, is how are these kind of constructs used by real software. I mean what kind of messages are usually being exchanged? Strings? Binary data?
If I understand correctly one can configure the transport protocol, but what is usually the application data format?
Is it a new way of communication, like e.g. SOAP WS or REST WS or RPC etc where each has a different application msg format?

Message queues usually using for application integration. In enterprise it is usually used to implement ESB, but nowadays there are smaller application systems that utilize similar patterns.
Concerning data being transmitted - usually it is XML messages, but actually depends on applications and MQ software - some of them are able to handle binary messages, some are not.
For example imagine you have two applications which require data interchange. If you integrate them using some kind of messaging software such as ActiveMQ, for example, then it will give you some benefits like routing, fault-tolerance, balancing, etc, out-of-the-box.
You may integrate your applications using MQ directly, but ESBs usually
give you ability to use web services: app just calls ws of ESB and knows nothing about underlying architecture.
Also MQs and ESBs gives you a level of abstraction: you may switch your apps in a system absolutely transparent, as long as data exchange interface is preserved.

MQs are mainly used for interprocess communication, or for inter-thread communication within the same process. They provide an asynchronous communications protocol, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time. Messages placed onto the queue are stored until the recipient retrieves them.
wikipedia can be good intro to topic. http://en.wikipedia.org/wiki/Message_queue#Standards_and_protocols
Also, to understand diff between webservice and mq, read this thread: Message Queue vs. Web Services?

ESBs vs Services

I'm new to Java EE and have been struggling with some basic middleware concepts for several days now and believe I might have just had a breakthrough in my understanding of "how tings work"; a part of this question is a request for confirmation of my findings, and the other part is a legitimate question ;-).
Please confirm/clarify: My understanding of service buses/MOM (message-oriented middleware) is that they are by nature intended to process client requests asynchronously. This, as opposed to the normal request-response cycle, which is synchronous, which is usually implemented by some kind of service. In Java, such a bus/MOM could be something like Apache Camel, and the synchronous service could be something like an EJB(3). So if the client needs a request processed right away, the HttpRequest may go to a web service which then forwards the request on to the correct EJB; that EJB process the message and returns the result to the service, which then returns the HttpResponse to the client. As such, if the client has a request that does not block them and which simply needs to be processed, the web service forwards their HttpRequest on to some endpoint on a service bus and the request is treated like a message and is handled by various processors (filters, transformers, etc.).
So first off, please correct me if I am wrong in stating that an ESB/MOM solution is best suited for handling asynchronous requests, and that EJBs (again, 3.x) are best suited for responding to synchronous requests in real-time; or confirm that I am correct.
In that case, it seems to me that big applications would need both types of backends to handle synchronous (blocking) and asynchronous (non-blocking) client requests alike. So my theory would be to have my backend implemented as follows:
Use a full-blown app server like JBoss or GlassFish
In the app server's web container have two WARs: WebServices.war and ESB.war; which represent the backend "gateway" and service bus respectively
In the app server's business container have all my EJBs
Now, the WebService.war (gateway) can detect whether to relay the request on to the ESB or the EJBs
My second question is: am I way off-base here and have I missed the basic concepts of Middleware 101, or is this a half-way decent approach?
Edit: From the initial responses I already see that I was wrong in two areas: (1) that ESBs and EJBs can in fact be either synchronous or asynchronous, and (2) that, when using MDBs, EJBs can be wired up like an ESB.
So these correction pose some new mental obstacles for me:
When to go with an ESB, vs. when to go with a MDB/EJB solution; and
I really like Apache Camel's Processors API (implementation of EIPs); could I use MDB/EJBs but inside every EJB just use a Camel processor (Filter, WireTap, etc.)?

This is a big question and it deserves a big answer.
ESB's can handle synchronous or asynchronous requests and messages are typically used asynchronously.
However your backend implementation theory is pretty wrong.
JAX WS web services can run straight our of an EJB jar or an EAR and can do it that way in any app server. The EJB can put a message onto a queue or even be asynchronous.
You should not be relaying requests to the ESB but the other way around.
The ESB should be relaying and transforming requests and responses between clients and backends. One of the big ideas with ESB is that if a backend changes the client does not know or care since their contract is with the ESB not the backend.
All this said, if your application is already exposing web services, then you probably don't need an ESB and remember there is no one RIGHT or WRONG way to do something.
I do suggest that you write a more defined question that covers your specific problem, you will probably get a wealth of advice on how to solve it.
UPDATE
You also get message driven EJBs which would indeed let EJB's be chained together in a bus like fashion.
FURTHER UPDATE
So one scenario when I would use an ESB is if I need to expose non standards based services in legacy systems as a SOAP service. However there is more to consider, you should also implement a data dictionary for your organization, this will allow a greater chance that the ESB exposed services can remain the same even if your legacy system is replaced.
So as a concrete example, the organization should define in its data dictionary what a customer entity looks like, the ESB could expose a service to retrieve a customer. The ESB will perform some call on a legacy based system and then transform the result. If in future the backend system storing customers changes, the ESB exposed service can probably remain the same, and just the backend call and transformation needs to be updated.
Now hopefully with that in mind the next bit will make sense. All of this is possible with a "traditional" ESB such as JBoss ESB or Mule ESB BUT it is also possible using EJB + Camel (or other things).
The advantage of the out of the box ESB are the provided connectors, listeners and transformers. However if none of the out of the box features helps you then there is very little difference in the direction that you choose.
An advantage in home growing your ESB would be maintainability, it is much easier to find a resource who knows EJB well and can learn Camel quickly if they need to, than finding a specialized ESB resource or training a resource.
I hope that helped!

As you have noticed, the world of middleware/integration is kind of a mess in definitions and terminology. Let me clarify a bit.
A service is just a concept of "something" that delivers a capability. There are multiple ways to expose a service.
When refering to EJBs below, I mean EJBs except MDB (Message Driven Beans), which implement asychronous messaging.
Synchronously request/reply - where the reply is expected "rather soon" after the request. Usually implemented via Web Services and EJBs (RMI,etc).
As a published message to a number of subscribers that consume the data (typically price-lists are pushed out from a price-master system to various systems needing the information, such as the order system).
As a fire-and-forget message from one application to the other. Typcially, the order system needs to send an order to the invocing system, then the invocing system exposes a service to create invoices.
Conceptually, an ESB, is a soft thing. It's a concept/agreement on how a companys business services should be exposed so that applications across the company can consume/use those services. This could essentially just be a set of contraints "Only request/reply services are allowed using SOAP/WebServices and all messages should conform to the OAGIS XML standard". However, in most cases, the application/server/system environment at most companies are not homogenous. There are COTS products, mainframes with COBOL applications, .NET apps as well as Java EE applications. Therefore a common approach is to use an ESB software suite to implement the service bus in technology, or to construct adapters towards the bus. Apache Camel could be part of an ESB implementation to setup routing, transformation, conversion etc.
One thing that is tightly integrated with ESB is Message Oriented Middleware, which you speak ok. It's typically just a server that implements message queuing. The benefits from MOMs are a few in contrast to just ivoking EJBs/Web Services directly.
If asynchronous patterns (publish/subscribe, fire and forget and async. request/reply, then a relay server that has a high up time and is very stable will make it possible to, overall, have less failed transmissions of business messages.
MOMs, ususally makes it rather easy to implement adapters and an ESB that is very resilient to load peaks, network disturbances and hardware/software failure. Messages are often persistent and are stored to disk before relayed. Also transactions are often available, specifically in JMS compliant implementations. That guarantees that data is not lost on the way.
I hope I did not mess things up more than before. This is my view of this at least.

Server-client Java distributed application

I have to design a distributed application composed by one server (developed in Java) and one or more remote GUI clients (Swing application with windows).
As stated before the clients are Swing GUI application that can connect to the server in order to receive and send data.
The communication is bidirectional (Server <=> Clients).
Data sent over the network is mainly composed by my domain logic objects.
Two brief examples: a client calls the server in order to receive data to populate a table inside a window; the server calls client in order to send data to refresh a specific widget (like a button).
The amount of data transmitted between server and clients and the frequency of the network calls are not particularly high.
Which technology do you suggest me for the server-clients communication?
I've in mind one technology suitable for me but I would like to know your opinions.
Thanks a lot.

The first technology that came to my mind was RMI - suitable if you're communicating between java client and java server. But you may get difficulties if you want do switch the client technology to - say - a webinterface.

I would go with RMI but implement the whole architecture using Spring framework. This way it is independent of technology used and can be switched to other ways of communication (such as HTTP or other ) with almost no coding.
UPDATE: And Spring will allow you to have none of RMI specific code.

I believe sockets should do the trick. They are flexible and not especially hard to code/maintain. Most entry level programmer should also be able to maintain them. They are also fast and adapt to any kind of environment.
Unless, your server is going to be off-site or you expect to have firewall issues. In that case, web services are the way to go since your basic communication happens through port 80.

I would second msparer's suggestion of RMI, except I would just use EJB3 (which uses RMI as the communication protocol). EJB3 are very easy and even if you don't use the other feaures EJB gives you (e.g., security) you can still leverage Container Managed Transactions (CMT). It really does make development easy.
As for the server->client communication, you would probably want to use JMS. Again, using EJB3 this is pretty e3asy to do with annotations. The clients will subscribe to the message service and receive update notifications from the server.
And yes, I am currently working on an application that does this very thing. Unfortunately we are using EJB2.1. Still, it is my opinion that this is where EJBs really shine. Using EJBs in a web app is frequently overkill, but in a distributed client/server app they work very well.

You can try using ICE http://www.zeroc.com for establishing server-client connection.