| Author |
Message
|
| pratuluv |
 Posted: Wed Feb 08, 2012 4:56 am Post subject: Using Java Compute Node over accessing JAR file through ESQL |
 |
|
Acolyte
Joined: 25 May 2011
Posts: 53
|
Hi,
I have a scenario where in I have to use Java code to perform some action. I would like to know the best approach between the 2 options below:
1. Using Java compute node to implement Java
2. Creating a separate Jar file and refer the java method through ESQL in Compute Node.
Please advice. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Feb 08, 2012 5:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The best option is the one that matches your requirements best.
Are you asking for the things you should consider when trying to match your requirements to a technical solution?
What things would you normally consider? I only ask so that I don't suggest things you've already thought of or tried. |
|
| Back to top |
|
|
| pratuluv |
| Posted: Wed Feb 08, 2012 5:09 am Post subject: |
|
|
Acolyte
Joined: 25 May 2011
Posts: 53
|
My requirement is very simple. I have to read a config file and do dynamic mapping based on the input file name.
Hence my java code takes the input filename as IN, fetches the corresponding values for that filename from the Config file and returns it back to my WMB flow. I am doing all this in ESQL. Now, I am deploying the JAR file in the EG and placing the config file in the shared class folder. But, we want to know the advantage of using a JAVA compute node over this approach. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Feb 08, 2012 5:49 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
From a performance perspective, the two access methods are equivalent. Calling a Java jar from ESQL is the same as calling a Java jar from JCN.
In most cases, I prefer extensive Java code to reside in separate Jars as a means to organizing the code better and assigning scope to units of work.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| kash3338 |
| Posted: Wed Feb 08, 2012 5:50 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
The solution depends upon the complexity of your requirement. If you just need to pass a String argument and get back the routing details from the java method, its better to invoke the java procedure from ESQL rather than using a JCN.
Compute node is comparitively easier and lighter to use than going for a JCN also taking into considerations the maintanace aspect. Many dont have the knowledge of Java to work on JCN's. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 08, 2012 6:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If the requirement were given to me, "read a config file and use it to do dynamic mapping", I would not use a JCN or a static java procedure.
I would convert the "config file" into a set of User Defined Properties on the message flow, and set them on the bar file that deployed the flow. Then I would use normal broker functions to access these values, without having to invoke Java code at all.
Or I would convert the values into rows in a database table, and again use normal broker means to access the data and make decisions.
If the intent of the config file is to make a fairly static set of data that is managed at an administrative level, the user defined properties on the bar file is a better fit.
If the intent of the config file is to provide enduser input into configuring the business routing, then the database is the better fit.
But using a config file simply because someone likes config files is not a good design decision. |
|
| Back to top |
|
|
| ganesh |
| Posted: Wed Feb 08, 2012 6:47 am Post subject: |
|
|
Master
Joined: 18 Jul 2010
Posts: 294
|
To add to what mqjeff said, it is also not a best practice to use config files and should be avoided wherever possible.
| Quote: |
| Often, to separate configuration information from business logic, customers externalize configuration information to a file or database. This technique can reduce performance, because reading a configuration or parameters file is a one-time activity at the time of the first instance of a node is created or at the time the first message is processed, instead of a loop checkup for each message. Since Message Broker is more CPU-oriented than I/O-oriented, it is usually best to avoiding I/O operations involving files or databases when possible. |
http://www.ibm.com/developerworks/websphere/library/techarticles/0809_kudikala/0809_kudikala.html |
|
| Back to top |
|
|
|
|
