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.
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'm working in an infrastructure team(Jboss 4.02/Tomcat 5.5/Weblogic 8.1 servers)in my company...some of the weblogic java applications are moving to jboss/tomcat servers.So what are the criterias we need to consider whether we need to go for jboss or tomcat? which is the best option?
Thanks in Advance,
Rakhesh
The main difference is certainly the fact that JBoss is an application server and supports the full Java EE stack, while Tomcat is a servlet engine and supports only a small fraction of the APIs which are defined in Java EE.
So, your main criteria should be: Which APIs (Frontend, Business Logic, Persistence, Third-Party, ...) do you need?
You should not make this an easy decision. The fact that you are asking the question indicates that you probably did not have the chance to play around with both and familiarize yourself with the concepts behind Java Enterprise stacks (Java EE vs. Spring vs. DIY).
My advice would be to take the time to evaluate both system - it looks like you are able to use both.
If you don't need much, you're probably better off with Tomcat, which is small and easy to use, but can be a nightmare to configure if you need advanced functionality.
JBoss AS comes with a full and mature stack. Everything is just right in place and works fine - the price you'll have to pay is that it way bigger and will take longer to start / stop / redeploy.
But again: That's a serious decision with a high impact on pretty much everything...
Both Tomcat and JBoss are very easy to install - simply unzip a file, and start it with a script. Both Tomcat and JBoss have great support for products like IDE's, monitoring tools, and such.
But in your migration case, JBoss is a better choice. Chances are your Web apps need JNDI data sources and JTA transactions - these things come built in to JBoss 4+, whereas you would have to graft them on to Tomcat 5.x, with much effort. You old WAR's will find JTA and JNDI data sources with no trouble on JBoss. Tomcat can indeed add these features, but JBoss packages them nicely into the system nicely. So even if you have no EJBs or JMS, then JBoss is still a good choice because many apps do need JTA and JNDI.
But of course if you find EAR files for your apps, then Tomcat will not work. And then JBoss will deploy the EAR files nicely.
JBOSS uses Tomcat as its servlet/JSP engine, so it's JBOSS and Tomcat or WebLogic.
The answer depends on whether the original apps use EJBs or JMS services. If they do, you have to use JBOSS, because Tomcat doesn't support EJBs (unless you add OpenEJB) or JMS (unless you add something like RabbitMQ or OpenJMS).
If you don't use EJBs, and only have JSPs, JNDI data sources, and JDBC, then you can deploy your apps as WAR files on Tomcat and pass on the full Java EE stack altogether.
I think you should consider starting with different input data:
what are the applications requirements ?
what are the production constraints ?
which product suits well to the administration team?
Just write a matrix with the 2 products and those criteria and your choice will be done!!!
Jboss is far more heavy than Tomcat but could offer some value added while putting the application in place ? Do you have some Nagios/Tivoli or any other SNMP management infrastructure ? in this case you can finnd easily SNMP adaptors providing proprietray MIBs to manage your JBoss server...JMX Beans in old releases are a very conveniant way to administer such tool
HTH
Jerome
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.
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.
I am trying to understand what does JBoss AS can bring into the project, comparing to standalone architecture?
My model application is a solid thing, starting, running and stopping as a whole and solely at the host.
It has a database storage, and communicates to user and other servers, clustering required.
It has web-part. It's just a standard big application.
JBoss for me is a shell for (in general) multiple applications, providing my application with some standard services. This shell is also a solid thing - "get all or nothing", something can be turned on/off (influencing your app unpredictably, or influencing other part of the JBoss) or replaced (very hard and is already kind a hack) with different version or other module.
Standalone application for me is something combined of pieces with glue among them (Spring if you like) with IoC wiring. We can get everything we could have with JBoss, but separately. Spring or other glue serves here like an application server, but it's thinner and we still can replace parts or even Spring itself (IoC wiring is straightforward from coding point of view).
For me, standalone, AS-free approach gives more control and flexibility. And further more, last versions of JBoss AS are purely documented, some features (most interested) are not documented at all.
So, why somebody still choose JBoss - what are benefits?
I favors more standalone application approach, but need more facts to understand better and convince others.
It seems to me that what you are describing is the classic choice between best-of-breed (collecting all the parts and glueing them together your self) versus integrated stack (JBoss wrote all the parts and integrated them for you). This is a debate that will rage on for eternity. If best-of-breed is working for you then stick with it.
JBoss is a J2EE container. Take a look at the J2EE spec if you are unfamiliar with it. Basically Sun's community process came up with an development framework that contains components that you may be interested in when creating large scale apps. J2EE contains multiple sub specs such as Servlets, EJB, JTA, JMS, and a whole host of other alphabet soup technologies. If you aren't using any of these technologies then you do not need a J2EE container. If you are just interested in using Servlets and JSPs then you are better off using a servlet container such as Tomcat, Jetty, Resin, etc.
Providing enterprise features such as scalability, transactional support, federated user management, etc. are difficult. A J2EE container provides a standard level of these features. If you can find them elsewhere to a level that meets your satisfaction then more power to you.
You can also pick and choose if you are running inside JBoss. If you are happy with the JBoss services you can use them or deploy some others if you don't like the one JBoss provides for you.
Starting from the JBoss minimal configuration and building up your own configuration should give you a setup where you don't have services running that you don't need. Personally, I like to know what my AS is running, so I prefer to start from minimal configuration adding only the necessary parts.
I would say the only reason to use JBoss is if you need to access the Java EE services (like Messaging, container-managed transactions and similar).
Keep in mind JBoss is (roughly described) Tomcat plus Java EE services (yes, yes, I know, this is a very simplified approach, just bear with me). I mention this as I would say your decision is:
If you only need IoC and some other capabilites you can get with Spring and Tomcat, go with that
If you application requires Java EE services, use JBoss
Keep in mind you can always start with the basic system (Spring + Tomcat) and move to JBoss if required later on. Nothing forbids that.And probably starting with that approach will show you if you really need the Java EE services or you were over-engineering the solution.