I'll need to develop a Java service that is simple because:
It only communicates via a TCP socket, no HTTP.
It runs on a dedicated server (there are no other services except the basic SSH and such)
Should I make this a standalone service (maybe in something like Java Service Wrapper) or make it run in a container like Tomcat? What are the benefits and detriments of both?
If you aren't working with HTTP, you will have to build your own connectors for Tomcat. When I've written these types of applications, I've just written them as standard Java applications. On Windows machines, I use a service wrapper that allows them to be part of the Windows startup process. On non-windows machines, you just need to add a start up script.
Using a container (regardless which) buys you that all the details about starting, stopping, scaling, logging etc, which you have to do yourself otherwise, and it is always harder than you think (at least when you reach production).
Especially the scalability is something you need to consider already now. Later it will be much harder to change your mind.
So, if somebody already wrote most of what you need, then use that.
Tomcat doesn't sound like a good choice for me in your situation. AFAIK it's primarily made for Servlets and JSPs, and you have neither. You also don't need to deploy multiple applications on your app. server etc. (so no benefit from ".war").
If you need dependency injection, connection pooling, logging, network programming framework etc., there are a lot of good solutions out there and they don't need tomcat.
For example, in my case I went for a standalone app. that used Spring, Hibernate, Netty, Apache Commons DBCP, Log4j etc. These can be easily setup, and this way you have a lot more freedom.
Should you need a HTTP server, maybe embedding Jetty is another option. With this option too, you have more control over the app. and this can potentially simplify your implementation compared to using a tomcat container.
Tomcat doesn't really buy you much if you don't use HTTP.
However, I was forced to move a non-HTTP server to Tomcat for following reasons,
We need some simple web pages to display the status/stats of the server so I need a web server. Java 6 comes with a simple HTTP server but Tomcat is more robust.
Our operation tools are geared to run Tomcat only and standalone app just falls off radar in their monitoring system.
We use DBCP for database pooling and everyone seems more comfortable to use it under Tomcat.
The memory foot-print of Tomcat (a few MBs) is not an issue for us so we haven't seen any performance change since moved to Tomcat.
A container can save you from reinventing the wheel in terms of startup, monitoring, logging, configuration, deployment, etc. Also it makes your service more understandable to non-developers.
I wouldn't necessarily go for tomcat, check out glassfish and germonimo as they are more modular, and you can have just the bits the need, and exclude the http server.
We faced a similar decision a while back, and some parts of the system ended up being jsw based, and the others as .war files. The .war option is simpler (well more standard for sure) to build and configure.
Related
There seems to be a current trend in java space to move away from deploying java web applications to a java servlet container (or application server) in the form of a war file (or ear file) and instead package the application as an executable jar with an embedded servlet/HTTP server like jetty. And I mean this more so in the way newer frameworks are influencing how new applications are developed and deployed rather than how applications are delivered to end users (because, for example, I get why Jenkins uses an embedded container, very easy to grab and go). Examples of frameworks adopting the executable jar option:
Dropwizard, Spring Boot, and Play (well it doesn't run on a servlet container but the HTTP server is embedded).
My question is, coming from an environment where we have deployed our (up to this point mostly Struts2) applications to a single tomcat application server, what changes, best practices, or considerations need to be made if we plan on using an embedded container approach? Currently, we have about 10 homegrown applications running on a single tomcat server and for these smallish applications
the ability to share resources and be managed on one server is nice. Our applications are not intended to be distributed to end users to run within their environment. However, moving forward if we decide to leverage a newer java framework, should this approach change? Is the shift to executable jars spurred on by the increasing use of cloud deployments (e.g., Heroku)?
If you've had experience managing multiple applications in the Play style of deployment versus traditional war file deployment on a single application server, please share your insight.
An interesting question. This is just my view on the topic, so take everything with a grain of salt. I have occasionally deployed and managed applications using both servlet containers and embedded servers. I'm sure there are still many good reasons for using servlet containers but I will try to just focus on why they are less popular today.
Short version: Servlet containers are great to manage multiple applications on a single host but don't seem very useful to manage just one single application. With cloud environments, a single application per virtual machine seems preferable and more common. Modern frameworks want to be cloud compatible, therefore the shift to embedded servers.
So I think cloud services are the main reason for abandoning servlet containers. Just like servlet containers let you manage applications, cloud services let you manage virtual machines, instances, data storage and much more. This sounds more complicated, but with cloud environments, there has been a shift to single app machines. This means you can often treat the whole machine like it is the application. Each application runs on a machine with appropriate size. Cloud instances can pop up and vanish at any time which is great for scaling. If an application needs more resources, you create more instances.
Dedicated servers on the other hand usually are powerful but with a fixed size, so you run multiple applications on a single machine to maximize the use of resources. Managing dozens of application - each with their own configurations, web servers, routes and connections etc. - is not fun, so using a servlet container helps you to keep everything manageable and yourself sane. It is harder to scale though. Servlet containers in the cloud don't seem very useful. They would have to be set up for each tiny instance, without providing much value since they only manage a single application.
Also, clouds are cool and non-cloud stuff is boring (if we still believe the hype). Many frameworks try to be scalable by default, so that they can easily be deployed to the clouds. Embedded servers are fast to deploy and run so they seem like a reasonable solution. Servlet containers are usually still supported but require a more complicated set up.
Some other points:
The embedded server could be optimized for the framework or is better integrated with the frameworks tooling (like the play console for example).
Not all cloud environments come with customizable machine images. Instead of writing initialization scripts to download and set up servlet containers, using dedicated software for cloud application deployments is much simpler.
I have yet to find a Tomcat setup that doesn't greet you with a perm gen space error every few redeployments of your app. Taking a bit longer to (re-)start embedded servers is no problem when you can almost instantly switch between staging and production instances without any downtime.
As already mentioned in the question, it's very convenient for the end user to just run the application.
Embedded servers are portable and convenient for development. Today everything is rapid, prototypes and MVPs need to be created and delivered as fast as possible. No one wants to spend too much time setting up an environment for every developer.
I have a VPS where I want to install a web application for production.
Currently, it works on Tomcat 6 connected through Apache Server using AJP module.
Every thing works ok, but I want to know if it is a good idea to configure Tomcat as the main web server due we gonna run only JSP applications.
FYI: the server must handle https requests.
Thanks in advance.
Misinformation
Years ago there was much misinformation against using Tomcat directly as a web server, but in fact Tomcat works very well as such.
I've used nearly every version of Tomcat on various projects, though all were relatively low volume. Never let me down – well, the WebDAV module never worked right. But other than that Tomcat is fast and reliable both for static content as well as dynamic servlet work.
httpd
Apache HTTP Server ("httpd") is of course very advanced and full of features. If you need those features, then use httpd. If you have very high volume traffic, then use httpd. If you have huge amounts of static access and want to relieve Tomcat of that duty thereby letting Tomcat focus its performance on your servlets, then use httpd. If you want to keep a front-facing web site running while take Tomcat up and down, use httpd. But for most relatively simple web sites or simple web apps, Tomcat suffices.
I suggest you try Tomcat alone and see how it goes. Start with your development and testing systems. Review your config files for httpd to see if all its features can be reproduced using Tomcat features. If that all works, then do some load-testing. Either hack some load-tests of your own, or try any of the many load-test frameworks.
While you can hot-deploy webapps to Tomcat, that was not always recommended in production (I'm not sure about current versions). Plan how to handle taking down Tomcat to deploy updated apps and to perform maintenance chores.
Recent Tomcat
You say you are using Tomcat 6. You may want to consider moving to Tomcat 7 or 8, but review the release notes.
Jetty
Also consider Jetty, the most direct competitor/alternative to Tomcat. Jetty is much akin to Tomcat in its purpose, scope of features, and great reputation.
If you're using SSL you will get the following benefits by front-ending with Apache HTTPD:
Ability to specify cipher suites in order of preference, which is practically mandatory if you want case-hardened SSL, and impossible with Tomcat alone.
Ability to request or require client certificates on a per-location basis instead of globally, which is Tomcat's only mechanism.
There are many other benefits as well, such as:
the ability to load-balance between multiple Tomcat instances, which alone is probably enough of a reason to do it
more control over what's logged and where the log files go
more tools to defend against attacks of various kinds.
I used standalone Tomcats for years, but having made the switch I would never go back even for a clean-sheet project.
I don't think either is better, it depends on your requirements. In environments where you may have to address security or logging requirements horizontally across heterogeneous backends (IIS, Tomcat, etc), Apache is your friend (or an expensive load balancer).
Assuming you don't have these requirements, I don't know of any advantage in using Apache for Apache sake.
SSL is easily configured in Tomcat and performance these days is likely to be on par with Apache and can be improved with APR.
We building a Netty/NIO based service, and I'm considering the deployment of this service to our production environment. Our standard way of deploying services is as WARs, to be deployed inside Tomcats.
When I suggested the same approach here, I got shouts and complaints that "it shouldn't be done", because both Netty and Tomcat are servers, and "it doesn't make sense to host one server in another".
To me it makes perfect sense because it completely solves my deployment issue, as well as saves me from writing some other code. Why is it such a big "no no" ?
The dynamic WAR deploying and undeploying that Tomcat provides are designed for web applications. The Netty application you are trying to deploy into Tomcat is not a web application but just a separate server that only shares the VM memory. It means Tomcat has been repurposed into a generic microkernel such as OSGi.
However, I don't think it's a big problem. Since your company uses WAR as the standard deployment mechanism, it might be a good idea to reuse it. You don't even need to write some management functions like remote shutdown because Tomcat already provides them. All you need to do is to make sure all resources are freed up when undeployed.
Some people might not like this approach though. Ideally, there should be a common infrastructure for deploying and managing whatever application (aka microkernel), where even Tomcat is deployed as a module and the microkernel manages WAR directly instead Tomcat does. But that's a long way to go.
It makes terrific sense. We in fact run a Java email server in Tomcat.
Tomcat has some huge advantages for housing an application:
The daemon scripts are already written for you
Tomcat allows hot deployment (so long as you're not using hibernate :) )
At some point you may need either an Admin UI or Admin API
Lots and lots of tools to monitor Tomcat which means free monitoring of your app.
Now with Netty, Mina, or any event driven network technology you will not be able to use most MVC frameworks. In fact you will not be able to use most Java enterprise frameworks because many things rely on a thread per request (transactions, security, etc...).
Do not start anything in Tomcat, it is very inconvenient, and this has a lot of pain issues. Just embed Tomcat (or Jetty) inside your application and run your application as plain java process.
My manager has asked me to suggest an application server for web application development work.
What are the factors that needs to be considered before we select any application server for web application development in Java J2EE development?
If I select one now and IN future and I want to change to some other application server, is that minimum effort to change?
Apache Tomcat and Jetty are the two most popular web containers. Tomcat is the reference implementation of a Java servlet container, Jetty is a little bit faster and more lightweight. I personally favor Jetty, but you can't go wrong with either of them. A little comparison of the two can be found here.
Generally the migration of an application between web containers is fairly easy - only some configurations needs to be changed, but nothing in the source code(which is not always the case with full blown enterprise application servers).
The answer is that you can make it more or less difficult to change application containers based on your development practices. For example, the Liferay portal includes the custom XML configuration files for many application containers, allowing it to be used on many containers. So, it's certainly possible to switch flexibly, but you have to re-do all the server-specific configuration files and you can't rely on container-specific features.
In some cases, the containers themselves make it difficult. For example, the JBoss classloader has a history of scant support for the actual J2EE and Java EE standards. This makes it easy to rely on non-standard features, and in some cases nearly impossible to use standard ones.
Besides making sure that your application server enforces standards compliance, you do want to make sure you need a full application server, as opposed to just a servlet container as mentioned above. Does your application need EJBs, or just servlets? If you aren't doing EJB development, then an application server is over-kill.
If you are doing EJB development or otherwise using other EE features beyond what a servlet container supplies, consider ease of configuration and administration along side standards compliance, and I think you'll find a server that fits your needs.
A well written Java web application can be deployed on any web container, possibly with a bit of external configuration.
Hence you can choose the one that works the best for you during development, and then do testing on the target deployment server.
For netbeans, Tomcat is enclosed, and is fine. Eclipse does not have an enclosed web container yet, but Tomcat is supported.
In any case, use one that others use, then they can help you, and you them.
For pure development purposes, I would like a server with
Small footprint and very minimal start/stop time.
IDE plugins
So, my vote goes to Jetty for web app.
If you are on Netbeans, Glassfish is not a bad choice either as it shows superb performance via grizzly that uses NIO.
I want to implement a Java HTTP server locally, I mean the server computer would be in my control. I'm expecting not more than 20 clients to send requests to it.
I was wondering how to go about it:
Should I use a J2EE servlet container, like Apache Tomcat?
Could I use J2SE classes and just build it using them?
Are there any existing alternatives?
What does your experience suggest?
There's a simple HTTP server embedded in the Sun 1.6 JRE. It's not JavaEE or servlet-compliant, it's very lightweight, but it might be good enough for your requirements. No need to download any 3rd party stuff if this is all you need.
The javadocs, rather bizarrely, are out on their own, here.
Embed Jetty in your application. Aside from performing quite well, it is delightfully easy to use and configure
You've got many options, not the least of which are Jetty, Grizzly, and TTiny.
I would strongly urge against writing your own web server, unless you've got time to kill and want to spend it writing things that are already available to you for free.
Seriously, reuse an existing solution. Why the hell are you even thinking rolling your own?
Now, 1. I don't understand your question as being about embedding a container. 2. You mentioned long polling several time. So I'd suggest to use GlassFish v3 / Grizzly (because there are many samples, e.g. have a look at the Dead Simple Comet Example on Glassfish v3 / Grizzly).
If you don't want to rely on the way a container implemented Comet support, use atmosphere and any of the container mentioned on the web site:
Atmosphere is a POJO based framework using Inversion of Control (IoC) to bring push/Comet to the masses! Finally a framework which can run on any Java based Web Server, including Google App Engine, Tomcat, Jetty, GlassFish, Weblogic, Grizzly, JBossWeb and JBoss, Resin, etc. without having to wait for Servlet 3.0 Async support or without the needs to learn how Comet support has been differently implemented by all those Containers.
If this is not a concern, just stick with the suggested option (GlassFish v3 / Grizzly).
For a concrete and recent comparison between Comet server implementation, checkout this awesome Comet Maturity comparison grid view (source: Comet Gazing: Maturity). It might help you to make your final choice... or not :)
I guess the biggest question is: why do you want to build this?
If it is for the purpose of personal development, I'd stick to whatever standard libraries come with your JDK and build it on top of that.
If on the other hand you have a particular application that needs a dedicated HTTP server I would try to take one of the open source servlet containers, like Jetty or Tomcat and build on those.
Perhaps look at the list of 26 open source web servers at http://java-source.net/open-source/web-servers.
http://java.sun.com/developer/technicalArticles/Networking/Webserver/WebServercode.html is actual code in a single file implementing a multi threaded webserver. For your requirements, such as they are, this should suffice.
http://java.sun.com/developer/technicalArticles/Networking/Webserver/ is an analysis of the code.
If you will write your own HttpServer you will have to implement all the methods of the HTTP protocol. Tomcat can be easily used locally.
Is it for practice, fun, to implement special requirements or why don't you just embed an existing solution?
Do you really want to build a HTTP server that deals with the protocol directly, or do you just want to write web apps? If all you care about is writing the web apps, then just use Tomcat, or Jetty, or Glassfish, or another server -- it will save you a ton of work.
If you really are interested in writing your own server from scratch, then the best way would be to just use Java SE, and not use any existing server technology.
Ad your 3) option: Try JBoss Netty.
http://fisheye.jboss.org/browse/Netty/trunk/src/main/java/org/jboss/netty/example/http/websocket