The Vision: a billion connected users and devices by the year 2000. The Plan: reinvent its operating systems, protocols, and services.
Jon Udell
A few months ago, we pulled the plug on Guernsey, BYTE's original NetWare server. First powered up six years ago, Guernsey survived anachronistically into the mid-1990s alongside newer systems, because NetWare 2.15C kept flogging useful work out of the lowly 286 PC we ran it on. That says a lot about chief architect Drew Major's skill and about the quality of the special-purpose operating system he invented to run network services in the inaugural decade of the LAN.
Newer versions of NetWare still retain the legendary speed and reliability of its predecessors, but these qualities alone can no longer sustain the huge conglomerate that Novell has become. Last spring, at
the 10th annual BrainShare '94 (Novell's developers conference) in Salt Lake City, Utah, the message to 5000 attendees was that NetWare was but one of three pillars of the new Novell. In the future, AppWare and UnixWare would receive equal billing with NetWare.
The message continued: After digesting a series of acquisitions--including USL (Unix Systems Laboratories), Serius, Software Transformation, WordPerfect, and Borland International's spreadsheet division--Novell would redefine the second decade of PC networking just as it did the first. Directory, WAN, messaging, telephony, hierarchical storage, document, and other advanced network services would become as common as file and print services are today. Novell would field applications exploiting those services and provide the tools and components needed to create and manage networked applications.
That was a fine vision, but the unrelated NetWare, AppWare, and UnixWare families of products formed an unsteady tripod, and Novell's network serv
ices (beyond file and print) are a mixed bag. Six months after BrainShare '94, at Networld+Interop in Las Vegas, Novell's CEO Robert Frankenberg emerged with a plan to regain the tight focus that Novell's hectic expansion had blurred. Dubbed pervasive computing, the new strategy ceded the desktop operating-system war to Microsoft's Windows and reaffirmed Novell's mission to scale networks from the department to the enterprise and beyond.
Frankenberg said that Novell would unify NetWare and UnixWare into an all-purpose SuperNOS and raise the ante on an embedded-systems framework called NEST (Novell Embedded Systems Technology) (see ``Smarter Copiers, Printers, and Fax Devices Are Coming,'' November 1994 BYTE). The client-side focus would shift to Corsair, a new graphical NetWare shell featuring a Mosaic-like network navigator called Ferret. Casualties included the AppWare leg of the tripod, which Frankenberg sawed off at the knee when he halted development of the AppWare Foundation, a toolkit that would
have enabled applications and Novell's brand of software components (AppWare loadable modules, or ALMs) to port across client (and eventually server) platforms. Frankenberg told BYTE that while the idea of portable components was appealing, Windows software developers just weren't lining up to support it.
More of that kind of brutal pragmatism will likely be required to meet Frankenberg's daring challenge. He wants a billion users and devices connected to NetWare by the year 2000 (versus an estimated 40 million today). Sheer hype and fantasy? Maybe not. Voice networks are that pervasive today, data networks will be tomorrow. Bob Metcalfe, inventor of Ethernet, has recently noted that Ethernet LANs pump vastly more data than does the Internet; thus, they collectively form the true information superhighway. NetWare, of course, runs most of the world's Ethernet LANs. However, Microsoft wants those billion connections, too; it already owns the desktop and is encroaching on Novell's server stronghold. To m
eet this challenge, Novell will have to retool its operating systems, protocols, services, and tools. Here's how the current plan is shaping up.
The Crown Jewel
NetWare's modern era began in 1989 at the fifth BrainShare conference, when Novell rolled out NetWare 386 (also known as NetWare 3.0). Two demonstrations brought the crowd to its feet cheering. In the first, Novell showed how the NetWare kernel could install in minutes and then dynamically load (and unload) disk, network adapter, and network protocol drivers (NetWare 2.x, like most Unixes, had required a kernel rebuild to accomplish these tasks). That flexibility remains to this day an inspiring example. We can, for example, restart AppleShare or NFS (Network File System) services on one of BYTE's NetWare 3.1x servers without interrupting logged-on DOS users. OS/2, Windows NT, and Unix can't match NetWare's dynamism; it's a key asset Novell must carry forward to SuperNOS.
The second demonstration showed how to writ
e an NLM in C, pass it through the Watcom compiler, and then load and run it. The roar of approval that greeted the appearance of ``Hello, world'' on the NetWare console would have puzzled noninitiates. Only those familiar with the arcane hacking needed to create a NetWare 2.x VAP (value-added process) could fully appreciate how the new ability to write NLMs using standard C libraries and tools would advance the state of NetWare. The beauty of this, of course, was that now NetWare could natively support database, mail, and other advanced services. Unix and OS/2 developers could port to or directly target NetWare, gaining a performance edge and automatic integration with NetWare's huge installed base.
C libraries and tools notwithstanding, NetWare 3.x was no more a general-purpose operating system than its predecessor had been. Running naked and fast at ring 0 on a 386, it made no use of the chip's ability to carve out separate, protected address spaces. (The newer NetWare 4's domain architecture now af
fords optional protection, but mostly for the convenience of developers; trusted production NLMs still run best in kernel address space at ring 0.) NetWare 3.x's new thread APIs were modeled after those of OS/2, but NetWare threads multitasked on a cooperative, not a preemptive, basis. Lacking real memory protection and preemptive scheduling, NetWare was--and remains--an eccentric platform for server applications.
The NLM Question
Advocates say the gain of porting to NLM is worth the considerable pain. It wasn't until late 1991, for example, that Gupta was able to convert SQLBase, its SQL server, into an NLM. ``But we topped 100 TPC [Transaction Processing Performance Council] transactions per second with our NLM,'' says Matt Miller, Gupta's marketing manager. Once available, NLMs seem to not only perform well but also run stably. ``My Oracle NLMs stay up for months on end,'' says Chris Cermak, lead systems analyst for Mettler-Toledo, a weighing and measuring equipment manufactur
er in Worthington, Ohio. Phillip Ellis, project manager for MicroAge, a technology distributor based in Tempe, Arizona, reports similar success with the Lotus Notes NLM.
Critics say that these results are achieved in an extremely controlled environment. ``Customers add a lot of memory, limit the number of users, and run just one application per server,'' charges Rich Finkelstein, president of Performance Computing, a Chicago-based client/server database consultancy. ``Why? Because they don't want to learn Unix.''
Indeed, Cermak and Ellis confirm that they run most NLMs on dedicated machines and that familiarity with NetWare--not performance--drove the decision to use NLMs. ``At DBExpo, in an audience of 300 [developers], maybe a dozen showed interest in NLMs,'' says Finkelstein, ``but two years ago, a third of the audience raised their hands.'' Finkelstein attributes the declining interest in NLMs to an increasing concern about NetWare's shields-down mode of operation. ``You can make a Sherman t
ank go faster if you take off the armor,'' he says, ``but that's not the point.''
Finkelstein and others point out that Unix, NT, and OS/2 alternatives are getting easier to use and are scalable to RISC and multiprocessor hardware. Lisa Yi, senior product manager for Sybase SQL Server, notes that ``some diehard NetWare users have begun to react favorably to NT.'' Attractive pricing, built-in IPX/SPX connectivity, and GUI-based administration lure these users into the Microsoft camp, says Yi.
NetWare for RISC
Although Novell's initiative to move NetWare to RISC has done little to clarify NetWare's role, its technology yield is crucial to SuperNOS. For the RISC effort, Novell rewrote NetWare in C and abstracted its hardware dependencies. Because Novell had previously used the name Portable NetWare to denote versions of NetWare hosted on VMS and Unix, this truly portable NetWare was called PIN (Processor Independent NetWare). It will run natively on PowerPC processors and sup
port NLMs.
In his BrainShare '94 keynote address, Drew Major admitted that NetWare could have migrated to C years ago, with little impact on its performance, had he been comfortable programming in C back in the mid-1980s. ``I'm still not always sure where the asterisks go,'' he joked. Attendees laughed, but nervously. It was scary to think about NetWare's extreme dependence on a single mind. The merger of the PIN code base with that of NetWare 4.x, following the release of NetWare 4.1, will finally close a window of vulnerability that Novell left open far too long.
The PIN effort not only decouples NetWare from the x86 instruction set, it also isolates it from PC-style bus, memory, and interrupt architectures (see the figure ``
Processor-Independent NetWare Architecture
''). This separation is defined by the NSI (NetWare Systems Interface), Novell's equivalent to the NT HAL (hardware abstraction layer). NSI's roots go way back, according to Carl Amdahl, CEO and chief technical off
icer of NetFrame Systems (Milpitas, CA), a company that has since 1989 adapted NetWare to run on superservers that are Intel-based but otherwise more like hardened mainframes than conventional PCs. ``We licensed NetWare and stripped out all hard-coded references to the interrupt controller, to BIOS routines--everything around the Intel chip was up for grabs,'' says Amdahl. This work later found its way into NetWare 3.11, which isolates platform dependencies into the module that loads the NetWare kernel, and has now evolved into NSI.
``Novell did a good, clean job of abstracting the kernel from the hardware,'' says Russell Sonnenschein, NetWare NSI engineering manager for Apple. ``It covers everything you need to get to the system prompt: video, keyboard, I/O, timers, interrupts.'' Working from Novell's specification, his team built an NSI layer for the Power Mac. ``When we first integrated Novell's kernel with our NSI,'' says Sonnenschein, ``we were up and running 5 hours after we loaded the NetWare im
age.'' He also verifies Novell's claim that ANSI C drivers that conform to NSI will recompile for and run on NetWare for the PowerPC. Note that PIN's benefits aren't confined solely to RISC. ``People forget that Intel is a PIN partner, too,'' says Glenn Thompson, manager of NT and NetWare server marketing for DEC, citing Pentium-optimized NetWare 4.1 as a key benefit of PIN.
Who Needs PIN?
NetWare servers are classically I/O-bound, not CPU-bound; the 486s and Pentiums in these machines typically idle at a fraction of capacity. CPU-intensive NLMs that might soak up those extra cycles are still relatively scarce. So who needs PIN? That's a hard question for Novell, especially since its original PIN partner, Hewlett-Packard, pulled the plug on NetWare for PA-RISC and plans for NetWare for the Alpha have been shelved. One answer is that NetWare 4.x targets the enterprise, not just the workgroup, and RISC-powered NetWare 4.x superservers can consolidate file and print services. ``But
now we believe the Intel binary compatibility of our new converged architecture [the forthcoming x86/PA-RISC hybrid] will meet that need,'' says Ray Mausling, HP's marketing program manager for NetWare.
Customers' and resellers' familiarity with NetWare is one key reason to deliver it on RISC hardware, say Michael Tiemann, president of Cygnus Support (Mountain View, CA), and blazing performance is another. Cygnus is providing versions of the GNU tools used to build NetWare and NLMs for RISC platforms. ``People criticize Unix and NT for their massive overhead,'' says Tiemann. ``There's a wide-open opportunity for a lightweight, portable OS that won't suck the cycles on your super RISC machine.''
UnixWare Revisited
When Novell first acquired USL and launched its own System V release 4.2 offering (UnixWare), it further clouded the NLM picture. Tailored to fit neatly into IPX/SPX networks, UnixWare was billed as Novell's robust, general-purpose applications server. Novell clai
med you could now build network services for NetWare and applications for UnixWare. What's the difference between a service and an application? In view of Novell's ongoing push to attract NLM versions of top-tier products, such as Oracle and Notes, the distinction was fuzzy at best. ``Anything that sells in high enough volume is no longer an application,'' jokes Nina Lytton, president of Open Systems Advisors (Boston, MA), ``it's a network service.''
Still, Unix is where most of the world's downsized applications run, and UnixWare's affinity for standard Intel-based boxes and NetWare LANs makes it a potent asset. A much-improved UnixWare 2.0 (which is due to ship in the first quarter of this year) exploits SMP (symmetric multiprocessing) hardware in a multithreaded fashion and rivals NT in its wealth of GUI-based system administration tools and in its ability to detect and configure for standard peripherals (see the screens ``
UnixWare 2.0's New Look
'', ``
User Set
up
'', ``
Processor Administration
'', ``
Hardware Setup
'').
With a single log-on to NetWare and UnixWare and the ability of each to use the other's print queues, the two systems integrate better than ever before. But they still don't couple as tightly as Novell would like. UnixWare 2.0 still won't run NDS (NetWare Directory Services); that support is slated for version 2.1, which is due before the end of the year.
Are customers confused by Novell's failure to integrate NetWare and UnixWare fully or to clarify the role of NLMs versus Unix applications? Perhaps not as much as analysts like to think. Holiday Inn Worldwide (Atlanta, GA) is equipping its 450 international hotels with a combination of NetWare and UnixWare. The two are nicely complementary, says Don Lynch, director of worldwide hotel systems development. The front desks use NetWare's file, print, and Btrieve database services but talk through a UnixWare gateway to the mainframe-based reserva
tion system. Because a Unix process buffers all transactions, there's protection against glitches on either the LAN or the WAN side of the gateway. Transactions can flow in both directions, because UnixWare can act as a client to a Btrieve database on a NetWare server.
Could NT fill UnixWare's shoes in this scenario? Perhaps, says Lynch, ``but do you want to buy a car from somebody who's just built their first one or from somebody who's been building them for 20 years?'' However, he notes that a one-box solution (which NT could provide) is more desirable than the current two-box arrangement--one for NetWare and one for UnixWare--and looks forward to a converged SuperNOS.
For Ameritech Library Services (Provo, UT), a leading vendor of public, private, and school library systems, UnixWare's connection to Novell opens doors in the K to 12 market. ``When you come into a DOS environment with a Unix solution,'' says Bernadete G. Razevska, vice president and general manager of the company's school divi
sion, ``you may have some hard selling to do.'' UnixWare helps overcome that resistance, she says, because it slides neatly into the NetWare LANs now found in many schools. UnixWare 2.0's scalability is a boon, Razevska adds, because it will ease districtwide consolidation of library systems.
These developers don't fret about NLMs. They know their applications need to run on a general-purpose operating system, and they think UnixWare is a good choice when those applications target users on NetWare LANs.
Multiprocessor NetWare
The ability of Unix, NT, and now OS/2 to exploit multiple processors has been another thorn in Novell's side, and at BrainShare '94, the company rolled out a three-phase multiprocessor road map delineating a strategy it calls distributed parallel processing, or DPP (see the figure ``
Novell's Distributed Parallel Processing Road Map
''). In the first phase, NetWare will support SMP hardware. This implementation will be less symmetrical
than the name implies, however. It entails only the minimal surgery required to spread NetWare's I/O processing (and specially adapted NLMs) across multiple CPUs (NetWare 4.1 and UnixWare 2.0 will share the same SMP APIs). A second phase will build on the NetWare 4 domain architecture and ASMP (asymmetric multiprocessing) to spread unmodified NLMs across CPUs in multiple protected domains. In the final phase, Novell wants to vault NetWare (by then converged with UnixWare to create SuperNOS) into the realm of clustered multiprocessing systems.
``You've always been able to scale NetWare by adding workstations,'' says Major. ``We want you to be able to scale at the back end in the same way, by adding servers.''
To coordinate such loosely coupled clusters of servers, Novell bought NetFrame's distributed lock manager, originally built for Oracle's Parallel Server. ``It's a generic way to coordinate resource access and manipulation,'' says Amdahl. ``The objects you register with the lock manager can r
epresent not just files or records but resources of any arbitrary type.''
Novell knows that PIN is a necessary short-term objective. The company has to gain control of the NetWare code, lay a foundation for hardware innovation, and allay concerns that arise when, as Tiemann notes, ``people see Novell's NLM stalwarts fighting their real performance wars on RISC.'' The phased DPP initiative is, likewise, an impressive and ambitious long-term goal. Today's shared-memory SMP systems could ultimately become atoms bound together in much larger molecules enabled by DPP. As these strategies evolve, much will depend on when and how Novell unifies the APIs and, eventually, the guts of NetWare and UnixWare.
SuperNOS
Novell's grand vision crystallizes in SuperNOS. This new operating system will be built on a microkernel so that it can be portable, modular, and distributable. Novell's NetWare and UnixWare architects are hammering out just what that microkernel will be. An obvious choic
e is Chorus Systems' (Saint-Quentin-en-Yvelines, France) Chorus, which USL had selected as the base of its future Unix products prior to its acquisition by Novell (see ``The Chorus Microkernel,'' January 1994 BYTE). It's particularly well suited because, unlike Mach and NT, Chorus blurs the boundary between kernel mode (privileged code in shared address space) and user mode (nonprivileged code in disjoint address spaces). In theory, that flexibility makes Chorus the ideal SuperNOS substrate, and Major says that a prototype of NetWare on Chorus is already up and running.
``We'll offer two execution environments--kernel and Spec1170 [X/Open's standard Unix API],'' he says. A SuperNOS file server or router will use the kernel environment, where trusted NLMs can deliver maximum throughput and real-time response. A SuperNOS applications server would use the Spec1170 environment, where applications enjoy protection and standard APIs. When both environments coexist, the result will be a one-box NetWare and Un
ixWare solution.
At press time, however, Chorus had not yet been officially anointed as the Novell microkernel. ``We'll take elements of it,'' says Major, ``but we need a next generation of Chorus.'' That generation is at hand, counters Michel Gien, vice president of technology for Chorus Systems. He says the company is tuning the microkernel so that colocated server processes can use direct function calls, reserving the message-passing form of IPC (interprocess communications) for communication across address spaces. Gien also gently suggests that Major's team has not yet fully absorbed the Chorus technology transfer. ``They are new at this,'' he says, ``and have not had a lot of hands-on experience [with the microkernel].''
Novell hopes that from this bubbling cauldron of egos and technologies will emerge the scalable multipurpose operating system on which its future depends. There is understandable friction but also a profound sense of synergy.
The Unix Systems Group, for example, has
defined its own clustering initiative, SSI (single system image). ``DPP and SSI are two sides of the same coin,'' says Major. The acronym doesn't matter, but the concept does. In today's client/server world, transaction-processing monitors handle load balancing and service replication for applications distributed across a few specialized servers. In tomorrow's intelligent networks, those servers will be numerous and standard, just as desktop systems are today, and the NOS will have to be able to recruit and reliably manage whole farms of them. Casting SuperNOS in that role is a vital initiative. Novell had better hurry, too. DEC, a pioneer in cluster computing, previewed an NT-based clustering technology at Fall '94 Comdex.
Rethinking IPX/SPX
NetWare takes a lot of heat for its favored transport protocol, IPX/SPX. Critics are right to point out that it scales ungracefully to WANs, but they are wrong to conclude that Novell should abandon it in favor of TCP/IP. ``IPX has some grea
t properties that IP bigots will never admit to,'' says Tim Gelinas, vice president of engineering for Spry (Seattle, WA). ``You just kickstart a workstation and boom, you're on the network.''
That's because IPX takes as its node address the unique number burned into every Ethernet or token-ring adapter. By contrast, administrators must dole out IP node addresses. While that tedious and error-prone chore can be automated using BOOTP or DHCP servers, such servers must be set up and cared for, and they can fail. With IPX, assigning node addresses is simply not an issue.
Another nice property of IPX is the generous size of its address space. An IPX address includes a 4-byte network number and a 6-byte node ID. IP, by contrast, crams the network number and the node ID into a 4-byte address. Apart from the administrative headaches caused by the sliding boundary between the network-number and node-ID parts of an IP address, there's real concern that the explosively growing Internet will exhaust the av
ailable supply of IP addresses. IPng (IP next generation), the Internet Engineering Task Force's proposed solution, will likely ease the crisis, but there's no guarantee that it will be painless for administrators.
Given the reach and simplicity of IPX, why do WAN experts always give NetWare such a bad rap? It's not IPX's fault. The real culprits are RIP (routing information protocol) and SAP (service advertisement protocol). RIP, which has been used in both IP and IPX networks (see the figure ``
The Family Tree of Routing Protocols
''), is a distance vector routing protocol. A RIP-based router maintains a table of distances (hops) to other routers, as reported by its neighbors. In Novell's implementation of RIP, routers broadcast updates every 30 seconds, whether network topology has changed or not. Those updates suck up bandwidth on a WAN, and RIP routers react slowly when topology changes. Worse, if a link to a router fails, routers with multiple paths to the failed link can becom
e confused and begin erroneously incrementing their hop counts, a syndrome known as the count-to-infinity problem. ``Because this is engineering and not mathematics,'' jokes Novell senior consulting engineer Radia Perlman, ``infinity turns out to be 15.'' In other words, the infamous 15-hop radius of an IPX internetwork is just an arbitrary limit.
Enter NLSP
A solution to the problems of RIP is at hand. NLSP (NetWare Link Services Protocol), like the OSPF routing protocol that is currently favored in the IP world, uses an alternative and more powerful link-state technology. Because a link-state router periodically sends out a complete map of its neighborhood and stores the maps it receives from other routers, it knows a lot more about the network than does a distance-vector router, can react more quickly to change, and can find alternate paths when a link fails. Because updates occur only in response to change (in Novell's implementation, every 2 hours if there is no change), the
re's a lot less broadcast overhead. Link-state routers see the big picture, not relying on immediate neighbors for topology reports, so no arbitrary count-to-infinity time-out restricts network diameter.
NLSP also cuts down on the once-per-minute SAP broadcasting that announces the availability of servers, printers, and all other advertised network services. Service advertisements propagate on the same bihourly schedule as do topology updates. Mark de la Vega, Novell's product line manager for Novell's NetWare infrastructure division, says that NLSP's elimination of RIP, its encapsulation of SAP, and its ability to compress SAP data--in concert with other optimizations, such as burst-mode IPX and large-packet IPX--can yield a 30-to-1 reduction in traffic on WAN links. Use of the NDS will improve matters still further, because you won't need to advertise services when you can simply look them up in a directory.
A Matter of Choice
Router vendors routinely include RIP and SAP
filters that can control NetWare's appetite for WAN bandwidth. Now in NLSP, they have a much better tool for that job, and they're lining up to support it. ``We'll have NLSP support in products in the first half of '95,'' says Dana Rasmussen, senior product manager for PC protocols at internetworking equipment vendor Bay Networks, formed by a merge between Wellfleet Communications (Billerica, MA) and SynOptics Communications (Santa Clara, CA). It is available now for Novell's servers and multiprotocol routers. Longtime critics of the IPX protocol suite may find to their surprise that it is about to become a quite credible substrate for networking on an enterprise or global scale. The remaining wrinkle is that Novell's implementation of NLSP lacks OSPF's ability to subdivide a large internetwork into smaller areas. Novell says that it or third parties can easily add this hierarchical routing capability on top of NLSP. ``They've done the forward planning,'' agrees Wellfleet's Rasmussen, ``and have proactively
included router vendors to help define how NLSP goes beyond level one [flat, single-area] routing.''
Enhancing IPX does not, of course, excuse Novell from catering to the IP bigots. Novell does offer NetWare/IP, which layers NCP (NetWare Core Protocol) on an IP substrate, but users and analysts say that it's neither cheap nor convenient. ``We thought it would be our be-all and end-all,'' says Blaine Bauer, network analyst for Mobil, ``but installing and maintaining the domain servers [replicable databases of SAP and RIP information] was a hassle, and performance was poor.'' Moreover, NetWare/IP doesn't yet automate the allocation of IP addresses. ``NetWare needs to come out of the box ready to run IP or IPX, just as Windows now does,'' says Jamie Lewis, president of The Burton Group (Salt Lake City, UT). ``Microsoft has done for transports what Novell did for network hardware--they've taken that issue off the table.''
When it comes to network APIs, though, Novell does have a valuable, if underap
preciated, asset in the form of TI-RPC (transport-independent remote procedure call). Windows Sockets, in its current version 1.1, expects a TCP/IP substrate. Microsoft has privately extended WinSock to work with SPX (on Windows 95 and NT), but transport independence won't be standard with all implementations until WinSock 2.0 arrives. TI-RPC, which is available on Sun systems and other Unix systems, as well as on all Novell-supported servers and clients, now offers transport independence. ``You can build a TI-RPC server for either UnixWare or NetWare that can talk to both SPX and TCP clients at the same time,'' says Steve Lemmo, founder and chief technical officer of RPC tool vendor NobleNet (Southborough, MA), ``and it'll be wire-compatible with a ton of Unix platforms.''
The Global Directory
NetWare 4's headline attraction was NDS, an X.500-inspired global directory service designed to bring an organization's users, servers, and network services under a single umbrella. NDS re
presents a great leap forward that, to Novell's chagrin, not many users have yet been willing to make. The great success of NetWare's golden release, 3.11, created equally great inertia. ``We did all the planning for directory services and thought it would take off,'' says Mobil's Bauer, ``but users don't see a big incentive, and site administrators don't like having to switch over to VLM [the new NetWare 4 shell that loads a set of virtual loadable modules].'' Indications are that Microsoft may face similar resistance moving users from its golden release of Windows, coincidentally--or not--also numbered 3.11, to Windows 95. The Windows 3/NetWare 3 matched set has become a deeply entrenched corporate standard.
To overcome the inertia, Novell and third parties will have to add a rich assortment of applications and services to NDS. In the 4.0 release of NetWare, not even Novell's own MHS mail directory could integrate with NDS. Many NLM-based services--including those from Oracle, Sybase, and Lotus--now
do, and in NetWare 4.1, so does MHS. NetWare 4.1 also supplies tools to prune and graft parts of NDS; the absence of these in the initial release was a deterrent for some users. And NetWare 4.1 will provide APIs for synchronizing with NDS so that an existing human-resources application, for example, might serve as the interface for adding new employees to NDS.
Despite its sluggish start, NetWare 4's ability to consolidate servers and other resources into a single system image has not gone entirely unappreciated. McGill University has already upgraded a few of its 120 NetWare servers and plans to complete the move to NetWare 4. ``Directory services will be a great help,'' says McGill's senior network-systems analyst, Lisa Laing. ``Users are logging in to servers all over campus looking for things; NDS will let us put our expensive new Xerox DocuTech printers where everyone can find them.'' And NetWare 4.1 will run at each of Holiday Inn Worldwide's 450 international locations, because, says Don Lynch, `
`I just want the latest and greatest.''
The AppWare Saga
When Novell combined Software Transformation, Inc., and Serius to create the AppWare Systems Division, it placed itself smack in the middle of the component revolution that is transforming the software industry. AppWare's mission, Novell said, was to expose network services to developers in the form of easy-to-use components and to field those components on a wide range of client and server platforms. STI's Universal Component System, or UCS (also known as AppWare Foundation), would provide the portability, abstracting a superset of the GUI facilities available in Windows, Macintosh, Motif, and Presentation Manager and defining common APIs across these platforms for file I/O, memory management, and IPC. Serius Developer, now called Visual AppBuilder, would be the first of potentially many implementations of Novell's component framework. It's a visual programming tool for the Windows and Macintosh environments that's used to
plug Novell's ALM components into an interconnection framework called the AppWare Bus. Novell planned to converge these technology streams so that ALM components could build from a single source for all AppWare Foundation-supported platforms.
AppWare Foundation's demise came suddenly, and it left both Visual AppBuilder and Borland's OWL (Object Windows Library) for AppWare stranded. The latter, hosted on the AppWare Foundation and intended to enable OWL applications to recompile for non-Windows platforms, simply died. Embarrassingly, OWL for AppWare ads were in print when the announcement came. Visual AppBuilder, however, was merely wounded. The tool still supports ALMs on Windows and Mac systems, but developers must use platform-specific APIs to create those ALMs.
AppWare Foundation's API neutrality mattered most if your development plans were truly platform-neutral. In reality, the majority of developers heavily invested in the Windows API would have had to weigh the effort of porting to the
AppWare Foundation against the free ride on MFC (Microsoft Foundation Classes) that Microsoft says can get Windows applications onto other platforms. In the end, Novell bowed out, electing not to buck the momentum of the Windows API. Will the AppWare Foundation survive? As we went to press, a small software tools company was courting venture capitalists and IBM for help in resurrecting it.
Why would OpenDoc require the AppWare Foundation? As with ALMs, OpenDoc parts issue platform-specific API calls; a neutral API would enable a part to be written once for a number of platforms. Partial solutions are coming from Apple (Mac and Windows) and IBM (Presentation Manager, Windows, and Unix), but neither of these covers the gamut of clients. ``We're a long way from a business relationship,'' says Cliff Reeves, IBM's director of object technology, ``but we're vitally interested in any powerful tool that supports OpenDoc.'' The irony here is that Novell, the developer of OpenDoc libraries for Windows 3.1, 95, a
nd NT, would benefit from the existence of a universal AppWare Foundation-based part framework.
Network Componentware
ALM wrappers for the NetWare directory, mail, and authentication APIs and for the Tuxedo transaction monitor, shipped with Visual AppBuilder 1.0. Wrappers for telephony, network management, and many other key NetWare services are slated to follow. Advocates say ALMs will do for network programmers what VBXes did for programmers of stand-alone Windows applications. ``Controls are the right way to interact with NetWare,'' says Willie Neumann, president of Hyper Active (Columbus, OH), a middleware developer. ``If you're building on NetWare services in C, you're spending man-years,'' says Steve Jones, vice president of ImPower, a Salt Lake City ALM developer. ``The beauty of components is that I really can snap things together.''
What about the loss of ALM portability? A pervasive computing strategy should reach all users, not just the 90 percent running Window
s, particularly because Windows' dominance is almost never total. Joe Garnett, Chief of the Advanced Systems and Networks Element with the Pacific Air Force Computer Systems Squadron, says that the over 7000 clients attached to his 17 NetWare LANs scattered around the Pacific basin include an ineradicable minority of Mac, OS/2, and Unix clients. If the military can't mandate homogeneity, clearly businesses can't either. Yet the kinds of new applications likely to be enabled by network-aware components are precisely the ones that should reach all users. A desktop CTI (computer/telephone integration) application, for example, should have the same 100 percent penetration that phones do. (For more on Novell's CTI initiative, see ``Computer Telephony,'' July 1994 BYTE.)
For core NetWare services, that 100 percent reach will be assured if Novell keeps its promise to create ALMs for all supported client platforms. Third parties can follow suit if they choose. Hyper Active, for example, has ported its Oracle A
LM from the Mac to Windows. Given the complex logic required for direct access to the database in the design-time environment, says Willie Neumann, the ALM port was a relatively small effort.
Once ALMs exist, corporate IS organizations can use Visual AppBuilder--which runs on Windows and the Mac--to deploy single-source applications across multiple platforms. Visual Basic, hosted only on Windows, doesn't offer that option. Visual AppBuilder's scope will further expand if, as is now planned, Novell brings it to UnixWare by mid-year. According to Joe Firmage, general manager of Novell's Network Development Tools division and vice president of strategic planning for the NetWare Systems Group, the tool will also support VBXes, OLE controls, and OpenDoc parts. ``The AppWare environment operates at a high level of abstraction,'' says Firmage, ``so it can consolidate these lower-level components.''
Riding the Software Bus
Novell's ambitions for AppWare go beyond just showcasing N
etWare services. It wants ALMs to ride on a (still experimental) AppWare Distributed Bus over multiple transports. At BrainShare '94, Firmage showed dramatically how Visual AppBuilder can divide an application into client and server parts that distribute transparently across a network. In addition, he showed how the network service thus created will replicate automatically to accept multiple clients. While that demonstration used Apple protocols--ADSP for transport and NBP for name service--Firmage says the AppWare Distributed Bus will also work with IPX/SPX and NDS; TCP/IP, an object request broker that complies with CORBA (Common Object Request Broker Architecture); and other substrates, possibly PeerLogic's Pipes.
One intriguing substrate is Novell's Tuxedo, an OLTP monitor that runs on a variety of Unix platforms and--thanks to a recent Microsoft/Unisys deal--NT as well. In a client/server system built with Tuxedo, clients don't simply ask servers for data, they ask them to perform autonomous trans
actions against data accessible directly to the servers. High-availability, high-performance systems demand this kind of technology, says Robert Coven, president of InterAccess (Totowa, NJ), a client/server consultancy. ``I can replicate a Tuxedo service on two servers, then take down server A, transfer all users to server B, rewrite the application logic, then bring up the service again on A, and transfer users back to it. That's 100 percent availability, and when I upgrade B and bring it back on-line, Tuxedo balances the load between the two servers.''
The Tuxedo model of distributed computing dovetails neatly with that of the AppWare Distributed Bus. Both divide applications into coarsely granular partitions. The key point, says Firmage, is that while client or server partitions may both profitably use pluggable software components (for UI on the client side or data access on the server side), ``the useful point of distribution is not between application logic and reusable components but between pie
ces of application logic'' (see the figure ``
Distributed OLE vs. Distributed AppWare
'').
In other words, network services are not simply remote components. Their execution environment is the network. They need to be able to do things like replicate for reasons of redundancy and load-balancing. That's a compelling feature of Tuxedo that Novell wants AppWare to expose to a much larger population of programmers.
Making It Happen
Pervasive computing, in the current Novell blueprint, entails a
four-layer infrastructure
. The foundation is SuperNOS, offering two execution environments--NetWare's for core network services and transports and UnixWare's for layered applications. The technical and political challenges here are equally daunting. Can the hybrid SuperNOS retain NetWare's speed and flexibility while at the same time empower Novell to lead the Unix community and challenge NT in the applications server realm? No one knows, becau
se SuperNOS is still--literally--on the drawing board. But the answers to these questions define the future of Novell and its products. Quite simply, these are bet-the-company issues.
Atop SuperNOS ride essential network services, including two on which Novell's growth critically depends--NDS and NDMS (NetWare Distributed Management Services). Reworked for NetWare 4.1 (and by year-end, for UnixWare 2.1), NDS is the fundamental enabler for pervasive computing. Given the slow uptake of NetWare 4.0x, the picture looks a bit gloomy. What could drive wider acceptance, though, is NetWare Connect Services, because 4.1 and NDS are the keys to the Novell/AT&T business Internet. How will companies manage these far-flung networks? That's the role of NDMS. But while NMS (NetWare Management System) 2.0 is a shipping product, with monitoring, analysis, software distribution, and licensing tools, NDMS is a strategic direction. Today, NMS monitoring is distributed, but NMS data is stored in local Btrieve databases. Th
e NDMS strategy is to separate that data from the console and distribute it across SQL repositories accessible to non-Novell management platforms.
That way, if a third party creates ``the AI, 3-D GUI wonder-of-all-wonders management platform,'' says Michael Smith, director of West Coast operations for NetWorth, a hub vendor in Irving, Texas, ``the NetWare administrator won't need a Ph.D.'' to use it. The data used by the local NetWare Hubcon utility, for example, will also be directly usable by the enterprise management system. Thus NDMS will generally enable, rather than specifically define, network management on the grand scale Novell envisions. However The Burton Group's Lewis cautions that ``NDMS as a general statement of strategy is great, but they're a long way from delivering on it.''
The third layer, which enables users and devices to access core services, includes NEST, Corsair, and AT&T NCS (NetWare Connect Services). NEST could enfold previously unconnected devices such as faxes, PBXe
s, and even (Frankenberg pointed out in his Comdex keynote speech) slot machines. Corsair, which Frankenberg demonstrated during that speech, presents a
virtual-world interface
intended to appeal not only to business users but to the vast and growing home market that Novell must reach to attain its billion connections. AT&T NCS aims to make the WAN as available as the LAN is today.
The icing on the cake is networked applications, including Novell's current and future groupware products, custom distributed applications enabled by Tuxedo and AppWare, and the distribution and sale of information and software through AT&T NCS to businesses and--increasingly--to consumers. That's the plan, but Novell's blueprint for building this layer is hardest to decipher. Last year's tools strategy, AppWare, has lost much of its momentum. Next year's strategy, the company says, is distributed objects, OpenDoc, and CORBA. But what about right now? Novell's brand of computing can't become pervasive un
less networked applications pull millions of new users into the fold. Where these new applications come from is the $64,000 question.
Point/Counterpoint
NetWare isn't a general-purpose That's right. It's a special-purpose
operating system. operating system with its finger on the
pulse of the hardware. NetWare's
near-real-time characteristics mean that
it can move a lot of data in a hurry.
IPX/SPX doesn't work well on WANs. Actually, the IP crowd should envy
IPX/SPX's large address space and its
administrative simplicity. The real
problems are RIP and SAP, outmoded
routing protocols that NetWare 4.1
replaces with the far more robust and
efficient NLSP.
Novell has abandoned the desktop As well it should, because Windows owns
operating-system battle. the desktop. Novell resources that were
being spent to make its DOS or Unix
products compete with Windows can now be
diverted to the unification of NetWare
and UnixWare into SuperNOS, a NOS with
global, not departmental, reach. The
Novell/AT&T ``business Internet,''
NetWare Connect Services, promises to
revolutionize WANs while leveraging
Novell's existing LAN stronghold.
UnixWare and NetWare don't It's true that Integration remains
integrate well. incomplete, but there's no questi
on that
UnixWare plugs into a NetWare environment
more easily than any other version of
Unix. With version 2.0, UnixWare's new SMP
capability and ease of use make it an
excellent choice for an applications
server on a NetWare LAN.
illustration_link (82 Kbytes)
illustration_link (4 Kbytes)
As with Windows NT's HAL, the NSI isolates system hardware and low-level machine-specific software components from the NetWare kernel and layer
s above it.
illustration_link (13 Kbytes)
A staged evolution, coinciding with the transition from today's NetWare and UnixWare to a converged SuperNOS, leads eventually to a distributed NOS that harnesses the power of server complexes whose pluggable parts are single-processor and multiprocessor machines.
illustration_link (5 Kbytes)
RIP isn't a Novell exclusive; originally IP networks used this distance-vector protocol, too. Novell's replacement for RIP, NLSP, is a cousin to OSPF, but most closely resembles the OSI link-state protocol, IS-IS (intermediate system to intermediate system).
illustration_link (4 Kbytes)
In Novell's view, distributed software should cleave between application partitions rather than between applications and their components.
photo_link (82 Kbytes)
In this Corsair virtual world, you might click on the capitol building to browse state government records and retrieve information about tax codes.
screen_link (48 Kbytes)
UnixWare 2.0's friendly face makes this powerful, SMP-capable applications server as approachable as its archrival, Windows NT.
screen_link (51 Kbytes)
Adding new users is a point-and-click affair.
screen_link (17 Kbytes)
Processors can be individually enabled or disabled.
screen_link (49 Kbytes)
Device settings are documented and accessible.
Jon Udell is a BYTE senior technical editor at large. You can reach him on the Internet or BIX at
judell@bix.com
.
Novell's Campaign
