'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]>
