Since it seems like you know a good deal about J2EE, maybe you could explain it to some of us which have a limited understanding of it.
I'm in no way an expert for the whole set of standards kown as J2EE but I'll try to give you an idea of the basics here.
First of all, J2EE (J2 Enterprise Edition) is a marketing name for a large set of standardized APIs based on top of the core of the Java class library which is the so called Java 2 Standard Edition (J2SE). There's also a standard called Micro edition (J2ME) but that doesn't matter here.
The J2SE defines the following core technologies:
- Applets (if you still care, otherwise useless) - JavaBeans (a component object model) - Serialization (binary short term persistance) - RMI (java-style remote procedure calls) - CORBA (platform and language indendepent RPCs) - JDBC (database connectivity similar to ODBC) - JNDI (naming and directory services, think LDAP) - Security (public/private key, hashes, etc) - XML
And a lot of more which isn't important regarding J2EE style application servers. Everything is standardizied by official spefications and you're allowed to implement them. If you want to call your result Java however, you need an okay from Sun.
J2EE adds the following core technologies:
- Servlets - JSPs - EJBs
plus a lot of helpers like Java Mail, Transaction API (JTA), Messaging API (JMS) and so on. Again there're specifications and rules how third parties can provide implementations. Sun only provides a reference implementation which isn't meant to be a competing product.
Well known open source products are Tomcat as servlet/JSP container and JBoss as a free EJB application server. Well known commercial EJB servers are BEA's Weblogic or IBM's Websphere. Most Apache Jakarta and Apache XML projects deal with technologies and solutions around J2EE.
In addition to the specifications, Sun provides blue prints and tools to help developers to know the "right way" to use these technologies. Many developers are still not conviced however, that these are really helpful for their problems because especially EJB targets very high end solutions for large cooperations but not really the mass of every day web solutions.
Perhaps one or the other remembers that strange J2EE vs. .NET Petshop benchmark fiasco. It's an apple and orange comparison because of the different problem domains for ASP/.NET and JSP/EJB. Perhaps it shows that EJBs by the book are too much overhead. This however doesn't mean that J2EE in general is bad.
Before I forget, Sun recently added Webservices to J2EE. I don't know details yet.
I'd like to concentrate on Servlets and JSP here.
A servlet is a plugable tiny little application that can be added to a so called servlet container, an application server framework which does most of the work so that the servlet programmer can concentrate on the "real" work. It's comparable with Applets and Webbrowser - but of course, servlets run inside a server application. Or think of Webservers (Apache httpd) and CGI scripts.
A servlet however, is a service that keeps running and waiting to its job. So so don't have to fork away operation system processes as plain GCI requires. It's interface is quite the same.
It has a service() method which gets a request and a response object passed and it can analyse the reqeust and prepare a reponse. There're some additional life cycle methods which are used by the servlet container to notify the servlet that is was just startet or that it gets destroyed now. The servlet container also provides the session management for the servlet.
While a servlet is a rather abstract entity, the HttpServlet is the most often used concrete implementation. Actually, most people call HttpServlets simply servlets, often not knowing that the mechanism is more general.
Servlets require a servlet container, a server program which starts, stops and run them, providing all the specified interfaces and Tomcat is such a server. Actually Tomcat is a full featured HTTP server because serving static web pages is just one special servlet (the default servlet as it is called in Tomcat). Another servlet even provides CGI for compatibility.
Servlets are normal classes which extends (inherits from) the Servlet class. A manifest file (XML format) describes the servlet and provides a way to add it so any standard-conforming servlet container. Therefore, no matter whether you'll use Tomcat or Jetty or Websphere or WebLogic, you servlet will (should) run without changes. Quite nice.
The typical hello world example
class Hello extends HttpServlet {
public void doGet(HttpRequest req, HttpResponse res) {
res.getWriter().print("Hi!\n");
}
}<web-app> <servlet> <servlet-name>hello</servlet-name> <servlet-class>Hello</servlet-class> </servlet> <servlet-mapping> <servlet-name>hello</servlet-name> <url-pattern>/*.html</url-pattern> </servlet-mapping> </web-app>
However, you could add security realms, filters, parameters etc.
I'm pretty sure that .NET has a very similar way to create web application. The big disadvantage IMHO is, that servlets do not support file upload so you need to use third party solutions here (jakarta has one). .NET also features files as form data. The advantage of servlets however is that you can use any container. From my skim of the .NET API, I think Microsoft is pretty vague here and you're suppost to use the Internet Intrusion Server here.
So much on servlets. JSPs (Java Server Pages) are based on this technology and compiled down to servlets (which gets then dynamically loaded) on the first usage. You can extend JSPs by taglibs, which can added to a web application using a manifest file again. Recently, Sun eventually defined a standard set of predefined taglibs, the standard tag library (STL) which basically defines a whole programming language in XML so that you don't have to add Java to your JSPs if you don't want. I'm still not a JSP believer, using a template library like Webmacro or velocity is often easier. Or you could use XML and XSLT, the Cocoon project provides a lot of useful stuff here.
Perhaps anybody else can pick up here, I'm running out of time.
Hope this helps, bye -- Stefan Matthias Aust // www.3plus4software.de // Inter Deum Et Diabolum Semper Musica Est
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
