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
