For Web applications, an application server will be running in the same environment as its web server s , and application servers are there to support the construction of dynamic pages and implement services like clustering, fail-over, and load-balancing, so developers can focus on implementing the business logic.
At IDRsolutions we like to describe it to non-technical users as a magic door. It allows you to write code to run on a server and code on a client and allow them to talk to each other. It all just works and handles all the complexity transparently for you. So now we have established what an Application server is, we will now take a look at the available Java Application Servers.
GlassFish is an open-source application server project originally started by Sun Microsystems for the Java EE platform and now part of the Oracle Corporation. Oracle no longer provides commercial support for GlassFish Server but several organisations have filled that space, most notably Payara. Glassfish allows you to to create enterprise applications that are portable and scalable, and that integrate with legacy technologies. Optional components can also be installed for additional services.
It is built upon a modular kernel powered by OSGi, and runs straight on top of the Apache Felix implementation. We have previous covered how to set up Glassfish on a Linux Server. If you are looking for an example of deploying a web app, there are some examples on our support section, where we show you how to deploy our software to GlassFish here and to Payara here. It is also available as a subscription-based server. JBoss works cross-platform and is usable on any operating system that supports Java.
Compliance is more important to some types of projects than others. Some servers are J2EE licensed, some are certified, while others are buggy or incomplete. Consider using a resource such as Flashline to track a product's certification, which indicates that implementation should be relatively accurate and complete. However, to find flawed implementations, scan the newsgroups, discussion forums, and product-specific message boards to see how many issues are raised.
If you choose an application server that is not compliant, look for one or more of the following:. You will have to decide if the application server needs to be compliant with the latest specifications. By limiting your choices to the latest servers added to the specification list, you may handcuff yourself to a subset of the available J2EE servers or find less support from various resources. Scalability and availability can significantly impact the selection process.
The following are the major questions that you should ask:. Hands-on testing is necessary for properly testing scalability and availability. Third-party tools are available to support high-volume load-testing of app servers, including Mercury LoadRunner and Rational SiteLoad.
To find out how well a server's features work, try pulling network plugs, killing processes, shutting down databases, etc.
By running these tests during the evaluation phase, you can reduce unnecessary surprises once the system goes live. I've found that no amount of planning can keep people from tripping over cables, processes from seg-faulting, machines from failing, etc. If the application server can make these mishaps a little less painless, all the better. Efficient Development.
Measuring efficient development is pretty subjective. However, if an app server can provide the following, I can safely say it supports efficient development:. Good integration between the development tools and the server can also be important for the development team.
Granted, if the team consists of one person running everything on one box, integration may be easy to achieve with any solution "tail -f stdout. However, for larger teams, effective tool integration will boost productivity significantly. Also, I've found that good debuggers are often undervalued on software projects. As an example, Visual Cafe Enterprise has a powerful debugger that ties into Weblogic while also providing full-featured IDE capabilities.
You may find that third-party debugging solutions such as Numega's DevPartner or Sitraka's JProbe satisfy your debugging needs without severely limiting your app server selection.
For a J2EE development team, consider how development can take place without one developer's changes clobbering or impacting another's. This can be accomplished through the following:. Broad platform support is an important requirement because it enables effective support if you choose to move platforms or versions within a specific OS. These components enable software developers to build large-scale, distributed applications. The following figure illustrates the components of the J2EE platform discussed in the following sections.
The J2EE application model divides enterprise applications into three fundamental parts: components, containers, and connectors. Components are the key focus of application developers, while system vendors implement containers and connectors to conceal complexity and promote portability. Containers intercede between clients and components, providing services transparently to both, including transaction support and resource pooling.
Container mediation allows many component behaviors to be specified at deployment time, rather than in program code. A container is a runtime environment that provides services such as security and transaction management to J2EE components.
Web components, such as Java Server Pages and servlets, run within the web container. The J2EE platform services simplify application programming and allow components and applications to be customized at deployment time to use resources available in the deployment environment. Remember when I said that application servers provide some infrastructure and functional capabilities to your application?
A specification called Java EE precisely defines the functionality of application servers. Therefore, strictly speaking, I should call only the containers that pass Java EE compatibility tests by the name application servers. Also, there is a Web Profile subset of the full EE platform now available, as well as a servlet-only web container.
The bottom line is that you can run Java EE applications on Tomcat. So Tomcat is mature, well-documented, and the most widely used Java application server. With good documentation and no shortage of tutorials about it on the internet, Tomcat is a serious contender for the role of application server in almost all Java web applications.
Just like Tomcat, it lacks support for many Java EE features. And just like Tomcat, you can still use most of the features by including additional third-party dependencies. Two of its main selling points are its compactness and small footprint. Both make Jetty a great fit for constrained environments and for embedding in other products. As such, GlassFish is more heavyweight than either Tomcat or Jetty—and, arguably, a bit more difficult to operate.
The downside of GlassFish is its lack of commercial support. Yes, this article is about free and open-source application servers, but this is still an important point. As your project grows and becomes financially successful, you might be willing to pay to get long-term support, security updates, customer support, etc.
0コメント