| Author |
Message
|
| kolban |
 Posted: Mon Oct 06, 2003 2:22 pm Post subject: Announce: JavaScript plugin node for Message Broker V5 |
 |
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Folks,
As I went around teaching and showing Message Broker V5, I continually got bombarded with the question "Why ESQL?". User after user commented on the use of ESQL as the scripting language.
In an attempt to address this concern, I have designed and developed a new plugin node for Message Broker V5 that provides "JavaScript" as a scripting language alternative to ESQL.
The results are beyond my expectations ... I now offer this to you for early alpha testing ...
The package and documentation can be down loaded from:
http://www.kolban.com/mbjavascript/
The package comprises a single ZIP file and a PDF document. Review the PDF file which also contains installation instructions.
Comments welcome ... lets all become JavaScript programmers ... it is soooo easy and powerful!!!
Please post back to this posting for questions and comments ... please do NOT email me directly. There is no formal support for this plugin. |
|
| Back to top |
|
 |
| gabbar |
| Posted: Thu Oct 09, 2003 10:35 am Post subject: Results |
|
|
Acolyte
Joined: 10 Dec 2002
Posts: 50
|
| Quote: |
| The results are beyond my expectations ... |
By results do you mean, JavaScript resulted in better performance? Compute nodes are the slowest nodes, may be because of ESQL. If JavaScript or any other language is improving the performance, then that definitely should become an alternative to ESQL. Please let me know if you could do any performance tests. WMQI performance has been a major issue in our implementation.
Thanks |
|
| Back to top |
|
|
| kolban |
| Posted: Thu Oct 09, 2003 11:43 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
I did some performance measurements which are included in the documentation.
The JavaScript executes 5x faster (for my tests) than ESQL.... with the exception of message tree access. This was actually slower in JavaScript than ESQL. We believe the reason to be the JNI crossing bridge in the IBM API for accessing message trees in Java. |
|
| Back to top |
|
|
| kolban |
| Posted: Fri Oct 10, 2003 8:48 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Folks,
Its all been very quiet on this topic. Are you having problems with the package? Do you need assistance with its applicability? |
|
| Back to top |
|
|
| wmqiguy |
| Posted: Fri Oct 10, 2003 9:20 am Post subject: |
|
|
Centurion
Joined: 09 Oct 2002
Posts: 145
Location: Florida
|
At the risk of opening Pandora's box.......I'll throw out quick question. 
I liked the general concept, but then it hit me. If I'm using Java-based code anyway, why not just buy Websphere App server and just start building everything there? I can use JDBC instead of database nodes, etc.
I'd still want MQ for asynch (and the like), but why not just move all of my transformation routines into an App Server? |
|
| Back to top |
|
|
| kolban |
| Posted: Fri Oct 10, 2003 10:33 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Ahhh ... now THERE is a good question.
Firstly, in WMQI (Message Broker) today, if you want to describe transformation logic and other tasks, you are limited to using ESQL as the language in which to describe the logic. User after User has asked me about alternate languages ... so here is a satisfaction of that request/requirement. Now one can describe the logic in JavaScript and/or scripted Java. This is the major component of this announcement, the ability to do things in Message Broker that were not do-able before.
On the concept of doing this stuff in a WebSphere J2EE environment, now we get into the state of "build vs buy". With J2EE, you currently have to write code and all sorts of middle ware plumbing. Message Broker and its brethern raise the bar in this area and provide high level capabilities where, only if you have to, do you drop down into code fragment writing. The infrastructure surrounding that code is provided for you.
Hey .. that my $0.0.2  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 10, 2003 10:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| kolban wrote: |
| Firstly, in WMQI (Message Broker) today, if you want to describe transformation logic and other tasks, you are limited to using ESQL as the language in which to describe the logic |
Or write a custom plug-in using C or Java.
Or use the Perl support pack to use Perl code.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kolban |
| Posted: Fri Oct 10, 2003 12:32 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Yup, that is most true ... my hope though is that the JavaScript node will make life much simpler than coding a C or Java custom node ...
As for PERL, I realize it has a huge following but, unfortunately, PERL isn't to my taste and I can't help but think that there are a larger number of Java and JavaScript users that there are PERL.
But I do realize that may be an academic question. The underlying concept here is that by providing JavaScript support ... Message Broker utilization has potentially been pushed that much further along. Just another weapon in the arsenal of tools and techniques. No more and no less |
|
| Back to top |
|
|
| duffMan |
| Posted: Sat Oct 11, 2003 4:03 am Post subject: |
|
|
Voyager
Joined: 03 Jun 2002
Posts: 75
|
Getting back to the performance issues...
When you say JavaScript is about 5X faster than ESQL, except in the case of message tree operations you are talking about interogating the message tree via commands as simple as:
SET OutputRoot.XML.MyOutXML.HelloWorld = InputRoot.XML.MyOutXML.GoodByeWord;
If that is the case, 90% of my use of MQSI (at present) is of that fashion.
You also state that the reason for the lack of performance (you think) is because of the use of JNI to access message tree operations in JAVA via IBM API's. I am one to know very little about Java, but are you saying that I could write a custom JAVA node to perform commands as the ones above and improve my performance of such operations rather than ESQL.
Just trying to understand how I can make us of plug-in node technology at our installation.
thanks. |
|
| Back to top |
|
|
| kolban |
| Posted: Sat Oct 11, 2003 3:54 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Not a 100% sure what you are asking ...
The JavaScript node allows access to the Java classes supplied by IBM to develop custom Java Nodes. These classes utilize JNI to access the C API used to access the message trees. It is my understanding that compared to the C API, the Java classes for accessing the message trees may be up to 5x slower.
So, for optimal performance, it looks like the C language API should be used.
Compared to ESQL instructions, it appears that JavaScript processing may be 5x faster (generalization) ... so if all one is doing is message tree assignments, ESQL may be preferred but if one mixes in other logic such as string manipulation or loops, JavaScript may have the edge. |
|
| Back to top |
|
|
| kolban |
| Posted: Mon Oct 13, 2003 7:22 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
New Update:
Just posted a refresh of package and documentation.
The JavaScript support now includes entry assist for variables supplied as properties and a new example illustrating how Message Broker can handle serialized Java Objects.
http://www.kolban.com/mbjavascript/ |
|
| Back to top |
|
|
| JLRowe |
| Posted: Tue Oct 14, 2003 4:22 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
Kolban,
Just a thought...
With regards to the performance for calling the Java plugin API, have you tried benchmarking the same code compiled as a class and deployed as a plugin?
JavaScript probably has to use reflection to call the methods, and this can be very slow.
Cheers,
Jonathan |
|
| Back to top |
|
|
| kolban |
| Posted: Tue Oct 14, 2003 6:23 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Now THERE is a good idea ... I will do that task today.
...
Later ... you were bang on ...
A 20,000 iteration set loop in ESQL took 47 msecs.
A 20,000 iteration set loop in a custom Java node took 63 msecs.
A 20,000 iteration set loop in JavaScript took 450 msecs.
So the thinking that this is expensive through reflection is probably sound. I'll look into this and see what can be done but it may just be the nature of the beast.
Still, the richness in functions and access to all the other goodies still makes JavaScript a more than viable option. |
|
| Back to top |
|
|
| JLRowe |
| Posted: Tue Oct 14, 2003 9:08 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
Well,
I agree wholely, give me Java over ESQL anytime...
One solution may be the apache project Bean Scripting Framework, I haven't looked at your source so I don't know which javascript engine you are using, but BSF has an object registry which sounds like it avoids constantly reflecting on external methods by caching them:
http://jakarta.apache.org/bsf/
In addition, it supports other 'esoteric' scripting languages: Python, TCL, Rexx, Ruby.
I've been thinking that until IBM come up with the goods, and send WBIMB down the J2EE road, an eclipse plugin could be written for a compiled java node. The editor is there in eclipse, WBIMB supports debug of java nodes, the only problem is deployment, getting the classes into the jplugin directory of the broker.
The current way of doing plugins by copying the plugin into the eclipse/plugins directory and copying the jar onto the broker is just too cumbersome for serious development.
As for the advantages of Java over ESQL, these are too numerous to list, but include strong typing (catch more errors at compile time) and the biggest baddest API around. Imagine calling EJB's to update a database instead of the cludgy PASSTHRU()  |
|
| Back to top |
|
|
| kolban |
| Posted: Tue Oct 14, 2003 9:39 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Jonathan,
The Scripting engine used is Mozilla Rhino. Looking at the BSF docs, it does appear that Rhino is supported through BSF so that may be an interesting examination. |
|
| Back to top |
|
|
|
|
