| Author |
Message
|
| er_pankajgupta84 |
 Posted: Fri Dec 09, 2011 8:59 am Post subject: Adding on to java favour |
 |
|
Master
Joined: 14 Nov 2008
Posts: 203
Location: charlotte,NC, USA
|
1. Java could be faster to process XML thru the use of XPATH.
2. Java can connect to almost all the DB.
3. You can use tools like FIndbug, PMD etc to do a code review of the java code so this might help in removing human generated error.
4. Java files (Jar) can be deployed separately from flow (I think in version 8 they have facility to deploy esql separately).
5. Dynamic loading of class. Effective and efficient use of it may turn your broker into process server (doing orchestration  ).
6. Frequent updation to java langauge (adding new construct).
People do see memory issues with java but those are bugs in the code. I agree that with esql that risk is lesser. A good programmer can easily overcome those issues. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Dec 09, 2011 9:34 am Post subject: Re: Adding on to java favour |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| er_pankajgupta84 wrote: |
| 1. Java could be faster to process XML thru the use of XPATH. |
XPath against the ESQL message tree? Cite your source!
| er_pankajgupta84 wrote: |
| 2. Java can connect to almost all the DB. |
Which DB can you get to with a JDBC that you can't with an ODBC.
| er_pankajgupta84 wrote: |
| 3. You can use tools like FIndbug, PMD etc to do a code review of the java code so this might help in removing human generated error. |
Granted. But in my day we did that with a thing called "testing".
| er_pankajgupta84 wrote: |
| 4. Java files (Jar) can be deployed separately from flow (I think in version 8 they have facility to deploy esql separately). |
AFAIK it's sub flows that can now be deployed separately. I'd also not be too quick to put the ability to just deploy jar files as a plus from a control perspective.
| er_pankajgupta84 wrote: |
| 5. Dynamic loading of class. Effective and efficient use of it may turn your broker into process server (doing orchestration ). |
There's no way this is an advantage. Even if you could do this "effeectively and efficiently" WMB is not process server any more than it's app server. Just because you can bend a tool successfully into a shape it's not designed for doesn't mean it won't break later.
| er_pankajgupta84 wrote: |
| 6. Frequent updation to java langauge (adding new construct). |
How many of these are valid in a broker environment? Unless you're turning it into WPS?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Dec 09, 2011 9:37 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
What was the purpose of reopeneing a thread that was more than 3 years old?
It is generally considered best practice to start a new thread and reference any old ones that may contain relevant information.
On the day that Broker 8 is available for download I'd be more inclined to open a new thread to debate the relative merits of coding broker flows using ESQL vs Java vs PHP vs .Net.
_________________
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 |
|
|
| Vitor |
| Posted: Fri Dec 09, 2011 9:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| What was the purpose of reopeneing a thread that was more than 3 years old? |
I wondered about that, but it is more or less relevant to the original discussion even if the points in the orginal thread are a few versions out of date.
And I couldn't let WMB = WPS go unchallenged!
| smdavies99 wrote: |
| On the day that Broker 8 is available for download I'd be more inclined to open a new thread to debate the relative merits of coding broker flows using ESQL vs Java vs PHP vs .Net. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Dec 09, 2011 9:45 am Post subject: Re: Adding on to java favour |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| er_pankajgupta84 wrote: |
| 1. Java could be faster to process XML thru the use of XPATH. |
XPath against the ESQL message tree? Cite your source! |
Aside from that, a bad XPATH expression will ruin performance and potentially hog memory much faster and much worse than a bad ESQL expression. |
|
| Back to top |
|
|
| inMo |
| Posted: Fri Dec 09, 2011 10:07 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
| Quote: |
| ... 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 ... |
The real question here is weather or not it is worth leveraging experienced WMB professionals. Knowing, or at least having an idea of strengths, capabilities, weaknesses and pitfalls of various approaches may be of value.
IMHO, a great starting question is why did the company invest in WMB? Were they actually looking for a Java Application Server and ended up with WMB by mistake? (a Java Application Server is effectively what you get with a flow model of Input->JCN->Output, and that flow model is predictable based on the stated qualifications of your team) |
|
| Back to top |
|
|
|
|
