Maintaining and operating a corporate network can be a challenge, and one of the greatest challenges that exist in regards to doing so is being able to systematically archive user data that is vital to a company’s success as a business. Present day archiving solutions have grown fairly complex and confusing to the average user who just wants to know that his data will be there when he or she really needs it. One of the best archiving tools around is IBM’s ADSM product—an excellent tool that can be used in a distributed networking environment to archive and retrieve file data. Normally, there is at least one network ADSM server that handles a variety of ADSM clients on different platforms. Currently, IBM has developed around 30 separate clients for different operating system platforms and versions.

However, even with a tool like ADSM, using a standard archiving solution for a corporate network—especially the distributed ones seen in companies today—can be problematic. Multiple platforms require multiple clients. Although IBM has developed a great deal of clients for use with the most popular operating systems such as Solaris, NT, and HP-UX—there is still a fair amount of administrative work that is involved in installing and setting up these clients for each platform. A different client is normally needed for each operating system and in some cases for each operating system version. Also, there is more than one version of the ADSM client piece that can be used for an archiving solution. In one sense, this means that IBM has given the network administrator a great amount of flexibility, but in another sense that same administrator can have a big headache on his hands if he has more than just one or two platforms to be concerned about in his environment.

So, for example, if a network administrator has AIX, HP-UX, and Windows NT running in a company’s network, he or she will need a separate ADSM client for AIX, HP-UX, and Windows NT to run ADSM. If the environment is running both HP-UX versions 9 and 10, then both Version 2 and Version 3 clients may be needed to talk to the ADSM server.

In addition to that, the ADSM client isn’t for everyone. The command-line client provided by ADSM is extremely flexible and highly configurable—probably one of the best clients on the market for archiving data.

However, for an end user who deals only with an environment that is "point and click" (Windows), the ADSM command-line client can be quite a challenge to both use and implement properly. Those who are unfamiliar with archiving data or administering networks might find the ADSM client quite a challenge.

There are other times when the ADSM client and server package by IBM cannot store all of the data that needs to be stored regarding a file or directory. A clear example is the environment at AlliedSignal Engines. The business rules of that organization clearly defined a set of requirements that needed to be followed for a successful archive to take place. There were additional parameters of files that needed to be archived or stored with the file data besides just the normal information such as file name, file size, file location, and file owner.

Allied wanted to archive other information in connection with their files. Some of that information included a unique identifier for each file, an Engine Program Description, a General Program Description, a Specific Program Description, a detailed tracking of retention period that went beyond the normal scope of ADSM, and a comment section of some length. In addition to that, Allied wanted to store user information for each file, including users’ first and last names, their employee ID number, and whether or not a user is an administrator for SAFE.

Also, Allied wanted to put together an architecture that allowed for public archiving and group designations for different sections or departments within the company and functional areas within the corporation. While some of these things could legitimately be handled by ADSM (such as a unique descriptor for each file), implementing all of them together with just ADSM would have been quite a challenge.

In addition to that, Allied had four other goals in putting together an archiving facility for the Engines division. First, Allied wanted to see an archiving system that was platform independent. While this could "virtually" be done by ADSM’s many clients, Allied really wanted to use only one client—the Netscape browser. In other words, Allied wanted to see web-enabled platform independence. Also, Allied wanted to see an archiving system that was easy to use and simple to follow for inexperienced users. An engineer who specializes in drawing engines in CATIA doesn’t need to spend all of his time trying to figure out how to archive a file with the command-line client provided by ADSM. Already mentioned has been the fact that Allied wanted to see extra information regarding each file or directory archived included in that archive. Finally, the archiving solution proposed needed to free up space on both local and network disks.

The solution to the above requirements for Allied was designing a Java based multi-tier application that uses ADSM to archive data called Strategic Archiving Facility for Engines, or S.A.F.E. SAFE uses ADSM to archive both local and network file data. It uses Oracle to store the required data that Allied designated. SAFE uses Netscape and Java to provide ease of use and a user-friendly environment. To provide a multi-tier, platform independent environment, SAFE uses Java.

One of the greatest benefits of using a multi-tier architecture is that each of the components of an application do primarily that which they do best. For example, in SAFE, ADSM only keeps track of archiving or retrieving files. Oracle keeps track of all file and user data. The Java Web Server controls access to the application and provides structure for servlets.

The tiers are roughly divided into three parts: 1) The Presentation Layer – which includes the GUI interface and interaction to the user, 2) Processing and Business Rules –which determine how the application is going to behave and who can access it, and 3) Resources (or Legacy Data Access) – which include access to the data of the application that resides in both ADSM and Oracle.

What makes all of this possible is the ADSM Application Programming Interface, or API. If there weren’t an API, at least one client would need to be used and provided by IBM for archiving and retrieving of data. Because IBM has provided administrators with an API, custom solutions can be developed to fit specific problems that the normal client may not address—as has been shown with the requirements laid down by AlliedSignal.

With the API, file data can be streamed across the network. Java’s Native Interface communicates with the ADSM API via a shared library and avoids having to write a great deal of code in C or C++. The ADSM API allows the developer to treat files as objects and provides a seamless interface to the server. In fact, the ADSM API can be used to transfer raw data from storage or other devices. This would be especially useful in the future if, for example, there would be no driver available for a specific device to be accessed with an ADSM client. As long as your application has access to the data, you can write the raw data to ADSM. This would be especially useful if the data being archived wasn’t file data but instead data in an RDBMS or object data built and stored in another application.

To keep track of all of the data entered into SAFE, however, Oracle is used to preserve that data. Using a standard RDBMS like Oracle allows Oracle to do what it does best—store data in an easy to get to format. All of the Allied specific requirements and even the file data that is normally entered into ADSM’s database is stored via Oracle to provide SAFE with the ability to have information there for the user.

Java’s JDBC enables Allied to avoid a vendor specific RDBMS. Oracle was chosen to use with SAFE but any RDBMS could have been used. The JDBC is not only platform independent in regards to operating systems—it also handles any RDBMS as long as there is a driver for that database available and the RDBMS conforms to standard SQL conventions. So, for example, SAFE could use any number of databases such as Sybase, Informix, PostgreSQL, and MySQL.

Both thick and thin clients can be used with SAFE to enable the user to easily access SAFE through the Netscape web browser. Netscape was chosen by Allied because it really is the universal client that exists there enterprise wide. A thick client is basically an applet of some sort that is used by Netscape to present a graphic user interface to the user that emulates the same environment that most window based systems enjoy. There is more processing associated with using a thick client, hence its name.

Using digitally signed applets provide SAFE with the ability to add an additional layer of security regarding login to SAFE and data transfer. Using the signed applets also allow for users to be able to archive and retrieve local data from their workstations—regardless of platform. So, a user who is using Windows NT can archive all of his Word documents and the CATIA user who is using a high-end HP-UX Workstation can archive any local data that he or she may have.

Applets give the user an easier to use and more flexible GUI than using plain HTML or a command-line interface. However, SAFE also has a thin client that allows users to archive data that resides in their home directory. This thin client is completely HTML/JavaScript based and is very simple and easy to use. However, because it is minimal in regards to its functionality, only network-based files can be archived or retrieved with the thin client.

The Java Web Server and the servlets that were designed for SAFE provide the application with platform independence. Actually, Java provides the platform independence. The Java Web Server provides the servlets with the underlying web server/network application environment so that the developer does not have to spend time writing web server or other network level code. Instead, the developer can focus on writing SAFE specific code.

While functionality is provided by the other tiers, this tier controls access and defines how that functionality or resources are used. SAFE uses servlets to control who can and cannot access the application. In addition to basic access, there is also an administrative section of SAFE that allows administrators to configure SAFE.

The object-oriented design of SAFE makes modifying the application simple. The design is further enhanced by the modular servlet environment. Because cost was a concern, the Java Web Server/servlet architecture was chosen instead of the more expensive application servers on the market today such as WebLogic’s Tengah server which uses Enterprise Java Beans in addition to servlets.

All SQL statements are in one Java class file and are not embedded in any other code in the application. Any SQL statement can be passed to Oracle under this design and further modifications to SAFE are just up to the developer’s imagination. Any result sets pulled from Oracle are put into a common data format so that there is no need for embedding SQL in code. In fact, the interface to Oracle is generic enough with this design that the servlets do not even know that they are talking to an RDBMS—the servlets are just under the impression that they send out a request and get back an answer.

SAFE provides the user community at AlliedSignal with a true Java-based multi-tier, platform independent application that enables them to archive and retrieve data with a great deal of flexibility that is currently unavailable in today’s market.

Almost everything in SAFE can be switched out without affecting the other parts of the application. Oracle can be switched out to Informix or another database, and SAFE wouldn’t have to be changed at all. The Netscape browser could be replaced with Explorer or another browser. In fact, although it would probably be undesirable, ADSM could even be switched out and another archiving system could be used. Instead of using the Java Web Server, SAFE could use the Apache Web Server. In other words, SAFE provides maximum flexibility in regards to using different vendors.

In addition to switching out major parts of the application, the underlying architecture of SAFE can be used for other applications. For example, designing an application that would create new user accounts for a network and keep its results in an RDBMS would mostly be a matter of designing the forms a user would fill out. The part of SAFE that talks to the RDBMS (Oracle) can be completely reused at any time by other applications and that could be used to provide the database access to store information regarding new accounts.

Also, SAFE is completely scalable. Setting up more than one SAFE server to provide load balancing would be extremely simple. SAFE already operates using both database connection pools and thread pools to minimize connectivity issues and maximize data access and application functionality. Each of those pools can be increased and decreased at any time depending on user load and application use.

What about revising the existing application? Because of SAFE’s multi-tier design, functions of the application can be easily modified and enhanced without affecting the rest of the application. More servlets can be developed to provide additional functionality.

All in all, using Java and the ADSM API to develop multi-tier archiving applications enables a company to have a platform independent, scalable, and reusable architecture that functions the way that they need it to function.