Our lab has a single machine that is open to http connections from outside. However, this machine is quite weak (little memory, slow CPU). We have other machines that are much stronger, but they are behind a firewall and cannot be accessed from outside the lab.
I am writing a GWT app whose server is very demanding. Is it possible to install the server on a strong computer, and the client on the weak compuer, and have them connect using RPC? I assume it requires some changes in the web.xml file, but what exactly?
Theoretically I can just wrap the demanding part in a separate TCP/IP server, and have the GWT server contact it, but I would like to know if it is possible to do directly in GWT.
The GWT client is downloaded from the server and runs inside a Web browser as javascript code. I don't quite understand what part of the GWT app you would want to run on a separate server.
If your GWT servlet (the RPC service implementation) is accessing external resources, like a database or Web services, you could move those resources to a separate server.
Another option is to install a reverse proxy on the "weak" server that would forward specific requests to a stronger server behind the firewall. The proxying could be done by Apache (httpd) on the "weak" server (using mod_proxy). Then Tomcat would only need to be installed on the stronger machine, and would take care of most of the processing.
I have tried to do this but was only successful in splitting a GWT project into 3 parts (Client, RPC, Server) as eclipse projects. In the end you are going to end up with 1 big WAR file and it'll be deployed in one place (unless someone else was successful at really separating the code.)
A solution you can do is to set up another server that will do all the server side processing (your strong machine) and have the GWT servlets act like a proxy. They accept the requests from the client and forward the data to another server for processing. Then wait for the response.
How you do it is up to you. You could use web-services, direct socket connection, JMS ..etc.
Depends on your setup.
GWT ACRIS- Please see this link.
EJB - One approach could be to keep business objects in remote machines as EJBs and your servlets accessing them over RMI/JNDI.
Spring - Another simple way to do it is with Spring Remoting. See this link.
Related
I'm having trouble wrapping my head around how to use servlets properly
I've set up a postgres database, and downloaded a JDBC driver for it.
What I want to have is my webpages post to the servlet, and the servlet get info from the database. I understand how to code everything (eg add library for driver, open connections, execute queries), but I think I'm lacking knowledge in how to set up the file structure.
I have the postgresql database running on pgAdmin. Do I also need to have a server running to make the servlets work as well? Can't I just make a web.xml file that maps to the servlets, and open the webpages to use the website? If I run the project through an IDE with a server running (glassfish) everything works. If I close the IDE and go to open the webpages on my browser again, I get 404's whenever I submit to a servlet.
Can someone give me a bit of guidance on the big picture of how everything is supposed to interact (with details on servers please). I've been searching the web and I havent found anything that explains the big picture very well.
Thanks
A Java web application is a set of files obeying a well-defined structure, and which can be packaged in a war file.
This web application is deployed into a server (also called container), which understands the file structure, listens to HTTP requests, and calls the appropriate servlet of the appropriate deployed web application when it receives one.
And of course, if you shut down the server, nothing listens to the HTTP requests anymore, so you won't get any response.
You could read the Java EE tutorial for more explanations.
I am planning to design an application which will require both web server and application server (Java EE based). Modern application servers like Weblogic, Websphere, JBOSS can provide support for both application server and web server. However I have seen many applications where the deployment architecture provides a segregation of web server and application server as a separate entity.
I would like to know:
What is the architectural benefit of segregating the web server and app server as a separate entity?
e.g. Assuming we are going to use weblogic as a web sever and app server do you think if there is any concern for large applications?
There is several resons to use a dedicated web server for static content:
In most case a web server is already present infront of the application server (reverce proxy), it is needed if the app server is clustered. So as it is already present.
If the static content is important (size and trafic), puting it in web server allow to scall the content and the application separeatly.
Historicly pure Java app server was slower that native web server, now NIO allow the same access to system call sending file directly to a socket without going back and forward between system and user mode.
So I think you should start with the contend delivered by the app server and complexify the system if it help you to solve issues you actualy enconter.
I created my first Java EE application (GWT + Hibernate). I want deploy my application on a Tomcat web server.
Could you give me a step by step tutorial?
You can start with Google App Engine + GWT tutorial if you are trying out deploying into Google Cloud - https://developers.google.com/web-toolkit/doc/latest/tutorial/appengine
This question is massive so I will try to bring it down to some steps that need some research to implement.
1st. You created an application using GWT and Hibernate. That means that you need some kind of a web server that understands java and can re-write the logic from java to javascript (for the clientside), and also connect to the database on the serverside and retrieve the data for the client.
This web server is tomcat so what you need is:
A computer that will work as a server. This could be your own machine or some server you can buy as a hosting solution. Buying something like this requires research and effort on your part and cannot be explained here.
A version of Tomcat or Resin or any other web server that understands java
A domain name. These can be bought from sites like this one, but there are some free ones around the web. They require static ips that is you cannot use them from a home line that changes ips. Even without a domain name you can host your site on the server but you need to access it by writing the machine's ip instead. - optional - A temporary solution would be to use some kind of dynamic dns service on your router.
After having set up tomcat (you might want to give port 80 to tomcat) and the server you can host your application by uploading the war file. You can make a war file from gwt by following the instructions here
To upload the war file you can use the tomcat manager interface, or you can connect to the server and place it manually in the folder used for the web applications.
I know that each step propably needs as much if not more explanation by I hope I cleared the area a little bit here.
I'm thinking about an application where in some cases both client and server would run on customer's computer. Concerning the client's resource usage I've found this question, concerning the general disadvantages of GWT I've found this, but I can't find anything about the overhead of the server part. I need no application server there, anything capable of running the server part of GWT would do.
What is needed to run the server part of GWT and how many resources it consumes?
If you use a ServiceImpl w/ your GWT app, you need to deploy it into a servlet container, like Tomcat or Jetty (or many others). Otherwise, it can be deployed on any web server, as it will only consist of javascript, HTML, and CSS.
Hosting an application on a web application server e.g. JBoss automatically brings in lots of app server specific functionalities with it e.g. security, clustering & load balancing etc. I have a situation where I have to develop a server app with which, legacy apps can talk to over TCP/IP socket as well as be highly available. Initially, I had though of using JBoss app server to leverage its clustering support for HA. However, I am not sure whether it would be possible to connect to a JBoss web app using pure TCP/IP sockets from both java and non-java apps.
What is the best way to achieve this without using web service or Http approach?
UPDATE: I am specially interested to know how legacy apps will connect to the hosted web app through TCP/IP socket.
A really simple solution to bridge the two worlds would be to add a simple Java server which maps the old TCP/IP requests to HTTP requests. This is probably a pretty braindead task, so this "server" will be simple to write and maintain. Also, this server won't need as much power since it just accepts and forwards connections (no business logic or DB code).
On the JBoss server, you develop like you normally would. The legacy apps connect to the little bridge server which passes the requests on to JBoss and translate the result back.
This ensures that you're building for the future: When new apps are developed, they can connect directly to JBoss and use all the great HTTP features.
There's no reason why you can't open up a normal socket in (say) a servlet application hosted in JBoss.
You can then get a byte stream from this. The headache is then to decide on a platform-independent representation of your messages, such that your client end can format and send such that the JBoss-hosted end can read. But it's all perfectly feasible.
I would implement a very simple http (1.0) client.