| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Should I use JAVA or JMS? |
« View previous topic :: View next topic » |
| Author |
Message
|
| varmamvn |
 Posted: Sat May 18, 2002 4:25 am Post subject: |
 |
|
Novice
Joined: 16 Mar 2002
Posts: 21
|
Murugan,
You are the man! You always try to help me.
Well, regarding the Correlation ID problem in JMS. I always seem to be getting 0's in my Correlation ID.
I have also observed the following difference in the host response when I browse using amqsbcg:
Host Response for the request sent through JMS has
Encoding : 273 CodedCharSetId : 819
Host Response for same request sent through MQ Base Java has
Encoding : 785 CodedCharSetId : 500
Could this be the cause of my problem. How can I correct this? On my side, I did not change anything to cause this?
_________________
Regards
Varma
varmamvn@mailcity.com |
|
| Back to top |
|
 |
| Vin |
| Posted: Sat May 18, 2002 11:14 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002
Posts: 212
Location: India
|
The limitations of MDBs are that it can subscribe to only one topic. In case you want multiple topic subscriptions you need to have an MDB defined for each subscription. Also MDB is just a listener which is under the control of a container. Sure it offers asynchronous processing but I was not sure about the performance overhead that this might cause. In other words if I have an MDB deifned and the container spawns like 50 instances of it at startup (OfCourse I could control this) and there are no messages comming in on the queue for quiet sometime; would that not take up unneccesary resources? Trigerring on the other hand is just process the message and die right? Even if it demands the user to do the transaction processing, I guess this is a one time thing and you can control it instead of relying on the container. Just a food for thought guys  |
|
| Back to top |
|
|
| amurugan |
| Posted: Sun May 19, 2002 5:45 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi peter ,
As varma has said it very clearly that in J2EE architecture the app servers will provide you with all necessary infrastructre services such as security , load balancing , failover , TX capability . If we use mq series base java then we might end up handling all this at our expense . IN J2EE ,JMS IS THE STANDARAD SPECIFIATION SET FOR messaging capability which is now being hailed as adhoc standard in the market as many MOMS have adopted it . moreover in the near future in the webservices market , JC (Java connectors) will also be using jms for passive integration and async messaging, So if you use mqseries jms apis you can switch to any MOM vendor adpoting jms s with much ease . even if you want to intergerate your mqseries with other app servers abd EAI vendors then if you have JMS APIS . you can very well develop it as a utility component and use it acros appservers , MOMS with parametrizing the service providers details . hope this finds you in comfort . |
|
| Back to top |
|
|
| amurugan |
| Posted: Sun May 19, 2002 5:46 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi peter ,
As varma has said it very clearly that in J2EE architecture the app servers will provide you with all necessary infrastructre services such as security , load balancing , failover , TX capability . If we use mq series base java then we might end up handling all this at our expense . IN J2EE ,JMS IS THE STANDARAD SPECIFIATION SET FOR messaging capability which is now being hailed as adhoc standard in the market as many MOMS have adopted it . moreover in the near future in the webservices market , JC (Java connectors) will also be using jms for passive integration and async messaging, So if you use mqseries jms apis you can switch to any MOM vendor adpoting jms s with much ease . even if you want to intergerate your mqseries with other app servers abd EAI vendors then if you have JMS APIS . you can very well develop it as a utility component and use it acros appservers , MOMS with parametrizing the service providers details . hope this finds you in comfort . |
|
| Back to top |
|
|
| amurugan |
| Posted: Sun May 19, 2002 5:51 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi varma ,
with respect to the correlation id . Is the message sending application an mqseries base java program or jms program . IF you use mqseries vase java apis before sending the message did you tried to debug and print the correlation id . does it contain the meaningful values that you wanted the message to have . if this is succesful try using JMSMessage.getCorrelationIdAsBytes() . bcos if the sending application is a non jms appln then as you know the message and the headers will be in bytes streams so try using the above method and then try to reconstruct it and print and find whether the correlation id marches with the one that you have sent . lemme know hit me 2 a_murugan@yahoo.com
Regards,
Murugan |
|
| Back to top |
|
|
| amurugan |
| Posted: Sun May 19, 2002 5:55 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi peter ,
okay i didnt go thru the second page . VIN has told that MDBS can only listen to a queue . yes thats true . if you dont want that then try using session pool mechanism . it can listen to any queue if yiou paramterize the queue name and so on . moreovr mqseries jms has implemented this as ASF (Application server faqcility) . if you feel that your solution does nt have any appservers , EAI vendors and ist just plain hub and spoke architecture then use mq base java apis . let me know abt it .
cheers,
murugan |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon May 20, 2002 4:54 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Varma,
| Quote: |
| JMS is definately a very attractive solution, since once you map the Queues and QMs into JNDI, you can always access it from anywhere. This is a major plus over Base Java, where it would work only if it exists on the same server as MQ. |
What does this mean? If I define the props of my queues in the JNDI, the book says JMS clients can retrieve these objects from the namespace and use them.
1)How is this better than a plain JAVA app client connecting to any server and using those queues?
2)Would this JNDI house queues from many different servers?
3)If you use JMS, do you HAVE to use JNDI?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon May 20, 2002 5:09 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Murugan,
| Quote: |
| As varma has said it very clearly that in J2EE architecture the app servers will provide you with all necessary infrastructre services such as security , load balancing , failover , TX capability |
The failover part intrigues me. Since JAVA does not support channel tables, our JAVA apps had to code failover routines in case their primary MQServer went down. Does JMS solve this somehow?
Does a MDB listen on only 1 queue, or does it watch many at the same time? I am still struggling with seeing how an MDB is better than a plain old trigger monitor.
Does anyone have a link to a real basic What-is-J2EE doc or tutorial? I hate to keep bothering you guys with really basic questions.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| amurugan |
| Posted: Mon May 20, 2002 5:02 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi peter ,
I think i have answered your questions .
What does this mean? If I define the props of my queues in the JNDI, the book says JMS clients can retrieve these objects from the namespace and use them.
yes JNDI is a naming and dirstory interface specification implemented by nedors for binding and looking up of objects in the name space .
1)How is this better than a plain JAVA app client connecting to any server and using those queues?
okay . let me explain this briefly inconnection with mqseries base java and jms apis . when you use mqseries base java apis you try to open a queue manager , connect to the queue and then perform operations on it . when you try to move to another MOM say talarian or fiorano or tibco these apis wouldnt be of any use as they are not portable as they are vendor specific . they same may happen if you are trying to move from any MOM to another MOM . when you use JMS . the interfaces in JMS are implemented by the MOM vendors and the applications written using jms need not change much except for the service providers details for JNDI lookup . so you can switch to new MOM vendors without your applications being changed .
2)Would this JNDI house queues from many different servers?
JNDI is a specification for binding objects and looking up 'em . different vendors implement them in differnt way . in mqseries the way jms has been implemented is a wrapper around the base . in the client side , we have a jndi implementation by mqseries which can either use file based or jdbc based context that stores all the definitions of the jms objects such as queue connection factories and queues which map to queue manager and the queues in the mqseries servers . weblogic has a pure jms implemntation where you can define the jms servers and destimations and the connection factories and ejbs and connection pools in the console . In weblogic jms , JNDI is implenmented as a tree structre , I think so . so JNDI dfosnt house queues they house objects in general .
3)If you use JMS, do you HAVE to use JNDI?
yes you have to use JNDI .
The failover part intrigues me. Since JAVA does not support channel tables, our JAVA apps had to code failover routines in case their primary MQServer went down. Does JMS solve this somehow?
no JMS doesnt solve this until the MOM vendor has said so . in MQSERIES JMS the failover doesnt occure at the client side bcaues there are literally no mqseries server objects in mqseries client side its only at the mqseries server side the fail over can happen using HA feature. whereas if use any app server for example weblogic , they support failover as the jms objects are clusterable .
Does a MDB listen on only 1 queue, or does it watch many at the same time? I am still struggling with seeing how an MDB is better than a plain old trigger monitor.
MDBS can listen only to one queue . if you using MDBS , they are triggered in async manner and the load balancing , fail over can be taken care by the J2EE container .the alternative may be go in for Server session pools
Does anyone have a link to a real basic What-is-J2EE doc or tutorial? I hate to keep bothering you guys with really basic questions.
for a J2EE tutorial . follow this link
http://java.sun.com/j2ee/tutorial/1_3-fcs/index.html
cheers,
murugan |
|
| Back to top |
|
|
| amurugan |
| Posted: Mon May 20, 2002 5:03 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi peter ,
I think i have answered your questions .
What does this mean? If I define the props of my queues in the JNDI, the book says JMS clients can retrieve these objects from the namespace and use them.
yes JNDI is a naming and dirstory interface specification implemented by nedors for binding and looking up of objects in the name space .
1)How is this better than a plain JAVA app client connecting to any server and using those queues?
okay . let me explain this briefly inconnection with mqseries base java and jms apis . when you use mqseries base java apis you try to open a queue manager , connect to the queue and then perform operations on it . when you try to move to another MOM say talarian or fiorano or tibco these apis wouldnt be of any use as they are not portable as they are vendor specific . they same may happen if you are trying to move from any MOM to another MOM . when you use JMS . the interfaces in JMS are implemented by the MOM vendors and the applications written using jms need not change much except for the service providers details for JNDI lookup . so you can switch to new MOM vendors without your applications being changed .
2)Would this JNDI house queues from many different servers?
JNDI is a specification for binding objects and looking up 'em . different vendors implement them in differnt way . in mqseries the way jms has been implemented is a wrapper around the base . in the client side , we have a jndi implementation by mqseries which can either use file based or jdbc based context that stores all the definitions of the jms objects such as queue connection factories and queues which map to queue manager and the queues in the mqseries servers . weblogic has a pure jms implemntation where you can define the jms servers and destimations and the connection factories and ejbs and connection pools in the console . In weblogic jms , JNDI is implenmented as a tree structre , I think so . so JNDI dfosnt house queues they house objects in general .
3)If you use JMS, do you HAVE to use JNDI?
yes you have to use JNDI .
The failover part intrigues me. Since JAVA does not support channel tables, our JAVA apps had to code failover routines in case their primary MQServer went down. Does JMS solve this somehow?
no JMS doesnt solve this until the MOM vendor has said so . in MQSERIES JMS the failover doesnt occure at the client side bcaues there are literally no mqseries server objects in mqseries client side its only at the mqseries server side the fail over can happen using HA feature. whereas if use any app server for example weblogic , they support failover as the jms objects are clusterable .
Does a MDB listen on only 1 queue, or does it watch many at the same time? I am still struggling with seeing how an MDB is better than a plain old trigger monitor.
MDBS can listen only to one queue . if you using MDBS , they are triggered in async manner and the load balancing , fail over can be taken care by the J2EE container .the alternative may be go in for Server session pools
Does anyone have a link to a real basic What-is-J2EE doc or tutorial? I hate to keep bothering you guys with really basic questions.
for a J2EE tutorial . follow this link
http://java.sun.com/j2ee/tutorial/1_3-fcs/index.html
cheers,
murugan |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 22, 2002 1:02 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
We use JMS, it's a standard messaging API so keeps our options open for the future.
You could use the AMI if you want an IBM provided wrapper to MQI. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
