File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Standalone client vs JSP/Servlets Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Standalone client vs JSP/Servlets" Watch "Standalone client vs JSP/Servlets" New topic
Author

Standalone client vs JSP/Servlets

John Meurig
Greenhorn

Joined: Apr 28, 2004
Posts: 5
Tried looking around for an answer to this but found none, I've been
wondering if there are any pros and cons between using standalone clients or JSP/Servlets to link up with EJBs for applications that require transactions?
[ April 28, 2004: Message edited by: John Meurig ]
Paul Lester
Ranch Hand

Joined: Dec 27, 2002
Posts: 40

Tried looking around for an answer to this but found none, I've been
wondering if there are any pros and cons between using standalone clients or JSP/Servlets to link up with EJBs for applications that require transactions?

John, I think that the answer depends on what you want to do with it and how much baggage you are willing to carry with you.
For example, having a Swing application that communicates directly with an EJB using WebLogic 6.1, for example, you have to include all of the compiled EJBs as well as a 25M weblogic.jar file at each installation. Now, if you take that same scenario, access the EJBs via XML-RPC, RMI, SOAP, or if you roll your own using URLConnection->Servlets, you can keep all of those things on the server side. Either way, you get your transactions.
Using JSP the communications path might look something like:
JSP->Delegate->ServiceLocator->EJB->DAO
Using the EJBs directly. I wouldn't recommend this one because you should be behind the delegate to hide the complexities and allow you to change at a later date should you decide to do it a different way.:
Application->EJB->DAO
Using the EJBs via a delegate, where the delegate is one of the above mentioned ways, in the application:
Application->Delegate->EJB->DAO
There are advantages/disadvantages to each. Security may come into play, etc.
Paul
[ April 30, 2004: Message edited by: Paul Lester ]

Where Photography meets vision.<br /><a href="http://www.photogravision.com" target="_blank" rel="nofollow">http://www.photogravision.com</a><br />Please stop by!<br /> <br />SCJP,SCWCD,SCJD,SCEA
John Meurig
Greenhorn

Joined: Apr 28, 2004
Posts: 5
Thanks for the reply Paul, I've been working on a design which was originally supposed to be a standalone that communicates with EJBs via RMI. Based on some past experiences with web applications, I selected the standalone as I wanted a more responsive feel(i.e. without needing to click the submit button to see changes to the data) as well as to be able to have more customisation for the user interface - not sure if these are valid points though.
As for security, is there any difference during communication between JSP/Servlets -> EJB and RMI -> EJB?
Paul Lester
Ranch Hand

Joined: Dec 27, 2002
Posts: 40
As for security, is there any difference during communication between JSP/Servlets -> EJB and RMI -> EJB?

Well, without overlaying any type of security on either one, they are both wide open. The difference is that if you need to communicate with a server that is behind a firewall, if you are using RMI, you will probably need to open a port in the firewall to get through among other things. This protects your assets behind the firewall, but the data that you are sending is still easy to read as it's just serialized data.
With using JSP/Servlets->EJB, you still have the problem of data that can be read easily unless you use SSL (https) to communicate. You can use this from a client if you use a secure URLConnection to do the commuication between client and server.
So, you see, it all depends on how sensitive your data is. In my case, I'm behind the firewall and am strictly INTRAnet and don't need to worry about such things.

Regards,
Paul
Augg Stine
Greenhorn

Joined: Mar 24, 2004
Posts: 27
for one instance, we can go for swing rather web ...
it is ur rich GUI.
Roland Barcia
author
Ranch Hand

Joined: Apr 15, 2004
Posts: 181
The answer should be dictated by how rich of a UI you need. A Servlet/JSP client can be co-deployed in the same container and use the Local EJB interface which is preferable than using the Remote Interface.


Roland Barcia: IBM Distinguished Engineer, CTO Mobile for Lab Services
John Meurig
Greenhorn

Joined: Apr 28, 2004
Posts: 5
So, you see, it all depends on how sensitive your data is. In my case, I'm behind the firewall and am strictly INTRAnet and don't need to worry about such things.

Unfortunately I've got to handle cases of both Intra and Internet.. are there ways where a standalone can protect data that's being sent? Would SSL work for it or can manual encryption(thru coding) suffice?
The answer should be dictated by how rich of a UI you need. A Servlet/JSP client can be co-deployed in the same container and use the Local EJB interface which is preferable than using the Remote Interface.

Are there any limitations to the sort of interface that can be produced by a JSP/Servlet client and a standalone one?
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
Unfortunately I've got to handle cases of both Intra and Internet.. are there ways where a standalone can protect data that's being sent? Would SSL work for it or can manual encryption(thru coding) suffice?

For the intranet ... do you need SSL? It's quite a heavy-duty way to do authentication.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Standalone client vs JSP/Servlets