• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

J2EE Client Application - Part II

 
Kartik Shah
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
This queries are related to Part II
1. How does having J2EE application client improves the reponse time ? (Remember there is hard requirement there !!!)
2. How does a J2EE Application Client "Securely" connects to the J2EE application components( EJBs, etc ). Constrained specified is that it must operate on HTTPS protocol.
3. Looking at the different options specified in Blue print for the Application Client.
Is Java Web Start and option with J2EE 1.2 ? If yes does it support HTTPS ?
4. Only feasible option ( to me ) is using applet and then doing applet to servlet communication to get application to send HTTPS ?
5. Considering the Interview with CIO and CEO and thier bend towards "Application" and "GUI..." What happens to re-usability... Are we suggesting to duplicate Client TIER for just 20 Users ? ( I know BAs out there will come and say "but those 20 users bring 60% of the business... blah blah blah..")
Thanks and Regards,
Kartik Shah
 
Harsh Deshpande
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kartik,
I haven't finished and submitted the assignment yet but here is what I think.
1. J2EE client can talk directly with the EJB tier so you do not have to talk to the web tier and do all sores of request/response manipulation. This improves response time. Please note that standalone Java client can also talk to teh EJB tier but you will have to hand code some stuff.
2.If you use J2EE client (vs the Java client), it uses the built in security, JNDI access and other good stuff in the J2EE for accessing the EJB tier. Also, the RMI-IIOP communication is taken care of by the J2EE client container.
3.I don't know the answer to 3.
4.Why do you want to do Applet Servlet communication? I don't remember the exact requirements but it just talks about having secured communication using SSL and I believe RMI-IIOP can be used over SSL. No need for HTTPS.
Also, if you do want to do HTTPS, can't you do it using URLConnection?
5. I don't know what to say on this one. I can book a ticket for myself using some jazzy UI on a website but when i go to a travel agent, they use the command line system to talk to SABRE servers.
Please let me know your views too.
Harsh
 
Kartik Shah
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your reply.

4.Why do you want to do Applet Servlet communication? I don't remember the exact requirements but it just talks about having secured communication using SSL and I believe RMI-IIOP can be used over SSL. No need for HTTPS.
Also, if you do want to do HTTPS, can't you do it using URLConnection?

I didn't have any idea of how to use RMI-IIOP over SSL so I was thinking to use URLConnection and do it over HTTPS. That was the reason I was bit concerned about the Response time.. Because using HTTPS I will still have to use the same web tier...Right ?

2.If you use J2EE client (vs the Java client), it uses the built in security, JNDI access and other good stuff in the J2EE for accessing the EJB tier. Also, the RMI-IIOP communication is taken care of by the J2EE client container.

1. Can you tell me more about J2EE Client ( Vs Java Client)
2. Just out of curiosity, can you lead me to any pointers for using RMI-IIOP over SSL ??
Thanks and Regards,
Kartik Shah
 
Shakti Sharma
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kartik,
There are two problem, One Firewall and other security. That is handled by RMI.
For security yiu can use secure socket factroies . As part of JSSE, javasoft ships an implementation of SSL. More precisely, JSSE contains the javax.net.sll package, which contains two socket factories
SSLSocketFactory
SSLServerSocketFactory
For Firewall
RMI's HTTP tunneling mechanism: it will encode remote method invocation as HTTP POST requests, and then decode the returent "web pages" into the approprite type of response. RMI accomplishes this seamlessly by using an elaborate type of custom socket as the default socket type.
The sockets returent by RMI's default socket factory automatically attemt to use HTTP tunneling if ordinary attempts to communicate with a server fail. In fact, the default sockets employ the following strategy when attempting to make invocation on server:
1. Attempt to make direct JRMP or IIOP connection to the server.
2. If that fail, attempt to make a direct HTTP tunnling connection to server.
3. If that fail, attempt to use firewall proxy.
4. if that fail, attempt to connect on port 80 of the server machine and send request to URL begining with /cgi-bin/java-rmi.cgi
5. same as above on proxy server
 
Kartik Shah
Ranch Hand
Posts: 102
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Shakti.
 
James Ward
Ranch Hand
Posts: 263
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Support for jsse is vendor-specific.... !
 
Rupert Rowan
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I made it one of my assumptions that only the web clients need to communicate with SSL.
Has anyone else made this assumption and not gotten points taken off?
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic