Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Development" <avalon-dev@jakarta.apache.org>
Message-ID: <3BCEDBA4.517C7A3B@apache.org>
Date: Thu, 18 Oct 2001 09:39:48 -0400
From: Berin Loritsch <bloritsch@apache.org>
MIME-Version: 1.0
To: Avalon Development <avalon-dev@jakarta.apache.org>
Subject: Re: Avalon vs. EJB (JBoss)
References: <PLEFKGHLMIEKJKKFPNFIIEABEHAA.neeme.praks@inpoc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Neeme Praks wrote:
> 
> At work we have started the process of replacing our current "application
> server" with some other, that would fit our needs better. As the process was
> started without me, others already chose to implement the new system on top
> of JBoss (but I can still drive them towards Avalon, if I would have enough
> arguments).
> 
> A little bit about the system itself:
> It is a request-response type of a system (for SMS applications), that will
> receieve request on a socket listener and will use messaging (JMS) as the
> main communication method between different parts of the system. It will be
> heaviliy componentized, to allow for better reusability.

Echoing Peter, there are a lot of holes in the description, so it is not as
easy to figure out what is best for the system.  I would *like* to support
Avalon in everything, but sometimes it is not practical.

EJB environements are _very_ restricting.  You cannot have access to the
streaming APIs.  You cannot have your own classloader.  You can use outside
systems through JNDI, but you cannot write to JNDI.  These are things that
you have to consider.

EJBs are best when used for data-centric processing, and simple logic only
management (i.e. session beans).  They are not good at providing services.
For that, you would need to wrap the EJB with all the service plumbing.

You can have both--but keep in mind that JBoss is GNU licensed (incompatible
with ASF).  In fact, if Phoenix were considered an Enterprise "application"
(really application server...), it would be able to call your EJBs from it's
own JVM.  Therefore, the service is taken care of by Avalon, while your EJBs
handle the pure logic.

This is a conundrum that the Axis development project is dealing with.  What
happens when an EJB is a client and a server?  In other words, what happens
when you have an EJB that is handling the SOAP call, but needs to make some
calls of its own to handle the request?  Currently, it opens up an AxisClient,
which in turn uses an InputStream to read the configuration and handlers live
in an AxisClassLoader.  These are both violations.


> Avalon arguments:
> * Avalon is more lightweight, better customizable
> * the framework encourages designing well componentized applications (not
> sure about EJB)
> * EJB standard development is out of our reach, while we can influence the
> development of Avalon (as long as the influence makes sense)
> * it's fun to participate on the mailing list and discuss "cutting-edge"
> topics in CS ;-)

* Avalon lifecycles are easier to understand, and are not over-engineered for
  most applications.
* Avalon best practices are described in one location, and not scattered accross
  many pages on the net.
* Avalon environments are more predictable and flexible
* Avalon is open source, so if the project goes under, you still can use it
  and modify it to your hearts content.
* Avalon architecture is available to client components/blocks--encouraging
  good design throughout the system.
* Using Avalon's architecture and design principles will encourage scalable
  and reusable code--without worrying about whether a server vendor is
  fully compliant or not.


> JBoss arguments:
> * JBoss is based on EJB standard, giving you some confidence that when JBoss
> fails to deliver, you can move to some other EJB vendor

     (At a HIGH price)

> * JBoss is also well designed and componentized

     (But the design and architecture of the server is not open to client software)

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org