Software Focus

Web Server: Apache 1.3.23; Red Hat Linux 7.3, Dell PowerEdge 1650

• Primary decision factors: Security, staff experience

Our discussion on the choice of a Web server was short. We put Microsoft's Internet Information Server and Apache on the table, and picked Apache. Security was the primary driver, though our familiarity with Apache also worked in its favor. With nasty viruses and worms around, and considering that even a firewall won't stop attacks on IIS, Apache won with little argument.

Web Application Server: IBM WebSphere 4.01, microsoft Windows 2000 Server, Dell PowerEdge 2650

• Primary decision factors: Cost, experience, availability of additional staffExperience and the availability of experienced developers played heavily in our choice of WebSphere. Our staff has plenty of experience with both Java and WebSphere, and there are many experienced Java developers in the Green Bay area.

The selection of Windows 2000, on the other hand, was based solely on cost. Although we would have loved to put WebSphere on some IBM big iron, the cost of hardware, software and training could not be justified. We considered BEA WebLogic, but it also was cost-prohibitive; moreover, our staff lacked experience with the product and would have needed additional training.

Mission-Critical Database: IBM DB2 7.2, Windows 2000 Server, Compaq DL760

• Primary decision factors: Interoperability, scalability, staff experience, migration paths

We had our hearts set on an Oracle database to provide mission-critical storage for NWC Inc. Unfortunately, the cost was too high. We bandied about the possibility of using SQL Server 2000 instead, but WebSphere doesn't play as nice with SQL Server as it does with DB2, Informix, Sybase or other corporate-class RDBMSs (relational database management systems), and our staff has experience developing for DB2. Because such a large percentage of our revenue is Web-based, we needed to consider the abilities of the development staff heavily: They will be required to use the database on a regular basis. Staff experience with DB2 administration and the availability of professional services with serious DB2 administration experience was relevant too. Using a combination of WebSphere and DB2 will provide NWC Inc. with features and functionality that would otherwise be difficult to implement.We also plan on growing our business, so our primary database must be scalable in terms of capacity and be able to migrate to other platforms if necessary. SQL Server could not have migrated to any operating system but Windows, while DB2 can be deployed on any number of operating systems, including more traditional corporate-class hardware-operating system combinations.

Directory Server and DNS: Microsoft Active directory Server and DNS, Windows 2000 Server, Dell PowerEdge 2650

• Primary decision factors: Cost, interoperability

We chose Microsoft DNS solely on the decision to deploy ADS as our directory server, and picked ADS because of its cost and interoperability with our chosen groupware application. We considered a Sun solution for directory services but were once again driven by cost concerns in terms of hardware. Sun SPARC hardware would have been more costly and, given that our employee count is nowhere near the limits ADS can handle, we went with the less expensive option.

Groupware Server: Microsoft Exchange 2000, Windows 2000 Server, Dell PowerEdge 2650• Primary decision factors: cost, staff experience, user training/support

In choosing a groupware server we needed to take into account myriad factors, not the least of which was user training and support for client software. In a world where Microsoft Outlook is used not only in the workplace but also at home by a vast majority, we needed a solution that could interoperate easily with the client to avoid racking up additional user training and support costs.

Although a good number of vendors have introduced adapters to provide connectivity between Outlook and their groupware offerings, our staff has extensive experience with Exchange. We decided that our experience coupled with the ease of interoperability with Outlook and cost made Exchange the best solution.

General Ledger: Great Plains eEnterprise 7.0, Microsoft Windows 2000 Server, Compaq DL580

• Primary decision factors: cost, database requirements, time to deployOracle Financials was our first choice but the cost of acquiring an Oracle database, as mentioned earlier, forced us to reconsider. We looked at offerings from PeopleSoft and SAP as well, but again, cost became a factor. Great Plains offered an affordable solution, and though it meant an additional database to support, we felt the TCO of such a solution outweighed the requirement for a departmental SQL Server installation.

Financial Database: Microsoft SQL Server 2000, Windows 2000 Server, Compaq DL580

• Primary decision factors: required by general ledger software, future application support

You can't run most Microsoft products without SQL Server 2000, and given that our general ledger choice required SQL Server 7.0 or 2000, we chose the latter. We also felt that the availability of a departmental-level SQL Server was typical in the enterprise and would offer us some flexibility in decisions regarding future application deployments.

Although DB2 is widely supported, many applications support only SQL Server. While we don't necessarily like it, it's a fact that all enterprises, including NWC Inc., must deal with, and having a SQL Server installation provides us the flexibility to choose such products in the future if they suit our needs. If you've been following our NWC Inc. blog, you know we've had problems with just about every application we've installed. In fact, we've decided integration should be a four-letter word.The networking world has long known that accepted standards are the best way to achieve interoperability. When is the last time you worried about uplinking a 3Com switch to a Cisco switch? But how about getting Apache on Linux to pass application server requests to IBM's WebSphere Application Server on Windows 2000? Or figuring out why Microsoft's implementation of DNS doesn't play well with BIND? Or ... well, you get the picture.

Through this implementation we've been DBAs, system and network administrators, software installers, and wire monkeys. And we were working under some tight deadlines. We had less than two months to procure the hardware, software and facilities upgrades to make this lab happen. Why? The same reasons you'd cite for such hurry-up-and-do-it projects in your organization: budgetary constraints, corporate red tape and politics, and the need to get the business up and running so we could start selling our widgets.

Although we ran into late shipments and downtime courtesy of electricians ripping up the place--not to mention running out of caffeine more times than we can count--nothing frustrated us more than dealing with the applications necessary to run this little business we created. In fact, after listening to us vent about some database issues, contributing editor Don MacVittie's only comment was: "Welcome to the real world."

One of the most common causes of application problems is that people who write software make assumptions. And while some of those assumptions are good, others are just downright asinine. Take Microsoft DNS, for example. If you aren't networked when you install it, it will decide you want to be a root server. That's an example of an assumption that ought to be a configuration option. When you finally do network that machine, guess what? You can't do anything but resolve addresses in the configured zones. Our directory server (ADS) was the first machine we installed, and we didn't have it networked because we didn't have our switches yet. When we finally hooked it to a switch and set up routing to give the machines Internet access, you can imagine our consternation. And to add insult to injury, the cure wasn't pleasant: We deleted the "." zone, and every last pointer record in the reverse-lookup zone was deleted along with it. As for Microsoft DNS, well, address resolution stopped working entirely.

And it's certainly not just Microsoft. IBM made some assumptions during the configuration of WebSphere Application Server that drove us batty. You can configure WebSphere to use IBM's HTTP Server (based on Apache) or Apache. In the last stages of the installation a dialog box pops up and asks for the location of the Web-server configuration file. Sweet. We set up a quick Samba share on the Web server machine and selected the file. IBM takes care of adding the necessary configuration to the file. Cool, right?Wrong. We installed WebSphere on a Windows 2000 machine, so the installation assumed (there's that word again) that Apache was also installed on a Windows OS. Not in our lab it isn't. The changes had to be taken out and hand configuration ensued. No help is better than bad help.

WebSphere is also picky about the types of databases with which it will communicate. DB2? Of course. Sybase? Yes. Oracle? Yup. Informix? Naturally. SQL Server? No way. We had to tweak WebSphere's configuration, the most important of which was upgrading the JDBC drivers from version 1.0 to 2.0.

After the pain, however, comes the payoff: The hardware looks good, the blinking lights are all the right colors, and the applications are coming along nicely. But we're not finished. As we continue to review business applications we'll be testing them against this environment, and some will get to stay and become part of our little family. Unlike out other Real-World Labs®, where we often wipe all our machines and start with a clean slate, we won't be interrupting our business application lab by starting over from scratch. You don't have that option and, in this lab, neither do we.

Welcome to the real world of NWC Inc.

Technology editor Lori MacVittie has been a software developer and a network administrator. Write to her at [email protected].Oct. 14: We have an application running on the app server. Yes, I did the happy dance. Don't look at me like that--you've done it too.

Oct. 15: Steve upgraded the BIOS on the servers today to get rid of that annoying false alert. I watched and learned.

Nov. 1: Our DSL from Choice One Communications has been installed! 1.5 Mbps up and down. It's sweet.

Nov. 5: Put together a servlet to simulate the manufacturing process. Basically it just increases the inventory of our widgets.

For more blogs and to view the lab in real time, go to inc.networkcomputing.com/.