Q comes to work at CSN Friday morning, hoping there are no new emergencies to interfere with the office happy hour coming up that afternoon. He brings up the next problem report on WebNet's queue of current problems. It seems that work at the U&U team has ground to a halt due to serious and sporadic printer problems. The U&U team just got their own lab set up with Macs and a fast color printer. They are on a LAN along with the S&M team next door, who use Unix computers and have their own printer. Above the basement labs, in an equipment room with a view of the Flatirons are a Mac server for U&U and a Unix server for S&M, connected to the workstations by a hub. When the LAN was being set up everything worked nicely, but now that there are people actually using the computers and feverishly trying to print out papers and proposals whose deadlines are fast upon them, files sent to the printer are getting lost, the printer often hangs and sometimes even the computers hang. Q looks at his email and sees some irate messages: he must solve this problem before he can party.

Q is methodical and well trained, so he starts by loading the LAN layout into the WebNet simulation component from the WebNet catalog. Then he runs two LAN utilities that are integrated in the WebNet system: one that probes the network (Trawl) to check the accuracy of the configuration from the catalog and one to analyze the general packet traffic on the LAN (TrafficAnalyst). He adjusts the layout in the simulation to agree with Trawlís findings, goes into the specification component to make sure that performance is a high priority, and runs the simulation.

The WebNet simulation opens its critic window and suggests that a bridge be added to filter the packet traffic to just those areas where the different kinds of packets are needed. Q looks at the TrafficAnalyst's report and discovers that, indeed, every packet is being sent to every machine, overloading the LAN with lots of unnecessary traffic. The report makes sense in the context of the simulation's suggestion and vice versa. The critic message is accompanied by a list of pointers to related information. Q explores some of this to refresh his memory of the different kinds of bridges currently available and their cost/functionality trade-offs.

Q now goes back to the original design requirements for the new LAN in WebNet's design rationale component. Here he finds that the Mac users plan to use only the printer in their lab and the Unix users will just use theirs. So all printer traffic should be restricted to its own zone. That is clearly the solution to the problem! Q can almost taste that beer and wings now.

Q uses WebNet's interface to mine the WWW's information space for current, reliable, relevant details on bridges for the LAN. He goes to CNS's product description pages that describe the boxes they have in stock. He also visits the vendor web pages of the major suppliers. As he browses, he copies and pastes details into a matrix form in his WebNet notebook. The matrix compares the different products in terms of cost, vendor, protocols supported, configurability, need for dedicated machine/remote control/plug-and-play, OSI layer affected, etc. This narrows down the choice of bridge to three or four. But Q is curious about how other people at CNS judge the different boxes. For his top choices, Q searches through the CNS email using WebNet's GIMMe component. He sees that people have had some awful headaches using bridges from Assanti and BlackBox in situations like the one he is working on. He does not want a headache while those U&U people are yelling at him. That clinches it for the plug-and-play bridge that Cisco recently released.

Just to check his decision (remember, Q is methodical), Q wants to try the Cisco 9604 bridge out in the simulation before ordering it and physically installing it. So he returns to the simulation component. Of course, the new bridge is not represented in the WebNet gallery of devices. Q looks on the web repository of gallery items to see if someone has developed a simulation agent representing the 9604. Unfortunately, no one has yet, but there is one for the similar Cisco 8614 bridge. So Q drags the icon for the 8614 from the web repository into his gallery; he modifies the icon by dragging in a picture of the 9604 from Cisco's web page; and he adjusts the specs and simulation behavior using the VAT end-user language. Q puts the new bridge into his simulation, connecting the hub to the two workstation zones. He runs the simulation and gets no critic messages. He is satisfied that he has found a promising solution.

Q orders the bridge. He saves the simulation layout with the new bridge back into the WebNet catalog. He also uploads his new bridge agent to the web repository so other people can use it. After he installs the bridge, he will document his success with email to the people who originally posted the problem to his queue. This email will be automatically stored in WebNet's GIMMe repository of LAN maintenance war stories. Through these simple clean-up operations, Q has incrementally evolved the information that will be available to him and his colleagues around the world in the WebNet catalog, the web-based agent repository, his own notebook and the email group memory.