avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Avalon vs. EJB (JBoss)
Date Thu, 18 Oct 2001 00:00:49 GMT
On Thu, 18 Oct 2001 12:03, Neeme Praks wrote:
> 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.

It is difficult to asses which is the better technology without knowing more 
about your problem domain but heres a basic shot at it. 

EJBs are very good supporting infrastructure if you have to do transactional 
database orientated buisness objects. However they start to loose their 
value as soon as you move out of this domain. For instance you can not write 
a compliant EJB bean that accesses many "heavy" resources such as sockets, 
files, threads and can not use many resources (like synchronization).

So in your case you would need to write "services" that are not EJBs that 
access all these resources. Each different EJB server uses a different 
approach to writing these services so whatever you write will likely be 
specific to one container.

EJB also requires certain overheads when calling methods - even if the user 
of EJB and EJB in the same JVM. In many cases this performance hit is 
significant - especially if you are making lots of calls to EJBs or even wors 
- you are forced to use RMI/IIOP/other distributed protocols.

Avalon/Phoenix on the other hand does not have many of these overheads and 
gives you much more wider access to resources in the JVM.  Combined with 
Cornerstone and Excalibur it also gives you a nice library of reusable 
components and hopefully makes it a bit easier to develope similar products.

The main negative with Avalon is that there is not yet a standard defined by 
JCP to access resources. Hopefully this will be rectified in the future.

> When I was involved into this process, and I heard that they chose to use
> JBoss, I suggested to consider Avalon as well. So far, I haven't really
> succeeded in turning them towards Avalon, and, as I do not really know all
> the pro/con arguments in the discussion of Avalon vs. JBoss, I'm not sure
> if I'm able to do that.

Avalon/Phoenix and JBoss are not really competing but more complimenting. It 
would be nice if there was some way to access Phoenix services from JNDI 
javax.naming.Context  in EJB beans. That way you could have your buisness 
logic in the EJB server and your "service" code in Phoenix.

It really depends on how much biz logic your app does and how tied to 
transaction manager/database this logic is. The more of this stuff then the 
more the logic should be in an EJB server.

> Maybe others, more familiar with the two, can give some more insights on
> the similarities/differences between them?
> So far, I came up with the following arguments:
> 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 ;-)

* comes with soem ready made components you will probably like reusing 
(socket/connection managers)
* Doesn't require the overhead for each call and management (ie Each EJB is 
cached and pooled and requires a bit of overhead each call)
* Allows you to be EJB vendor neutral when writing your other part (ie socket 
accessing bit)

> 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
> * JBoss is also well designed and componentized

* comes with a lot of support for biz orientated apps.
* unfortunately need to be tied to container to write other part (ie socket 
and request processing)

> Some more? Does this comparison make sense at all?
> I think these issues would be also interesting for the general public and
> could be put on the website as well.

good idea. 



The phrase "computer literate user" really means the person 
has been hurt so many times that the scar tissue is thick 
enough so he no longer feels the pain. 
   -- Alan Cooper, The Inmates are Running the Asylum 

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

View raw message