I am currently evaluating JMS and I don't get what I could use it for.
Currently, I believe this would be a Usecase: I want to create a SalesInvoice PDF and print it when an SalesOrder leaves the Warehouse, so during the Delivery transaction I could send a transactional print request which just begins when the SalesOrder transaction completes successfully.
Now I found out most JMS products are standalone server.
Why would a need a Standalone Server for Message Processing, vs. e.g. some simple inproc processing with Quartz scheduler?
How does it interact with my application?
Isn't it much too slow?
What are Usecases you already implemented successfully?
JMS is an amazingly useful system, but not for every purpose.
It's essentially a high-level framework for sending messages between nodes, with options for discovery, robustness, etc.
One useful use case is when you want a client and a server to talk to one another, but without the client actually having the server's address (E.g., you may have more than one server). The client only needs to know the broker and the queue/topic name, and the server can connect as well.
JMS also adds robustness. For instance, you can configure it so that if the server dies while the client sends messages or the other way around, you can still send messages from the client or poll messages from the server. If you ever tried implementing this directly with sockets - it's a nightmare.
The scenario you describe sounds like a classic J2EE problem, why are you not using a J2EE framework? JMS is often used inside J2EE for communications, but you got all the other benefits.
What ist Java Message Service (JMS) for
JMS is a messaging standard that allows Java EE applications to create, send, receive, and consume messages in a loosely coupled, reliable, and asynchronous way. I'd suggest to read the Java Message Service API Overview for more details.
Why would a need a Standalone Server for Message Processing, vs. e.g. some simple inproc processing with Quartz scheduler?
Sure, in your case, Quartz is an option. But what if the invoice system is a remote system? What if you don't want to wait for the answer? What if the remote system is down when you want to communicate with it? What if the network is not always available? This is where JMS comes in. JMS allows to send a message guaranteed to be delivered and to consume it in a transactional way (sending or consuming a message can be part of a global transaction).
How does it interact with my application?
JMS supports two communication modes: point-to-point and publish/subscribe (if this answers the question).
Isn't it much too slow?
The MOMs I've been working with were blazing fast.
What are Usecases you already implemented successfully?
Used in system such as a reservation application, a banking back-office (processing market data), or more simply to send emails.
See also
EJB Message-Driven Beans
Why would a need a Standalone Server
for Message Processing, vs. e.g. some
simple inproc processing with Quartz
scheduler?
The strength of JMS lies in the fact that you can have multiple producers and multiple consumers for the same queue, and the JMS broker manages the load.
If you have multiple producers but a single consumer, you can use other approaches as well, such as a quartz scheduler and a database table. But as soon as you have multiple consumer, the locking scheme become very hard to design; better go for already approved messaging solution. See these other answers from me for a few more details: Why choosing JMS for asynchronous solution ? and Producer/consumer system using database
The other points are just too vague to be answered.
I've used it on a number of projects. It can help with scalability, decoupling of services, high availability. Here's a description of how I used it on a project several years ago:
http://coders-log.blogspot.com/2008/12/favorite-projects-series-installment-2.html
The description explains what JMS brought to the table for this particular project, but other projects will use messaging systems for a variety of reasons.
Messaging is usually used to interconnect different systems and send requests/commands asynchronously. A common example is a bank client application requesting an approval for a transaction. The server is located in another bank's system. Both systems are connected in an Enterprise Service Bus. The request goes into the messaging bus, which instantly acknowledges the reception of the message. The client can go on with processing. Whenever the server system becomes available, the bus forwards the message to it. Of course there needs to be a second path, for the server to inform the client that the transaction executed successfully or failed. This again can be implemented with JMS.
Please note that the two systems need not to implement JMS. One can use JMS and the other one MSMQ. The bus will take care of the interconnection.
JMS is a message-oriented middleware.
Why would a need a Standalone Server for Message Processing, vs. e.g. some simple inproc processing with Quartz scheduler?
It depends on what other components you may have. I guess. But I don't know anything about Quartz
How does it interact with my application?
You send messages to the broker.
Isn't it much too slow?
Compare to what ?
What are Usecases you already implemented successfully?
I've used JMS to implement a SIP application server, to communicate between the various components.
From the Javadoc:
The Java Message Service (JMS) API provides a common way for Java programs to create, send, receive and read an enterprise messaging system's messages.
In other words, and contrary to every other answer here, JMS is nothing more than an API, which wraps access to third-party Message Brokers, via 'JMS Providers' implemented by the vendor. Those Message Brokers, such as IBM MQ and dozens of others, have the features of reliability, asynchronicity, etc. that have been mentioned in other answers. JMS itself provides exactly none of them. It is to Message Brokers what JDBC is to SQL databases, or JNDI is to LDAP servers (among other things).
I have found a very good explanation of JMS with an example.
That is a simple chat application with JMS queues are used to communicate messages between users and messages stay in the queue if the receiver is offline.
In this example implementation they have used
XSD to generate domain classes.
Eclipse EE as IDE.
JBoss as web/application server.
HTML/JavaScript/JQuery for UI.
Servlet as controller.
MySQL as DB.
The JBoss configuration step for queue is explained nicely
Its available at http://coder2design.com/messaging-service/
Even the downloadable code is also available there.
Related
I am currently testing out JMS queue (first time using JMS) and message driven beans.
I have created a queue to provide other applications with state updates for one of our projects.
Logic is written in native JMS, deployed on a JBOSS7 using the ActiveMQ implementation.
It depends on a selector to deliver the messages to the right client, and while I can just place good faith in my colleagues, preferably I would like to enforce the use of the selector so the clients don't consume messages not meant for them.
So basically I would prefer that no messages are delivered to a client which has not specified a selector.
When I deploy a consumer without any selector it just consumes all messages available on the queue.
Otherwise everything works as expected.
I have looked and haven't been able to find anything I am looking for, maybe it's possible by configuring ActiveMQ itself but I am not really at home in that ecosystem.
So the problem is resolved by using a system I wasn't that aware about and I thought I'd share it here if someone need it:
The JMS clients are on different physical machines so originally the plan was to do manual JNDI remote lookup to access the queue but this caused some problems. Mainly having to write retry logic when the Queue is unavailable.
I threw that plan out the window to opt for a Bridge instead, following the guide found here: http://www.mastertheboss.com/howto/jboss-jms6/configuring-jms-bridge-with-wildfly-10
This has multiple advantages (both the producer system or the client can go down without causing too many problems) but most notably this solves my problem: I can define a selector on the bridge per Client. So the responsibility of choosing who receives which messages is back in my court.
I will have a crack at implementing this.
I'm confronted with a system (Java, OSGI-based, Equinox, Blueprint) that needs to send asynchronous notifications via SOAP messages to a remote system. The system must ensure that the notifications reach the remote system (i.e. it reponses with a confirmation message, WS-ReliableMessaging is not available).
Now I see two Options:
Use the EventAdmin mechanism of OSGI to trigger the notifications, implement my own handler which persists the notification in a queue. A quartz job would poll the queue and try to send the Soap message. The message would only be removed from the queue if the remote system reponses successfully.
Use a messaging middleware like ActiveMQ (e.g. as part of Apache Servicemix) to make use of JMS and make the whole task a lot easier.
What do you suggest?
Take JMS, if you go for 1 you'll end up implementing some of the stuff that is already provided by a JMS system. OSGi events are nice, but after a shutdown of the container they are gone. So this will be at least one of the drawbacks that you'll have to re-implement that a JMS messaging system like ActiveMQ already provides.
I'm looking for a full duplex streaming solution with Java EE.
The situation: client applications (JavaFX) read data from a peripheral device. This data needs to be transferred in near real-time to a server for processing and also get the response back asynchronously, all while it keeps sending new data for processing.
Communication with the server needs to have an overhead as low as possible. Data coming in is basically some sensor data and after processing it is turned in what can be described as a set of commands.
What I've looked into:
A TCP/IP server (this is a non-Java EE approach).This would be the obvious solution. Two connections opened in parallel from each client app: one for upstream data and one for downstream data.
Remote & stateless EJBs. This would mean that there's no streaming involved and that I pack sensor data in smaller windows (1-2 seconds worth of sensor data) which I then send to the server for processing and get the processing result as a response. For this approach, while it is scalable, I am not sure how fast it will be considering I have to make a request each 1-2 seconds. I still need to test this but I have my doubts.
RMI. Is this any different than EJBs, technically?
Two servlets (up/down) with long polling. I've not done this before, so it's something to be tested.
For now I would like to test the performance for my approach #2. The first solution will work for sure, but I'm not too fond of having a separate server (next to Tomcat, where I already have something running).
However, meanwhile, it would be worth knowing if there are any other Java specific (EE or not) technologies that could easily solve this. If anyone has an idea, then please share it.
This looks like a good place for using JMS. Instead of stateless EJBs, you will probably be using Message-Driven Beans.
This gives you an approach similar to your first solution, using two message queues instead of TCP/IP connections. JMS makes your communications fully asynchronous and is low-overhead in the sense that your clients can send messages as fast as they can regardless of how fast your server can consume them. You also get delivery guarantees and other JMS goodness.
Tomcat does not come with JMS, however. You might try TomEE or integrate your existing Tomcat with a JMS implementation like ActiveMQ.
There are numerous options you could try. Appropriate solutions depend on the nature of your application, communication protocol, data transfer type, control you have over the client and server and firewall restrictions on client server routes.
There's not much info on this in your question, but given what you have provided, you may like to look at netty as it is quite general purpose and flexible and seems to fit your requirements. Netty also includes a duplex websocket implementation. Note that a netty based solution may be more complex to implement and require more background study than some other solutions (such as jms).
Yet another possible solution in GraniteDS, which advertises a JavaFX client integration and multiple server integrations for full duplex client/server communication, though I have not used it. GraniteDS uses comet (your two asynchronous servlets with long polling model) with the Active Message Format for data which you may be familiar with from Flex/Flash.
Have you looked at websockets as a solution? They are known to keep persistent connections and hence the asynchronous response will be quick.
I decided that it is time for me to dig into the whole Java EE stuff. I am using EE some techniques whithin Java SE like JPA or JMS, but i still messing around with Java SE and i believe Java EE and an application server will solve some of my problems i have.
BUT: I have still some questions after reading some articles on the web.
1st: Am i limited to request-response applications? I have an application which serves XML documents via HTTP. All delivered objects are added to a queue which will be dispatched in a different thread. Some validation is made for this objectes, including the opening of sockets to a remote machine (I heard EJ-Beans are not allowed to do this, is this true?). So, is is possible to do this within an application server?
2nd: I know there are Message driven beans, is it possible to send JMS messages to a MDB from outside of the application server? I have a service which sends JMS messages, but runs, as a legacy system, not inside the same application server.
3rd: How can the System Adminstrator or User configure my application? I know that some things like database connections are configured within the application server and my application can lookup them via JNDI or get them via DI. But what about application specific configuration?
Yeah, these are quite noobish questions, but maybe someone has the time to explain me how all this stuff is working. :)
regards,
Posix
PS:
4th: It seems EJBs are not allowed to do anything with files, so Java EE seems to be no option for a Service which receives Files, pushes them around to different systems and want them to write to a Socket (see question 1)?
I can say that Java EE can be used without any doubts in your case. Let me drill a little bit more into your specific questions:
You can open socket connection from your EJB. There is nothing that prevents you from doing that. However this kind of operation is not advised for Java EE applications. In my opinion the better option is to implement Java EE Connector (JCA) that would manage pool of socket connections to your proprietary system. This is the model way to implement such a integration as per specification.
Yes! It is perfectly possible to receive messages send from external application/system (outside the AS). This is main idea of integration using messaging :) In many cases your application being Java EE application receives messages via MDB from JMS channel, but JMS is only an API and can be implemented by any messaging system e.g. IBM MQ. In this architecture the external system puts an MQ message onto the queue and your Java EE application that listens to the very queue receives the message via JMS API!
Generally speaking Application Server gives the Administrator great tools to manage Java EE resources i.e. data sources, JMS connection factories, JMS destinations, JTA transaction manager, etc. If you require the ability to change your specific Java EE application the best options seems to be JMX. Just implement a few MBeans, export those to the JMX server embedded within your Application Server and you are done. This task is really trivial in, say, JBoss, but most of the modern Application Servers offer extensive JMX capabilities these days.
For the first glance, EJB doesn't seem to be the best for dealing with files. But remember that implementation of your EJBs is still written in pure Java, so nothing prevents you from reading/streaming files and so on. I have experience with large Java EE applications that are handling large files as input files and can assure you that Java EE is is a good technology choice :)
Here are the restrictions on EJB 1.1 spec.
Here's my take on your questions:
I believe an EJB can open a socket on a remote machine, but I would say that opening sockets is too low level an operation. I'd think about exposing whatever that socket is doing for you as another EJB.
An MDB is just a listener that's registered with a particular topic or queue. It doesn't say anything about sending. If your client knows how to get a message to the queue it's possible. They just have to know the queue URL and be able to create a connection.
The admin sets up connection pools, JNDI names, etc. - everything. They do it using the admin console for the app server.
It's a violation of the EE spec to do anything with files (to ensure that an EE app is portable and distributable). However since it's all just plain Java code, yopu can choose to do anything that you want. As long as you know how your target environment looks (eg the system is for internal use) I wouldn't hesitate modifying files just because the spec says so.
In an application server like Tomcat (others too, probably, but I've never worked with them) you can not only execute things upon receiving a request, but also do things (including starting long running threads) on server startup. Basically you can do anything that you can with "normal" Java. In fact, you could put a normal Java app in application server if you just include a piece of code which calls the appropriate main() on server startup.
I would suggest applying each technology to the appropriate points where you are currently feeling pain. Regarding your specific points,
In an EE context, you would add the messages to a JMS queue, that has MDBs which would do the actual processing. Regarding the management of the HTTP request/response lifecycle, you would manage this the same way you do now, or use an existing library to do if for you. By moving to an EE app server, you would allow the app server to manage the threading, transactions, etc. instead of having to manage it manually.
As duffymo stated, MDBs are responsible for receiving messages, they do not care where the message originated from.
The system administrator can configure the app server as duffymo stated. Additionally, you can expose JMX beans to other systems or to the end user to allow them to configure services if you so desire.
I have a web service, that takes an input xml message, transforms it, and then forwards it to another web service.
The application is deployed to two web logic app servers for performance, and resilience reasons.
I would like a single website monitoring page that allows two things
ability to stop/ start forwarding of messages
ability to monitor throughput of number of messages in the last hour etc. Number of different senders into the webservice etc.
I was wondering what the best way to implement this was.
My current idea is to have an in memory database (eg Debry or HSQL) replicating data to share the information between the two (or more) instances of my application that are running in different instances of the app server. I imagine I would have to setup some sort of master/ slave configuration.
I would love a link to an article that discusses how to solve this problem.
(Note, this is a simple spring application using spring MVC)
thanks,
David.
This sounds like a good match for Java Management Extensions (JMX)
JMX allows you to expose certain operations (eg: start/stop forwarding messages)
JMX allows you to monitor certain performance indicators (eg: moving average of messages processed)
Spring has good support for exposing beans as JMX MBeans. See here for more information.
Then you could use an open-source web-based JMX console, such as jManage
Hope this helps.
Sounds like you are looking for a Message Queue, some MDBs and a configurable design would let you do all these. Spring has support for JMS Queues if I'm not wrong
I think you are looking for a message queue. If you need additional monitoring, using a web service as the end point may not suffice - with regards to stop/start or forwarding of messages; monitoring http requests to web service is more cumbersome than tracking messages to a queue (even though you can do it).
If you are exposing this service to third party, then the web service will sit on top of the message queue and delegate to to it.
In my experience, RabbitMQ is a fine messaging queue service with a relatively simple learning curve.