'kay. Summary: (everyone, please correct and add to?) --------------- SIMILAR EFFORTS --------------- Here's a list of similar efforts that I know of... (requirments: 1) some kind of application platform 2) 100% java 3) open source)
JBoss ----- goal: provide open source J2EE server. offers: J2EE compliance, EJB, JMS, O/R-mapping, JNDI, JCA, JTA/JTS, JAAS, GUI Management (JMX), Servlet/JSP, Database, JDO license: LGPL url: http://www.jboss.org status: release notes: huge developer community Jahia ----- goal: provide portal solution built on J2EE components. offers: JBoss, Database, Servlet/JSP, custom portal server (dunno what it does as the installer fails on my win2000 box) license: Jahia License (commercial) url: http://products.xo3.com:8080/ status: (preliminary) release notes: Paul, seems like a shrink-wrap commercial solution to me??? Enhydra ------- goal: provide open source web application server. offers: Servlets/JSP, Template Engine (XMLC), Sessions, Database connectivity, MVC Framework license: Enhydra Public License (Mozilla-style) url: http://www.enhydra.org status: release note: dying slowly it seems, as Lutris is pulling out EAS --- goal: provide BSD-style license J2EE server. offers: Servlets/JSP, EJB, Avalon license: BSD-Style url: http://eas.betaversion.org status: alpha note: been dead a while now as backing company went bankrupt. ---------------------------- OPEN ENTERPRISE DISTRIBUTION ---------------------------- goal: provide an open source alternative architecture to J2EE. offers: Database, Pooling, Logging, Management, etc. (to be defined) license: Apache-style url: none (will be sourceforge) status: conceptual Candidate Components For Inclusion ---------------------------------- Jakarta: Avalon Struts Turbine Velocity James Jetspeed Slide Tomcat Apache XML: Cocoon SOAP SourceForge: Enterprise Object Broker Simper (soon, anyway) HSQL Ozone JBoss Maverick Jetty Niggle OpenCMS Pi (...the list goes on and on...) Exolab: OpenEJB OpenJMS OpenORB Castor Tyrex (...) Clearly, there are loads. We need some criteria. Architecture ------------ One thing I think OEB needs is formalization of the patterns of choice in the form of core interfaces. The two projects I know that deal with that are Avalon and Turbine. Another thing it needs is a definition of how it "glues". Options are JNDI, SOAP, JMX, Avalon Service framework, Turbine Services Framework, CORBA...and I'm sure I'm missing a few. Of those, of course _I_ am in favor of the setup Avalon uses, but hey ;) This e-mail is now officially more than long enough. cheers, - Leo -----Oorspronkelijk bericht----- Van: Andrus Adamchik [mailto:[EMAIL PROTECTED]] Verzonden: maandag 25 februari 2002 1:27 Aan: Jakarta General List Onderwerp: Re: The Complete Server Platform? Tim Hyde wrote: > Andrus, > > I'm 100% behind the idea of the complete platform, but I'm worried that your > proposal talks about 'Web Applications'. > > I believe that what's needed is an alternative to the very idea that J2EE > (or even J2SE) is *the* definitive collection of java libraries, and that > the project should offering a number of sensible alternatives for use in any > architecture. We still will depend on certain commercial JVM's (Sun or IBM), right? > Database access, Logging, and Development Process are three things that > you've specifically mentioned that aren't particularly Web or Server > oriented. > > Web Applications, or Server Applications, are more part of today's 'fashion' > than inherent categories of how you make a computing solution, and we can > expect things to move on during the lifetime of Java. Well, we can hope, > anyway. :-) You are right. I was mentioning Web applications just cause I wanted to limit initial scope to something sane. And I guess because I am myself is a better expert in this area then in any other. This would've helped to concentrate on a certain solution-based approach from the beginning. But I agree we can widen the scope as long as we can outline the problems being solved. > > So, if possible, why not talk about a 'development and deployment platform > for Java applications' - and then start off by assembling both the > underlying 'component' toolsets and a number of combination-examples, such > as the jGuru one Ted mentioned, and whatever else might emerge during the > project as perhaps 'miniature live examples'. +1, like I said above, I am for it if we define use cases we are going after. > Naturally, server applications are the primary interest point initially, but > it would be nice to think that the collection of tools being provided for > distribution would be offered as having wide applicability. > > In particular, I believe that if a thing like this is available *and gets > marketed* (in the Red Hat sense) properly, we could start to see the > weakening of the Dilbert idea that only vendor-supplied products are > 'serious' tools. > > This *marketing* focus is the very thing I had settled on as being the > logical conclusion of the recent threads (J2EE considered harmful, EJB=Bad, > etc). A way to bring the marketplace to see that there are better > alternatives than the Dark Lords. Hence the marketing side (meaning actual > activity to spread the word and work in PR mode with the media) needs to be > a vital part of this project, needing volunteers of a different sort than > technicians. > > But assembling the distribution first is very important, and I'm with you on > this. yes, this should be the starting point > > One small extra: if a RedHat style toolkit distribution were available, the > number of independent consultants who could offer their support services > would exceed the number available to BEA, for example, eliminating that > argument that 'I buy where I can depend on getting support'. Well, we can > dream, anyway. +1. I am an independent consultant myself, and I would stick with a technology that - allows me to concentrate on customer requirements rather then repetitive coding tasks, - offers strong design direction, - implemented most of the standard tasks already. The only thing that would prevent me from using such technology is that customer's CIO has never read about it in JDJ. > > I had been considering a project along these lines, and had thought of the > name 'Tonic', both because it might revive a sickening architecture and > because the Tonic (in musical terms) is where you want to go after the > Dominant :-) > > But, if OED is the same thing, yes, what's in a name ? But, think marketing > eventually !! I like the name Tonic, but I think Open Enterprise Distribution may actually serve that same marketing goal better. It does sound ..umm.. serious or something :-) .. -- ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~- - Andrei (a.k.a. Andrus) Adamchik http://objectstyle.org list email: andrus-jk at objectstyle dot org personal email: andrus at objectstyle dot org -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>