[Mono-list] Mono quotes from a Sun evangelist
Stefan Matthias Aust
sma@3plus4.de
Sat, 29 Mar 2003 19:22:11 +0100
Miguel de Icaza wrote:
> 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