| Author |
Message
|
| DJN |
 Posted: Mon Aug 25, 2008 3:15 pm Post subject: Java vs esql |
 |
|
Apprentice
Joined: 14 Apr 2003
Posts: 47
|
I would appreciate any and all feedback...
On a project where I am working they have decided to code all java compute nodes and pluggins and exclude as much esql as possible. I believe that they made this decision because they could not find enough message broker developers, so they converted a bunch of java coders into message broker developers. I was wondering if this is the general trend of the message broker or are they out there on their own? |
|
| Back to top |
|
 |
| AkankshA |
| Posted: Mon Aug 25, 2008 8:05 pm Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
No No No...
I would never recommend that...
eSQL is much easier and faster then java in MB for most of things...
also having all java nodes would hamper the performace too..
its always best to have not more than 1-2 java nodes in a flow ...
_________________
Cheers |
|
| Back to top |
|
|
| Maximreality |
| Posted: Tue Aug 26, 2008 2:23 am Post subject: Re: Java vs esql |
|
|
Acolyte
Joined: 04 Jun 2004
Posts: 65
Location: Copenhagen
|
Java is all about knowing the class library, for broker development in JCN you will probably use less than 1% of the class library in java.
The java developers might as well code in eSQL, as it is fairly easy to understand for any programmer.
Personally i think eSQL code is easier for most operations and gives a better understanding/overview of what is going on in the code. |
|
| Back to top |
|
|
| sandeep9678 |
| Posted: Tue Aug 26, 2008 2:25 am Post subject: |
|
|
Apprentice
Joined: 04 Aug 2008
Posts: 41
Location: India
|
From my experience I will never recommend the use of Java compute Node until there is absolute need and the things you cannot do in ESQL.
But ESQL is really easy, very fast and you will find very rare requirements which you cannot do in ESQL.
Use of JCN have some issues like performance, memory leakage. If somehow you get the memory leakage issue then you will have really bad time in MB.
So try to use esql as much as possible.
Also read the JCN issues on this forum.
Also go through the memory allocation for JCN at runtime. You will find esql is the best option.
_________________
Cheers,
Sandeep |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Aug 26, 2008 9:23 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| they converted a bunch of java coders into message broker developers |
It should be obvious, but the choice of Java vs ESQL should not depend only on the skill set of the developers.
Java sometimes performs faster than ESQL. Often, ESQL is faster and easier. It is not wrong to use Java in a message flow, and IBM has never said that 'Java is better than ESQL'.
You cannot 'convert Java coders into message broker developers'. If you try that, you will probably get Java applications which are triggered by a thin layer of message flow logic. Whatever the technical background, message broker developers need to properly understand the product and its advantages. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Aug 26, 2008 11:07 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The easiest way to "find" MB developers is to take people who know database SQL and give then a few days ESQL training.
Please don't make WMB into a Java wrapper - this would be a disaster for the product direction.
The broker message flows should be easy to understand and contain as little complex programming code as possible. Use the builtin features to the max - DON'T CODE unless absolutely no alternative.
Java is relatively low level. Keep WMB logic as high level as possible to make it easy to understand and maintain.
You don't need to find MB developers (i.e. ESQL experts) because it's so easy to use ESQL. Anyone with simple 3GL programming or SQL background can learn it almost overnight. |
|
| Back to top |
|
|
| broker_new |
| Posted: Wed Aug 27, 2008 6:33 pm Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
But in my experience most of the Java developers doesn't like to code the things in ESQL at all....even putting the performance overhead aside they like everything to code in Java.....Companies like Walmart they insist the Broker developers to use Java instead of ESQL (independent of requirement)......  |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 27, 2008 8:48 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| broker_new wrote: |
| But in my experience most of the Java developers doesn't like to code the things in ESQL at all....even putting the performance overhead aside they like everything to code in Java.....Companies like Walmart they insist the Broker developers to use Java instead of ESQL (independent of requirement)...... |
So what is the trouble? You can do all of the manipulations you would be doing in ESQL also in Java. Yes there is a learning curve but it should not be too steep if you already know Java. One reason to avoid using JCN is huge messages that would need a bigger java stack or heap.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Aug 27, 2008 9:58 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Developers who have done Java at University can sometimes become WMB developers without any proper WMB training.
When asked to develop something in WMB, they naturally revert to what they know best, even if it is the WRONG architectural choice.
The outsourcers need to train their developers properly or provide experienced mentors - that's the key here. The other factor is cultural - these developers need to try out new technology.
Experimentation is the key to learning - try ESQL out guys! |
|
| Back to top |
|
|
| Sridar |
| Posted: Wed Aug 27, 2008 10:12 pm Post subject: |
|
|
Acolyte
Joined: 14 May 2006
Posts: 72
Location: Chennai, India
|
Compute Node in general eats some performance compared to the other nodes due to the parsing.
When it is JCN you will lose a lot in performance and memory.
Well they don't even have to use JCN. using Java itself they can accomplish a lot.
Learning ESQL is no big deal. I learnt ESQL in just 3 days and started working on my own. Especially with IBM's help pages for all the functions and nodes and Forums such as these.
There is nothing wrong in learning a new technology. Infact i have now moved from a Web developer to an EAI developer.
Getting a WMB developer is not a big task also if your HR are looking at the right place.
Even otherwise you can get a 3 day or a 5 day Training from IBM.
_________________
Thanks and Regards
Sridar |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Thu Aug 28, 2008 10:37 pm Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
And if you want to have as vendor / product independent solutions as it is possible(with WMB) you might consider use xslt:s to map xml messages.
And when choosing to use java or esql you can think is there possibility to come out something reusable (for other applications), and then think about performance issues and other things...
Marko |
|
| Back to top |
|
|
| mq_blr |
| Posted: Wed Sep 10, 2008 3:15 pm Post subject: any docuemnt on this |
|
|
Apprentice
Joined: 30 Sep 2005
Posts: 49
Location: Brisbane,Australia
|
I would love to see any document/recommendations some thing like pros and cons
regards
Durga Prasad |
|
| Back to top |
|
|
| billybong |
| Posted: Thu Sep 11, 2008 5:51 am Post subject: |
|
|
Disciple
Joined: 22 Jul 2005
Posts: 150
Location: Stockholm, Sweden
|
From my own perspective being one who started as a java coder and later became an EAI consultant I have to say ESQL is preferred in almost all situations.
ESQL is basically more easy to read, uses less overhead and just "feels" safer to me. Add the fact that you have code completion on modelled messages in ESQL while jcn mostly uses Xpath strings its faster to develop too.
From my pow I tend to use ESQL for everything unless I have to design something which could only be implemented by using an external java API.
And as other have stated, try to use as little code as possible. If there is a way to acheive the same result with the given tools (nodes etc) that should always be your first option.
_________________
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Integration Developer V6.0
IBM Certified System Administrator - WebSphere MQ V6.0
IBM Certified Solution Developer - WebSphere DataPower |
|
| Back to top |
|
|
| MrSmith |
| Posted: Fri Sep 12, 2008 3:40 am Post subject: |
|
|
Master
Joined: 20 Mar 2008
Posts: 215
|
DJN
I am sorry but if you have a HR department then sack them cos they didn't spend anywhere near enough time looking for resources. If they wanted permies then maybe the process is longer admittedly but there is a reasonable pool of contract WBIMB people out there anhd they could have got their local agencies or some of those that scout on here to have provided your resourc. I expect there will be the discussion of cost and you can always train in-house in conjuction with your contractors and kill moer than one bird with your stone. As was said previously you don't choose a technology or bandage one in based on your current resource that spells D.I.S.A.S.T.E.R. JCN and ESQL have their strengths and places and that would be apparent in the extensive up front design on which i am sureyour embarking right ?????? |
|
| Back to top |
|
|
| JLRowe |
| Posted: Fri Sep 12, 2008 3:57 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
If I could pitch in from a java perspective:
* By being statically typed, java is designed to catch as many errors as possible during the compile phase. The java editor in eclipse is also much more comprehensive than the esql editor.
* Java code is more re-usable. Of course if your are coding to the message broker api then this is a moot point. But it is possible if careful to re-use message broker java code outside of message broker and of course emply the vast army of available java libraries in your message broker code.
* In terms of raw speed, Java will be faster. I don't know if esql is compiled or interpreted, but JVM's have been around for over 12 years now and improvements to performance are constantly being made by all the vendors. Typical message broker code spends a lot of time parsing or in the database, so there will not be much of a difference for message flow performance.
* I have seen threads about memory leakage in the JCN, but have not encountered it myself. I would say this is not a problem inherent in java, but perhaps message broker constructing a new instance for each message and keeping hold of the old references? If this is indeed a bug, I would say it is pretty fundamental and has probably been fixed already? |
|
| Back to top |
|
|
|
|
