I want to subscribe to the JMS queue with no usage of EJB MDB. The reason is that I want to receive messages only when I want, but not automatically.
Is there some ways to implement it using plain Java (no Spring or smth else)?
I use WebLogic and its internal JMS provider, if it is important.
Thanks.
Yes, you should be able to connect to your JMS Queue of your Application server. JMS is a quite good standard, so after getting your Connection/Queue, the implementation is Vendor agnostic.
Here is a short overview what you have to write to create a consumer/producer with JMS: JMS Sample
This shows each step in detail with WebLogic JMS: Developing a WebLogic JMS Application
I didn't used WebLogic or it's JMS implementation, maybe you have to configure Weblogics JMS: Configuring and Managing WebLogic JMS
For a comprehensive overview of the programming capabilities of your WebLogic JMS Provider, look here: Programming WebLogic JMS
Related
We have a requirment to connect to a JMS queue provided by an externally controlled IBM Websphere MQ server. Now, the easiest way to do it would be to include the Websphere MQ client into our application and just use the queue.
But IBM was so far not able to tell me about possible licensing costs of this setup. I saw forum posts and hints on IBM download pages that using the client is free of charge, but I do not know for sure. Maybe it's even the case, that the owner of the MQ server is allowed to provide us the client jar to use it for connecting to them, but again, I don't know for sure.
So I am evaluating the possibility to setup my own open source JMS server, for example an Apache ActiveMQ, and then bridge over to the Websphere MQ. For this, 2 questions rise up for me:
Technical solution: How would that be done exactly? I read a bit about bridging between JMS providers and something about the Apache Camel project, but have so far no exact idea how much work this will be and what needs exactly to be done.
Impacts: What should I bear in mind when implementing such a scenario? Do I still have to include the MQ client and such would not benefit over a direct connect? Are there any negative impacts compared to a direct connect that I must consider?
Update: Our application is a Java EE 6 application running on a JBosss 7.1. Concerning the MQ server version I have no information yet.
2nd Update: The MQ server version is 6.5.
The client to MQ is available for you to use; there's a license agreement to accept not a charge.
There are several options for how these client libraries could get to you practically.
You mention JMS is being used - within what container/environment is this? JavaSE/JavaEE/OSGi or something else.
JavaSE or the 'something else' would the JMS Client JARs.
JavaEE would need the IBM MQ Resource Adapter
OSGi would need the OSGi Bundles
In earlier versions of MQ there was the 'extended transnational client' that had a charge associated with it (pretty much the same as a full server) but that is no more.
As this is for JBOSS 7.1 - the solution would be to follow this link
http://www-01.ibm.com/support/docview.wss?uid=swg21633761
.. and download the IBM MQ Resource Adapter directly from the instructions there... 7.5.0.4 has also been released this last week. Please consider this as downloading the MQCxxx support pac will give you too much. This download does have the license agreement to accept but it's the same as the one has been highlighted elsewhere. It does mention Liberty but it's the same RA that is supported for within JBOSS.
For information on configuring the RA inside JBOSS please look at
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q031820_.htm
The version of the RA or JMS client code is not tightly coupled with the server version. Client or bindings.
You won't have any support apart from via the web; unless you get the company running the externally controlled server to raise it.
Edit: have added download links
Pasting from this page
Category 3 WebSphere MQ SupportPacs are supplied under the standard terms and conditions provided by the International Program License Agreement (IPLA) and thus, carry program defect service for WebSphere MQ customers. Please read the IPLA and LI files that accompany the SupportPac, to ensure you understand the conditions under which the SupportPac is provided.
If you encounter what you believe to be a defect with the SupportPac, and you have a current license for a WebSphere MQ server product, you may request Program Services by reporting the problem via the same defect reporting channel you employ for the WebSphere MQ server product(s) on which you are using the SupportPac. No proof of entitlement is required to use this SupportPac.
Service is available for the v7.5 version of this SupportPac for as long as the WebSphere MQ V7.5 server product is supported by service. Refer to the WebSphere product lifecycle pages for the relevant service information. It is only supported with MQ platforms which are themselves supported.
I am thinking text in bold indicates MQ Client is free.
WebSphere MQ Client has no licensing fees. The only fees (and I think they did away with this one) would have been for the XA client. The client download should come with Client for JMS, which is not the same as Client for Java (native IBM API in java). When you install the client, just check to ensure you have /java/ which will contain all of the dependent jars for connecting to IBM MQ.
I would highly suggest using Apache Camel as your bridge vs creatng your own. You can then choose to run the camel route inside of the ActiveMQ JVM or other supported container. Most of the work will be learning how to do it the first time. Once you have it set up you will realize the time savings and power of Apache Camel.
No matter what you need MQ Client. MQ Server includes MQ Client, so if all this is on the same host you have nothing else to install. If by direct connect you mean bindings mode vs client mode, then yes, bindings mode is always the most efficient. And on the flip side, if you run your route in your broker you can take advantage of the VM transport.
The main considerations you need to think about for messages bridging between ActiveMQ and WebSphere MQ are really typical messaging questions. For example, Do you need the message to survive an outtage? If so, then consider using local transactions with your routes.
Bridging an ActiveMQ broker with a WebSphere MQ queue manager requires the same client libraries as a direct connection.
You are correct that you can pretty easy setup such a bridge using Apache Camel, that comes bundled with ActiveMQ.
One possible benefit from having a local broker as a buffer might be that your application can rely on a broker that is up and controlled by you. The remote/external controlled WebSphere MQ might be taken down for maint. by external parties or the network might be shaky. Of course, your application can handle such things using logic and rescheduled transmissions but it's far easier to set up a Camel route in ActiveMQ to do that and focus your logic in the application to do business logic.
I need to deploy EJB3 MDB on JBOSS 5.1 and listen to the Topic deployed on IBM MQ. One way is to configure the RemoteJMSProvider inside of $JBOSS_HOME/server/default/deploy/messaging/jms-ds.xml. The second way is to use the MQ Resource adapter and deploy it in JBOSS.
What are the advantages of one approach to another? Are there any other ways?
The RemoteJMSProvider is a generic JMS JCA adapter and so can be used by lots of JMS Providers. Essentially it is a JCA wrapper around a standard MQ JMS client that then talks to the MQ QueueManager. This does mean it is not optimised for any specific JMS Provider, and is also likely to not be tested by the vendor of JMS Provider being used.
The MQ Resource Adapter is built by IBM and so will be tested and fully supported by IBM when used in a Java EE application server. It will also mean it is optimised for MQ.
I need some help with using JMS to write to Secure MQ.
Our middleware team has decided to start securing MQ objects and they have asked us to start using the secure MQ queues.
Most of our applications that write to MQ are Websphere applications although we do have some stand-alone clients as well.
Our websphere version is WAS 8.5 and MQ version is 7.5
What different types of options are available to access secure queues from java - as a producer and also as a consumer?
Is there any document / tutorial / code sample that will help with understanding how can I use Java / JMS to write to a secure queue? What kind of information do I need to gather to do more research on this topic?
One of the comments they have made is - The preference is that the client id is configured by the websphere / MQ administrators and the developers should not know that.
Our middleware team has decided to start securing MQ objects and they
have asked us to start using the secure MQ queues.
There is no such thing as "secure MQ queues". Did your company purchase IBM's WMQ AMS and you want to encrypt messages?
Or are you looking for how to configure your JMS application to use MQ SSL?
One of the comments they have made is - The preference is that the
client id is configured by the websphere / MQ administrators and the
developers should not know that.
The deployment team should be responsible for setting the UserID and Password (and not the developers).
I'd like to use the Java Message Service but it says it's for the Java EE Platform. Is there a way to port it to a regular Java application (which I'm working on in Eclipse)?
JMS is part of the Java EE spec, but you can use it from any Java application. Depending on your needs, you may have to run a standalone broker, but this is just like running a regular daemon (or Windows service).
Yes, you absolutely can use JMS from a J2SE application. In fact, you can access a JMS broker from programs not written in Java at all. The ActiveMQ JMS server includes several transport connectors. The connectors allow clients to interact with ActiveMQ using different communication protocols. Most Java clients use the openwire connector. I've written a PHP client that used the STOMP protocol with great success. It consumed messages sent to a JMS Queue by a Java application running in the Tomcat Servlet Container.
This is a much more complicated question than the answer would indicate. Jms is a spec. Really just a set of interfaces. You can absolutley use those interfaces from a standalone java process. Hell you could write your own jms compliant messaging implementation. Questions you should be asking yourself is what messaging implementation will i be using and does it support jms? Even after answering that there are numerous caveats to take into account when connecting to brokers outside of a container including but not limited to transactionality, load balancing, connection pooling, and high availability. You should be very clear about what your trying to do and what messaging vendor you are working with before you can answer this completely
Many Messaging servers also provides their java api for the communication like MQ, open source Apache ActiveMQ. In that case you don't realy need to worry about JMS. You simply need to understand and use that API.
Latest version of both, can not see how to enable ActiveMQ as an endpoint in Glassfish. Would like to use ActiveMq as the JMS provider in Glassfish, the stuff I found on google does not make sense. Any advise welcome.
Is it possible to just use the JMS connector and poitn at ActiveMQ - believe not but have I just configured wrong ?
Thanks
Please look at this tutorial: http://javadude.wordpress.com/2011/07/21/glassfish-v3-1-running-embedded-activemq-for-jms-part-1/
I've written an article (based on Sven's) that describes how to connect an external activemq broker to glassfish and deploy a Message Driven Bean that consumes messages from ActiveMQ.
You can find it here: http://geertschuring.wordpress.com/2012/04/20/how-to-connect-glassfish-3-to-activemq-5/
Deploy activemq-rar-[version].rar as Connector Application to Glassfish
You will need some *.jars (http://weblogs.java.net/blog/rampsarathy/archive/2007/03/glassfish_v2_an_1.html) in \domains[domainName]\lib\ext
Create Connector Connection Pool with ActiveMQ
Create Connector Resource (Factory) with Connector Connection Pool from 2.
Create Queues.