CODEWITHSUNDEEP
javajavascriptadapteribm-mobilefirst
user3036762
user3036762

Reputation: 15

Worklight Adapters - Java vs JavaScript

Is there any drawback to having the JavaScript Worklight adapters calling Java code? Is there a performance hit, or any caveats?

The reason I ask, is that 1) I'm much more familiar with Java than JavaScript, and 2) Java is so much more powerful than JavaScript. I'm tempted to just have the adapter always call a Java class to do all the work, but I'm just concerned there might be some reasons I shouldn't.

Upvotes: 1

Views: 990

Answers (4)

christianmenkens
christianmenkens

Reputation: 790

I can only support ravidor's statement here. Since all JavaScript in the Adapter is executed in the Java-based Rhino Javascript engine inside the Servlet and the same Servlet Context, the call of a Java Class or instantiating a Java Object does not have impacts. Running a complex code in Java might even be faster.

Nevertheless, when leaving Javascript and moving to Java you are loosing some of the architectural modularization of the adapters. All Java code is in the one Java source folder and all code has to be deployed with the full WL Console. You are loosing the loose and modular nature of the Adapters that can be maintained and deployed independent.

Also, the Worklight security framework with it's security tests and realms and all is tailored towards securing Adapter procedures.

Also, you are loosing the out-of-the box code for HTTP, SQL, etc. network communication that the Javascript adapter does automatically. If you are falling back to Java and need to call your back-end you need to code all of that network communication yourself. As well as some of the JSON transformation.

We had discussions in our projects and we ended up going with a good mix of Java for more complex data processing components and with Javascript for much of the network calls and the worklight security. In one project we even used full Groovy on the Adapter Java side and it worked fairly good. Sometimes we ran into problems with thread pooling and things like that.

Upvotes: 3

Raanan Avidor
Raanan Avidor

Reputation: 3583

There are no drawbacks in calling Java code from the JavaScript Worklight adapters.
There are no performance hit or any other caveats.
If you feel more comfortable writing Java instead of JavaScript then you should do so.
The invocation of the adapter procedure from the client side will call the JavaScript function, from it you can call your Java code that will return to the JavaScript function and from there respond to the client with the invocation results.

Upvotes: 2

Joshua Alger
Joshua Alger

Reputation: 2132

Using Java inside of your adapters is meant as "an extension of the adapter function and not a replacement". Worklight does provide a full tutorial and even sample code of implementing java inside of your adapter which can be found here:

Using Java in adapters presentation:

http://public.dhe.ibm.com/software/mobile-solutions/worklight/docs/v610/04_08_Using_Java_in_adapters.pdf

Using Java in adapters sample:

http://public.dhe.ibm.com/software/mobile-solutions/worklight/docs/v610/WorklightAdaptersProject.zip

As the sample mentions using java inside of your adapters is meant as an extension in cases "Where JavaScript is not enough to implement [specific] functions, or a Java™ class [already] exists". Again this is meant as "an extension of the adapter function and not a replacement".

Upvotes: 3

Bluewings
Bluewings

Reputation: 3488

AFAIK there won't be any problem if you are not using JAVA for backend calls.also to make a note whenever there is a change in your java you might needs to redeploy the war again. In another case if it is JavaScript it is easy to deploy the adapters in worklight server

Upvotes: 0

Related Questions