Tomcat support and managed J2EE - servlet/jsp/ejb

Hosting packages comparison

We offer Private Tomcat JVM and Private JBoss JVM accounts running in a shared environment, in addition to our dedicated server plans. All our plans have been developed for the Enterprise Java developer, with development tools such as ant and svn pre-installed and a development domain as part of the package. This document is aimed at those who wish to understand the differences between packages in context with key industry trends which hopefully will help you arrive at the hosting plan best suited to you. For a list of FAQs relating to our Java hosting plans please visit our hosting faqs page.

Private Vs Shared JVM

Please note we no longer offer shared JVM accounts, for technical details click here

A 'private JVM' is an environment where a single JVM (Java Virtual Machine) is dedicated to a single user; no other user(s) can start/stop your JVM or in any way interfere with or run their application(s) within it. In contrast to a private JVM, a 'shared JVM' plan will normally have multiple users running their web application(s) within a single JVM. The architecture of Tomcat ensures user's web applications run in isolation from each other and no single user can stop or start Tomcat. To control their applications shared JVM account holders can use the Tomcat 'manager' application to deploy and undeploy their applications. Private JVM users have a wider range of possibilities available to them to manage their web applications; they can start/stop Tomcat or use the admin and manager applications. To summarise the major advantages a private JVM package has over a shared JVM package:

Deploy up to 5 domains with separate web applications (not just aliases)
Full control of Tomcat
Upgrade your Tomcat installation
Upgrade your JVM version
Modify your JVM - (i.e. install unlimited US security policy files)
Use Jikes for JSP compilation (vast speed improvement)
Total separation from other users
More bandwidth
More diskspace

JBoss Vs Tomcat

JBoss and Tomcat provide containers for distinct subsets of J2EE (Java 2 Enterprise Edition) and serve very separate purposes - The Servlet Vs EJB argument is a misnomer. JBoss is principally a EJB (Enterprise Java Bean) container, whereas Tomcat is a servlet container. To confuse matters, JBoss's pluggable architecture allows you to run a Servlet container (such as Tomcat and Jetty) within it. While getting a positive reception and acceptance, EJBs have been widely criticised by programmers and the IT press alike, the core complaints being they (EJBs) are too complex, too slow and too often mis-applied by contractors keen to decorate their CVs. However, if you require industrial level transactional control then EJBs may still have a place within your application's architecture. The long awaited EJB 3.0 specification aims to redress the complexity issues, time will tell if it succeeds.

EJB 3.0 Update

With the arrival of the EJB 3.0 specification EJBs look like an exciting technology again. Tightly coupled with new features in JDK 1.5 (5.0), EBJ 3.0 relies heavily on annotations which are a method of 'annotating' code so that 'side files' (such as deployment descriptors) are no longer necessary. All information relating to deployment now resides directly in the source code file which simplifies deployment making it a less error prone process. As an example, rather than declaring your business interface to extend EJBObject as in previous EJB releases, you would declare your entity bean with an annotation:

@Entity
public class MyBusinessClass implements Serializable {
  ... class definition ...

No more EJBHomes and other artificial 'interfaces'. Business interfaces are now plain classes. In all, the EJB 3.0 specification has make huge inroads into the simplification of EJBs which promises to make EJB 3.0 an exciting proposition for Java projects. Apart from the core features of EJBs (transactions, security, queues) the persistance mechanism by itself provides a highly compelling reason why you would think of using EJB 3.0. To those familiar with persistance frameworks such Hibernate, Toplink and JDO, the persistance mechanism has been heavily influenced by these technologies. Unlike the earlier EJB specs. persistence does not require the use of a container, and having a xml file to declare your bean->table mappings is no longer a requirement, annotations are again used to declare the db/bean relationship.

Accounts, useable techologies and marketing myths

Many hosting companies rely on misleading marketing to state that their hosting products uniquely support Struts, JDBC, Cocoon, Java Server Faces, Hibernate or something as simple as JavaBeans (which is no more than a specification of how to write your Java classes). The truth is; if they provide a compliant Servlet environment (and therefore J2SE) then they support these technologies. All our accounts are compliant with the latest Servlet specifications (Servlet 2.5/JSP 2.1), so you're not restricted to using just JSPs, Servlets or JavaBeans. Remember, there's more to J2EE than JSP!

Document Control: Version: 1.8b - Date: 25/03/2008 - ar