[Mono-list] J2EE/.NET/WDNA De-mystified
Sat, 29 Mar 2003 12:17:36 -0800
I'd like to help clear up the Java/C# J2EE/WDNA issue. However, this
post is unfortunatlly REALLY long. I'll save most of you the trouble
by summarizing first:
Q: Should we build a J2EE style architecure for C#/.NET?
Even if you released a 100% functional Enterprise environment which
beat the pants off J2EE and WDNA/.NET, not a single Enterprise
developer would care, because C# is "not yet real" outside Windows,
and WDNA/.NET is the way to interoperate on Windows.
Lets make Mono/C# sing on every platform on the planet, and then
ask this question again.
Q: What is J2EE?
J2EE people ask "what is open source?" because they don't
understand it. Here is one explanation:
Open source on Linux (*nix) is unified because almost all the
software available compiles with gcc, is unpacked with gzip and
tar, and uses GNU configure. Furthermore, we use diff, and usually
CVS for change control. We use Internet mailing list for
communication. We can all easily contribute to open-source software
because every time we download a piece of open-source software, we
know exactly how to compile it, exactly how to change it, exactly
how to submit patches, and exactly how to talk about those
patches. This set of patterns and habits is constantly in flux and
being improved by new techniques.
Now when you ask "what is J2EE?", I'll offer a similar explanation:
J2EE is the same sort of lingua-franca for the Enterprise software
and implementation consulting world. When software is developed for
J2EE, IT professionals know how to setup machines, how to install
the software, how to hook it to other J2EE software they already
have, how to plug into it's APIs, how to make it work with their
security systems, how to make it scale up as their needs grow, and
how to talk about configuration and customizatoin
issues. Enterprise developers know how to make their software play
nice in this world, and how to talk to IT professionals about what
they need. This set of patterns and habits is constantly in flux
and being improved by new techniques.
Q: No really, what is J2EE?
Find a comfortable chair and read on...
On Sat, Mar 29, 2003 at 07:22:11PM +0100, Stefan Matthias Aust wrote:
> I'd like to concentrate on Servlets and JSP here.
I'm not a J2EE programmer, but AFAIK, Servlets and JSP are not the
parts of J2EE that supporters would say are "more mature" than .NET.
The Servlet API is trivial, and as you mention not all that great. The
nicest thing about is that it's the same from server to server. The
equivilant on .NET is ISAPI. ISAPI works on (at least) IIS and Apache.
JSP is a code-in-template dynamic HTML system. This is very similar to
ASP.NET. While these technologies are very popular, they certainly are
not the only way to build web-apps. MVC style template systems are
gaining popularity such as Java Velocity/Webmacro. JSP is trying to
emulate with "struts". The point is, JSP is not the only game in town.
Yes, these two pieces are part of J2EE, but J2EE is more about (a) the
"advanced services" such as multi-tier, EJB, JTA, JMS, JNDI, and (b)
the "whole package" that all these things come together in a way where
(theoretically) XYZ Corp can buy a J2EE application and install it on
their existing application server of choice, alongside their existing
applications, and then use components of J2EE to allow the two
applications to talk to eachother.
The Windows-world equivilant is known as "Windows DNA" (Windows
Internet Applications Architecture). It offers the same concept
without the openness. That is, XYZ Corp can buy a WDNA application and
install it on their existing WDNA environment. The trick is that there
is only one WDNA environment, and it comes from Microsoft. Here is a
component for component comparison:
-- J2EE Goals --
Of course if you don't know J2EE or WDNA, all those words probably
didn't answer your question, which is likely:
What the heck is J2EE good for anyhow?
There are many answers. Here are a few of them:
1. It's a marketing label just like .NET, which focuses industry
attention and support.
2. It is a multi-tier scalability model. The J2EE scalability model
is not amazing. However, if developers follow the model, it's
likely that someone else will be able to get reasonable
scalability out of their applications without the original
developer thinking about anything more than the J2EE mutli-tier
pattern. Having built really-large web services involving hundreds
of machines, I don't think J2EE is that great. However, most
developers really don't know too much about scalability, and J2EE
helps. Really good scalability architects can probably figure out
how to map their designs onto J2EE application servers, and then
mere-mortals can install and configure that software elsewhere
because they understand "application server goes here", "front-end
server goes there".
3. It is a philosophy and a set of goals shared by Enterprise
Developers and Integrators. The holy-grail is to be able to buy
Enterprise Applications, and easily plug them together to do
whatever you want. Of course neither J2EE nor .NET actually
achieve that goal, because what you can do is always dependent on
the details of how each application is implemented. However,
people who build applications for J2EE (theoretically) intend them
to be good citizens in the J2EE environment.
One of the simple built-in examples that they have already figured
out is security/login. Any J2EE web-application that your
enterprise purchases will share YOUR login and authentication
system. Whether it is NIS, NIS+, LDAP, Active Directory, Kerberos,
or Jimmy's Password File.
There are community JSRs for "continuous availability" (jsr 117),
"client provisioning" (jsr 124), "connector architecture 1.5" (jsr
112), "rule engine" (jsr 94), "data mining" (jsr 73). Again, these
APIs could exist anywhere (J2EE, .NET, C++, Gnome, C,
wherever). J2EE is a focal point for Enterprise Software
Developers and Integrators to come to agreement on standards.
Most developers will read that list and still not understand. That's
okay. That just means you're not developing applications which need to
be customized and integrated. I'll still try to explain the J2EE
Some developers will read that list and argue that J2EE isn't really
all that great, and it's alot of overhead. However, you really can't
argue with #1.
-- Should we develop something like J2EE? --
However, lets go back to the point of this whole thread. Someone said,
"lets create a J2EE architecture for C#/.NET". Then much discussion
about the merits and capabilities of J2EE vs. .NET ensued. The real
question is really:
What would be most helpful to the Mono/C# development community?
I don't believe (at this time) there is value in trying to fill
percieved gaps in .NET vs. J2EE by creating new APIs. Here are my
1) Most of the benefits of J2EE come from being standardized across
several implementations. The focus of the industry is on
Microsoft's work with .NET. For there to be a similar industry
concensus, it must come from Microsft, just like J2EE came from
Projects to fill out the WDNA architecture on Mono/Linux would
be useful. By building ASP.NET, WebForms, and implementations
of the .NET API components, we are already moving towards this
In other words, even if you released a 100% functional Enterprise
environment which beat the pants off J2EE and WDNA, not a single
Enterprise developer would care, because C# is "not yet real"
outside Windows, and WDNA is the way to go on Windows.
2) IMO, Mono is more about C#/CLI than about WDNA/.NET. gcc/glib
implemented an open C/C++ environment with a standard C library. It
did not implement MFC. Similarly, Mono is implementing C# and the
standard C# library. Much energy is being focused on building out
Windows compatible versions of many APIs, such as
Windows.Forms. However, it is already more practical to build
Mono/C# GUI apps using Gtk# than Windows.Forms. That is because C#
(even in Microsoft's mind) is a programming language, while Java is
a "cross-platform compatability environment".
3) In order for Enterprise developers to care about a non-J2EE,
non-WDNA Enterprise standard on C#, the C#/CLI environment will
need to be stable, well supported, and mainstream on platforms
other than Windows.
Lets focus on this goal.. Mono everywhere!
-- No, but really... What is J2EE? --
Frankly, I already told you. If you think that some list of technical
descriptions of J2EE is going to help you understand it, I think
you're wrong. Like most of us technical folks, you'll look at the
pieces, and you'll understand that the J2EE tools are more useful
sometimes and less useful others, and you will still be scratching
However, if you agree not to argue about whether any of these
components is of any use, you can read on. If you are a J2EE wizard,
please feel free to clarify (or correct) my explanations:
EJB - Enterprise Java Beans
Java is a class-based language. There are many things you want to do
with objects which are published as "components" which are not
easily represented in the class model. For example, you want to
export customization properties, and give them nice names, help
text, and categories. You also want to save the configuration state
and reload it later. Java Beans does this. A "bean" is a
"component". Replace every occurance of "Bean" with "Component" and
their documents will probably make more sense.
C# enables component programming with Properties, Attributes, and
Serialization. System.EnterpriseServices is a backward compatible
layer for having C# components play nice in the world of COM+
Enterprise Java Beans extends the capabilities of Java Beans. It
makes the serialization of Bean state part of a database backed
transaction environment -- plus a bunch more stuff.
C#/.NET handles the transaction part of this with MTS. The gap is
the binding of a component to the transaction services.
JTA - Java Transaction Architecture
This allows several transaction oriented systems to coordinate. If
you want to commit a change to three application servers and an
oracle database, you do it with JTA.
.NET uses Microsoft Transaction Services to do the same thing.
JMS - Java Messaging Service
Often you need to send messages out from one component, to be
received by another component, without knowing where these
components live. You do this with JMS. JMS could be implemented with
a Java standard like RMI, or with an open standard like Jabber.
Microsoft has "Microsoft Message Queueing". I don't know how this
JNDI - Java Naming and Directory Interface
A means to store and retrieve configuration information. The JNDI
provider can have a backing store in any number of places. JNDI is
often used as an interface to access the Windows Registry.
On Windows, applications access the windows registry directly, using
a custom API. It's possible that the Active-Directory APIs are
closer to JNDI. I'm not sure.
Phew, we're done... I hope that was useful.
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + firstname.lastname@example.org