P1: c-161
SoftwareDesign WL040/Bidgoli-Vol III-Ch-24 June 23, 2003 16:25 Char Count= 0
TECHNOLOGIES FORBUILDINGWEBSITESOFTWARE 291The .NET Platform
The Windows .NET platform collection of technologies
was introduced by Microsoft as an alternative platform for
building Web software applications. Its goals and much
of the details of the technologies are similar to the J2EE
platform, and comparatively speaking, it is conceptually
easy for developers to move between the two platforms
(although there are large differences in the syntax and ter-
minology that describes the concepts) (Vawter, 2001). Mi-
crosoft .NET is partially based on the older Windows DNA,
a previous Microsoft platform for developing Web appli-
cations. Windows .NET includes many technologies that
were already being used, including Microsoft Transac-
tion Server (MTS) and COM+, Microsoft Message Queue
(MSMQ), and the Microsoft SQL Server database. The
.NET platform includes these technologies as is or in mod-
ified forms and adds a Web services layer on top.
Whereas the J2EE platform is based on the Java pro-
gramming language, .NET is intended to be language-
independent and is designed to allow components in
multiple languages to interoperate. Software components
within .NET can be written in languages such as VB .NET
(Visual Basic for .NET) or C#. C# is Microsoft’s new object-
oriented programming language and is very similar to
Java. C# programs are first translated into Microsoft Inter-
mediate Language (MSIL or IL). The IL code independent
of platform and is analogous to Java bytecode. One key
(only partially realized as of this writing) is for the IL to
be independent of language, thus multiple languages can
be translated into IL. If a translator is available to trans-
late a specific language to IL, the language is called .NET
enabled. The IL code is how .NET allows integration with
legacy software.
The .NET platform handles server-side processing in
a variety of languages, although the dominant language
is currently ASP .NET. Compiled modules are translated
into the IL and processed efficiently with a .NET server.
Traditional ASP was a scripted page technology and is still
the technology used within the .NET platform. The .NET
platform includes specialized components written at the
middle-tier layer, called managed components. The man-
aged components are supported by COM+, C#, or another
.NET enabled language and are used to implement busi-
ness logic. Database interaction is through the ADO .NET
interface.
A number of articles have compared J2EE with .NET
(Farley, 2000; Middleware, 2002; Sessions, 2001; Vawter,
2001). They are all informative but the perceptive reader
must take care to check the publisher, underwriter, or
author for bias. Although the referenced articles should
help the interested reader see more details, the differ-
ences can be summed up succinctly. As reported by
Farley (2000), the clich ́e is that “J2EE is language-
specific and platform-independent, and .NET is language-
independent and platform-specific.” This clich ́e is only
half true because J2EE applications can and do include
multiple languages (although most J2EE developers try
to avoid multiple languages for sound engineering rea-
sons) and many J2EE applications are restricted to sin-
gle platforms. Additionally, most .NET applications use
C# and the other built-in technologies so the language-independence has not, as yet, been widely taken advan-
tage of. Being newer, .NET has also improved on some of
the technical weaknesses of J2EE, including better XML
support and simpler deployment.XML as the Glue
A problem that software engineers have faced for many
years is that of passing data among software components.
The two components must agree on format, types, and or-
ganization. Web software applications have two unique
requirements for data passing, loose coupling and dy-
namic integration. The fact that the components are very
loosely coupled makes it more difficult for developers to
establish a priori standards. The developers may be sep-
arated by time and geography and be in separate, even
competing, companies. Web software applications also
use dynamic integration, which means that the software
engineers may not know which components will interact
when the software is written.
In the 1970s, data were usually stored as records in files
and the file formats were often not documented. If a new
program needed to read a file, the software engineer had
to deduce the file format by reading the source of the orig-
inal program if it was available. If not, the engineer would
usually induce the file format by trial and error—writing
programs to read and print strings from the file. In the
1980s, data were usually stored in memory as abstract
data types. They were saved in long-term storage in files,
and both the file input–output and access to the abstract
data type was managed by wrapper modules. Although
much improved over previous methods, this method was
usually slow, the developers of the programs had to agree
on the data format, types and organization, and maint-
enance was often challenging because it was not clear who
owned the wrapper module. These problems are exacer-
bated with Web software because of the extremely loose
coupling, dynamic integration, and heavy reuse and use
of third-party software components.
A solution from the World Wide Web Consortium
(2000) is XML, or extensible markup language. XML al-
lows data to be transferred between software components
in a way that is independent of type, self-documenting, has
an easy-to-understand format, and that can be parsed in
simple ways. XML stores data as plain text (UNICODE)
strings. Each string value is stored in between tags that
are meant to imply some semantics for the contents. For
example, the title for an encyclopedia article might be en-
coded as<Title>Software Design and Implementa-
tion in the Web Environment</Title>. This allows
XML to be used as the primary way to pass data back
and forth between Web-based software components. The
principal syntax rules (Sall, 2002) are as follows:The document must have a consistent, well-defined
structure,
All attribute values must be quoted (single or
double quotes <Title Type = "article">, not
<Title Type = article>),
White space in content, including line breaks, is signifi-
cant,