| Author |
Message
|
| prudent23 |
 Posted: Sun Oct 07, 2007 4:48 pm Post subject: Java Compute Node in WMB V6 |
 |
|
Newbie
Joined: 07 Oct 2007
Posts: 6
Location: Bangalore
|
Hi All,
I am a regular visitor of this site. The experts out here are really doing a great job. I hope I would get a proper answer to my question.
What are the advantages and disadvantages of using Java Compute Node(JCN) in WMB V6?
Where should we use strictly JCN?
If we are going for a new message flow design, should we use JCN or Compute node using ESQL?
Is there any performance problem associated with JCN?
Best Regards,
Sam |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sun Oct 07, 2007 6:30 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I'd say it really depends on maintainability and skills set.
If you are going for performance you should use references in ESQL and relative mapping in JCN. Remember that "walking the tree" has its own cost...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| prudent23 |
| Posted: Sun Oct 07, 2007 6:53 pm Post subject: |
|
|
Newbie
Joined: 07 Oct 2007
Posts: 6
Location: Bangalore
|
| Hey, thanks for the quick reply. So what it means is for any new deisgn, we can always propose for JCN instead of Compute Node for better maintainbility. is my understanding correct? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Oct 07, 2007 8:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| prudent23 wrote: |
| Hey, thanks for the quick reply. So what it means is for any new deisgn, we can always propose for JCN instead of Compute Node for better maintainbility. is my understanding correct? |
Not quite. What I meant was that it depends on the talent on your site whether you want to go the ESQL route or the JCN route.
Keep in mind as well that performance will be influenced by the number of JCN nodes in a flow... the greatest work being done on the Input and Output of the JCN... I have heard it said that ESQL is a little bit more forgiving in this regard...
Best bet: take your most complex flow and write it in ESQL, then in JCN. After that you can deploy / undeploy and run some comparison metrics on the same hardware...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 08, 2007 12:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
MB Java code is slower and more complicated to write, and to write well than ESQL. The Java API requires you to know more about how message trees are constructed and manipulated - including lower level information about parsers. Because of this additional complexity, it can be harder to maintain MB Java code than ESQL.
There are things you can do in Java that you can't do in ESQL - read/write files, access that only have JDBC support, access network protocols that you don't have built-in nodes for, etc.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| prudent23 |
| Posted: Mon Oct 08, 2007 6:42 am Post subject: |
|
|
Newbie
Joined: 07 Oct 2007
Posts: 6
Location: Bangalore
|
hey people,
I think I got quite a fair idea about the design considerations for JCN. I believe getting straightforward answers to questions like his would be always difficult and thats where the forums help. I will keep you people posted about the scenarios and performance comparison matrix for this particular problem.
Thanks...
 |
|
| Back to top |
|
|
|
|
