leosimons 2003/01/29 07:57:47
Added: src/documentation/content/xdocs/history book.xml
call-to-vote.xml index.xml need-for-avalon.xml
what-is-a-server.xml
Log:
move history to avalon-site
Revision Changes Path
1.1
jakarta-avalon-site/src/documentation/content/xdocs/history/book.xml
Index: book.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//APACHE//DTD Cocoon Documentation Book V1.0//EN"
"book-cocoon-v10.dtd">
<book software="MyProj"
title="MyProj"
copyright="@year@ The Apache Software Foundation"
xmlns:xlink="http://www.w3.org/1999/xlink";>
<menu label="About">
<menu-item label="Introduction" href="index.html"/>
<menu-item label="Call To Vote" href="call-to-vote.html"/>
<menu-item label="Need For Avalon" href="need-for-avalon.html"/>
<menu-item label="What is a Server?" href="what-is-a-server.html"/>
</menu>
</book>
1.1
jakarta-avalon-site/src/documentation/content/xdocs/history/call-to-vote.xml
Index: call-to-vote.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
<document>
<header>
<title>History</title>
<subtitle>Proposal</subtitle>
<authors>
<person name="Stefano Mazzocchi" email="[EMAIL PROTECTED]"/>
</authors>
<notice>
This documentation is provided for historical purposes to document the
beginnings of Avalon.
</notice>
<abstract>
In this mail to the Java Apache mail list, the author
proposes the creation of the Java Apache Server
Framework and explains its goals and requirements.
</abstract>
</header>
<body>
<section>
<title>Introduction</title>
<p>
I spent some time thinking about some of the issues that were discussed on
this
list in the last month, after the first release of Apache JServ 1.0b and
after the
development pressure was reduced.
</p>
<p>
It is clear, to me and to others on this list, that Apache JServ 1.0 just
barely
scratched the potentials of this project in sharing IQ and ideas aiming to
fill
those gaps the advent of the Java technology on the server world produced.
</p>
<p>
It is also clear, from different perspectives (users, developers, software
engineers, management people), that servers are a big part of the
present/future
of everyday work and that Java allows the creation of performance oriented,
solid and
rapid-delivered server solutions. Other languages do not perform as good when
all these three "forces" are evaluated together (besides, maybe, SmallTalk,
but
this is another issue).
</p>
<p>
Java is trendy, that's true, but we all know that Java is a well-designed
object
oriented language. May not be the best, I grant that, but it's the only one
that came
to please all those people I listed above.
</p>
<p>
Following this direction, and feeling the lack of professional Java server
solutions on many fields, the Java Apache Project was created to fill this
gap
using the power of open source. We don't want to compete with Apache or with
any other server implementation. We are betting on Java for the server side,
but
we will never "rewrite" some server implementation in Java, unless this can
lead to significant improvements and doesn't go against other open source
projects.
</p>
<p>
The final goal is a family of 100% pure server solutions for the Java Virtual
Machine.
</p>
<p>
Since server applications share lots of logic/code between them, it is
obvious
that a common server framework, along with design rules and abstract
implementations, would allow faster time-to-market, easier code management,
parallel development, bug fix reflection on all projects and tight
integration
between the different server solutions.
</p>
<p>
I do believe that the time taken to design and develop such a framework will
be
"invested" by this project and its developers. The creation of this project
doesn't
mean other projects can't continue to evolve: the final goal is to integrate
existing server solutions (JServ) into the framework but this is not a short
term
goal so this doesn't influence it's evolution/time-to-market for future
releases/features.
</p>
</section>
<section>
<title>Request For Vote</title>
<p>
For the reasons above, I propose the creation of a new project to handle the
design of a the Java Apache Server Framework that will be the foundation on
which all server projects hosted by the Java Apache Project will be based
on.
</p>
<p>
This project goals are:
</p>
<ol>
<li>
Design and documentation of the Java Apache Server Framework.
</li>
<li>
Creation and implementation of this framework (interfaces, abstract
classes,
and shared modules).
</li>
<li>
Centralized management of the evolution/fixing/patching of both the shared
code and the framework design.
</li>
</ol>
</section>
<section>
<title>What the Java Apache Server Framework Is</title>
<p>
It's a design methodology that allows design reuse as well as code reuse
between
different server projects. These projects gain the advantage of software
reuse
and the simplicity of developing/managing only the different logic.
</p>
<p>
This framework will be based on Java technology and would allow:
</p>
<ol>
<li>
Partition of shared logic context into polymorphic modules that are used
through their public interfaces and not through their actual
implementation (Log
systems, Object stores, Virtual File Systems, Configuration repository,
Concurrency Strategies, etc..)
</li>
<li>
Creation of a common lifecycle for server operations (the Service
interface)
</li>
<li>
Creation of a ServiceManager for service management (maybe both internal
or external the JVM: native wrapping and control via JNI would allow
better fault tolerance for the JVM through process separation)
</li>
<li>
Shared resources can be either centralized or duplicated for each service,
allowing the use of a single JVM for multiple servers and common logic
sharing (i.e. common thread pools, log systems and configuration
repositories...)
</li>
<li>
A central access point for configuration (via HTTP, SMTP, voice, RMI,
SNMP, IIOP, depending on the services implemented)
</li>
<li>
Reduced effort in service development since they become plugins for this
framework and reuse big parts of the code base. The design and behavior is
also documented and shared between different services.
</li>
</ol>
</section>
</body>
</document>
1.1
jakarta-avalon-site/src/documentation/content/xdocs/history/index.xml
Index: index.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
<document>
<header>
<title>History of Avalon</title>
<authors>
<person name="Avalon Documentation Team" email="[EMAIL PROTECTED]"/>
<person name="Peter Donald" email="peter at apache.org"/>
</authors>
<notice>
This documentation is provided for historical purposes to document the
beginnings of Avalon.
</notice>
</header>
<body>
<section>
<title>History</title>
<p>
This document tracks the history of the Avalon project. Avalon was originally
started with
a realisation that Java is a great platform for developing server products and a
<link href="call-to-vote.html">call to vote</link>. There was a lot of work
formalizing what exactly a <link href="what-is-a-server.html">server</link>
consists
of and why this project was <link href="need-for-avalon.html">needed</link>.
These
discussions led to the initial development of the Java Apache Server Framework.
</p>
<p>
Over time the Java Apache Server Framework project was renamed Avalon. This was
in
recognition that the original ideas have evolved over time. Avalon became a
repository of general utility code, a design and testing ground for component
based
solutions, a micro kernel and set of generalized server oriented services. This
combined
with a move from the Java Apache project to the Jakarta project prompted the
revision.
At this time the kernel code was repackaged under the name Phoenix, core
services
under the name Cornerstone and the general components was packaged under name
Excalibur.
</p>
<p>
You may check the historical changes from before splitting Avalon into separate
projects <link href="changes.html">here</link>.
</p>
</section>
</body>
</document>
1.1
jakarta-avalon-site/src/documentation/content/xdocs/history/need-for-avalon.xml
Index: need-for-avalon.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
<document>
<header>
<title>History</title>
<subtitle>Do we really need this?</subtitle>
<authors>
<person id="SM" name="Stefano Mazzocchi" email="[EMAIL PROTECTED]"/>
</authors>
<notice>
This documentation is provided for historical purposes to document the
beginnings of Avalon.
</notice>
<abstract>
In this document, I introduce my vision for the Java Apache
Server Framework project. I explain why I believe that
open-source projects should invest more time in software
engineering and why this may be worth even if very successful
and high quality software projects.
</abstract>
</header>
<body>
<section>
<title>Hardware vs. Software</title>
<p>
One thing that always puzzled me is the different quality meters used
on hardware and software by users: little flaws in software systems
are accepted as inevitable, while hardware flaws (even small ones) may
even create market panic if discovered. It's hard to tell why this is
so, but today's software quality standards are becoming more and more
selective, especially when monopolies are broken and users are able to
judge the differences between products and solutions.
</p>
</section>
<section>
<title>Open Source as Quality Management</title>
<p>
The open source development model has emerged as a powerful way to
control and improve software quality. The most important assumption,
in this case, is the fact that debugging and code testing are
parallelizable tasks. For this reason, different individuals are able
to track down problems right into the source code, independently from
one another. In open source projects, compared to closed source ones,
the complexity of the software system grows slower than the ability to
debug it, due to this parallelizable effort.
</p>
<p>
Open source processes are auto-organizative: when a seed of ideas
and goals is thrown in the right place at the right time, it catalyzes
the development process. Usually, when this happens, the user base
expands, the complexity of the software system grows to meet the
requirements of this bigger user base, incorporating new ideas,
solutions and code and creating a positive feedback that keeps the
process going.
</p>
</section>
<section>
<title>Software Engineering and Open Source</title>
<p>
Software engineering doesn't fit well into an auto-organized system
driven by user requirements. Still, I believe that careful software
design may allow the development process to <em>know</em> the ability
of its developers and to provide them guidelines to reduce the work
and to increase parallel capabilities. Of course, due to the extreme
flexibility that open source projects show, software engineers should
carefully design the system to match this flexibility and to avoid any
restriction that may create friction with users and developers.
</p>
<p>
It is evident how the use of modern object oriented programming
languages like Java helps the development and reduces the debugging
efforts because most error prone tasks are handled automatically by
the language itself. Still, the most important object oriented
solutions (such as Interfaces and abstract classes) are very much
unused in auto-organized project, where the work is usually done with
the smallest possible effort to get something working.
</p>
<p>
The incredible improvement in time-to-market offered by these
programming languages that reduce the debugging process to logical
bugs rather than developer's programming mistakes, is a great feature
and it's well appreciated, but it may lead, on the longer term, to
code maintenance problems.
</p>
<p>
In all software systems, the maintenance costs greatly exceed the
first development ones. In open source software systems, the cost is
measured in terms of <em>time</em> and <em>energy</em> spent by
developers to meet the new requirements and to expand the complexity
of the software system. It has been shown (in the Apache JServ
project) that the wrong use of object oriented features may lead to
project stall and create friction between developers and users about
the need for <em>revolutions</em> instead of <em>evolutions</em>
driven by the need of a complete code redesign.
</p>
<p>
The rules "if it works it's good enough" and "if it
works don't change it" may fit well in those programming contexts
where developers need to design the code on their own to make it work.
In object oriented systems, more than ever, working code is not
automatically good code.
</p>
</section>
<section>
<title>Frameworks and Patterns</title>
<p>
The solution I propose is the introduction of coding guidelines to
place new requirements to meet the "working" state: by
introducing the use of software frameworks and design patterns, we are
able to <em>shape</em> the work of developers without restricting
their creativity. While object oriented languages don't pose such
limitations or guidelines, the introduction of carefully designed
engineering rules, contracts and patterns would create some additional
requirements to the development process, but will allow better code
maintenance, a more coherent parallel development process and, in the
longer run, easier maintenance.
</p>
</section>
<section>
<title>Conclusions</title>
<p>
The use of development guidelines and frameworks is proposed as a way
to reduce internal tensions that produce revolutionary development
processes rather than evolutionary ones. Even if such ability is yet
to be demonstrated, it has been shown how object oriented languages
require different approaches and more careful design stages to be
successful in the long run.
</p>
</section>
</body>
</document>
1.1
jakarta-avalon-site/src/documentation/content/xdocs/history/what-is-a-server.xml
Index: what-is-a-server.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN" "document-v11.dtd">
<document>
<header>
<title>History</title>
<subtitle>How to write servers using Avalon</subtitle>
<authors>
<person id="PF" name="Pierpaolo Fumagalli" email="[EMAIL PROTECTED]"/>
</authors>
<notice>
This documentation is provided for historical purposes to document the
beginnings of Avalon.
</notice>
<abstract>
In this document I try to explain how a server could be developed
using the benefits offered by the Java Apache Server Framework
(Avalon) and I introduce the reader to the concept of what a
<code>Block</code> is.
</abstract>
</header>
<body>
<section>
<title>Introduction: Servers and Services?</title>
<p>
It's somehow difficult to give a proper definition of "server",
due to the confusion created in the time so far by the different meanings
that term had, facing the different evolution of the technologies.
</p>
<p>
The term "server" is commonly used with at least three different
meanings:
</p>
<ul>
<li>
<strong>"Server" as computer:</strong> With this meaning the
server term is intended to be the computer sharing resources.
<br/>
<em>
Ex. Our corporate "server" is a double Pentium II
running at 450 MHz with 12 GB of SCSI hard disk running Linux.
</em>
</li>
<li>
<strong>"Server" as a program:</strong> With this meaning the
server term is intended to be the application that enables the
resource sharing, not caring about the network protocols it
implements.
<br/>
<em>
Ex. Our Mail server is FlosieTek FTGate release 2.1 which
implements the SMTP and POP3 protocols.
</em>
</li>
<li>
<strong>"Server" as a protocol handler:</strong> With this meaning
the server term is intended to be the application that enables
the access to shared resources via a specified protocol.
<br/>
<em>
Ex. Our HTTP server is Apache 1.3.4.
</em>
</li>
</ul>
<p>
While we can clearly see the difference between the first definition of
"server" (computer) and the other two (applications), it's hard
to see the difference between the second definition ("server" as
a multi-protocol handler) and the third ("server" as a single
protocol handler).
</p>
<p>
Since it's crucial for all developers involved in the Avalon project to
share the same common idea of "server", I would like to define
a server as a <strong>protocol handler</strong>. We would, then, have HTTP
servers,
SMTP servers or POP3 servers, but we cannot use the term MAIL server.
</p>
<p>
What we called the mail server is in fact the union of two (or more)
different "server"s (in our example the union of a SMTP and a
POP3 server).
</p>
<p>
We can clearly see, anyway, that a POP3 and an SMTP server will have to
share most resources and code to build up a complete mailing system, like,
for example, a central repository where messages could be stored. We would
then define the union of the SMTP server, the POP3 server and the central
messages repository (we could call it <strong>Mail Engine</strong>) as a Mail
"service". To clarify things a little bit, maybe a picture would
help:
</p>
<figure src="images/server-01.gif" alt="Server 1"/>
</section>
<section>
<title>Dividing the code</title>
<p>
We can clearly see, however, how this approach to the problem brings to
a monolithic implementation of the code, not allowing, or making really
difficult, for other persons to add features, for example, integrating an
IMAP server within our Mail Service.
</p>
<p>
In fact, if we don't clearly separate the code (and a good developer
should always keep in mind his server expansion) adding a feature like an
IMAP server into our service could become hell, and, most developers will
try to find other solutions already in the market rather than using and
improving what we have done.
</p>
<p>
The solution would be to have a sort of "in-core" modularization of our
server.... To be continued...
</p>
<figure src="images/server-02.gif" alt="Server 2"/>
<figure src="images/server-03.gif" alt="Server 3"/>
</section>
<section>
<title>The concept of a Block</title>
<figure src="images/server-04.gif" alt="Server 4"/>
</section>
<section>
<title>The Avalon Framework</title>
<fixme author="PF">We need some info in here.</fixme>
</section>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
$Revision: 1.1 $ $Date: 2003/01/29 15:57:47 $
</legal>
</footer>
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
