| Author |
Message
|
| mqjeff |
 Posted: Fri Jun 21, 2013 4:39 am Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqsiuser wrote: |
Mapa is not (even) mentioning XSLT. Thank you!
| mapa wrote: |
| switching from cardinality+while to for+reference |
I thought it is while (do, LASTMOVE) + references?
For ... what? EACH? ... (I guess no "i++") ? |
| Code: |
| FOR myReference AS InputRoot.XMLNSC.Body.Row[] DO |
And kash3338 - http://en.wikipedia.org/wiki/Mu_%28negative%29 |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Jun 21, 2013 7:23 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Wow! that's deep thinking!! Un-ask the question i.e. not applicable!!! 
darn contact admin!
_________________
MQ & Broker admin
Last edited by fjb_saper on Fri Jun 21, 2013 7:48 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 21, 2013 7:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
Wow! that's deep thinking!! contact admin the question i.e. not applicable!!! |
Or simply obnoxious. I leave it up to the reader. |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Tue May 31, 2016 9:09 am Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
From my experience, I found that the Java API for IIB/WMB was terrible. Hence why most recommend sticking purely to ESQL for all the mediation logic.
While I agree that ESQL should have everything you need, in some cases ESQL syntactically becomes very verbose. I have seen some ESQL code that is syntactically a nightmare. Some of this code could have easily been written with Java in a few lines. The same goes for contact admin Java code to ESQL.
I would argue that the Java community continues to grow and prosper where ESQL is stagnant. You can find Java developers almost anywhere, but finding ESQL developers is difficult. Compare ESQL to modern Javascript or Groovy's XmlSlurper API and I would argue the latter are far superior for writing logic for mapping unstructured data and other advanced techniques. Unfortunately WMB doesn't support Javascript. You can use Groovy but it seems rather pointless since the WMB provides very good data mapping features.
So basically stick to ESQL, in rare cases you may need to use Java (e.g. maybe you need to call a 3rd party API). I recommend when doing Java, consider looking at Groovy's XmlSlurper class for unstructured data, or JAXB for structured data. Stay clear from WMBs Java DOM API. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 31, 2016 11:28 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| sleepyjamie wrote: |
From my experience, I found that the Java API for IIB/WMB was terrible. Hence why most recommend sticking purely to ESQL for all the mediation logic.
While I agree that ESQL should have everything you need, in some cases ESQL syntactically becomes very verbose. I have seen some ESQL code that is syntactically a nightmare. Some of this code could have easily been written with Java in a few lines. The same goes for contact admin Java code to ESQL.
I would argue that the Java community continues to grow and prosper where ESQL is stagnant. You can find Java developers almost anywhere, but finding ESQL developers is difficult. Compare ESQL to modern Javascript or Groovy's XmlSlurper API and I would argue the latter are far superior for writing logic for mapping unstructured data and other advanced techniques. Unfortunately WMB doesn't support Javascript. You can use Groovy but it seems rather pointless since the WMB provides very good data mapping features.
So basically stick to ESQL, in rare cases you may need to use Java (e.g. maybe you need to call a 3rd party API). I recommend when doing Java, consider looking at Groovy's XmlSlurper class for unstructured data, or JAXB for structured data. Stay clear from WMBs Java DOM API. |
You are conveniently forgetting that in some versions (depending on your licensing) ESQL is not at your disposal and you will have to use the Java API.
The Java API to manipulate the message tree is not overly complex and can be learned quickly by a skilled java programmer.
Like in all things it takes a modicum of skill and you will not be successful with the monkey programming technique...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue May 31, 2016 11:40 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Also, in later versions of WMB, you can use JAXB to access/transform the message tree...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Tue May 31, 2016 12:31 pm Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| fjb_saper wrote: |
| sleepyjamie wrote: |
From my experience, I found that the Java API for IIB/WMB was terrible. Hence why most recommend sticking purely to ESQL for all the mediation logic.
While I agree that ESQL should have everything you need, in some cases ESQL syntactically becomes very verbose. I have seen some ESQL code that is syntactically a nightmare. Some of this code could have easily been written with Java in a few lines. The same goes for contact admin Java code to ESQL.
I would argue that the Java community continues to grow and prosper where ESQL is stagnant. You can find Java developers almost anywhere, but finding ESQL developers is difficult. Compare ESQL to modern Javascript or Groovy's XmlSlurper API and I would argue the latter are far superior for writing logic for mapping unstructured data and other advanced techniques. Unfortunately WMB doesn't support Javascript. You can use Groovy but it seems rather pointless since the WMB provides very good data mapping features.
So basically stick to ESQL, in rare cases you may need to use Java (e.g. maybe you need to call a 3rd party API). I recommend when doing Java, consider looking at Groovy's XmlSlurper class for unstructured data, or JAXB for structured data. Stay clear from WMBs Java DOM API. |
You are conveniently forgetting that in some versions (depending on your licensing) ESQL is not at your disposal and you will have to use the Java API.
The Java API to manipulate the message tree is not overly complex and can be learned quickly by a skilled java programmer.
Like in all things it takes a modicum of skill and you will not be successful with the monkey programming technique... |
Oh god... If someone forced me to use WMB witht he Java API over the ESQL then I think I would quit.
While the Java API is not overly complex, it is definitely overly verbose for performing simple tasks.
As a Java programmer who has worked with many Java DOM APIs, I always favour JAXB if the data structure is well defined. But JAXB is often overkill, which is the reason why companies are adopting JavaScript and Groovy. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 31, 2016 1:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| sleepyjamie wrote: |
Oh god... If someone forced me to use WMB with the Java API over the ESQL then I think I would quit.
While the Java API is not overly complex, it is definitely overly verbose for performing simple tasks.
As a Java programmer who has worked with many Java DOM APIs, I always favour JAXB if the data structure is well defined. But JAXB is often overkill, which is the reason why companies are adopting JavaScript and Groovy. |
Now, now... the truth is far less drab then you define it. And by the way you can always use SONAR (or some other java modelling tool) to make sure you hit the 85 % and do not repeat too much code....
Don't know where you're going with overly verbose... but it's not so different... from ESQL... once you get into it...
You need to put on a different set of glasses, may be take a shot or 2 and have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sleepyjamie |
| Posted: Tue May 31, 2016 1:21 pm Post subject: |
|
|
Centurion
Joined: 29 Apr 2015
Posts: 135
|
| fjb_saper wrote: |
| sleepyjamie wrote: |
Oh god... If someone forced me to use WMB with the Java API over the ESQL then I think I would quit.
While the Java API is not overly complex, it is definitely overly verbose for performing simple tasks.
As a Java programmer who has worked with many Java DOM APIs, I always favour JAXB if the data structure is well defined. But JAXB is often overkill, which is the reason why companies are adopting JavaScript and Groovy. |
Now, now... the truth is far less drab then you define it. And by the way you can always use SONAR (or some other java modelling tool) to make sure you hit the 85 % and do not repeat too much code....
Don't know where you're going with overly verbose... but it's not so different... from ESQL... once you get into it...
You need to put on a different set of glasses, may be take a shot or 2 and have fun |
haha only if i could drink at work. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 01, 2016 3:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The thing about JAXB is that in later (i.e. current) versions of WMB/IIB you can use JAXB to access the logical message tree.
So by the time it gets to your JCN, the data you're accessing should already be structured...
If you're trying to use a JCN to muck about with a BLOB, then you're doing it wrong.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Sep 01, 2016 1:35 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
I caught a developer doing exactly that - calling a JAR from a JCN to parse his JSON message.
That's why Java is so dangerous - developers don't read the IIB manual.
ESQL is easy to learn and making them read the IIB documentation is a good thing.
_________________
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 |
|
|
| Vitor |
| Posted: Thu Sep 01, 2016 5:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| That's why Java is so dangerous - developers don't read the IIB manual. |
In fairness, no-one reads the manual...... 
IMHO Java is so dangerous because IIB is the only place in JavaLand where your Java is not sitting on top of an application server and you have all sorts of inbuilt features (like the ability to parse JSON). So the Java developers that you can find everywhere do what they do every time they've ever written Java - call out to a JAR to parse messages, use JMS directly to access a queue manager, find creative places to put properties files and spend ages looking for a console where they can set up JNDI. Also they never bother to clean up their objects because the garbage collection does that for you.
All of this is good Java programming practice. Except in IIB. And it gets you every time. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 01, 2016 5:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Someone should write a devworks article or something on "How to break IIB using a JavaCompute node".
Someone other than me.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| vishBroker |
| Posted: Thu Sep 01, 2016 6:27 am Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
My $0.02 -
Well, why compare oranges and apples?
It depends on the usecase.
We recently worked on a usecase - where we were required to convert JSON to Java and vice-versa.
That was just not possible with ESQL.
As a thumb rule, we recommend clients using Java or ESQL as per their resources' comfort level. If client is a majority a Java shop - then use JCN otherwise use ESQL.
Performance wise, I have not seen much difference for simple transformations done by ESQL or JAVA - rather was not able to notice any difference. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 01, 2016 6:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vishBroker wrote: |
We recently worked on a usecase - where we were required to convert JSON to Java and vice-versa.
That was just not possible with ESQL. |
Forgive my ignorance, but what do you mean by "convert JSON to Java"? How does that differ from parsing JSON with IIB and processing it with any of the programming languages?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
