MAST

Links

Home
Mighty Automated Build (MAB)

MAB Overview
Setting Up
Configure and Build
Mighty Automated Deployment (MAD)

MAD Overview
For Developers
For Administrators
External links

ArchStudio 3
xADL 2.0 Site
Official xArch Site
UCI Institute for Software Research
MAST - Mighty Automated Deployment - For Site Admins Mighty Automated Software Tools

Mighty Automated Deployment - For Site Admins

This section is for site administrators who want to deploy MAD deployment for their developers at their own site. Software developers who want to deploy software through MAD should see here.

As an administrator, there are several ways that you can facilitate software product releases from your organization via MAD. Depending on how much of an administrative commitment you want to make, and how much "branding" you want to be able to do to your MAD installation, more or less effort may be required. It is important to understand that client users will use one MAD application/applet. There is not a separate "MAD for ISR" and "MAD for MyCompany.com" to users. Therefore, all products displayed through MAD that are available to a user will be displayed and managed in the same user interface. Users who have already downloaded or installed MAD from one organization do not have to do it from any other organization. Therefore, there are varying levels of involvement you can choose for your organization:

  • Setting up a server to serve MAD-deployed software, but direct your users to the ISR site to obtain and start the MAD client.
  • Setting up a server to serve MAD-deployed software, but also serving the MAD client application/applet from your own site as an additional service.
  • Doing both of the above, but also rebuilding and re-signing the MAD applet/application from your organization.


Part A: Set up a server to serve MAD-deployed software.

A server that serves MAD-deployed software is simply a Web server with FTP write-access to a Web-accessible directory. This is the way many Web servers are set up already. The platform of the server machine, or the specific server software running on it are not important.

The precise method for setting up a server with both HTTP (Web) and FTP access depends largely on the HTTP/FTP server software you are running, and therefore is beyond the scope of this documentation. Assumably, there will be some local directory on the server, such as:

/var/www/html/somedirectory/

or

C:\InetPub\wwwroot\somedirectory\

that maps to a URL such as:

http://www.mycompany.com/somedirectory/

MAD-deployed software should have its own directory on the server. Create a new, empty directory on the server such that it has a Web-accessible URL. Then, give this directory name and URL to your developers.


Part B: Understanding how MAD accesses deployed software.

The MAD client accesses software deployed with the MAD releaser via a standard HTTP connection to the Web server. Each MAD client keeps, on the client machine, a list of URLs (along with optional username/password combinations) it checks for new and updated software. These URLs are input on the URLs panel:

URLs Panel

The URL the user should input on this panel is the same URL given to developers where they release their software with the MAD releaser, above. If the URL is accessible and has software deployed there, the URLs panel will display that it is "OK" (as shown above). If not (if it does not exist or authentication credentials have not been met, for instance) the URLs panel will display an error.

This panel is accessible no matter from where the MAD client was obtained. Thus, as a site administrator, you can direct your users to the ISR Software Update site as a primary location for them to obtain and configure their MAD client.


Part C: Deploying MAD additionally at your own site.

For obvious reasons of branding, you may not want to direct users of MAD to ISR's site to get your software. Instead, you may choose to additionally offer it at your own site with support information about your own products, etc.

This is permitted as long as you follow the licensing and redistribution terms specified in the LICENSE.TXT file that comes with MAD. These terms are fairly broad in terms of what you are able to do.

Assuming you don't want to change MAD's behavior, then you can offer mad.zip on your own site for people to use for off-the-Web usage. Deploying the MAD client at your own site as an applet is slightly trickier.

One option is to fake it, to build a site, but when you want to pop up the MAD applet, just insert this HTML:

<a target="_blank" href="http://www.isr.uci.edu/projects/softwareupdate/mad.html">

Users who click on this link will have a new window open with a full-window MAD applet running in it.

If you want to deploy the applet at your own site, the APPLET tag should look like this:

<applet archive="mad.jar" code="edu/uci/isr/mad/Mad.class" width="100%" height="100%" align=center alt="Your browser understands the &lt;APPLET&gt; tag but isn't running the applet, for some reason.">
<param name="URL_1" value="http://www.mycompany.com/software/">
<param name="USERNAME_1" value="myusername">
<param name="PASSWORD_1" value="mypassword">
Your browser is completely ignoring the &lt;APPLET&gt; tag!
</applet>

Note that MAD only works with the Java 2 version 1.4 plugin, so you should check the user's JDK version before sending them this tag. See the ISR site for an example of how to do this.

The parameters are optional. If you include them, then the URL/username/password combination you specify will be automatically added to the user's MAD client's list of URLs to check for software. If you don't require HTTP authentication at this URL, just omit those two parameters. This tag assumes that you have mad.jar accessible from the current Web directory, of course. The mad.jar must be the one that is distributed with the MAD client from the ISR site; you can't modify it because it is a signed applet. If you need to modify it for some reason, see below.


Part D: Modifying and re-deploying the MAD client.

If you're going to modify the MAD client, to add features or to change its behavior for some reason, that is allowable as long as it is done within MAD's license restrictions. To be recompiled and re-deployed as an applet, you'll need to sign the JAR file first. Signing the JAR file requires a code-signing certificate, and is somewhat complicated. If you really want to do this, please contact Eric Dashofy for assistance. Or, consider contributing the changes to ISR so they can be included in the next MAD build for all users.




Copyright (C)2000-2003 The Regents of the University of California. All Rights Reserved Worldwide.