We Keep Coding

Simple Java app on a Windows Server ... should I use Java EE

I'm gonna be creating a fairly straightforward Java app for my company that will process a csv file nightly. It's going to be running on our existing Small Business Server 2011 box so it definitely needs to run as a service (cause it has to run whether someone is logged into the server or not). Eventually I'd like to add a web component to it so I can view the log files from this app via a browser instead of having to pull them off the server manually.
I'm looking for feedback on what would be the best approach for this project. Should I use Jave SE and use a service wrapper around the created app to turn it into a service. Or should I use Jave EE (which I assume already runs as a service)? I've never used or developed for Java EE, so I'm not sure if this would be the best approach or if it would be overkill. If Jave EE is the best approach any and all information you can share on how to get started with it would be much appreciated.
Thanks,
Harry

For the short term, are you looking for a web interface through which someone uploads (web interface) or some process pushes (web service) a csv file that you then process? If yes, then consider Java EE: servlets, RESTful web services, and such, as others have mentioned.
Otherwise, are you just going to process an existing csv file that's "out on the file system somewhere" on a scheduled basis? If yes then consider timer based Java EE service.
Your production environment's management team might have some insight on what they'd prefer. If they are oriented around a windows management scheme they might be more comfortable with the "native windows" approach to deployment, start, stop, restart, scheduling, etc (i.e. the service-wrapped java program). Another layer of "service management" for just one process may be unnecessary complexity.
Document your setup/configuration/expectations whatever you do.
Longer term, as pointed out by others, your desire for a java-based web monitoring interface will require an app server. Consider your short/longer priorities, schedules to be met, etc. What do you need, when?

Java EE is a set of APIs, including JMS, servlet, JNDI, JDBC, EJBs etc. Consequently by using any one of these APIs you can pretty much claim that you're using Java EE, for what it's worth.
As to your particular problem, I would perhaps develop your program as a simple servlet based app and run it under a small container such as Jetty. That way you have a lightweight container (Jetty) and a fairly trivial program to write that can have a simple front-end for admin/monitoring. Note that the Servlet API forms part of the Java EE spec, so you're Java EE compliant, albeit in a minor fashion.
An alternative to this is (depending on how important that web interface is) is to write the program as a standalone program, and run it as a service using the Java Service Wrapper. At a later date you can then embed Jetty into your program and write your simple servlet-based API to run under the embedded web server. I used this approach on a number of projects and it works very well.

Anything that requires enterprise-level functionality should be done using Java EE:
The Java EE platform is built on top of the Java SE platform. The Java EE platform provides an API and runtime environment for developing and running large-scale, multi-tiered, scalable, reliable, and secure network applications.
http://docs.oracle.com/javaee/6/firstcup/doc/gkhoy.html

Others have explained you what is JavaEE.
Since you say "simple", I guess JSP and Servlets can do the work. You will need a web container like tomcat and that's all(it is easier than having a ejb container + web!). Actually servlets and JSP can do stuff which are not simple too.
If you are willing to use something like sessions, which have great design than Servlet sessions, then you might want to deal with EJB and all.

Unless you're ready to implement a web server yourself from Java SE, you don't have much choice: you'll need some web application framework. It can ba a Java EE web container, or another implementation like Play, for example. But Java SE won't be sufficient.

You may use webservices for instance axis2

Implications of building a java program against the jars of one web container and deploying it in another

What are the implications of building a java program against the jars of one web container (say Jetty) and running it in another (say Tomcat)?
I have an application which I run in Jetty durring development but which is deployed into a tomcat server for production (Why? because it seems easier to develop without having to run a whole tomcat server.)

You should compile against only the official Java EE API's for the level you target, for any non-developer builds. Preferably by a build engine. Preferably on a different operating system than you develop on.
For a web application this mean the appropriate servlet API as downloaded from Oracle. Similar for an enterprise application.
In my experience this is the best way to keep it straight.
Edit: Java EE SDK is available from http://www.oracle.com/technetwork/java/javaee/downloads/index.html. If you need an older version than Java EE 6, then follow the "Previous Releases" link.

You can get issues such as MethodNotFoundError. You can usually resolve these by making sure versions of jars installed on the servers match.

you typically want to develop where you deploy. It might be slightly harder to develop with tomcat vs jetty, but you have identified a potential mess of a problem with jar conflicts, so doesn't it seem worth it to develop with tomcat, since you deploy to tomcat?
Also, typically the pain of developing against tomcat/your container of choice is mitigated by putting in the time to write a ant (or other) task that will deploy your code to your development container. The work cycle bemoes
1) Write new code
2) make sure tests pass
3) run your 'redeploy' script
4) poke around in the running instance
You probably want to do that.
Finally, in the spirit of loose coupling, you probably do not want to depend on a container-specific libraries if you can avoid it; only do that as an absolute last resort.

Creating a dll from a java .war file

I have an external tool that is a tomcat webservice (distributed as a .war) that I would like to use from .net. I have a fairly complex environment and I would like to not have to deal with adding more moving parts (tomcat, java, etc) to the production machines. Is there a way to convert the app to a dll?

I'm afraid the only option you have is to deploy the WAR in a Java environment and then call it from your .NET environment.
I can recommend Jetty for deploying the WAR, I have had much better experiences than using Tomcat. It's simpler, starts up faster, the errors are easier to understand. (But obviously any Java web container will do.)
Then call your Java service from your .NET code. It seems like the Java code already offers a web service, so you need to build a client for that in .NET. If it uses a standard web service protocol like SOAP there should be lots of libraries available for .NET to allow you to do that.
There is no quick automatic way to convert Java into .NET alas; so this is your only option.

.dll are totally windows specific things where .war is totally jvm specific thing.
I don't think you will find tool / converter for it.
I would suggest consume web Services from your .net

Utterly impossible. Be glad that having this tool as a webservice means you only need a JVM and a servlet container to use it, rather than having to rewrite it completely. When it comes to application integration, this is a very easy case.

Why does Java apps need an application server and .Net just IIS Web Server?

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.

What web server should I use if I want to run Java code behind it?

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.