Mailing-List: contact ace-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ace-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4AE75864.5020708@nanthrax.net>
Date: Tue, 27 Oct 2009 21:30:28 +0100
From: Jean-Baptiste Onofre <jb@nanthrax.net>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706)
MIME-Version: 1.0
To: Marcel Offermans <marcel.offermans@luminis.nl>
CC: ace-dev@incubator.apache.org
Subject: Re: Interest on Apache ACE and possible relationship with
 AutoDeploy/Kalumet
References: 
 <88968009-1256624312-cardhu_decombobulator_blackberry.rim.net-1610962159-@bda030.bisx.produk.on.blackberry>
 <D79D5684-9741-44A6-98CF-A0780A2E09F8@luminis.nl>
In-Reply-To: <D79D5684-9741-44A6-98CF-A0780A2E09F8@luminis.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Marcel,

thanks for your feedback.

> 
> Of course. We're working hard on providing more documentation to help 
> people get started, so watch this space! :)
>
Yes, I see exactly what you mean, we have exactly the same problem on 
ServiceMix ;)


> 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.
>
Yes the concepts are very close.

> 
> 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.
OK. Does it mean that I can provide a bundle implementing the 
DeploymentAdmin spec to perform an update logic ?

> 
> 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!
Yes in AutoDeploy we have Update Journal, notifier and publisher.

> 
>> - 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.
OK.

> 
>> - it embed a quartz scheduler to "fire" an update automaticaly.
> 
> Are you pushing updates to an agent in that scenario? 
Yes, WebAutoDeploy fires an update request to the agent.
The agent embeds a small Axis/CXF server that expose a WebServices set. 
WebAutoDeploy call the agent via this WebService. Like this, it works 
fine through firewall, the only requirement is to open HTTP 
communication of the agent given port.

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.
I have begun to make "updater" bundles to manage application server 
update. Theses bundles provide OSGi service to update resources and 
application into the application server. The updater bundle uses JMX to 
interact with the target application server.

> 
>> - via non-JEE software resources, we manage ESB (ServiceMix of course 
>> ;)), web server (Apache httpd), printout systems (streamserve, ...), etc.
> 
> Nice.
It's the same as for application server: I provide "updater" bundle to 
execute system command, files, etc.

> 
>> 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!
Don't worry, no emergency :)

I propose to open a demo environment on WebAutoDeploy to let you see the 
configuration and usage.

On my side, I have just checkouted the ace source and begin to 
investigate deeper.

Regards
JB
-- 
Jean-Baptiste Onofr�
---------------------------------
  HomePage
http://www.nanthrax.net
---------------------------------
  Contacts
jbonofre@apache.org
jb@nanthrax.net
---------------------------------
  OpenSource
BuildProcess/AutoDeploy
http://buildprocess.sourceforge.net
Apache ServiceMix
http://servicemix.apache.org
-----------------------------------
PGP : 17D4F086