aspose file tools*
The moose likes Websphere and the fly likes WebSphere 5 and WebSphere MQ Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Websphere
Bookmark "WebSphere 5 and WebSphere MQ" Watch "WebSphere 5 and WebSphere MQ" New topic
Author

WebSphere 5 and WebSphere MQ

M Givney
Greenhorn

Joined: Sep 24, 2003
Posts: 25
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!
Kyle Brown
author
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
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


Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
M Givney
Greenhorn

Joined: Sep 24, 2003
Posts: 25
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
Ranch Hand

Joined: Aug 10, 2001
Posts: 3892
    
    5
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

Joined: Sep 24, 2003
Posts: 25
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 ]
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: WebSphere 5 and WebSphere MQ