Re: [Embedlets-dev] Re: [Arch] ANT

[Gregg G. W. <gr...@sk...>]

>For those who are advocating not going with Ant I would like to see your
>solution to the plastics plant scenario listed above.  I will also volunteer 
to
>put together a table that compares the various proposed build/deploy solutions
>against the above scenario if any more are submitted.

This is true today...

Okay, we have a customer that has ~200 'wide fanout hub' devices that collect 
data and control some 460 end devices.  The 'wide fanout devices' software is 
implemented by another company, and is not java based.  They send proprietary 
messages to our 'broker' that we in turn forward to 3 different JDBC 
accessible databases as well as log to files for the support staff to 
reference.  The broker requires no changes to add new field devices nor 'wide 
fanout hub' devices.  The 'wide fan out' devices have bugs fixed here and 
there.

We have a servlet based web tool that can be accessed from anywhere in the 
enterprise.  It references a directory tree populated with the 'wide fanout 
hub' manufactures executables, as well as per device configuration files.  It 
also references a configuration database that tells what specific settings 
apply to each 'wide fanout hub' including its primary, secondary and tertiary 
broker.  From anywhere in the enterprise, you can connect to the associated 
servlet, with a browser, and (re)configure or reload a 'wide fanout hub' 
and/or the end devices attached to it, via this servlet.  The 'wide fanout 
hub' is loaded via ftp, and can be reset via ftp as well.

In the 3+ years that this system has been installed, we have upgraded the 
broker software 3 times.  The 'wide fanout hub' devices have been through at 
least 20 software revisions.  The enterprise has moved the databases to 
different servers 3 different times, with a 4th coming soon when we will also 
move the brokers 2 states away and across networks.

Careful organization of the applications, the configuration materials and 
documentation has made it possible to do all of these things without any loss 
of service, and with very little work other than that explicitly required to 
install devices, or recable equipment etc.

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.

Now, I will not say that ant might not be useful for some things.  I have 
gotten along without it by designing tools that would have to be built to run 
under ant if that was how I chose to deal with automation.

We started this before there was an Ant, J2EE, JMS, JMX, J2ME, and even 
Java-2...  However, we have integrated most of these technologies into our 
systems with little effort, because we have followed the progress of them, and 
tried to participate in associated mailing lists.

GUI tools are important for many management tasks.  They help enumerate as 
well as synchronize steps that need to be performed.  Making a task visible is 
often the most important issue in designing a complicated system...

The issues is that obviously the more detailed a particular management task 
is, the more details need to be covered in any tool that automates things.  
When you provide an automation tool in a package that is a development 
platform, its lack of a particular functionality often shapes the way that 
people with less experience design their applications on that platform.

Consider how much really bad HTML was handwritten until there were HTML 
editors.  Also consider the fact that the templates in most HTML editors now 
confine the styles of web pages that are visible on the web.  This is good 
from the perspective that it makes all of us more comfortable because the 
sites are similar.  However, it also causes people that have special needs, 
but not the knowledge of HTML, CSS or otherwise, to be confined in their 
implementation. I don't know that I have a grand idea for how to eliminate 
this reality though :-) I often just leave out automation tools when I feel 
like their solution space is so narrow that they confine more than they extend 
the system involved.

And no I am not saying that Ant is confining... :-)
-----
gr...@cy...  (Cyte Technologies Inc)