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.)
Related
We have a number of related Java Spring applications running on our servers. Lets call them App1, App2 & App3. As is standard all these use the common code in our-common-utils.jar
I want these applications(App1, App2 & App3) to broadcast their state to one or more remote listeners. For e.g.
App1: I failed to read file abc.
App2: I am using more than 90% of my heap space etc.
The listener/s of these events will take specific actions such as send emails to support and/or clients based on the notifications received.
The best solution I can think of is to have a NotificationSender JMX enabled(implements NotificationBroadcasterSupport) bean in our-common-utils.jar. This will have a thread consuming from a queue of Notifications and firing off sendNotification() to the listeners for each Notification. This will be done by each of the Apps in our eco system but using common code from common-utils.
Do you see any flaws in this design? Any more efficient ways/frameworks of doing it?
Many Thanks :)
Alternative solution is to use any distributed coordination service zookeeper for example. I used it in my very first micro service project. As I can see you are using spring. Spring cloud provides necessary solutions that you can use in declarative way. I would pay your attention to #FeignClient. It is very simple in use and flexible in spring world.
If I would work on this issue now, I would use spring hystrix based solution. To simplify integration between your java services I would recommend to check service-registration-and-discovery.
Ignore my opinion if spring is not general engine part in your projects (may be you need other vendor solutions, there are a lot of alternatives). I concentrate my attention on spring solutions because spring is not restricted in my projects and I can use anything I wish if it's reasonable.
I'm fairly new to Java and am currently writing a web application using a number of Dropwizard based micro services and Java8 SE. I now want to integrate a Message Queue for Async communication between the services and want to start by using a cloud based queue like Amazon SQS. However I don't want to lock myself into a particular cloud provider so would like the option of easily switching to another provider or using something like RabbitMQ or ActiveMQ later on. So my question is, is there a framework in Java that allows this? For example with Hibernate I can switch between databases with a simple config change, is there an equivalent for Message queues?
I've spent quite a bit of time researching this but haven't been able to find a definitive answer anywhere, so far I've found;
JMS, Which looks a bit like what I'm after but looks to only be available in the Java EE edition and may require and app server? Is that correct?
AMQP, Which looks like a low level protocol for message queue interoperability. There is also Apache Qpid Proton which looks like a pure AMQP message library but all the documentation and examples for Java seem to use the JMS.
All the tutorials I can find for specific MQs (Rabbit, etc) use those Queues specific client libraries.
Obviously I could add my own abstraction layer but don't want to re-invent the wheel and I suspect I'm not the first developer to want to do something like this.
Just as Hibernate or just JDBC for that matter allows you to switch amongst differing Database providers the JMS API allows you to switch amongst message Brokers or message Providers at will without breaking you code provided you are not using any specific vendor extensions in your code.
JMS is just an API, there is no JMS protocol only the API that various vendors implement and provide you a client to use with their messaging provider. You can use the JMS API from your Java 8 code just fine, you just need to pull in the JMS API jar using whatever build management tool you happen to have chosen along with the client jar from the vendor you happen to be using at that time. To see how to grab an Apache licensed version of the JMS API jar see the answer to this question.
From what I can see Amazon does offer a JMS implementation, the documentation here seems to cover it well.
When or if you decide to switch to another messaging product such as ActiveMQ or RabbitMQ there are JMS implementations offered by each that allow you to swap out the client and not need to change any existing code (again provided you aren't using any vendor extensions). If you switch to a messaging solutiuon that offers AMQP 1.0 support than there is a JMS over AMQP 1.0 implementation offered by the Apache Qpid project here.
I think you need to spend some time reading up on the JMS specification and some tutorials to get a handle on what JMS is and how leveraging JMS and JNDI you can create provider agnostic code.
JMS in the java world is one of the most common API for producing/consumming messages over queues. When using JMS you are free to use any JMS provider (activeMQ, rabbitMQ ...), and if do not make any direct call to your provider (only calling the JMS API) you can switch from one to another easily.
In order for the message to travel from a producer tu a consumer you need a broker ( a software that will handle them). Brokers can be hosted on a dedicated servers or embbeded in your application (I would not recommend the second option).
AMQP is a more recent protocol and is wire-level. Some Brokers are able to handle both AMQP and JMS.
Both AMQP and JMS can provide you with decent abstraction. However they both have their limits. On one hand with JMS you may be tempted to use some feature/fine configuration tuning, and then you may become implementation-depend due to a specific set of behaviors. On the other hand with AMPQ given the AMQP version you've choosen (0.9 or 1.0+), you only may be able to select only a few broker because those versions differs heavily and at the moment most broker only supports one of them.
Check your provider carefully if you're looking for JMS 2.0, some - i.e., ActiveMQ - only support JMS 1.1.
We're starting work on a monitoring application that will be providing status for several pieces of hardware. The data will be updated on an Oracle DB by a backend process, this application will have to be developed in Java and deployed on a WebLogic 12c application server stuck behind an Apache HTTPD server.
Since the monitoring will be real-time, we'll be needing almost instant refresh of the data that was added on the database. To achieve this, I've been doing some tests with the following frameworks:
Hibernate as ORM.
Spring 3.0.5.
JSF 2.2 and PrimeFaces 3.5 with PrimeFaces Push (Uses Atmosphere).
My tests were successful and I was able to get something working quite quickly. However, I've noticed that Atmosphere has some potential that is being contained by the PF implementation, also, I don't know if this is the most lightweight solution.
Because of this, I wanted to ask you if you guys had any other approaches for this solution, i.e:
Spring MVC + Atmosphere.
Other MVC + Other Comet/WebSocket framework.
Most of the data shown will be for charts, tables and maps. The biggest limitation will be that everything must be Java compatible, since the application server won't be changed.
To summarize, my question is:
Which alternative options do you suggest for this project based on the requirements and limitations I established?
Let me know if you need additional information.
Spring 4 has good Websockets support, have a look here at the documentation. It makes possible to create a websockets endpoint, and use it in a publish-subscribe model based on the STOMP protocol.
This protocol is a messaging protocol that allows to subscribe to a topic and receive notifications, publish to a topic to all subscribed listeners or send a server push message to a single client.
Currently Websockets might not work for all users due to browser limitations, proxies that are not configured to forward the upgrade headers needed to upgrade from HTTP to Websockets, or network elements that timeout long-lived connections.
Spring 4 provides good support for this via SockJS, which has transparent fallback capabilities (to ajax, iframe) if a Websocket connection cannot be established.
All these things are needed to use Websockets in this day and age, and Spring 4 provides a complete out-of-the-box solution.
Have a look at this blog post to see how lightweight this solution is, specially if used together with Spring Boot.
If it's a frontend intensive application you might to couple Spring 4 with AngularJs, for frontend widget development. But Primefaces is a great solution, if the widgets they provide suit your needs it would spare a lot of work.
I have an application in C++, but it'll need to 'talk' to Java based message-service. In the past we used WebSphere MQ and used their C++ libraries to do the 'talking'.
So I am in search of (ideally) free C++ to Java solution which doesn't hold the whole JVM in memory.
The other option I've looked into is SOAP.
I've looked into Axis2-C but it gives me the whole server implementation, which I don't need.
I've seen talk about gSOAP but saw mixed comments here. And again it seems to be providing me with a whole server.
I could write the code myself - but it goes against my (Java based) belief that excellent free code exists out there.
Thanks!
A'z
There are a couple of points here which don't make sense to me, JMS is a java specific abstraction over a generic messaging API, much the same way that JDBC is a java specific abstraction over a generic database API.
I can't imagine anyone wanting a JDBC driver for a C++ application, they would rather use an ODBC driver.
So if I assume that your objective is to send messages without using Websphere MQ from a C++ application, then I can recommend that you consider the following:
Do you need asynchronous messaging? i.e. store message on queue until message is consumed?
If yes, then web-services will not work for your application, unless you are prepared to host a web-server to receive the responses, and call back to your application.
You haven't mentioned whether the underlying java based message service is going to be JMS or WebServices.
You could consider using ActiveMQ as a messaging provider, it provides an implementation of the JMS API and also implements the STOMP protocol, which has client libraries for a number of languages including C++.
You could leave open your decision for end-point protocols while you try out various options, by implementing an integration layer using something like Mule.
You can quickly develop small integrations on Mule e.g. to accept a Message on ActiveMQ, and post it to a WebService and put the WebService response on a different ActiveMQ response queue. Or vice-versa, accept web-service call and post SOAP onto JMS queue, wait for JMS response and build SOAP response.
There are many ESB-like frameworks which can facilitate these sort of integrations to various degrees :
Mule
ServiceMix
Fuse
Apache Camel
Spring Integration
JBoss ESB
EDIT:
Given the clarification I will refine my answer:
You need a common message broker that is accessible to C++ and Java such as ActiveMQ.
You need a small / lightweight integration layer such as some of those above to accept from ActiveMQ and forward to SonicMQ, and vice-versa.
2.1 From what I know of Sonic, they have an ESB stack that should be able to do this instead of using one of the containers/frameworks mentioned above, but that will open up issues of integration ownership between you and the client.
I found 3 links showing Sonic support for C and C++ :
- http://www.sonicsoftware.com/products/docs/sonicmq_app_server_ds.pdf
- http://www.sonicsoftware.com/developer/documentation/docs/sonicmq_c_v60.pdf
- http://communities.progress.com/pcom/servlet/JiveServlet/download/10809-3-10161/cclients_readme_76.htm (dodgy mime type on this link)
The SonicMQ site seems to indicate that they support C++.
It would appear that this is suitable.
There are C++ libraries for SonicMQ. The main constraint is that you have to be using the same build (ie. STL libraries, etc) that Sonic used to compile the libraries.
http://web.progress.com/en/sonic/sonicmq-clients.html
Of course you asked this question over half a year ago, so this information is probably a bit late. :-)
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.