What is the best (easiest, most seamless) way to build a Java app while relying as little as possible on the actual application-server used in deployment?
For example, say I want to deploy on Apache Geronimo, and later want to use GlassFish, how difficult would the transition be? What is the best way to abstract the use of each app server?
Excuse my ignorance, I'm relatively new to Java development. I want to start a new project, but am unsure on whether to use separate APIs for the functionality I need or develop on top of a chosen app-server from the start.
Thanks for your help,
Ivan
Without getting into too much details, even though you can write bare-bones Java EE code, the configuration around it is not very simple. Each application server has its own set of configuration files and naming conventions (for example, the format for specifying the location of the AS is different in IBM WAS and in JBOSS). Though these are not very important for application development, once you get to the deployment phase, these will become important.
As far as the libraries and your code is concerned as long as you stick to EJB standards you will be able to run your application on majority of the application servers (I know of WAS and JBoss - the code that I wrote didn't have to change for these servers; the configuration though, well that was a different beast !).
Follow Java EE specification as much as possible, while follow server specification least as possible.
If we try to find out what are in common among there Java EE application servers(JBoss, WAS...), answer is Java EE specification which server vendors must follow. If you have 2 solutions on a Java EE problem, you could check which solution comply with Java EE specification better rather than server specification.
From my experience with Jboss and Sun AS, you should just forget about AS-independency.
In sql, for example, you can do quite a lot without employing vendor-specific features. Well, it's not like that in Java EE. For Jboss and SAS even 'hello world' applications will require different configuration. And more application grows, more vendor-specific features you have to use.
In particular, if you look at official Sun Java EE tutorial, you'll find that it employs SAS-specific configuration files (sun-web.xml, sun-ejb-jar.xml, etc) from the very beginning.
But all above applies only if you use full range of Java EE features (like EJB, JMS, mbeans). I've found that if you just have servlets/jsps packaged in one war-archive, such application can still be very portable.
If you have the resources then consider developing and testing for several application servers instead of just your initial target one. This will allow you to - from the start - pinpoint things that need to be configurable and code accordingly.
Personally I would consider Glassfish 3.0.1 in such a situation as it is the reference implementation, so things should at least work there without any special efforts.
Related
I come from a website programming background and I recently started to learn Java with the primary intention of being able to create a Back-end "Scheduling" service. This means that users should be able to create/configure methods to be run at specific date/times.
The solution must work on for a Windows OS.
I understand a number of required concepts;
Singleton Javabean
SOAP/REST Web Services
The plan is that my PHP front-end would need to communicate with a Java SOAP/REST Web Service which would, in turn, communicate with a "Singleton Javabean", The Javabean must start at boot time. I need another Bean to loop infinitely that would read SNMP(and other network messaging systems) and have those values read into a Web Service.
In the future I wish that these solutions to be able to be read into an Android Application.
However, I don't know how I would run a method that listened for specific times from a config file updated from a database or have a Bean run as a service to facilitate reading SNMP.
I've looked into some Java Servers, like JBoss, Glassfish and Tomcat but the documentation is so vast that it is intimidating to troll though to find out if they support the features I require.
I don't require a step-by-step guide here, just a push in the correct direction.
How would I configure a Javabean that listens for specific times? How would I configure a Javabean to run as a service to facilitate reading SNMP in an infinite loop?
Executor
For the periodic execution of the task in Java, learn about the ScheduledExecutorService. Search StackOverflow for many examples and discussion.
besides that class, you will find much discussion about the Timer class. But Timer is older, less flexible, and most importantly, should not be used in a Servlet environment.
The tricky thing is learning how to properly handle thread-safety. By definition you have multiple threads working with the same data.
Servlet
Those servers you mentioned such as Tomcat and Jetty are based on Java Servlet technology. Servlets are an alternative to your PHP.
If you want to keep your PHP, you can use one of those Servlet servers only as a Web Service server. So you will not need to master all that documentation.
Launch
The way to kook into your web app launching in a Java Servlet container is to make a class that implements the ServletContextListener interface. A pair of methods will be called by the container, one when the web app is being deployed (launching) and another when the web app is being I deployed (shutdown).
Again, search StackOverflow for many examples and discussion.
No Need For Singleton
No need for a Singleton. Singletons "are evil" as some people say (such as Miško Hevery), making testing difficult and keeping the instance in memory endlessly. Having a single instance is not the problem, it is the Java implementation of the Singleton Design Pattern keeping an instance in a static var that is the problem.
ServletContext
You can access the ServletContext to store and retrieve instances for your entire web app. Call the setAttribute and getAttribute methods to pass any Object subclass you want.
Annotations
Be sure to learn about annotations in Java. They can greatly reduce the configuration work of your server and web service. For example, #WebService and #SOAPBinding(style=Style.RPC).
Java Enterprise Edition
Java version numbers are confusing, and there is more than one kind ("edition") of Java.
Regular "desktop" or "standard" Java follows certain number scheme. The "enterprise" Java ("Java Enterprise Edition" or "Java EE") built on top of standard Java follows its own numbering scheme. So currently as of 2015-01 we have Java Standard Edition 8 but Java Enterprise Edition 7 (tutorial) (built on Java SE 7).
Be sure to look at the information on Java EE 7 rather than 6. I'm not an expert on publishing web services with Java. But I believe you’ll find many advances that may be easier now in Java EE 7.
Furthermore, there is a lighter smaller version of Java EE 7 called "Web Profile" that supports Servlets and a handful of additional technologies. The full Java EE layers on dozens of other technologies as well. For a list of those Web Profile technologies, see my answer on another question.
Tomcat & Jetty are both outstanding products. But both Tomcat & Jetty aim at mainly Servlets, that being a subset of the Web Profile which turn is a subset of full Java EE. You may, or may not, find the additional features of the Web Profile or full Java EE useful for publishing web services. In that case you may want to use the full Java EE servers such as TomEE or Glassfish or others. Or, sometimes the lighter way to go is to start with Tomcat or Jetty, cherry-pick a few of those additional technologies, and add their jar files to your project.
In particular, you may find JAX-WS useful (tutorial, reference implementation). Or if you prefer REST style, look at Java API for RESTful Services, JAX-RS.
I certainly agree with your statement that the documentation is vast. Unfortunately I think you're going to have to deal with that problem head on. As for scheduling a task, you could use Spring's Task Scheduling feature. This will work on any webapp, but it will also work without a webapp.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Java EE has this "mysterious shroud" around it for younger Java developers - one that I've been trying to lift myself for quite a while with little success.
Confusion arises from:
Java EE seems to be both a library and a platform - there are multiple ways to "get" the Java EE library, typically from something like Oracle's Java EE SDK download. However, the Java EE library will not work, nor compile unless if your code is being run on or has access to a Java EE application server (such as JBoss, GlassFish, Tomcat, etc). Why? Can't the libraries function outside of the application server environment? Why do I need something massive as JBoss just to compile simple code to send an email?
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Why are there so many Java EE offerings when there is really only two main flavors of standard Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?
What can one do with Java EE that they cannot do with standard Java?
What can one do with standard Java that they cannot do with Java EE?
When does a developer decide they "need" Java EE?
When does a developer decide they do not need Java EE?
Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. Java 7)?
Thanks for helping me clear the flog!
Why can't the libraries function outside of the application server environment?
Actually they can. Most of the libraries can be directly used standalone (in Java SE) or included in a .war (practically that's nearly always Tomcat). Some parts of Java EE, like JPA, have explicit sections in their respective specifications that tells how they should work and be used in Java SE.
If anything, it's not so much an application server environment per se that's at stake here, but the presence of all other libraries and the integration code that unites them.
Because of that, annotations will be scanned only once for all your classes instead of every library (EJB, JPA, etc) doing this scanning over and over itself. Also because of that, CDI annotations can be applied to EJB beans and JPA entity managers can be injected into them.
Why do I need something massive as JBoss just to compile simple code to send an email?
There are a few things wrong with this question:
For compiling you only need the API jar, which is below 1MB for the Web Profile, and a little over 1MB for the full profile.
For running you obviously need an implementation, but "massive" is overstating things. The OpenJDK for example is around 75MB and TomEE (a Web Profile implementation containing mail support) is only 25MB. Even GlassFish (a Full Profile implementation) is only 53MB.
Mail works perfectly fine from Java SE (and thus Tomcat) as well using the standalone mail.jar and activation.jar.
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Java EE in a way was one of the first attempts to split up the already massive JDK into chunks that are easier to manage and download. People are already complaining that the graphical classes (AWT, Swing) and Applets are inside the JRE when all they do is run some commands on a headless server. And then you also want to include all the Java EE libraries in the standard JDK?
With the eventual release of modularity support we'll just have a small base JRE with many things separately installable as packages. Perhaps one day many or even all classes that now make up Java EE will be such package as well. Time will tell.
Why are there so many Java EE offerings when there is really only two main flavors of standard Java (Oracle JVM/SDK | OpenJDK JVM/JDK)?
There are more than just two flavors of Java SE. There is at least the IBM JDK, the previous BEA one (JRocket, which is being merged into the Oracle/Sun one because of the acquisition), various other open source implementations and a slew of implementations for embedded use.
The reason behind Java SE and EE being a specification is that many vendors and organizations can implement it and thus it encourages competition and mitigates the risk of vendor lock-in.
It's really no different with C and C++ compilers, where you have many competing offerings as well all adhering to the C++ standard.
Why is Java EE library version not in sync with standard Java library releases (Java EE 6 vs. Java 7)
Java EE builds on Java SE, so it trails behind. The versions do correspond though. Java EE 5 requires Java SE 5. Java EE 6 requires Java SE 6 and so on. It's just that mostly when Java SE X is current, Java EE X-1 is current.
Here are a few quickly composed answers to your questions...
Why can't JavaEE libraries function without an application server?
The services provided by JavaEE (container managed transactions, container managed dependency injection, timer service, etc..) inherently involve JavaEE compliant Application Servers (for example: GlassFish, JBoss, WebSphere, etc...). Therefore the JavaEE libraries serve no purpose without such a container. "Why do I need something as massive as JBoss just to compile simple code to send an email?" You don't. There are ways to send an email without JavaEE... But if you want to do it the JavaEE way, you need a JavaEE container.
Why are JavaEE libraries not included with JavaSE download?
The same reason that many libraries aren't included: it would be overkill. Since you can't even use the JavaEE libraries without an application server, why bother to include them? JavaEE should be downloaded if and when a developer installs an application server and decides to use JavaEE.
Why are there so many JavaEE offerings?
Are there really "so many" JavaEE offerings? If so, please list some of them. More accurately I believe there are multiple implementations of the same APIs.
What can one do with JavaEE that they can't do without standard Java?
Lots. You can't rely on an application server to manage transactions or persistence contexts without JavaEE. You can't allow an application server to manage EJB dependency injection without JavaEE. You can't use an application managed timer service without JavaEE. The answer to this question should make the answer to the first question quite clear... Most of the services provided by JavaEE require a JavaEE container.
What can you do with JavaSE that you can't do with JavaEE?
Um... I don't know.
When does a developer decide they need JavaEE?
This question is completely subjective... But if you need any of the services provided by JavaEE, you start to think about it. If you don't know what JavaEE is... you probably don't need it.
When does a developer decide they do not need JavaEE?
See previous answer.
Why is JavaEE library version not in sync with JavaSE version?
Good question. I won't pretend to know how to answer it... But I would guess the answer is: "because they're not in sync".
At bird's eye view, Java EE is a platform, i.e. something that we can build on.
Taking a more technical perspective, the Java Enterprise Edition standard defines a set of APIs commonly used for building enterprise applications. These APIs are implemented by application servers - and yes, different application servers are at liberty to use different implementations of the Java EE APIs.
However, the java ee library will not work, nor compile unless if your code is being run on or has access to a Java EE application server (such as JBoss, GlassFish, Tomcat, etc).
You compile against the Java EE APIs, so you only need those APIs at compile time. At runtime, you'll also need an implementation of these APIs, i.e. an application server.
Why do I need something massive as JBoss just to compile simple code to send an email?
You don't. However, if you wish to use the Java EE API for sending mail, you will need an implementation of that API at runtime. This can be provided by an application server, or by provided by a stand alone library you add to your classpath.
Why are Java EE libraries not "standard" and included in the regular JVM download and/or the SDK?
Because only the APIs are standardized, not the implementations.
Why are there so many Java EE offerings
Because people disagree on the right way to implement certain features. Because different vendors compete for market share.
What can one do with Java EE that they cannot do with standard Java?
Since Java EE implementations are built with "standard Java": Nothing. However, leveraging the existing libraries can save a great deal of effort if you are solving typical enterprise problems, and using a standardized API can prevent vendor lock-in.
What can one do with standard Java that they cannot do with Java EE?
Nothing, since Java EE includes Java SE.
When does a developer decide they "need" Java EE? When does a developer decide they do not need Java EE?
Generally speaking, the Java EE APIs solve typical, recurring problems in enterprise computing. If you have such problems, it usually makes sense to use the standard solutions - but if you have different problems, different solutions may be called for. For instance, if you need to talk to a relational database, you should consider using JPA. But if you don't need a relational database, JPA won't help you.
What is Java EE?
Let's start from canonicity definition at wiki:
Java Platform, Enterprise Edition or Java EE is Oracle's enterprise
Java computing platform. The platform provides an API and runtime
environment for developing and running enterprise software, including
network and web services, and other large-scale, multi-tiered,
scalable, reliable, and secure network applications.
The main point here is that Java EE is a platform provides an API, not some concrete library.
What for Java EE needed?
The main scope of Java EE is the network based applications, unlike Java SE oriented to the desktop applications development with simple network support. This is the main diference between them.
Scalability, messaging, transactioning, DB support for every application... the need in all of this has increased with the evolution of the network.
Of course a lot of ready solutions which Java SE provides are useful for network development, so Java EE extends Java SE.
Why do we need application servers to run our code?
Why do we need operation systems? Because there are a lot of painful work with hardware we need to do to make even simpliest application. And without OS you need to do it again and again. Oversimplified OS is just a programmatic container, which provides us a global context to run our applications.
And this is what the application servers are. They are allows us to run our applications in their context and provides us a lot of highlevel functionality which is needed for enterprise highloaded network applications. And we are don't want to write our own bicycles to solve this problems, we are want to write code which will satisfy our business needs.
Another example here could be JVM for Java.
Why Java EE doesn't contains onboard app server?
Hard to say for me. I think, it was done for more flexibility. Java EE says what they should do, they decide how to do it.
Why JVM doesn't include Java EE?
Because they directed to different market sectors. Java EE has a bunch of functionality which is doesn't need for usual desktops.
Why are there so many Java EE offerings?
Because Java EE only describes the behaviour. Everybody can implement it.
What can one do with Java EE that they cannot do with Java SE?
To conquer the internet. It's really hard to do with Java SE applets and sockets :)
What can one do with Java SE that they cannot do with Java EE?
As mentioned above Java EE extends Java SE, so with Java EE you should be able to do everything what is available for Java SE.
When does a developer decide they "need" Java EE?
When they need the power of Java EE. All what is mentioned above.
When does a developer decide they do not need Java EE?
When they write a usual console or desktop application.
Why versions of Java SE and Java EE are unsynced?
Java always had troubles with it's technologies naming and versioning. So this situation is not an exception.
Java EE is all about container concept. Container is an execution context within which will run your application and which provide this last a set of services. Each kind of service is defined by a specification named JSR. For example JSR 907, JTA (java transaction Api) which provide a standard way to manage distributed transaction against different resources. There are generally many different implementations for a given JSR, the implementation you will use depends on the container provider, but you don't really mind about that as you are sure the behavior respect the predefined contract : the JSR API. So to take advantage of Java EE, you need to run your application inside a container. The two main ones are EJB and servlet container which are both present on any Java EE certified application server.
The aim of all of this is to defined a standard execution environment to allow to package your application with only the essentials, id.est. your business. It avoids to depend on a unknown and various set of third-party libraries that you would have to package and provide with your app otherwise, and which may be sources of conflict with other apps on the server. In Java EE you know that all standard non functional requirements like security, transaction, scalability, remote invocation, and many more will be provided by the container (factorized for all apps running inside it) and you just have to base your work on its.
Why is there so much confusion in the java world with various servers like apache, tomcat, jboss, jetty, etc and in .Net world it is just IIS that does that job. I would like to understand the need and use of it and am not starting a java vs. .net.
There are several reasons.
A Java EE app server is a transaction monitor for distributed components. It provides a number of abstractions (e.g., naming, pooling, component lifecycle, persistence, messaging, etc.) to help accomplish this.
Lots of these services are part of the Windows operating system. Java EE needs the abstraction because it's independent of operating system.
It should also be said that the full Java EE specification isn't necessary for developing web applications. JDBC, the part of Java that deals with relational databases, is part of Java SE proper. Java EE adds on servlets, which are HTTP listeners, and Java Server Pages, which is a markup language for generating servlets. You can develop fully functional web applications using just these technologies and Java SE. Tomcat and Jetty are two servlet/JSP engines that can stand in for full Java EE app servers.
If you take note of the fact that .NET has HTTP listeners built into the System.Net module, you realize that it's as if .NET took a page from Java and folded the javax.servlet functionality into the framework.
If you add Spring and a messaging functionality like ActiveMQ or RabbitMQ, you can write complete applications without having to resort to WebLogic, WebSphere, JBoss, or Glassfish. You don't need EJBs or the full Java EE spec.
UPDATE:
Spring Boot offers the possibility of developing and running full-featured Java applications as an executable JAR file. There's no need for any Java EE app server, just JDK 8 or higher.
This is because Sun and Microsoft had very different goals with their software, and ways to reach that goal.
The Sun mantra for Java has been right from the beginning "Write once, run everywhere", and that has resulted in that much effort has been put into creating _API_s that specify how the environment should look like to allow a minimalistic piece of code do its job.
The API for "process a web request and return a web response" was named Servlets, and has been extremely successful due to it filling a void and being well specified. All mainstream Java based web servers I know of allow to run servlets. An early implementation of a complete servlet capable web server is only 1500 lines Later this was expanded to include JSP's to provide for HTML with server side code (like PHP).
For any solution to be truly scalable, including web solutions, it means that eventually the load is so high that one computer is not powerful enough to run it on its own anymore. A scalable solution MUST be able to spread over multiple computers aware of each other, and that single requirement brings a LOT of other things to the table:
Code must be able to invoke code running on a different computer (EJB's).
Data must be available to all computers in a consistent way (database).
Access to said database must be efficient (database connection pooling).
... and much much more
Sun then created API's for all of the functions they found were necessary for this to run, and named it "Java Enterprise Edition" (those days the word "Enterprise" was used for a lot of things), and created a system implementing all these API's which people could buy and use.
The difference between Microsoft and Sun now comes in play. Here Microsoft would just make IIS public, and say "use these API's" in clients but not actually want anybody to create another server providing these APIs. Because they want to sell Windows to run it!
Sun wanted people to use the language instead, so they made it possible for ANYONE to implement the Java EE specification, but they had to pass a rigorious test suite from Sun (and pay) to be allowed to use the Java EE brand. This has caused a large number of Java EE servers to be available where you usually can reuse the core business logic, but have to configure the Java EE server to provide the resources the application needs.
See http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition#Certified_application_servers for the state of servers today. Both commercial and open source are available based on your needs - pick the one that suits you best.
So, the reason is that Java EE is a set of well defined API's that anyone can implement, and they have.
First off, you can run .NET code off Apache using mod_mono, so it is not limited to IIS. There are also several other web servers (Cassini and XPS come to mind) that will run ASP.NET as well.
In order to run a dynamic web application you need both a web server and an application server. Sometimes these integrate so well they appear to be one and the same, sometimes not.
In regards to Java - it has always supported more platforms than .NET and has been more open, therefore got integrated to more web servers (on the Linux stack).
As both .NET and IIS are technologies that came from Microsoft, ASP.NET and the application server aspects of it (aspnet_isapi.dll) were bundled with IIS and the different .NET installers integrate with IIS. Of course, Microsoft only implemented it on their OS and for their web server.
Apache is very analogous to IIS, and doesn't have much to do with Java.
Application Servers in Java provide additional services that .NET provides in various ways, with different products or from the Windows operating system.
Apache is typically used in Java deployments as a proxy to an application server behind it, and potentially serves static content, or handles SSL, and similar concerns. It is entirely optional, although there are good reasons to use it.
Tomcat and Jetty are basically java web servers, which provide a defined framework (Servlets among other things) for creating dynamic web sites with Java code. They are often components of a larger application server, or can be deployed alone.
JBoss is an example of an application server (Glassfish and Weblogic are two very common others), which provides the full J2EE specification. The idea behind the J2EE specification is to allow a defined way to build an application server so that an application can be switched between different application servers from different vendors that comply with the spec. The specification is about how to interact with defined services that are useful for server-side program.
Because Java EE is a specification, not a product itself. Remember that Java is a lot more open than .NET (In the specification sense).
Each application server has different features, different performance, different target users/enterprises, different price tags, runs in different platforms, require different hardware. Differentiation is why those all application servers exists, one size does not fit all.
One reason is that writing a servlet is as easy as implementing the javax.servlet.Servlet interface in a concrete class. Servlet containers, then, only need to support a fairly simple API in order to call themselves web servers. This makes setting out to develop a servlet container extremely simple because of this limited contract of functionality.
The choices off tools are one of the advantages and disadvantages of Java, look at the available Java Web Developement Frameworks,you could evaluate them endlessly just to decide. in .Net it's pretty much MVC. With servers it's relatively simple. Most go to Tomcat if they need a web server and JBoss if they need a free application server though. The reasons for this have already been said, J2EE is a specification.
At the moment, I have lot's of Java which does all kind of nifty stuff and I'm happy with it. The code is command line driven which have been great so far, but I recently decided I want to make the functionality available through web-services. Since my is complex and I'm happy with the way it's written , I don't want go through the pain of porting it to other languages. So I set out on a google journey to find out what web servers exist (on a Linux machine, though it's interesting to hear the answer without that limitation).
From what I could find, it seems that there are two viable options: Apache Tomcat and Sun Java Server.
What are the reason to choose one on top of the other? what are the strength of each and what are the weaknesses? Or, perhaps, there is a third one which is much easier, flexible and less cumbersome.
Anyone?
Easy, flexible and not cumbersome, that would be Jetty, but also Simpleweb might be useful. You dont say much about your software so i'm not really sure, but for a command line program, I don't think you need all the JavaEE stuff.
The mainstream servers are these.
I think the Apache Tomcat vs Glassfish (Sun Java Server) discussion is irrelevant for your needs, any would do.
There are many containers for Java web applications, they all have their own strengths and weaknesses. If you're looking for a container to support a business application, you should probably take a look at how they differ and work out which suits your business and IT drivers.
The key thing is that they all support the servlet specification - your webapps can run in any of them - which means you can change your mind easily. Some of them will also support more of the Java Enterprise Edition specs, so may be too heavy for your needs.
If you're just getting started, I'd suggest Tomcat. It's basic, but it's reliable, quick to run and start up, and it's got a really easy web-based webapp deployment interface.
Your question is actually a bit too ambiguous and wide. You can in fact run Java code at any machine you like, regardless of the language you programmed the webbased interface in. You can for example create a PHP based website which interacts with a "backend" Java application (the "command line application" as you call it). The only requirement is to have a JRE at the server machine. Then basically everything as web interface suffices: CGI, PHP, ASP, Python, etcetera, you name it. As long as it has access to the underlying commandline runtime, which is in the PHP example to be done by exec().
But Java, actually Java EE, also provides a web application programming interface: the JSP/Servlet API, the web component of the large Java EE API. This make integration with the "commandline Java application" much more seamless. You can basically just put your application in the classpath and import/access/use it in a Servlet class the real Java way:
YourApplication app = new YourApplication();
Result result = app.doStuff();
// ...
To be able to run JSP/Servlet (JSP is at end actually also a Servlet), you need a concrete implementation of the Servlet API (the whole Java EE is just an abstract specification). Apache Tomcat is good to start with, the other popular alternative being Eclipse Jetty. Those are 'simple' servletcontainers which implements the Servlet API, with Jetty being a more embedded approach of it (you can configure and run it as a "plain vanilla" Java Application). But if you need to support/cover the other aspects of the Java EE API as well, then you need an application server, such as Sun Glassfish or JBoss AS (both which by the way uses Tomcat as the servletcontainer part).
To learn more about JSP/Servlet, I can recommend the Coreservlets.com tutorials.
Apache Tomcat should do good.
The standard concept for running code inside a web server is the "Servlet API" from Sun.
Essentially it provides a few interfaces which the web server uses to invoke your code, and defines how the web server should behave. This allows you to write very generic code that can run in a variety of web containers which implement the Servlet API. See the Wikipedia article for details - http://en.wikipedia.org/wiki/Java_Servlet.
They come in all sizes too, depending on your needs. Some small enough for embedding in your own application, some very big. The servlet API allows you not to care.
For a beginner, the quickest way to get up and running, is to download the full version of Netbeans which includes full support for doing this kind of work, and has a built in servlet container.
I know this is a stupid question and I really have been looking around for a few hours... but how can I get Java EE? I would like the Java EE and j2eeadmin tools. What do I download
I have downloaded and installed the jdk-6u16-windows-i586 (Java SE Development Kit 6u16 for Windows)
Can someone point me in the right direction? Thanks.
JavaEE sometimes hard to define
Oh, your question isn't so stupid. It turns out that downloading JavaEE is a slightly tricky thing.
If you go over to Sun, you will find this located at http://java.sun.com/javaee/downloads/. But that's actually a GlassFish d/l. It's fine, but if you go somewhere else you might end up with JBoss which will have its own container implementations and its own package of modules to load. JavaEE is a big umbrella of technologies, many of them quite clunky and obsolete, and in any case you develop and deploy a very specific collection of things, rather than a program which just loads classes from some bigger version of JavaSE.
Or, you might want to start with something even smaller, like Tomcat.
You might want to think more in terms of "how should I set up to develop for the xyz application server".
If you want to just play with JMS on your local computer, you could start with GlassFish from Sun. It will pretty much "just work" out of the box.
Yes, you get the full boat Java EE app server and stack as well, of which JMS is but a component, but at the same time it's trivial to install and get working. Especially if you add in NetBeans as the IDE, since it's well integrated with GlassFish.
That said, you certainly don't need an entire Java EE app server just to use JMS. There are many JMS compatible Messaging servers available. ActiveMQ is a single example.
I only suggest Glassfish because it has a great out of box experience in terms of download, install, start up and it's running.
If you want to work on configuring another option, there are several.
Also, I suggest GlassFish (or any full Java EE server) simply because even if you're just interested in JMS, you'll likely find that the Java EE Message Driven Bean (MDB) model actually works pretty well as a mechanism to leverage JMS. And it, too, is pretty simple to set up for the basic use cases. Once you have an MDB, you might want to talk to a database, and the Java EE server has connection pooling, etc. built in already as well. You also get transaction management with Java EE (which can actually be important with JMS).
Basically, while JMS alone is interesting, the other services are also compelling, even if you "don't need them yet". If you want to dabble with them, they're readily available in a full Java EE server, which promotes experimentation, and perhaps adoption.
So, starting with a GlassFish download can actually be an interesting door for learning and discovery things above and beyond JMS.
http://developers.sun.com/downloads/
Select the Java EE link. Select Java EE 5 (first option). One reason I didn't post the link directly is that you'll be sent to a different link depending on the operating system you are using.
see Java EE at: http://developers.sun.com/downloads/