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/ + [EMAIL PROTECTED] _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
