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.
Ok, I know this is a vague question, and I expect a vague/basic answer.
I am well versed with PHP driven MVC frameworks and how the process of serving pages works. I'm very interested in learning Java, and I figure the only way to learn it is to do it. However, after reading page after page after page, it gets more confusing as I read.
I'm running into GWT (front end), Hibernate (ORM connection?), Spring Architecture, Spring Roo (what is this?), JBoss (servelet), JPA (ORM), POJO (a style of using regular java objects with orm?), Maven?
My basic question is how do all of these fit together? I like the idea of using a framework, because it's worked well in the past with PHP. How do I use this functionality with java? Suppose I wanted to build a web application with a relational data store. How does java authenticate, initate a session, and serve pages with dynamic content? What is the process?
When responding, please don't say "stick with what you know," (as I've seen on other pages) because I'm very interested about java and I'm trying to learn.
I totally hear you - too many acronymns have propped up as Java EE has evolved.
I will try to put an explanation
Java is the language
Java EE (Java Enterprise Edition) is the general term used to encapsulate all Java technologies that help create an enterprise/web application with Java
So a typical web application with Java looks like follows:
Front End
Use JSP or JSF for server side processing and rendering (JSP and JSF
offer ability to define your UI using HTML and server side tags that
bind easily with your Java Beans) However they do tend to mix UI with
backend if not implemented correctly
you can also use plain HTML and any client side toolkits for rendering (such as jquery, dojo, extjs or flex) and fetch your data
from the Java EE server.
you can even mix the two (use a client side framework in a JSP to achieve best of both) or use a toolkit like GWT that offers client side richness with javascript with Java APIs and ease of accessing your java beans
Middle tier
Java Servlets offer the base for all server side processing with Java EE (Servlets offer session persistence, HTTP request processing, response processing) and typically offload the business processing to a model bean - which could be a POJO or spring bean.
Servlets are Java programs you write and are executed in what is called a Java EE container. Popular containers are tomcat, IBM websphere, BEA Weblogic
To help implement a good MVC architecture, there are several frameworks and tools provided on top of Servlets:
Struts2 and Spring MVC are examples of such frameworks
To make it easy to implement web services, Restlet/Jersey help with REST based web services, JAX-WS/APache Axis help with SOAP based web services
Integration with backend database/persistent store
You could use JDBC in your POJO or other model bean to access the DB using Java.
Or alternately use one of the frameworks such as Hibernate to make it easy to interface with the DB backend
Sun's petstore application is a good place to start to learn how the pieces fit together
http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-eedocs-419425.html#7522-petstore-1.1.2-oth-JPR
Build and Deployment
Ant and Maven are tools used to build your app and manage dependencies
the application gets packaged as a WAR or EAR file and can be dropped into any Java EE container to deploy it. Once it is deployed, it can be accessed using a URL
Tools like Eclipse, Netbeans, Oracle JDeveloper offer integrated IDEs to help with local deployment and testing
The good part with Java EE is that you can pick and choose the components you want to use to build your webapp.
The problem Java has is that it's fairly old and there are TONS of frameworks and packages that do similar things as other packages. At the very core, however, is the Servlet, that specifies how Java behaves as a server over the HTTP protocol.
With that basic building block, there are lots of web frameworks like Struts, and Spring MVC that build up layers of functionality by using lots of good OO development patterns, like Fiters, Delegates, Factories, MVC, etc., to allow the developer to put together an application that takes web requests as input and returns a web response as output.
Those frameworks often build on other frameworks or packages to give application developers more capabilities at different layers of the application. This includes things like ORMs (like Hibernate) to talk to relational databases, or view compositing frameworks like Tiles or Velocity to help put together an HTML page as part of the response.
There are lots of other acronyms and tools and layers that get built up around web frameworks, but essentially they are all just programming tools that have useful functionality pre-built and just need to be used.
If you are looking for a more packaged web application development framework that is more cohesive and doesn't make you feel quite as lost, you may want to take a look at Grails. It is in Groovy, but it is very close to Java in terms of the language and actually builds on top of lots of the other tools you have heard of.
Grails itself builds on the Spring and Spring MVC frameworks, as well as Hibernate, so it's using the same technologies as other more pure Java frameworks, but it abstracts the ugly details away so you don't have to worry about them unless you want to. You can then bundle in additional functionality, like authentication / security, through plugins. If you are well versed in PHP-based MVC frameworks and how they work from an architecture standpoint, you will feel right at home in a similar MVC environment like Grails or Spring MVC. The Grails User Guide is a great place to start, and the rest of the documentation is good too.
If you are new to the Java language, I would strongly suggest doing a few small applications (not web apps, just simple ones) to learn the language and get familiar with how things work. Java is very different from PHP, since PHP bundles in a lot of the base functionality into the language whereas Java has a fairly sparse language with much of the commonly used functionality coming from libraries.
Once you have a good grasp of the Java language, I would jump right to the Grails framework and I would skip all of the nitty-gritty details of servlets and ORMs and Hibernate, etc. at first because you don't need to know it all and there is so much there that it can get in the way of actually understanding things.
Then, once as you start to build out an application with Grails, you will gradually get a deeper understanding of the technology Grails is built on in order to do more complex and powerful things. Slowly, you will work your way into Spring and Hibernate and build up an understanding of how things are put together under the covers, but you can be doing real things faster since you don't have to know all of that from the beginning and can quickly make web applications in Grails the just work, especially with an understanding of the MVC architecture pattern with respect to an application responding to a web request.
Wow, not only is this an open ended question, but it could have pages and pages of answers. I worked in php ~ 7 years ago without a framework so I'll try to point you in some starting directions and compare my experience (which is outdated and sans framework!)
You need an application server just like your Apache server for your Java web app, such as Tomcat, Jboss or Glassfish. These servers handle serving dynamic content.
On top of the server you have your web frameworks which you've mentioned GWT, Spring, and Spring Roo. Spring Roo is like Rails, but in Java. GWT goes all out and and will write your html/javascript code based on your Java code.
In Spring You can define objects to be used in your forms and then when they are submitted the entire object is passed back so there is less work. I remember the days of getting a lot of $_POST[] stuff and I'm thankful not to have to do that when using spring. There is Spring Security that you can use for auth.
The web frameworks are configured to connect to the database and then there is the database abstraction ORM, Hibernate. In PHP I used EZSQL for abstraction which didn't contain nearly the amount of features Hibernate does. Hibernate has a steep learning curve, but is worth learning.
For dynamic GUI's you'll probably want to research JSP, but may be interested in learning JSF.
If I were you, I'd pick an application server, maybe tomcat, then a web framework to play around with, personally I'd go with Spring. The framework will probably have dynamic GUI examples so you'll pick up jsp/jsf. Then possibly add the ORM and a build tool to build externally from your IDE, such as Maven, Ant, or Gradle.
There are some very mature java libraries that each target a very small need in a web application. This means that many tutorials on the subject will have to pick and choose the libraries for each need. For someone just starting out from your position, this probably sucks.
Naively, then, I searched for "java full stack framework" and found: Full stack framework for Java
The benefit of a full stack framework is that you don't have to choose each component. The framework has strong (perhaps rigid) opinions on how ORM is done, how templating is done, how mapping URLs to functions or actions is done, etc.
As for your list of technologies and acronyms:
GWT - a framework from google that focuses on the front end. Poorly stated, write your front end functionality in Java and have it magically transform into javascript.
Hibernate (ORM connection?) - yep, store and load objects in your app.
Spring Architecture - Spring is pretty close to a full-stack framework, but it doesn't have as many rigid opinions on things. You can swap out templating engines, swap out ORM, etc. Not a bad framework, though. You might want to simply follow a tutorial on Spring (see below on Roo), and use the components suggested by the tutorial. Just know that you might find something else later that fills a particular niche.
Spring Roo (what is this?) - Spring Roo takes Spring and becomes opinionated (use what we say). This allows for less code on your part because it provides the code that integrates the various components. It still allows quite a bit of flexibility when you want to change something. Bonus, it comes with a nice tutorial.
JBoss (servelet) - Usually I think of JBoss as an application container. Since the Java EE spec is a bit more complicated than simple CGI--there's a lot of things that need to be set up by the web server (loading classes, loading configuration files, connecting crap together)--JBoss does that stuff. Alternatives are Tomcat or Jetty.
JPA (ORM) - Yeah, it's a common set of interfaces that the various serialization providers might implement. It might be a database, it might be something else. But the idea is that your code for storing and retrieving objects would look the same.
POJO (a style of using regular java objects with orm?) - In context, probably. "Plain Old Java Objects" are nice for any library. Sometimes a framework might require that you inherit your classes from some special class, like Model or Controller to work properly (also, HTTPServlet). This isn't good, because it restricts your own class hierarchy design and makes your own code less flexible. Consequently, things that work with POJOs are considered better.
Maven - Maven is a tool that helps manage dependencies. Without it, java has its own form of DLL hell. Library A depends on version 1.1 of Library B, but Library C depends on version 1.5 of Library B. Ohhh crap, time to read through a tutorial on classloaders. Don't worry too much, though, any tutorial on java web apps is likely to tell you exactly what you need to download and use.
The first thing I would suggest you to start with, given a knowledge of http protocol, is the JSP technology. Although you would probably use some framework like JSF2 for instance, it is important to start with JSP in order to well understand the technology and how to use it to deal with request/responses (that's my humble opinion of course).
Once you are familiar with JSP and, let's say, JSF 2.0 (you can find loads of documents on that topic) the next step is to try to connect with a data source. In Java EE technology there is a specification called JPA (Java Persistence API). JPA is just a specification for ORM (which is, roughly speaking, mapping an object java model with a set of DB tables)
Once you have your web application working with some basic pages and some operations on a DB you could enforce the security of your app introducing some security mechanisms.
this is a very good reference and start point for all of these topics and much more. It's a long path and it will take you some time. But, believe me, it's worth it!
Good luck!
I suggest you google those keywords and look for some books and tutorials.
Maven
is a tool for managing your Java projects and artifacts (JARs, WARs, etc.). I'd start learning Maven first, so that you have a foundation to create your Java projects on. It also handles your dependency management: you just specify what JARs you need in your application and Maven will download them for you.
JPA (Java Persistence API) handles the Object-Relational-Mapping of your entities. You can write POJOs (plain old Java objects) and map them to your database tables.
Hibernate is a JPA provider (i.e. implementation of JPA). Usually you don't have to deal with Hibernate that much, most of the time you can use JPA directly. You just configure the JPA provider in the persistence.xml config file.
CDI (Context and Dependency Injection) see description. CDI "wires" the components of your application together.
Springframework started as a framework to offer Dependency Injection capabilities, but today it's much more than that. The WebMVC module of spring might be interesting to you. You can write Controllers and Views (using JSP for example).
Servlet API A servlet acts like a little server, handling a HTTP request and generating the response. You can write your own servlets or use a web framework to do it's job, for example Spring's DispatcherServlet or Java Server Faces, or whatever framework.
JSP is a technology to write templates for your HTML files. JSP files are being compiled into Java classes and can contain HTML code, JSP-specific XML code and Java code.
Example:
<ul>
<c:forEach items="${countries}" var="country">
<li>${country}</li>
</c:forEach>
</ul>
renders a list of countries, where ${countries} might be a collection of country objects (or strings in this case).
JSF (Java Server Faces) is another framework for building web applications, utilizing JSP and/or XHTML for defining the views and backing beans for the backend part. I would start learning with JSP instead of JSF, it's easier to learn.
Most of the frameworks are part of the JavaEE standards portfolio. For stuff like CDI to work you need either an application server (like JBoss AS) or at least a server with a servlet container (like Apache Tomcat or Jetty) in combination with Spring.
Spring and Hibernate are not standard, but they implement many of the standard APIs nowadays.
**EDIT: ** you might also want to learn about Annotations in Java code. They are around since Java 5 and are widely used as an alternative to XML based configuration.
So my suggestion is that you start learning Maven (not necessary tho, you can also manage your project manually), then Spring and JSP to be able to create a simple web application and then JPA/Hibernate to make your data persistent.
In my opinion learning Spring is much easier than learning the whole JavaEE APIs, since Spring is quite good documented.
One of the nice things about GWT is that you'll right your client code in Java, with all of its benefits and if you have server code, that could also be in Java as well, and you could share some of the source code, even if the front-end ends up running as JavaScript.
TO build a basic Java web application, go through this tutorial as it will explain the core foundational technologies with the standard Java EE platform and how to develop something real with them.
http://netbeans.org/kb/docs/javaee/ecommerce/intro.html
It will demonstrate the standard Java web technologies such as EJBs, Servlets, JSP, JPA, and how to use Netbeans for your IDE.
Most beginner's are very overwhelmed by the thousands of different technologies and platforms out there with the Java EE framework. Java caters to a very 'open source' type of community and that means that you have ALOT of different choices and road maps on how you can build applications. This is very different from say the .NET world where everything is pretty straightforward and there's a very clean cookie cutter path.
Once you have learned these foundational basics by going through the tutorial, you will have a grasp on what the Java EE framework. Once you understand these basics, you can then start to learn about Maven or Spring and how those type of technologies can help you build better applications and you can make better and more educated decisions.
GWT - Web interface tools. Some competing technologies: Spring, JSF, Wicket
Hibernate - ORM mapping for databases. Competing technology: JPA
Spring Architecture - Web Framework. Competing technology: JSF, Wicket, GWT
Spring Roo - An MVC style flavor of Spring.
JBoss - Application hosting. Competing technologies: Glassfish, Tomcat
JPA - ORM mapping for databases. Competing technology: Hibernate
POJO - Plain old java object. Just a simple object.
Maven - Maven is a way to manage libraries or dependencies that your project uses. There's a central server that hosts many of these libraries and if you ever need to import a new one to use in your project, it's as simple as searching through the server and then copy and paste the configuration settings that they provide you into an XML document called the POM file or pom.xml
Vijay's answer above is pretty much spot on. I'll elaborate on a few points.
Most of the "fameworks" that you mention, spring, roo (which is just a way to work with spring), gwt, struts, etc. all work on top of "Java EE". Java EE is Sun (now oracle's) term for the "standard" way to work with web applications. Java EE also includes a lot of more enterprise stuff like EJBs, JMS, JMX which you won't really need to concern yourself with unless you're doing very high end stuff.
JSP is the part that will be most familiar to you coming from PHP, it's a way of embedding code inside of an HTML page.
Servlets are the middle tier, that's where database connections are created and application logic happens. As it turns out, JSPs are converted into Servlets at compile time.
All Java EE stuff runs inside of a "servlet container" or an "application server". That's the big difference between java and php. Your choices here are usually Tomcat, JBoss or Jetty.
Maven is a build system that helps you to manage 3rd party jar files (libraries) and compiles and runs your test codes. It has plugins to deploy your code to tomcat/jboss/jetty.
POJO stands for "Plain old java object". Most modern frameworks try to shield you from the complexities of what happens under the hood and let you work with "POJOS". This comes into play when working with something like spring or hibernate. You may also see the term "java bean" tossed around, that's a standard way of defining "pojos" that just sets up a convention about how to name getter/setter methods and constructors.
I would recommend getting a book on getting started with JSPs/Servlets and starting there.
I'm just trying to get started with Java EE and related concepts. However, I'm having some trouble understanding the relations between some technologies and the roles they play.
As far as I understand, a Java EE Servlet is a Java class that runs inside a server, and generates responses to requests (typically HTML responses to HTTP requests, though Servlets can theoretically serve any protocol).
My questions:
As far as I understand, I can either write a Servlet class directly, or I can use some technology like JSP or JSF, which will then generate/provide a Servlet for me. At any rate, the Java EE web container (e.g. Apache Tomcat) where I ultimately run my app will only see Servlets, and will not care how they were created (so Servlets are kind of a low level plumbing). Is that true?
If Servlets are kind of low-level, is there any reason to actually use Servlets directly? I have seen many tutorials that explain how to write a Servlet, but that seems rather unpractical. Is there any situation where writing a Servlet directly is better/preferred to using JSP or similar?
Finally, Servlets need a server to run in (e.g. Apache Tomcat). When reading about servers in that context, I've seen various names such as (Java EE) web container, or servlet container, or JSP container, or just Java EE server. Do these terms all mean the same, or is there a difference?
Thanks for helping me get started!
When not using a MVC framework like JSF, Spring MVC, Struts, etc, you still need a servlet to do the basic request/response controlling job. The JSPs -while under the covers indeed being compiled to servlets- should be used as view only, not as controller.
I think your confusion is caused by the relatively huge amount of low quality tutorials about servlets where they are been used to print plain HTML by out.print() statements. This is in view of MVC utterly wrong. I'd suggest to start at our wiki page: https://stackoverflow.com/tags/servlets/info
JSP and JSF are presentation-layer technologies. While it is true that JSP's are compiled into servlets, and that you can even write plain Java code inside of a JSP, doing so is extremely bad coding style. In general, your JSP files should not contain any Java code, and should not do things like query your server's database or directly inspect request parameters. All of that should be done in a separate Servlet (or if using a web framework, then your framework's abstraction of a Servlet) prior to hitting the JSP.
In the typical case, coding up a Servlet for every request you want to service is not practical. Most Java web frameworks completely abstract away the Servlet interface so that you can build a complete webapp without ever directly implementing a Servlet. However, there may be occasional unique cases where it is most effective to bypass a web framework and provide a Servlet that provides some special-case functionality.
They're pretty close to the same, really. All of them are servlet containers. Some of them may also include other Java EE features beyond servlet support. Being a servlet container does not guarantee support for additional Java EE features, but being a Java EE container does guarantee support for servlets.
When the container loads the servlet, no, it won't care much where it came from. That said, different containers handle this differently when it comes to things like dynamic loading and stuff like that, but I wouldn't worry much about it.
Servlets are low level. They're the base abstraction upon which all of the other Java EE web frameworks are based. In the "real world", most of the time, people will use some higher level framework rather than a raw Servlet.
That said, Servlets are still useful when you actually want to get to that "bare metal" (well as bare as Servlets get) interface to an HTTP request. For simple things, it's just easier to write a Servlet than stand up a bunch of framework jars and such.
As far as containers, the distinction is basically Java EE server vs Servlet container or server. Tomcat is NOT a Java EE server, it only handles the web portion of the Java EE stack. To confuse things, Java EE 6 now has a "web-profile", which is basically the Servlet stack, but whereas before a Servlet container couldn't be consider a "Java EE Server", now it can be a "Java EE Server - Web Profile".
Yea, I don't know what it means either.
The key difference is that the Servlet containers (Tomcat, Jetty, Resin) don't come bundled with the rest of the Java EE stack (notably EJBs), but have several other components that are part of the overall Java EE stack.
If you're just getting in to Java EE, I would pick a full boat container (like Glassfish) since a) you can, b) it's easy (GF is trivial to setup) and, c) you won't have to second guess what is or isn't included in your container vs whatever you're reading about requires. GF will have "everything" that is Java EE. It won't have Spring, for example, as that's not Java EE, but if it's in your Java EE book or web site article, GF will have it.
Later you can choose when you want the full kit or just want to use something like Tomcat or not.
A lot of frameworks use servlets under the covers, but abstract them away from the end user. The idea is that servlets themselves are very low level, and the frameworks provide useful abstractions that allow the developers to focus on application design and business logic. I tend to agree with that, but there are hardcore developers who like to work at the servlet level.
Knowledge is power, to answer your second question. So its a good idea to know what servlets do; it can only help. If you ever need to augment your underlying framework, you might find yourself working at the Servlet level - you might do this to debug issues as well.
Servlets do run in servlet containers. There are technical distinctions between a servlet container and Java EE containers. You can have the former without the latter, but you can't have the latter without the former (I think). Servlets are one part of the Java EE stack. Other parts are things like JMS (messaging) and JMX (management extensions), among others.
The frameworks like JSF, JSP, Struts etc internally depend on the servlet spec. These frameworks are built on top of servlets only.
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.