The digital signature was generated with an untrusted certificate.
This is telling.
Is signing the jar files in application is only way to avoid the security warning?
The Jars are apparently already digitally signed, but with an unverified certificate.
An unsigned app. would have a different warning (and Oracle has warned that in future, they will be defaulting the JVM to not run them at all).
An app. signed with a verified certificate will produce much the same warning as you are currently seeing, except the 'Publisher:' would be listed, and if the user ticks 'always allow' (which apparently no longer appears on self signed or unsigned code), the JRE will store and remember that decision.
Does signing jar file cost? Is there any way sign the jars for free?
The answer to the second question is 'how much does it cost you now?' The answer to the first is 'yes'.
Currently the services which runs on Tomcat7 as a JavaEE application is accessed by Web start application through http connection. Do I need to use https instead of http once the jars are signed?
No.
I found that I need to add the following tag to .jnlp file:
<security><all-permissions/></security>
Apart from above change is there anything else that I need to make in Java or xml files?
I doubt you need to specify that. Even a sand-boxed app. can 'phone home' to the same server. If digitally signed using a trusted certificate, the warnings will be more mild.
One thing you need to keep uppermost in your mind, is that all this security is not for the convenience of the developer, but the safety of the end user (and user confidence in the plug-in). So when you try to find 'room to squirm out of it' you are effectively trying to find security bugs in the JRE.
If you do find one, please let us know so we can raise a high priority bug report with Oracle, and get it fixed.