Hi EKS...About NW - NT and Applications
Whenever a comparison between Netware and NT is made, the subject of applications comes up. Lately, with Novell adding JAVA, COBRA, and other enhancement, this topic has been getting very confusing (at least to me and maybe few others on the thread). To get a clear picture on what is happening here, I asked our "Mystery Man" to enlighten us on this subject. He spent 6 hours to come up with this outstanding write up about this subject. This is a keeper for anyone who wants to understand this subject. Here it is:
-------------------------------
What Is An Application Server?
by Mystery Man
As we all know, NetWare was originally designed to be a "special purpose operating system". It was optimized for ultra high performance in the areas of network protocols and file and print services - and it does those things extremely well. It was also designed to be extensible, so that additional services or "application systems" could be added to the "core services" and these would also have terrific performance. Examples of these are NetWare for SAA (Novell's market-leading SNA gateway) and Oracle 7 (the popular high-end database). NetWare is strictly a "server" operation system; it was NOT designed for use as a "client" or "desktop" OS. Consequently, NetWare lacks many of the features of a client OS, such as a GUI.
Windows NT, on the other hand, was designed to be a "general purpose"
OS. Furthermore, NT is a "dual role" OS in that it can be used as
either a server or as a client (and it is now sold in packages that are supposedly optimized for each role, although originally that was not the case). A general purpose OS, especially if it is intended to be utilized for applications written by casual or inexperienced
programmers, must incorporate numerous "protection" features that are
designed to keep it running even if an individual application is poorly written and "crashes". These protection features unavoidably add "overhead", and thus performance suffers. Many client-oriented features (such as a GUI) are highly complex, and this complexity tends to reduce reliability (despite the built-in protection features).
But even though the original design concepts were quite different,
NetWare and NT are, each in their own way, evolving toward similar goals (but achieved via dissimilar technology). Novell has been adding more "application-oriented" features to NetWare, and Microsoft has spent considerable effort optimizing and "fine-tuning" NT so that it will perform the most important services (such as "file and print") faster and more reliably.
The question of whether or not NetWare is or is not an application
server is complex and can be very confusing. It is made even more so by the fact that the term "application server" is used rather loosely to mean several different things. Let's try to sort them out.
APPLICATION REPOSITORY SERVERS
Sometimes the term "application server" is used rather casually to mean a server that can deliver desktop (client) applications to the
end-user's client PC (so that many clients can share a single copy of
the application code, which is resident on the server). This use of the term might more properly be stated as "application repository server". This, of course, is nothing more than good old "file and print services", which is the one thing that everybody agrees NetWare excels at, above all others. Microsoft often tries to confuse this issue by implying that Microsoft's desktop applications (such as Office 97) somehow "work better" when delivered from a Microsoft NT server - but this is pure horse manure.
VENDOR-WRITTEN APPLICATION SYSTEMS
Another use of the term "application server" refers to a server that
runs major "application systems" from both the OS vendor and other
software vendors. Examples of these "application systems" are e-mail
products (such as GroupWise), mainframe SNA gateways (such as NetWare
for SAA), web servers (such as Netscape Enterprise Server), database
systems (such as Oracle 7), and accounting packages (such as payroll and accounts receivable, which are available from a number of major
vendors). These applications are offered by large software vendors and are written by experienced vendor-oriented "software engineers". In many respects, this type of application can be regarded as a "system extension" - like the OS, they support many concurrent users, and high performance is an important design criterion.
NetWare provides the much-maligned NLM facility for implementation of
"system extensions" or "application systems". NLMs normally run with
exactly the same lack of protection features as do most internal
components of the operating system itself; this provides optimal
performance, and it is one of the reasons why web servers and database
systems have been repeatedly measured as running CONSIDERABLY faster
under NetWare than under any other OS. (The other reason is that web
servers and database systems are heavy users of precisely those
facilities that NetWare does best: network protocols and file and print services. In a sense, these applications are "really" variations of the ultra high performance core services of NetWare itself.)
For several years, NetWare has provided an option to run NLMs with a
limited form of memory protection (a form that protects the OS itself
from damage by a buggy application but does not protect these
applications from each other). However, this option is seldom used,
because the vendors that write these major applications are capable of
producing programs that are highly reliable; and, given that they are
reliable, customers would rather get the highest possible performance.
At Brainshare this week, Novell announced that the next release of
IntranetWare would include additional support for "memory protection and virtual memory". These are the "missing pieces" that will enable buggy applications to be protected from each other; these facilities are not so important for vendor-written "application systems" but they are vital for applications written by "casual or inexperienced programmers".
A prevalent myth about NLMs that I want to dispel is that they are "hard to write". In fact, for the audience to which they are addressed (vendor-oriented software engineers), NLMs are considerably EASIER to write than executables for Microsoft's operating systems! Compared to Windows 95/NT executables, NLMs are structurally less complex (no messy "message handling loop") and have a simpler and more straightforward memory management scheme (one flat globally-shared address space for both code and data). The reasons for this "myth" are
(a) The only widely available languages for writing NLMs are C and C++
(which are preferred by "vendor-oriented software engineers" but not by "casual or inexperienced programmers").
(b) There are very few "programming tools" available (since Novell,
unlike Microsoft, is not a major "programming tools" vendor).
(c) Novell has not done a good job of "evangelizing" the NLM development environment (Microsoft has a considerable advantage here, because they are a major vendor of compilers and tools, which Novell is not, and because their server development environment is exactly the same as their much-more-widely-used CLIENT development environment).
So when somebody complains that "NLMs are hard to write", what they
really mean is "I can't write them in Visual Basic" or "I can't use
Microsoft's Visual programming tools". For the audience for which they are intended (vendor-oriented software engineers), NLMs are in fact "a piece of cake" - almost the IDEAL software executable, because they are structurally simple, they are written in the languages that software engineers prefer (C/C++), and they "run like gangbusters".
CUSTOMER-WRITTEN APPLICATIONS
The third (and last) use of the term "application server" refers to a
server that runs SERVER-BASED applications written by customers. This
is the area in which NetWare has historically been deficient - although that is rapidly changing. Some of the major deficiencies I have already mentioned: the lack of memory protection features, the lack of support for languages such as Basic that appeal to the "casual or inexperienced programmer", and the scarcity of modern programming tools. There has been a virtual explosion in Novell's support for these things over the last six months. Some of this support is already available (such as NetBasic and the Java SDK) and much more was announced this week at Brainshare (such as enhanced memory protection and Sun's Project Studio development tools).
But none of the new facilities really replace the NLM - indeed, they are all "built on top" of the NLM. Except for a few special cases like "hardware device drivers", ALL machine code that is executed under NetWare ultimately comes from an NLM. NLMs play the same role in NetWare as EXEs do in DOS or Windows. The NLM is (and probably always will be) the underlying "fundamental" executable in NetWare, for both "application systems" and "customer-written applications" - although in the latter case, NLMs will often be employed indirectly, and the customer may not realize that an NLM is involved. To clarify this, I need to explain some things about "computer programming technology".
There are two fundamentally different methods that are widely used to
get computers to run ("execute") programs that are written in "source
code" by human beings. One method is called "compilation". In this
method, the "compiler" (which is itself a computer program) reads the
source code and translates it into a compact machine-specific form known as "object code" or "machine code". This "machine code" is the only kind of code that the processor (Intel or Motorola or whatever) can actually process (or "execute"). The "compilation" is performed at the time of "program development"; the resulting "machine code" is saved in the form of an "executable file" (.EXE in the case of DOS or Windows, .NLM in the case of NetWare). This executable file (also called a "program binary" in the Unix community) is all that is needed when the program is run (perhaps months or years after it was compiled). NLMs are normally produced by a C or C++ "compiler".
The second method is called "interpretation". In this method, the
"interpreter" (which is itself a computer program) reads the source code and executes (performs) each line of source code as it is read. No machine code is generated, and no executable file is produced. All of the "machine instructions" necessary for carrying out the actions
indicated by the source program are already contained within the
"interpreter", and these instructions are executed as needed to perform the actions called for by the source program. Every time the program is run, it is "interpretively translated" all over again by the "interpreter". Needless to say, this is slower than executing a program that has been "compiled" (because the "translation overhead" is incurred at "run time" rather than "once and for all" at "compile time").
But "interpretation" does have certain advantages. It is "more
dynamic", because the interpreter "knows more about what's going on" -
since it is actually running the program as well as translating it.
Certain computer languages (such as APL and Smalltalk and Lisp) depend
heavily on the dynamic capabilities of interpreters and are practically always "interpreted" and are rarely compiled (except in "research projects" - in fact, it is an "open question" as to whether or not it is even POSSIBLE to compile certain languages). Another, very pertinent advantage of interpreters is that they can "catch and prevent" a lot of the bad things that a buggy program could do. In particular, they can prevent programs from accessing or damaging areas of memory that "don't belong to them". So interpreters are "another way" of implementing "memory protection" - which can be important if hardware-based memory protection is not available in the processor or implemented in the operating system.
There are numerous variations on compilers and interpreters, but one
that is of special interest these days is the one used by Java. Java
uses a hybrid scheme, in which it is both "compiled" AND "interpreted". The Java compiler reads the Java source code and produces an abstract machine-independent type of "object code", which is known in Java circles as "byte code". The Java "virtual machine" is actually an interpreter, which reads the "byte code" (perhaps months or years later) and "executes it". This hybrid scheme has some of the advantages of both traditional methods. Most (but not all) of the "translation overhead" is incurred at "compile time", so Java is faster than a "pure" interpreter. But because the Java "byte code" is interpretively executed by the Java "virtual machine", it can (and does) implement an extremely thorough set of "protection features", including memory protection. Java's rather EXTREME bias toward "protection features" is known in Java circles as a "sandbox".
Now that I have explained the technology, here is a partial list of the ways that Novell is enhancing NetWare/IntranetWare to make it a MUCH more suitable platform for customer-written applications:
(1) Support for NetBasic was added, starting with the release of
IntranetWare last fall. NetBasic is very similar to Microsoft's highly popular Visual Basic (which is considered a "RAD" language - for "Rapid Application Development"). Like Visual Basic, NetBasic is interpreted, not compiled (Basic is a language that can be either compiled or interpreted; but most commonly, it is interpreted). Because NetBasic is interpreted, it is (at least in principle) a "safe" language for writing, testing, and debugging customer-written application programs under NetWare. It is a highly appropriate language for its intended audience: casual or inexperienced programmers - and they don't have to know an NLM from a hole in the ground. But note: the NetBasic interpreter ITSELF is an NLM - vendor-written and tested, of course.
(2) For the more experienced programmers, Novell is supporting Java.
Novell, like most of the rest of the industry, is betting on Java BIG
TIME as a counter to Microsoft's current dominance of application
programming methods and tools. Java is a much more complex and robust
language than NetBasic - in fact, it is nearly (but not quite) as
complex as C++. And since Java's "byte code" is interpreted by the Java "virtual machine" (aka "sandbox"), Java provides all of the "protection features" that are not "built-in" to the NetWare OS (and then some)!. Java programming does not produce any NLMs - but the Java "virtual machine" ITSELF is (you guessed it) a vendor-written NLM. The Java Software Development Kit (SDK) for NetWare (which includes a Java compiler and the Java "virtual machine" NLM) is currently available. Because Java has its own GUI (known as "AWT" - for "Another Window Toolkit"), Java applications written for NetWare can utilize a GUI if they want to - on the NetWare console! This is yet another step in making NetWare more like Microsoft's Windows 95/NT operating systems, although it's obviously not as important on a server (which is usually locked in a closet) as it is on a client OS. Nevertheless, the Java GUI will find some uses, such as for installation and setup programs and console-based monitoring programs. The Java "virtual machine" will also be included in the next release of IntranetWare.
(3) Additional memory protection and virtual memory support is being
added to the NetWare OS. This will be useful to those customers who do want to implement and debug NLMs of their own in C or C++. It is
irrelevant to those who program in NetBasic or Java, and it is likely to be ignored by vendors such as Oracle who implement major application systems as NLMs.
(4) Support for "preemptive" multi-threading is being added to the
NetWare OS. NetWare has always supported a robust facility for TRUE
multi-threaded applications; but it is NON-preemptive, because this
reduces the overhead for application systems. A preemptive option will be a useful "protection feature" for customer-written applications, because it reduces the possibility of their "hogging" the processor (CPU).
(5) Support for Oracle's network computing architecture. I don't know
the details of this, but "under the covers", at least, it will certainly involve a set of vendor-written NLMs. Most likely, one of them will be the Java "virtual machine", since the network computing architecture is heavily "Java flavored".
(6) CORBA. This is an industry standard for communication between
"objects" in both local (same machine) and remote (different machines)
environments. CORBA is considered to be an alternative to Microsoft's
proprietary standard for inter-object communication (COM/DCOM, also
known as "ActiveX" or "OLE"). This will undoubtedly be supported for
Java objects and probably for C++ objects as well. I won't try to
explain objects here - suffice it to say that objects are a basic
concept in a modern approach to programming that many people consider to be "more modular" and "more reliable" than the traditional "procedural" approach.
(7) Sun's Project Studio. This is a nifty "RAD tool" for developing
applications based on a robust set of pre-coded Java objects (which Sun calls "Java beans").
Note that Novell's whole approach to making NetWare/IntranetWare a good, useful "application server" (for the customer-written application area in which it is viewed as deficient) involves NO FUNDAMENTAL ARCHITECTURAL CHANGES. There are some incremental extensions to the OS (such as enhanced memory protection and preemptive multi-threading) - but some form of these existed already. Vendor-written NLMs will still be able to run as "OS extensions" (in a mode that is known technically as "Ring 0"), thus offering the highest possible performance. By this path, NetWare is evolving into something very similar to a "general purpose" OS, offering much the same facilities for application programs (including oodles of "protection"); but it is achieving this with an "unconventional design" - one that does not sacrifice the ultra high performance and inherent stability for which NetWare has long been famous!
-------------------------------
Regards
Salah |
