The first open source implementation of the latest specification for enterprise Java is expected in JBoss Group LLC’s increasingly popular open source application server next year, Gavin Clarke writes. Read the article at TheRegister.
Open Source J2EE 1.4 Gets Sun Green Light
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
What exactly is an application server? I don’t get the sense that this is the full java system, complete with compiler and vm. But then, the java world is so full of buzzwords it’s hard to tell what’s what.
The application server sits on the Web Server. It allows for Java Server Pages (.JSP) and also for running applications on the Web Server. Thus .JSP and .HTML can be used as the frount end user interface and a Java program on the server can run the back end. In the non-java world, the back end would be PHP or Perl.
Sure.
Joe is correct, sort of.
Application Server means different things to different people.
This is one generally accepted definition of an Application Server.
The Application Server, ideally, is that part of an overall multi-layer application that focuses upon the business logic of the application.
The common “3 tier” or 3 layer business application, particularly e-business application, consists of a Presentation Layer, an Application Layer and a Database Layer.
The Presentation Layer for a web application would be the part that formats the pages for the application. It acts as an interface between the Application Layer and the user.
The Database Layer is the area dedicated to read and writing permanent data. It typically interfaces directly with the Application Layer, rather than the Presentation Layer.
So, in this simplistic model, you see that the Presentation Layer handles the user interface, and gets all of its data from the Application Server, and the Database server handles the data interface dealing, typically, with straight SQL. Where the Presentation Layer talks about Customers and Products, the Database Layer talks in Rows and Columns.
It’s the Application Server in the middle that handles all the madness of processing Customers and Products and filling in the appropriate boxes with the proper values for the Databases Rows and Columns.
Of course, the Application Layer does all of the other work to, such as calculating sales tax or checking for back orders.
Now, the real issue is that the boundaries between the 3 layers can be really fuzzy.
For example, what if all of your business logic (i.e. the routines that calculate sales tax) were done in Stored Procedures implemented within the Database? At that point, the Database takes on the roles of both layers. The same can be said when the business logic is implemented directly in the applications that interface with the users. This is the classic “Client/Server” paradigm as it was known.
Application Servers have become more popular today because of system integration. A simple example is say that you were running a mail order catalog and decided you wanted to take orders from the web. Well, in the past all of your order processing logic was trapped either in the client or database layer which made it difficult to use in the new domain. But, of course, you want the rules to be the same and to be consistent.
So, an Application Server gives the developers and system integrators a place to put this kind of order processing logic, but still have it accessible to different applications. Today you’d write a web app for your online customers, a client app for your in house users (with a perhaps richer interface than the web app), both talking to the same Application Server which talks to your database.
Mind you, this is a trivial example, there are a lot of issues that complicate it, and an Application Server is most certainly not a panacea. There are zillions of applications that get along just fine without them.
J2EEs real role, though, is as an Application Server and integration service to help bring disparate applications together in the enterprise. This is a far cry from a simple web app (and most of the are really pretty simple in architecture). Tie the J2EE Server with “Web Services” (which are basically application services over HTTP) and you can start glueing whole swaths of applications together.
Hope that helps.
This post is acronym city… but I think it’s important to explain a bit about J2EE. Having an open source implementation of something this large (scope wise) is quite amazing. It has existed in bits and pieces from various open source efforts, the largest being JBoss which hasn’t been approved by Sun yet.
J2EE Java 2 Enterprise Edition
J2SE Java 2 Standard Edition
J2EE runs on J2SE and can be thought of as J2SE with extra apis organized in a framework. Aside from what’s in J2SE, J2EE must include specific versions of the following API’s:
EJB Enterprise Java Beans
Servlet dynamic web pages – although not restricted to web
JSP like servlets but HTML/XML/tag based text files
JMS Java Message Service
JTA Java Transaction API
JavaMail Java Mail
JAF JavaBeans Activation Framework
JAXP XML apis
JCA Java Connector Architecture – for legacy mostly
JACC Java Authorization Service Provider Contract
WebServices:
JAX-RPC Remote Proceedure calls with XML
JAXR Java API for XML Registries
SAAJ SOAP with Attachments
JAXR Java API for XML Registries
Management:
JMX Java Management Extensions
J2EE Deployment API
APIs that are already in J2SE:
Java IDL Interface Definition Language
JDBC for database connectivity
RMI-IIOP for remote object
JNDI Naming and Directory services
JAAS Authentication and Authorization
JAXP standard access to SAX and DOM XML parsers
There are several requirements for J2EE such as it must have application client container, applet container, web container for servlets and JSP pages, and
an enterprise bean container.
Aside from the requirements most servers will come with a more than basic Naming Directory, UDDI registry, ebXML registry, more of the JMX spec for management, and features like caching, failover, clustering, etc. These are the areas where competition is still alive but in general you can write a J2EE application and run it on application servers from different vendors.
So with an open source implementation of J2EE you would be able to develop on a free server and then run the application on a paid server that may or may not provide better scalability, management features, or whatever.
http://java.sun.com/j2ee/
J2SE is the compiler/development environment and J2EE is the added libraries/servers for doing all that web services stuff. Is that correct? My problem was with confusing J2SE and J2EE.
Very nice description Will! It’s nice to see people helps out other one!
We’ll have Java for BeOS? That’s reason enough to focus on Java coding and start running BeOS again.
—
Banned: Necrohiphop.com, NonPhixion.com messageboards
Permanent -1 Status on Slashdot
Do your worst…
No, I don’t think so. J2EE is for the most part server oriented software and is built on J2SE. J2SE is what you can call the core of Java. It has the runtime and all of the basic API’s. J2SE is what you’d want to run on BeOS b/c if it did, J2EE would run on it too (except for any apis that have a native component).
Open Sourcing java isn’t necessary for it to run on BeOS. Take Blackdown’s implementation of java for instance. It runs on intel/ppc linux and windows as well I think. It is both free and doesn’t come from Sun but is not open source.
We’ll have Java for BeOS? That’s reason enough to focus on Java coding and start running BeOS again.
Hmmm, Java for RiscOS.
You also have J2ME, which is not an extention of J2SE, but a cut down version for Mobile phones, with a reworked GUI system for small LCDs.
> We’ll have Java for BeOS?
Kava already runs on BeOS (or atlest did), this was only 1.1 (maybe even 1.0).
> We’ll have Java for BeOS?
There’s always beKaffe, which is java 1.2 and sort of works. Developpement seems to have stopped but that’s probably because beunited are meant to be porting the Sun jdk 1.4 (I wish they would release some status updates or something)
Maybe when that’s done they can get cracking on porting jBoss 🙂
Almost.
J2EE is “simply” a specification that describes the behaviors of a compliant server, but it is not an actual implementation (Though they do distribute some packaged interfaces under the J2EE banner).
A system can implement and be compliant with the J2EE specification, but, of course, there’s nothing that holds the vendor to that specification. They can go above and beyond the spec (and most do in some ways).
It’s all very confusing, and some may think it’s a bit backward.
Many of the “standards” (like language standards for C, FORTRAN, Lisp) were developed with the implementations in mind, rather crafted out of thin air and awaiting implementation.
The J2EE specs were, sort of, simply created out of thin air. “We’d like a system that does this”. Of course, that’s not completely true as you really can’t design a system of this complexity without at least some working models. However, it is pretty common that rather than drive the specifications, the implementations follow the specifications. (Mind you the folks actually developing the specifcation include the vendors themselves, so its not as if the new spec comes out of a vaccuum to smite the vendors).
The nice thing though is that you have Sun pushing this specication hard, and you have the vendors owning up to it. For good or ill, the specification is mostly pretty portable across imlpementations, and that’s a very powerful selling point I think for the entire system. It’s good the the vendors Play Along.