| Author |
Message
|
| adubya |
 Posted: Thu Sep 01, 2016 6:51 am Post subject: |
 |
|
Partisan
Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK
|
I prefer to use ESQL but do dip into Java occasionally to make use of Java library capability which isn't available to me in ESQL.
_________________
Independent Middleware Consultant
andy@knownentity.com |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Sep 01, 2016 6:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| 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? |
I'm guessing this is something like JAXB, where the JSON becomes java objects.
But it's really not clear why that would be needed, even in a JCN. You're still working with JSON data under the covers. So using a string of getters/setters on an object tree doesn't make a lot of difference. If you want to get down to a subset of the JSON document, you can use a pointer/reference/object of MbElement type that binds to the right place in the JSON tree.
And then you can use MBElement getters and setters, just like you can use JSON parser getters and setters.
A technical preference, btw, is not a usecase. it's a technical preference. So "required to convert from JSON to Java and vice-versa" is a technical preference (and not even a technical requirement) and not a usecase.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| vishBroker |
| Posted: Thu Sep 01, 2016 6:57 am Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
THe use case was to expose Spring services as RESTful APIs via IIB.
We did use JSON parse to parse the incoming JSON. Then we JCN to convert incoming json to java and call spring method.
(We do use, ESQL as well to do some pre-processing and store some Environment variables and use GC as well)
Anyway - all I wanted to share was - it depends on the usecase whether to use java or ESQL or both. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 01, 2016 7:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vishBroker wrote: |
THe use case was to expose Spring services as RESTful APIs via IIB.
We did use JSON parse to parse the incoming JSON. Then we JCN to convert incoming json to java and call spring method. |
That's not really helped me, but thanks for trying 
Java. Bah.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vishBroker |
| Posted: Thu Sep 01, 2016 7:33 am Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
| Vitor wrote: |
| 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"? |
Retrying -
Try {
1. The target service is spring remote service. The method(s) that will be called, expects JAVA objects.
2. The JSON is required to be converted into corresponding JAVA object - on the fly.
3. Clients Spring services(java code) was not having any annotation to get them converted into RESTful APIs using existing 3rd party tools.
4. THe JCN uses JACKSON interfaces to do the required conversion.
}
Catch
{
I felt it much easy to convert JSON in to corresponding JAVA class in JCN. I did not find any mechanism to do so in ESQL.
}
Finally
{
There is no point in comparing ESQL and JAVA. Both have their strengths. It depends how you are using (or misusing) them.
}
} |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 01, 2016 7:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So you were running the Spring code inside the broker JVM? Or in a separate JVM that you were using RMI to talk to?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 01, 2016 8:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vishBroker wrote: |
| Vitor wrote: |
| 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"? |
Retrying - |
Still no luck but to be clear, the problem is with my understanding not your explanation.
Java. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Sep 01, 2016 8:44 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
Java. |
Java is a FOUR letter word. Don't need to say much more.
My personal thoughts about Java
I've programmed for 40+ years and used strucured languages, assembler and even flight critical software with ADA and Java is IMHO just about the worst language as far as implementaton goes that I've ever encountered and that includes Lisp and Forth. The language is fine but the class libraries that call other CL's and other CL's and .....
There are a multitude of bad habits in use by Java devs all over the world. We see that here with the misuse of Log4J in an IIB Environment.
One IIB dev I worked with was fond of dropping into Jave at almost every opportunity. He then proceeded to use all sorts of 3rd party class libraries to do stuff that was plain and simple in ESQL. He got banned from using Java after one of his flows was left on test over a long weekend. We returned to the office on the Tuesday and found that the test system had 'stopped' because the /var/tmp filesystem (all 100Gb of it) have been filled with the Logfiles generated by this flow at it processed 480K messages.
I do know that there are good Java devs out there but I really do not like mixing it up in IIB. I even know of a project where they call Java from XSLT from IIB. The Java reads flat files to help in the transformation (content based). Each file is read for every message. A performance and support nightmare.
Java is a four letter word IMHO.
_________________
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 |
|
|
| timber |
| Posted: Thu Sep 01, 2016 11:23 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Quote: |
| The method(s) that will be called, expects JAVA objects |
Fair enough - that means that the message flow is forced to create Java objects. Java might just be the correct choice for that task  |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Sep 01, 2016 11:42 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
| Vitor wrote: |
| zpat wrote: |
| That's why Java is so dangerous - developers don't read the IIB manual. |
In fairness, no-one reads the manual...... 
|
I always read the manual. Coming from Sysprog background when my Assembler code could wreck the entire system if a single bit was out of place.
With ESQL it's essential to know the functions provided - and it's pretty rich in string handling. Almost as good as REXX.
Now - why didn't the IBM WMB developers just have a chat with Mike Cowlishaw at Hursley and adopt REXX for the broker language? 
_________________
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: Fri Sep 02, 2016 12:39 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| zpat wrote: |
Now - why didn't the IBM WMB developers just have a chat with Mike Cowlishaw at Hursley and adopt REXX for the broker language? |
Perhaps they thought (at the ttime) one or more of the following...
1) REXX and Mainframes were going the way of the Dodo
2) More people knew at least some SQL
you could always submit an RFE for a REXX compute Node. 
_________________
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 |
|
|
| zpat |
| Posted: Fri Sep 02, 2016 1:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
REXX has been available on all IBM platforms (remember SAA?).
Object REXX, and NetREXX are open source now (and an ISO standard).
But I think Unix fans prefer cryptic, unreadable, scripting languages. Also they like to invent yet another one every year or so.. 
But ESQL is pretty decent (a bit REXX or PL/I like in fact).
_________________
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 |
|
|
| mqjeff |
| Posted: Fri Sep 02, 2016 4:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'm sure someone could write a custom Broker node that can use Rexx...
But not me...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
|
|
