Committers from Apache's Avalon project are pleased to announce that Avalon-Phoenix 4.0 has been shipped. Phoenix is a container for server side components and has JMX capability; It is a micro kernel that can mount other services such as EJB, JMS, HTTP, etc.

See the Phoenix Phoenix - home page

More Info
=========
Phoenix is a server of servers. Phoenix is a micro kernel for Java components. Phoenix is 'Avalon Container Enterprise Edition'. Phoenix is not an EJB server. Phoenix does not provide RPC capability out of the box, thus is not a replacement for an EJB server. Phoenix mounts applications distributed in SAR format (like EAR in a way). Phoenix has a JMX management application (MX4J) via port 8082. Phoenix likes components that implement some, all or none of the interfaces from the Avalon-Framework project.

FAQ:

Does Phoenix compete with EJB? Not really. You could build an EJB server on top of Phoenix.

What uses Phoenix? Numerous Apps

What can be used to help build apps? Avalon-Cornerstone

Where are we trying to go? Well, we are interested in seeing many servers mountable as components inside Phoenix. That includes standards like FTP, POP3, IMAP, LDAP, DNS, Echo, Finger, HTTP, SSH, EJB, CORBA, JMS and OGG servers (multiple implementations).

The correct Phoenix home page :

Phoenix

Laurent

Does anyone know why the FTP link is dead?

This is great...but, what does it do? Yes, I read the description, and read it again, and again...

I guess I don't understand the point of this project. Perhaps someone could, using small words, explain to me why this project exists and what I can do with it that I can't do without it. I'm sure there's a good reason, but I'm not seeing why, at least for the things I do.

Please enlighten me. Thanks.

Say you want to build a server application in Java--an EJB Server, a database server, a JMS server, etc. Phoenix provides all the basic infrastructure you need to build servers. For example, instead of the JBoss group having to create the JBoss system package, they'd simply develop blocks that run on Phoenix. Of course, I doubt they'll do that. But I would expect, that eventually other Apache projects--Tomcat for example--will start using Phoenix.

Seems to me you can use Avalon-Phoenix to put together a server with only the specific components you need. Instead of a service that implements EJB, and also does JSP, servlets, etc., you can streamline the service to only load the EJB component. If that's all you want on a given server, you can avoid the bloat of additional functionality you're not going to use.

This is the basic service based architecture that HP was pushing with HP application server on top of CSF and that Avalon has been developing for some years now. Lutris exposed a similar infrastructure in their application server. A bunch of other app servers internally use the same basic ideas, including weblogic. JSR 111 was supposed to standardize this -- server components could be portably "snapped into" an app server instead of being forced to sit on top. For example, a pre-J2EE 1.4 scheduler service might be useful. If I were going to build another application server, I'd take a close look at Avalon, or at least use the same approach for hosting components.

Also, JBoss uses JMX directly to achieve the same sort of thing.

As an aside, this is all a rehash of the Service Configurator pattern that Doug Schmidt described a long time ago, just applied to a different context than I/O stream handlers.

Greg

> was pushing with HP application server on top of CSF
> and that Avalon has been developing for some years now.
> Lutris exposed a similar infrastructure in their
> application server.

SwiftMQ <wink> does the same with its Swiftlet framework; Extension Swiftlets are hot deployable incl. version upgrades during runtime.

-- Andreas

IONA's Adaptive Runtime Technology (ART), the technology platform underlying products such as our Application Server Platform (ASP), has been supporting this microkernel approach for years. ART has two implementations of its architecture, one in Java and one in C++, and both are kept in sync. Both support dynamic loading and pluggability of services at multiple levels of abstraction, such as transports and protocols (e.g, JMS, SOAP, HTTP, GIOP/IIOP, RMI/IIOP, multicast), containers (e.g., the CORBA POA, an EJB container, and a Web Services container), system services (e.g., application and system configuration, system logging, and management (including JMX)), and application-level services (e.g., CORBA's DynAny, J2EE's servlets). ART also supports enterprise-scale highly available and fault tolerant applications. ASP's full support for the CORBA and J2EE specs, along with sophisticated Web Services support, are a result of ART's highly modular architecture and its dynamic pluggability. Despite its dynamism and flexibility, though, ART's performance is comparable to, and often better than, other general CORBA and J2EE systems, and we're constantly improving its performance. As if that weren't enough, both implementations of ART are highly portable -- even the C++ version has been ported to over 30 different platforms (OS/compiler combinations).

Okay. So what differentiates Avalon et al from JMX?

As Per the website now Apache Avalon is closed
http://avalon.apache.org/closed.html

Bye for now

As Per the link http://avalon.apache.org/closed.html

Apache Avalon is closed now

Bye for now

CSJakharia