[Dev] End-to-end

[Brett Wooldridge]

Just thought I¹d shoot out an email to you guys to tell you that I got a
full end-to-end backup working.  Here¹s the play-by-play:

1. the ZipTie Server was started
2. a Backup Job was created consisting of one device, via the SOAP API
3. a Schedule was created to run the Backup Job once per minute at the top
of the minute, also via the SOAP API
4. at the appointed time (the 0th second of the next minute) the Quartz
Scheduler fired the Backup Job
5. the Backup Job created a Task to backup the device and placed in the
operation dispatcher.  This is Chris Hamlett¹s most excellent Dispatcher
that we¹ve had in hibernation for the past 12 months.
6. the Dispatcher locked access to the device and invoked the Task
7. the Task invoked the backup through the Network Layer¹s SOAP API (using
Java bindings), passing in a Connection Path URI and a set of Credentials
8. the proper Perl adapter was located, SOAP parameters translated into Perl
objects, and the backup() method called on the adapter
9. everything worked, and a populated ZipTie Element Document (aka ³The
Model²) was returned (via SOAP) to the Task, which currently printed it and
then threw it away.

Several cool things happened behind the scenes with respect to our new
extensible architecture:

1. When the server started, the Equinox Jetty bundle was initialized, which
went looking for bundles containing Servlets and found our...
2. Axis servlet, which it deployed.  Our Axis went looking for bundles that
are advertising SOAP services and found our...
3. Scheduler, which it deployed.  Our Scheduler went looking for bundles
advertising Job Types via our Quartz Job extension point and found our...
4. Core Job bundle, which advertises a ³Backup Job type².  The Scheduler
registered the Backup Job type and advertised it via SOAP...
5. Independently, our Adapter Web Service bundle initialized, located the
Axis bundle, and registered it¹s custom handler (because it dispatches to
Perl, not Java).  It consulted the AdapterService...
6. The AdapterService interrogated the adapter bundle (soon to be bundles)
and discovered IOS, Vyatta, Linksys, JUNOS, and Baystack adapters and
dynamically registered them as SOAP endpoints, effectively making each
Adapter itself a SOAP API (complete with self-publishing WSDL).
7. The BSF bundle interrogated all of the bundles looking for bundles
advertising Perl modules, it found the Adapters among them and contributed
their modules to the Perl Include path.

That took about 3 seconds.

All of this means we can ³just drop in²:
* Bundles containing Servlets, and they will be bound to their selected URL
* Bundles containing SOAP services, and they will be bound to their selected
SOAP endpoints 
* Bundles containing Job Types (i.e. Updates, reports, etc.), and they will
be registered with the Scheduler and advertised via it¹s SOAP API
* Bundles containing Adapters, and they will be found, and bound to unique
endpoints based on their Adapter ID.
* Bundles containing Perl modules, and they will be found and their
directories containing modules contributed to the Perl execution environment

Despite the seeming complexity, taken individually these bundles are simple
in their implementation, especially with respect to their touch points with
the rest of the system.  This thanks largely to the OSGi framework,
componentization model, and more importantly ³philospohy² it brings.

Thanks to everyone for getting us to this point.  There is definitely some
polish that needs to happen over the next few days, but so far the
architecture is not only hanging together it is looking better every day.

-Brett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20070525/c121e9f1/attachment.html