I have some doubts regarding Spring Integration :
Can we integrate more than two applications using Spring Integration framework?
Is it point to point intergration or middleware oriented integration?
In client-server architecture If both (client & server) are java based applications, then what should we use for synchronous communication ? means, should we go for Spring Integration or JAX-RPC ? Which one will be faster for synchronous communication ?
Spring Integration is a lightweight integration framework. It does not use or need a central broker (many see that as a benefit).
It is not just point to point; you can configure a many-to-many environment, but no broker is required. You can, of course, use a middleware broker if you wish (e.g. RabbitMQ or JMS).
There are many ways to perform synchronous (request/reply) integration. In Spring Integration, the components usually used for that are called gateways (outbound on the client, inbound on the server).
One of the benefits of this is the application doesn't have to know what technique is being used. With simple configuration changes, you can change the actual protocol used to whatever you want, with zero changes to the application itself.
Many techniques are provided out of the box, including ReST (http), SOAP WebServices, JMS, AMQP, TCP/IP, ...).
It's best not to think of synchronous integration as RPC - it's all about loose coupling using request/response messaging, with the message content being the contract, not the API.
One-way integration is achieved using channel-adapters rather than gateways.
I suggest you take a look at the reference documentation... http://static.springsource.org/spring-integration/reference/html/
Related
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/
I have numerous services distributed on a private network and there is a service which has to broadcast a message to all other services(e.g. the expiration of authentication token). My application is based on java Spring framework and ever since I have started to get acquainted with an architecture that satisfy my condition, I found that it is called Event Driven Architecture and two famous frameworks related to this architecture are AKKA and Reactor. But reading the reactor tutorial (which integrates with spring much better than AKKA) I found that all services including Producer, And Consumer must submit into a Reactor class within the same context. Now I wonder if there is a way of distributing the services on multiple machines.
In one of our recent projects, we have decided to use a message based solution to integrate an existing .Net app to a new JAVA based application. There is a requirement to not use a Application Server. So I am trying to look into some alternative options. Currently we are planning to use ActiveMQ as the JMS provider. Also the Java application needs to interact with an backend database. So, when trying to figure out options, I found that the Spring framework would be quite helpful. It appears that Spring may need some additional components (e.g, Atomikos) to provide transaction support for JMS & JDBC operations.
I am trying to limit the user of additional components as much as possible.
So, Is this the right approach to use ActiveMQ with Spring. If so, can I just use the built-in transaction module available in Spring to support transactions?
Any advice would be very helpful?
Leo
Use WebSphere MQ .NET interface (.NET native or XMS .NET) for sending/receiving messages from your .NET application. At the Java app end use MQ JMS interface. MQ JMS interface supports two phase commit, so you can synchronize your message gets and database updates.
Keep the integration through MQ and WS. More tight coupling may lead to problems and complexity.
I'd go with a messagequeue that has good .NET and Java clients - e.g. RabbitMQ That builds on AMQP. As well as serialization technology that has good cross-language capabilities (Thrift, Protocol-buffers etc.)
What are the important motivations for upgrading from EJB2.0 remoting to Spring remoting using HTTPInvoker?
The one that I found was that in EJB2.0, the client code has to do jndi lookups and on the server side, we need to write extra classes and interfaces(remote,home).
In Spring HTTPInvoker, we just configure the remote EJB bean as a service and we are good to go.
Just wondering if there are other benefits except this one.
If this is the only benefit, how to decide whether to go for web services or HTTPInvoker?
Spring's HTTPInvoker is a very simple RPC-over-HTTP mechanism, using standard java serialization. If that meets your requirements, then by all means use it.
However, it falls a long way short of EJB-style remoting, which as well as being more efficient (HTTP remoting is not very performant), adds facilities such as transactions and security. Both of these can be provided by Spring, but it means additional wiring and configuration.
As far as deciding between HTTPInvoker and proper Web Services, the former is highly proprietary (both ends must be Spring), and tightly couples the client with the server (they have to be serialization-compatible). Proper web-services are standards-compliant and client-agnostic (if done properly).
A little context: I would like to separate the Java application I'm writing into a more or less typical server-client model. I would provide a "server" which takes care of business logic and persistence, but write it in a very service oriented fashion. Any front-end code (GUI) would then call upon the server to provide the functionality in a user friendly fashion.
As I'm writing the application using Spring (and an ORM framework), it would make sense to explore the usual suspects to expose the server functionality, with the usual suspects being RMI, Spring HTTP, Hessian, web services, etc (the Spring natively supported options). These are well well documented, both in reference documentation and on here.
However, for the actual question: are there any less obvious, more exotic options I could consider to use for exposing my server services?
It's important (as always) to get the right balance between ease of use (from a front-end POV), performance and scalability. For example; since I've thought about providing the Spring-BlazeDS integration in the server any way (for Flex/AS3 clients), it dawned on me that BlazeDS provides a Java-native API for calling AMF services.
Any pointers are much appreciated.
I would recommend BlazeDS if you have a Flex front end and Spring HTTP if not. Both eliminate the non-productive work introduced by having to translate XML to objects and back again.
Spring HTTP is especially attractive because you can write POJO Spring service interfaces just as you always do, deferring the choice to expose via HTTP remoting until the end. You keep your options open that way. If you decide that Spring web services work better for you later on, you can keep re-using the same POJO Spring interface.