This week's book giveaway is in the Reactive Progamming forum.
We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line!
See this thread for details.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

WebSphere 5 and WebSphere MQ

 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy ranchers!
A couple of quick questions regarding WebSphere Application Server and it's relationship with WebSphere MQ.
I have been tasked with writing an application that utilizes WebSphere MQ that basically lets our retail website (j2ee) communicate with our VB6 dispatch system. My only requirements are that 1) I must deploy this application to the WebSphere Application Server v5.02 and 2) I must use WebSphere MQ as my Message Oriented Middleware. I was wondering the following:
If I decide to include the mq related jars to my build path, is there anything within WAS (i.e. the Application Server) that won't allow me to bypass JMS and communicate directly with MQ?
Thanks in advance!
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can, but you shouldn't. WAS is designed to work with JMS, not with the basic underlying MQ. Why would you want to bypass JMS?
Kyle
 
M Givney
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kyle,
Thanks for the response. I have a couple of reasons why I would want to pull this out of the container management via JNDI and into my source, feel free to poke holes into my rationale wherever possible...
1) Debugging applications on WebSphere is a nightmare. I develop with Eclipse and debugging anything against the AppServer is slow as molasses.
2) I agree that JNDI and JMS provide abstraction. If we decide to move off of WebSphere and go to WebLogic/JBOSS etc. some day, I am going to have to refactor some code. By the time this company moves off of WebSphere, this technology is going to be antiquated anyway...case in point, they still use Btrieve here...yikes!
3) Complexity. With the abstraction that JNDI and JMS provide, they also bring complexity. Yet another configuration that has to be done that can be done incorrectly and cause problems (which brings it back to point 1). The group that manages WAS at my company doesn't provide access to the Admin Console. We have to provide instructions and the Middle tier support group does the configuration. I would rather not play that game.
4) Finally, I have experience working directly with MQ via my VB and C++ development days. I am somewhat of a novice to the JMS api and JMS best practices.
Regards,
Matt
[ December 04, 2003: Message edited by: M Givney ]
 
Kyle Brown
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by M Givney:
Kyle,
Thanks for the response. I have a couple of reasons why I would want to pull this out of the container management via JNDI and into my source, feel free to poke holes into my rationale wherever possible...
1) Debugging applications on WebSphere is a nightmare. I develop with Eclipse and debugging anything against the AppServer is slow as molasses.


Might I suggest moving up to WebSphere Studio Application Developer? Developing and debugging in-place in WSAD is quite snappy and reponsive... If you've never done it you really don't know what you're missing. It's lovely.


2) I agree that JNDI and JMS provide abstraction. If we decide to move off of WebSphere and go to WebLogic/JBOSS etc. some day, I am going to have to refactor some code. By the time this company moves off of WebSphere, this technology is going to be antiquated anyway...case in point, they still use Btrieve here...yikes!


The abstraction is there for a reason. It is SIGNIFICANTLY more complicated to communicate from WebSphere using Base MQ than it is using JMS. Not only that, but in future versions of WebSphere you will be FORCED to use JMS as the base MQ classes just won't work because they violate J2EE rules like threading, etc...


3) Complexity. With the abstraction that JNDI and JMS provide, they also bring complexity. Yet another configuration that has to be done that can be done incorrectly and cause problems (which brings it back to point 1). The group that manages WAS at my company doesn't provide access to the Admin Console. We have to provide instructions and the Middle tier support group does the configuration. I would rather not play that game.


At least setting up the JMS configuration with WAS is supported by IBM so if you have problems you can open problem tickets with IBM... Otherwise they'll tell you to take a hike... Also, the JMS setup procedure is going to be much better documented in other places like Redbooks that you can have the admin people read in their copious spare time...


4) Finally, I have experience working directly with MQ via my VB and C++ development days. I am somewhat of a novice to the JMS api and JMS best practices.
Regards,
Matt
[ December 04, 2003: Message edited by: M Givney ]


OK, I knew the REAL reason would come out. Take a risk. Learn the new technology. You'll find there are MANY very good books and tutorials out there for learning JMS and JMS best practices. For instance, I'd recommend Monson-Haefel's book on JMS as a good start. Your code will be much more long-lived as a result, integration will go much more smoothly, and what's more, you won't run the risk of someone coming in 9 months from now and having to rewrite it because you didn't follow standards...
Kyle
 
M Givney
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kyle,
You are a gentleman and a scholar =). Thanks for the information, I'll take a look at it.
Regards,
Matt
[ December 04, 2003: Message edited by: M Givney ]
 
Let's go to the waterfront with this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!