[Embedlets-dev] [Ant] Build vs Deployment vs Management processes

[Andrzej J. T. <an...@ch...>]

Gregg posts an insightful comment (snipped for brevity):

> The servlet has the ability to do mass updates to multiple sites so that
> mistakes due to missed steps or missed devices are highly unlikely.

> Ant is not required because we have automated recognition of new devices,
> installation of new configurations, replacement of devices due to failures
> etc.

Absolutely.

Let's get clear on the fact that a build process (from the perspective of 
compiling and assembling an executable), is a different beastie than a 
deployment process (which is typically charged with configuration and 
dissemination of the application), which is again a bit different than a 
management process (thinking from an Operations/Monitoring perspective). 
There is some overlap that forms a grey area (configuration, reconfiguration) 
that any of these processes can subsume, which seems to be causing some 
of the confusion on this subject.

The build process will probably be very nearly identical (with variations for 
specific platforms possibly, JStamp vs TStik vs. uVM, etc) regardless of the 
application.

The management process will probably be rather unique to each particular 
application, but by supporting an emerging standard like JMX, existing 
systems management tools could easily be used to perform this function. The 
uniqueness here is not found so much in the management tool (use Tivoli, 
OpenView or even a custom servlet like Greggs, but in all cases JMX provides 
a base level of commonality on how you technically do the management), as 
much as unique business procedures (when this alarm is raised, do this.....) 
which may or may not be automated, depending on the circumstances.

The deployment process will probably be very unique to the particular 
application that was created.  As Gregg said, they created a custom 
deployment solution using a servlet for their application.  There probably isn't 
enough deployment commonality across the whole space of possible 
applications that Outpost/Embedlets are targeted at to be able to create a 
single universal "deployer" solution that will meet everyones needs.  For 
example, whether an embedlet/applications needs static versus dynamic 
configuration capability might alter the thinking of which process should do the 
configuration, as follows:

If the application is using dynamic configuration of the deployed Embedlets 
(which is proposed to be an optional Outpost service), then the build and 
deployment processes are quite detatched from each other.  You would do 
one build (per platform), then use the deployment process multiple times to 
load/config/run the code on many devices (note..the overall deployment 
process to multiple devices could be automated, basically in a loop that runs 
through the single device deployment process for each device).  The dynamic 
configuration would be performed using the optional Outpost Management 
Service...which could be easily implemented as a Browser-visible Servlet that 
issues (under the covers) the JMX management calls to do the config for each 
device, similar to Gregg's implementation (or maybe using some other 
technique).  No problem....the architecture handles it nicely, and the build and 
deploy are nicely separated in responsbility.

If we look at more constrained devices or applications that use static 
configuration (that may not be able or want to support dynamic configuration) , 
there would probably be a bit more interaction between the build and deploy 
processes.  The build process, which might include generation of the static 
config, could be used as a "subroutine" of the wider scoped deploy process.  
For example, the deploy process might grab the config info from a database, 
then call the build process (which could be just an JVM process which runs 
Ant) with some parameters specific to the device being deployed/configed, and 
the build process (Ant) would create a custom static build based on those 
parms.  The deploy process would then grab this output (the statically 
configured build) and would somehow install it on the device.  So even in the 
static scenario, it's possible to decouple the very application-specific deploy 
process from the build, by treating the build as a self-contained "subroutine".

Ant is very powerful for build processes, especially Java and XML-oriented 
ones (it comes with a large library of tasks to handle very common Java and 
XML activities, including XSLT transformations, which might be useful for any 
static code generation we need). 

It's yet to be determined whether Ant also provides enough compelling value to 
a "deployment process" (that will be unique to each user's application and 
environment) to make it worthy of consideration.  My guess is that Ant will not 
be as useful for that, and that more custom, UI-based deployment solutions 
will be required for many scenarios.  But we don't have to make that 
determination yet.

That being said, there may be some situations where there would be benefit to 
having the Deployment tool generate a custom Ant build.xml script for each 
device that needs to be deployed, based on a template script.  This might 
provide for a more flexible custom deployer solution, as compared to one that 
hard-codes the deployment process in Java (or some other) code.  
Conceptually, this hybrid approach uses Ant as a rudimentary BPM (Business 
Process Management) engine with the businesss process (deployment 
process in this case) being declaritively specified in XML files (templates, etc.). 
For large Fortune 1000 companies with massive deployment requirements, it 
might even make sense to use a commercial BPM for this task, rather than 
investing in the development of a custom solution. 

More philosophically speaking, regarding the design of business systems, 
declarative specification of processes is much more flexible and maintainable, 
at lower cost than procedural (eg. programmed/coded) implementations, for 
complex processes.  Also the design practices/paradigms of Separation of 
Concern, Modularity, Layering and Encapsulation apply to the 
build/deploy/management process implementations as much as to the 
Container design itself.  In a  nutshell:  "keep 'em all decoupled as much as 
possible".

Anyway...some thoughts from snowy Canada.

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com