| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| ESQL or Java #beginner |
« View previous topic :: View next topic » |
| Author |
Message
|
| saviobarr |
 Posted: Wed Oct 22, 2014 5:04 am Post subject: ESQL or Java #beginner |
 |
|
Centurion
Joined: 21 Oct 2014
Posts: 100
Location: Sao Paulo, Brazil
|
Hi all,
What are the vantages and disavantages of using ESQL and Java Compute for message processing and transformation? When should a developer choose one over other?
Many thanks again
Savio Barros |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Oct 22, 2014 5:16 am Post subject: Re: ESQL or Java #beginner |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| saviobarr wrote: |
| What are the vantages and disavantages of using ESQL and Java Compute for message processing and transformation? |
ESQL is native to IIB and has functions more closely tied to broker concepts (like the message tree). Java has more common syntax (like XPath) and can be extended by the use of 3rd party jar files, which is a problem that makes ESQL a better choice....
| saviobarr wrote: |
| When should a developer choose one over other? |
If the developer has existing Java skills it makes no sense to learn a new language, it makes more sense to learn the difference between a Java Compute node and (for example) a Java MDB. It's the failure to recognise these differences and code appropriately for them that's the source of most of the "I'm having problems with Java" posts in this section. Along with rants from people like me who are sick of Java people loading down the broker with jars they think they need but don't. Specific examples of this poor coding practice include but are not limited to:
- assuming you don't need to clean up at the end of a Java Compute Node because the garbage collection will do it for it
- assuming you don't need to rethrow unhandled exceptions because they'll automatically escalate somewhere
- assuming you can use JMS to send and receive messages inside the JCN
If the developer has existing database or procedural language skills then ESQL is probably a better fit. You'll find much abstract discussion here on which language "performs better"; IMHO you'll get more "performance" out of writing good code in either language than you will from the underlying language support. While ESQL is native and runs somewhat faster in a pure benchmark, a well written piece of Java will outperform a badly written piece of ESQL in the real world.
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Wed Oct 22, 2014 5:19 am; edited 1 time in total |
|
| Back to top |
|
|
| MB Developer |
| Posted: Wed Oct 22, 2014 5:18 am Post subject: |
|
|
Disciple
Joined: 03 Feb 2014
Posts: 179
|
Compute -- ESQL code (like SQL )
JavaCompute Node -- Javacode
--> Compare to Java code ESQL code is easy.
--> Less code is enough for ESQL
---> If you are very well in java then you have to choose java compute node otherwise ESQL is better
--> for more goto infocenter ....
_________________
Thanks.... |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Oct 22, 2014 5:23 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
ESQL is very easy to learn/use.
It makes you think "WMB/IIB" and read the help information.
Actually reading about the WMB product seems to be optional to many developers if you let them use Java. It's not optional for proper use.
The danger with using Java is that you code in an inappropriate way for WMB, not learning the proper way to do things.
As someone working in support, flows coded in Java cause 80% of our problems, sometimes hard to solve JVM related issues (even though 80% of our flows are in ESQL!).
You should not be coding very complex compute nodes - the point of the IBM product is to reduce coding, not act as yet another application server.
Never ever allow developers to use any external JAR files, unless they convince a WMB expert that there is no alternative.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Oct 22, 2014 6:49 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I saw a Java coding problem cause an EG memory size to rise from 500Mb to 23Gb. It was very difficult to diagnose.
Sort of backs what zpat was saying.. Mind you you can cause huge problems by simply wiring things up incorrectly. For example, loops in nodes and not in code.
Broker/IIB is a very complex tool. Even us experienced devs don't know everything about everything and do make mistakes. Personally, I now refuse to code anything for Broker in Java simply because it takes longer and is harder to find bugs when things go wrong. Oh, don't even mention log4J in my presence. It is not the solution to anything in the Broker world.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
