I want to run a standalone java application on a remote server. It would not be accessible to clients, but would do background calculations and interact with a database and Secure Socket connection to a third party site. It would also interact with a php site.
Do I have to deploy this with JSP, or can I write a standalone application? If so, how would I deploy a standalone java application (jar file) on a remote server? I understand that I must have them install a jvm on the server (not a problem) but then how would I deploy it (if possible). Would I start it with a command line?
I know I have much to learn, but I am not sure how I would access the command line on a remote server. Through the cPanel?
Thanks.
First of all, you'll want to set up some firewall rules to allow access to that server. I'm hoping that you don't expose that server naked to the Internet.
If all you need is database access exposed on the Internet, I don't see why it can't be a secured web app deployed on a servlet/JSP engine and accessed via a web server. You can leverage basic auth for security, JDBC access to the database from the server, and servlets as controllers to accept requests in a nice REST API.
It'll save you the complications of sockets and inventing your own protocol (use HTTP), starting and stopping the application (now it's just a web server/servlet engine), and deployment (send a WAR file).
Does it really must be a 'standalone' application? I think that in your case the best match would be to use Spring container to load your application within some server (tomcat?) and expose services via standard controllers - with Spring you only have to add some annotations on services methods actually.
Then, your php site can interact with these controllers using for example ajax requests.
If your application is written already, you can easily transform it to run within Spring container. It's very non-invasive and promotes usage of POJOs.
Related
I have developed a Spring MVC app that can detect Ajax requests sent into my local environment 'localhost:8000/examplePath' with a json body being received as a mapped parameter. So, until here, all is fine.
My question is: Do i still need to deploy my application on a container 'Apache Tomcat/ HTTP Server for example' for my application to be accessible externally on a possible production environment, and if so why?
I want to better understand the necessity of such, if my backend 'Spring MVC app' can already receive and respond to ajax requests
Spring MVC creates a Web application that must be deployed to a Web Application Server to run. The server handles the low level stuff such as raw sockets and the HTTP protocol.
This is because you can't access from internet to your local environment, you need a public adress to access your application from everywhere only if you want to access it over internet otherwise can do it with a local network connection to access it.
If you want any container, you can do it easy with Pivotal. This a container platform for Spring apps.
I've read some articles on the Internet that this is not possible. To communicate own SQL database that is located on other server from GWT application. Jetty doesn't allow it.
I found a way how to perform it but it's not very cosy. I have client and server part inside GWT. The server has to communicate with MySQL database on localhost. So I've written an ant script to build a war that I can launch on Apache Tomcat server. It works perfectly there but I'm not able to debug the code effectively.
Do you have some advices how to perform this task? I was thinking of writing the clienty only in GWT and find some waz how to communicate my own server written outside the GWT. I've found Apache Thrift for GWT but this edited library of thrift seem not to work properly.
Thank you very much for your answers:)
It is possible to communicate with a database from a GWT application. The client side has to call the methods of the server via GWT-RPC, which can communicate with any database.
Maybe Jetty does not support it (have not tested it personally) but you can develop your web application using Apache too. There you can access the database the same way as from any web application:
You will need the mysql-connector-java-5.1.20-bin.jar file (downloadable from: http://dev.mysql.com/downloads/connector/j/ ), and restart the server added to the $CATALINA_HOME/common/lib directory.
OR added to the WEB-INF/lib folder of your web application.
You can find tutorials online of how to develop an application using Tomcat instead of Jetty. For example: https://wiki.auckland.ac.nz/display/BeSTGRID/Deploying+GWT+to+Tomcat+in+Eclipse
Reshi, stop and think about how applications really work. Nobody provides web pages with javascript to read/write databases, that would be crazy and unsecure. Servers are always in themiddle of all communication in this case. You need to create services that run inside your server, one of these services will be a database layer.
Javascript cant create network connections and read/write binary data, thus it would be insane to attempt to get the gwt compiler to compile any jdbc drvier and more.
Jetty does NOT stop us from connecting to a database. All you have to do is to follow the MVP model way. Although MVP is better bet against all hurdles, at a minimal point, you would have to try not having SQL code on the client package.
I have an existing Java application running on a linux box that monitors the state of relays and network information. This is a stand-alone device currently.
What I would like to further develop is a web server for the device to remotely monitor, configure, and control the device via an Ethernet connection. To achieve this, I need some way to interface between the web server, which could be configured as enabled/disabled, and the master device, which is always running.
Is there a good way to do this? I have looked at apache w/ tomcat and similar web servers but not sure if this is what I need. The key here is that the web server needs to be able to access the existing java application without interfering with its always running services.
You either develop a webapp, use your Java application's API inside the webapp, and deploy this webapp inside a web container. Or you can do the reverse and embed a web server inside your application (see here for documentation to embed Jetty).
If you want to keep the webapp and the original application in two separate JVMs, you'll need some wey to communicate between both, like sockets, RMI, or even files, but it will be more complex.
You might want to take a look at JMX http://docs.oracle.com/javase/tutorial/jmx/overview/index.html
I am currently developing an application for some researchers in my university.It's a small java program that you can use by command line. The next step is to package that program and deploy it to an application server. Some clients program will submit requests to the server who will call the tool that I wrote. Lately, we will add more tools to the server and he has to dispatch the requests to the right tool.
Which application server fits my needs ? I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Is it possible to use those servers in some context different from web context? Which package archive should i use (jar, war) ?
Any advice?
Some clients program will submit requests to the server who will call the tool that I wrote.
The big question is what server-side technology and what communication protocol can you use between the clients and the server. You basically have two major options: HTTP and web services (in that case, consider using either JAX-WS or JAX-RS) or RMI-IIOP and EJBs (in that case, you'll have to use a Java EE compliant server like GlassFish).
I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Not really. As I said, they can also be used for web services oriented applications. And GlassFish can be used for EJBs applications.
Which package archive should i use (jar, war)
The packaging will depend on the type of application you'll write, it's not something that you choose upfront, it's just a consequence. EJBs are packaged in an EJB JAR and typically deployed inside an EAR; Servlet based web services are deployed inside a WAR.
You really need to think about what technology to use first (with the current level of detail, I can't provide more guidance).
Do you even need an application server? There's nothing stopping you from adding the necessary network bindings and deploying it on its own.
Of the servers you mention, you've got 2 different categories: servlet containers and full-stack Java EE servers
Tomcat and Jetty are servlet containers. That doesn't mean that you can only do web stuff with them and you could manually add the required libraries to get a full Java EE server.
Glassfish is a full-stack Java EE server and can be compared with JBoss (both are open source) or the commercial rivals Weblogic and Websphere.
Sometimes this question is simple as the environment you are working in mandates a particular flavour of app server. You should check this first.
If you're not forced to use an app server, I'd ask why you think you need to use an app server?
I don't see why you would want to use tomcat, glassfish or jetty for a command line program.
If it's command-line based, and you want it to run server-side, you could write a little program that allows users to, for instance, telnet to your server, which in turn starts the CLI-application in question, and relays input / output to the client.
You may also want to look into Java Webstart, which makes deployment of new versions a breeze.
Actually we can't answer with so few elements.
- What are you planning to do
- With what technologies
- Where are you planning to host your application (have you got budget?)
- In which language are written the clients (even the future ones)?
- Could clients be on mobile phones (add some technlogy constraints...)
....
It would also be great to know what kind of request the clients will do, and what kind of response the server will provide...
Actually with what you tell us, all those application servers can do what you want...
I have looked for Tomcat, Jetty and
Glassfish but it seems that they are
only used for web application
You could even make a webapplication (servlet) and on the clientside use a httpclient to call that servlet... there are so many options :)
vive Paris!
For my web application, I am thinking about using the Spring framework. Initially, I was thinking of having different actions like create user or login, but now I have to expose some functionality to other applications. Should I create a web service that I call from my application and others do as well, or create an action from Spring and then just have others call the web service? It seems like I should minimize the different ways to call something, but does it make sense to call a web service that is running on the same application server as my main app? Would this be a bad idea from a performance stand point?
Update
I was concerned that Tomcat wouldn't be able to serve both the static or dynamic pages on port 80 (so users could go to www.example.com/welcome.jsp instead of www.example.com:8080/welcome.jsp), as well as a web service but I guess it doesn't matter as both are just served as requests from Tomcat. I'm guessing this means I'll have to change Tomcat to run on port 80 and other applications will have access the web service via this port. Or I could leave Tomcat running on port 8080 and put Apache in front on Tomcat on port 80 and Apache will serve the requests to Tomcat. Is that correct?
I'd put the common business logic in a "business service" and :
call it from an action in your web app
expose it as a web service for other applications
To me, there is nothing bad with this approach and it's pretty easy and clean to implement it with Spring. Actually, I would find ugly to expose this business service as web service only and to call it from the web app (and I'm pretty sure that this will be more complicated to implement on the web app side). You have different "usage contexts", just expose the adequate interface for them.
(EDIT: I'm answering a question of the OP posted as comment below)
You can deploy the web application and the web service in the same WAR (but this is just a deployment choice, you could package the business logic in a JAR and use it in several WARs). Regarding the port, I'm not sure to understand your question. Traditionally, you'll use a web server (e.g. apache) in front of your application server. If you don't, you can always choose to run you app server on port 80. Actually, in both case you are free to use whatever port you want. Using port 80 is just convenient.
Yes, your update is correct.