[Mono-list] J2EE/.NET/WDNA De-mystified

[David Jeske]

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:

   http://www.integrantinc.com/whitepapers.htm

-- 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
components below.

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
reasons:

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
   Sun. 

   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
   goal.

   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
your head. 

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+
  components.

  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
  works.

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/ + jeske@chat.net