ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Interest on Apache ACE and possible relationship with AutoDeploy/Kalumet
Date Tue, 27 Oct 2009 18:11:47 GMT
Hello Jean-Baptiste,

On Oct 27, 2009, at 7:18 , Jean-Baptiste Onofré wrote:

> Thanks for your feedback.
> Unfortunately, I won't be at ApacheCon US, I'm stuck with a customer  
> at the same time.

No problem!

> Concerning ACE and AD, I need to see ACE deeper to provide a correct  
> overview.

Of course. We're working hard on providing more documentation to help  
people get started, so watch this space! :)

> That I can say about AutoDeploy:
> - AutoDeploy is composed in two parts: the agents are deployed on  
> target servers and WebAutoDeploy. The agents call WebAutoDeploy  
> (http WS) to retrieve the configuration. WebAutoDeploy is a webapp  
> based that interact with the agents using webservice. WebAutoDeploy  
> is ajax based (echo2 framework) and the configuration is stored in a  
> xml file. It's a central tool to manage all environments with a  
> journal of all actions performed.

ACE too has this notion of a local agent that is running on the  
target, even inside the actual OSGi framework. It talks to the  
deployment subsystem of the ACE server which sends it updates (either  
a full set of components, or delta's between versioned sets). Another  
part of the server deals with defining components, grouping them and  
assigning those groups to targets. That part has a GWT based web  
interface.

> - you define resources: JEE (datasource, connection pools, jms  
> servers, jms queues, ear/war artifacts, etc) or non JEE (sql  
> scripts, files/location, etc). After you define an "update plan"  
> mixing the resources. You have notifier (informing the users when an  
> update will be launched) and publisher (informing the users about  
> that the update has done).

Here, ACE builds on the DeploymentAdmin spec, which defines a way to  
send all types of components to a target (not only OSGi bundles, but  
also configuration data, or any file type you might define yourself).  
Along with custom file types it also sends resource processors, which  
are bundles that know how to install and uninstall these file types  
you've defined. According to the spec, the whole update occurs within  
a transaction, so if any of the components fails to install, the whole  
update is rolled back to its previous/original state.

To get feedback from the target back to the server, we have a feedback  
system, which monitors any life cycle changes and sends them back to  
the server. That way we have a complete historic log of any target  
that contains not only information of when an update started and  
completed, but also when the target was started, shut down, etc. Very  
valuable information for support and sysadmins!

> - as it uses Apache Commons VFS, all resources (for example  
> artifatcs location) can be local, in a archive (zip, tar.gz, etc) or  
> remote (http, ftp, cifs, etc) and you can combine it.

Nice. We have separated metadata from components completely, and we  
reference components by URL, so any URL scheme you can plug into Java/ 
OSGi can be supported and any repository (OBR, Maven, Nexus, ....) can  
be used.

> - it embed a quartz scheduler to "fire" an update automaticaly.

Are you pushing updates to an agent in that scenario? By default, we  
use a pull from the agent side, because of a number of reasons:
  - usually, looking at firewalls, it's more likely that a target can  
find a server, the other way round often is tricky;
  - pushing out updates to 1000's of nodes could become a performance  
bottleneck;
  - when pushing updates, you might contact targets at moments where  
the application running on the target is doing something critical and  
might not want to update at that point in time.

> - it supports JEE applications servers like weblogic, jboss,  
> websphere.

This definitely is an area where we don't have any specific support  
yet, apart from the fact that a lot of application servers seem to be  
embracing OSGi.

> - via non-JEE software resources, we manage ESB (ServiceMix of  
> course ;)), web server (Apache httpd), printout systems  
> (streamserve, ...), etc.

Nice.

> I began the project around 5 years ago and the users pool is growing  
> up ;).

Before we donated ACE, it had been in development at luminis for quite  
some time, and we built different versions. From the similarities in  
the stories above, you can see that we definitely learned similar  
lessons over the years.

> The current stable release is pure java with apache projects  
> dependency (commons vfs, commons digester, xerces, ..). Feel free to  
> take a look on the source code.

I will as soon as I can make some time!

> The trunk is now OSGi based using Felix (framework for now, I think  
> Karaf soon), CXF, etc. I use some bundles that I have done for  
> ServiceMix.

We obviously run on Felix too, but recently Toni did some valuable  
work to allow us to use Pax Runner which means we can quickly run on  
any framework that is supported (the major releases of Felix,  
Knopflerfish and Equinox).

> Before giving a feedback on relatinship between ACE and AD, I would  
> like to checkout the ace source code to get a better understanding  
> of the ace scope, provided features, etc. I will begin tonight.

Good. I hope this e-mail helped a bit. :)

Greetings, Marcel


Mime
View raw message