Introduction
Microsoft
and Sun's Confrontation
It's new - it's powerful - it solves lots of problems - and it
is threatening to a vast community of Java worshippers, and best (or worst) of
all it's from Microsoft. You guessed it right; I am talking about .NET.
Around 1995, Java was generating the same vigor as is generated
by .NET today. May be I am being a bit unfair; actually Sun's Java was a much
bigger event than .NET. My intention is not to belittle .NET's arrival; but
what's true is true! Sun's Java introduced a revolutionary approach of
software development. Previously you had developers specializing in either
Visual C++, or VB or Tcl/Tk (for UNIX based platforms). Finding an
individual who is conversant in various competing languages was next to
impossible. With Sun's Java - all that the programmers needed to know was a
single language - namely Java; thus Java provided the programmer's with a unique
tool that solved their ages long problem of platform independence.
Sun
furthered their service to the Computer Industry by tackling the issue of web
development with applets, JSP (Java Serve Pages) and Servlets. Then came Sun's
EJBs (Enterprise Java Beans). EJB brought an end to the painful era of
distributed application development. All this time when Sun was winning our
admiration; Microsoft was trying their level best to match up to Sun's tools. Although many of the technologies that J2EE use, were introduced by Microsoft (e.g. OLE/COM was present before EJB, ASP was developed before JSP etc.), but Sun's J2EE better many of these technologies and popularized them with their Java platform independence approach (with .NET Microsoft has done the same - namely - improved not only upon their existing technologies but on J2EE as well).
But Sun
was uncatchable. Sun's unique approach of "distributing it
free" helped them in gaining popularity amongst developers. Sun addressed industry's needs by developing or by enhancing tools
like JSP, Servlets, EJB, JMS, JNDI, JNI etc. Sun stuffed these excellent tools
under one umbrella - the Java2 Enterprise Edition (J2EE). Microsoft's equivalent to J2EE was Microsoft's Windows DNA programming model. DNA's popularity was marred by Microsoft's proprietary approach; while J2EE are a set of specifications, DNA is a Microsoft's propritery implementation. With the world depending more and more on the Internet - and
Sun's tools becoming the foremost media for the web applications, Microsoft
seemed to be loosing the battle. But Microsoft has a wonderful history of
starting late but catching up quickly (Windows vs. Macintosh,
Internet Explorer vs. Netscape ). So Microsoft put their best men at work and started calling
the project as Next Generation Windows Services (NGWS). The outcome of the
project is what we now know as .NET. .NET has borrowed most of it's ideas from
Sun's J2EE; but this time Microsoft has really outdone themselves. .NET
strengthen
many of the features of J2EE, and it also makes up for most of Microsoft's
mistakes.
A few months back when the hype of .Net (and C#) started, I
rejected the hype since I am more of a Java and Visual C++ lover. When it comes
to Web development or distributed application development I prefer Sun's Java,
Servlets, JSP and EJBs. And when it comes to Windows application, Microsoft's
Visual C++ is the tool of my choice. So my immediate reaction was - "Hmmm,
yet another of Microsoft's gimmick; I won't fall for this at all !!!". But
then I started reading about it and the more I read, the more I liked. It was as
if for the first time in Microsoft's history they have actually listened to our
cries. With .Net Microsoft isn't telling us how to do our job, but it is the
outcome of a thorough consideration of developer's feedback.
Programming in Visual C++ has always made be feel proud of
myself. Those of you who have used Visual C++ to develop OLE, COM, COM+, ActiveX
applications would know what I mean. Every time I make an ActiveX client/serve
or an ActiveX control, I get up from my computer fully satisfied
and content. But making a Java Bean never gives me that satisfaction -
simply because it's so damn easy !!!. With .NET Microsoft has made lots of
things even easier not only in comparison to their previous technologies but
even in comparison to Java.
When I started reading about .NET, I almost always came across
biased or one sided views. So rather than being swayed by Microsoft or
Sun's claims I decided to make my own opinion - and that is the prime
reason of writing this article.
The rest of this article delves deeply in .NET. The article
concludes with the future predictions made by the IT pundits.
The most
important question is What is .NET ?, and the simplest answer is : it is a
Framework in which Windows applications may be developed and run. I agree that this answer
does not tell much. In order to understand .NET we must go back in time and
follow the development of Windows and the advent of Windows programming.
Let's see how a traditional windows application works.
Windows provide the programmers with various functions - called
API. Starting from the very first time Windows enter the commercial market to
the latest version of WindowsXP, APIs are the basic tool to let the
Windows know what you want it to do. If you want to create a Dialog Box you must
call a specific API provided to you by Windows. Making a button requires another
API call. And the list goes on. As new GUIs appear on the seen, new APIs are
introduced in Windows. But using these native APIs was a very challenging task.
Making a simple Window that prints "Hello World" could take more than
hundred lines. Compare this to 5 lines of "Hello World" program in
DOS. Due to this difficulty, Windows programming was considered something better
left
to the experts. Microsoft and other commercial organization's realized this and
started marketing Visual Tools that made the programmer's life easy. Using
Visual C++, Visual Basic, Borland's C++ and other such IDEs, it became simpler
to make Windows programs.
Various vendors develop their own "Wrapper
classes" that wrapped the Windows APIs in an Object-Oriented way. The
Microsoft Foundation Classes (MFC) that are used in Visual C++, is an example of
Wrapper classes. The MFC equivalent of Visual Basic is VBRun; and for Visual J++
it is WFC. These Wrapper Classes, along with the Visual GUI tools made it
very convenient to make windows programs.
Microsoft realized that applications need a solid way to talk to
each other. And this resulted in the introduction of Object Linking and
Embedding (OLE). OLE was an extremely useful concept, but it had two major flaws
: It was
notoriously difficult to program, and it was very limited in its scope - i.e. it
only did a few things like drag and drop, clipboard sharing, OLE client, OLE
server etc. Microsoft addressed (or at least tried to address) both these
problems. They upgraded OLE to COM. COM was much more capable than OLE,
and it introduced new concept like ActiveX controls which directly competed with
Java Applets. As for the difficulty of programming OLE/COM; Microsoft expanded the MFC
and VBRun to take care of most of the dirty job. Although making an ActiveX
application still was slightly tricky in Visual C++, but developing an ActiveX
application in Visual Basic was extremely easy; and hence Visual Basic became
the foremost ActiveX development media.
The Internet revolution posed new problems and challenges. C/C++ which was the tool of
champions was not suited/ready for Web Development. Microsoft tried expanding MFC, and
included several network oriented classes - like CSocket, CASyncSocket, and
several HTTP based classes. Using these classes a programmer could very
develop a distributed application - although not without considerable effort.
But these applications were always customized and targeted to the specific task.
The developers had to take care of the gory network communication details
themselves. By now object-oriented analysis and development had started becoming
ubiquitous. Although technologies like Remote Procedure Call (RPC) was a great
help to the programmers; but it was limited in its scope. With programmers
following the Object-Oriented development RPC was not much help at all; since
RPC did not allow passing objects as parameters. This major issue was addressed
by introduction of industry's agreed upon standards like CORBA, IIOP, RMI, DCOM
etc. All these standards used customized protocol to transmit an object over the
network, and they required a tight coupling between the server and the client -
i.e. the client needed to be fully aware of how to talk to the server. Due to
this tight client-server coupling all these protocols needed considerable
deployment efforts in order for distributed applications to function properly.
Sun did come up with another layer on top of RMI - the famous Enterprise Java
Beans (EJB). The EJB container provided lot of services for free - all that a
programmer had to do was to extend (inherit) from an appropriate EJB base class
and there you have it - a fully functional distributed application. EJB made
programmer's life extremely easy; but it did not eradicate the client-server
coupling issue.
While all this was happening - Microsoft was still not facing
the writing on the wall - MICROSOFT NEEDED SOMETHING RADICALLY NEW TO
MATCH UP TO THE CHANGING TIMES AND CHANGING DEMANDS. Microsoft soon realized
that upgrading their existing technologies would not work - what they needed was
a complete change in their philosophy. OLE was upgraded to COM - and it was
welcomed by all. COM was then upgraded to COM+. Microsoft addressed the
distributed programming issue with the introduction of DCOM. Although
COM/COM+/DCOM were all good technologies but these technologies required
significant learning curve. Sun on the other hand was making things easier and
hence a majority of developers were turning towards Java based technologies for
distributed enterprise applications.
Microsoft - after the cold treatment faced by DNA - got their
gurus together and asked them to reflect back on DNA and to come up with a
future vision. This group came up with so many new and great ideas which made
Microsoft realized that no amount of up gradation or extension in MFC/VBRun/WFC,
COM/COM+/DCOM, ASP, APIs etc. would even come closer to realizing this new
vision. So they made a radical but correct decision - and this was the decision
of coming up with something big, something new, and something that lets
Microsoft make up for their lapses - this was called the .NET Framework.
The remaining portion of this article discusses a few of the
main features and components of .NET framework. After having introduced .NET in
brief I'll conclude this article by answering the million dollar question -
"What is .NET ?"
This article assumes that the reader has a solid programming
experience. IT also assumes some experience of JAVA. Although experience of RMI,
EJB, ActiveX, VC, VB is not required but having an introductory knowledge of
these tools would help appreciate .NET better.
go to top
The diagram given below describes various components of .NET
Framework[3]
Now we explain these components briefly...
The .NET framework can only be exploited by languages that are
compliant with .NET. Most of Microsoft languages have been made to fully comply
with .NET.
.NET also introduces Web Forms, Web Services and Windows Forms.
The reason why they have been shown separately and not as a part of a particular
language is that these technologies can be used by any .NET compliant language.
For example Windows Forms is used by VC, VB.NET, C# all as a mode of providing
GUI.
The next component of .NET is the .NET Framework Base Classes.
These are the common class libraries (much like Java packages) that can be used
by any .NET compliant language. These classes provide the programmers with a
high degree of functionality that they can use in their programs. For example
their are classes to handle reading, writing and manipulating XML documents,
enhanced ADOs etc.
The bottom most layer is the CLR - the common runtime language.
The CLR is discussed in detail in [7].
go to top
One of the obvious themes of .NET is unification and
interoperability between various programming languages. In order to achieve
this; certain rules must be laid and all the languages must follow these rules.
In other words we can not have languages running around creating their own
extensions and their own fancy new data types. CLS is the collection of the
rules and constraints that every language (that seeks to achieve .NET compatibility)
must follow. Microsoft have defined three level of CLS compatibility/compliance.
The goals and objectives of each compliance level has been set aside. Given
below are the three compliance levels with their brief description:
COMPLIANT PRODUCER
The component developed in this type of language
can be used by any other language.
CONSUMER
The language in this category can use classes
produced in any other language. In simple words this means that the language
can instantiate classes developed in other language. This is similar to how
COM components can be instantiated by your ASP code.
EXTENDER
Languages in this category can not just use the
classes as in CONSUMER category; but can also extend classes using
inheritance.
Languages that come with Microsoft Visual Studio namely Visual
C++, Visual Basic and C#; all satisfy the above three categories. Vendors can
select any of the above categories as the targeted compliance level(s) for their
languages.
go to top
CLR is .NET equivalent of Java Virtual Machine (JVM). It is the
runtime that converts a MSIL code into the host machine language code, which is
then executed appropriately. [7] gives a detailed description of CLR.
go to top
A .NET programming language (C#, VB.NET, J# etc.) does not
compile into executable code; instead it compiles into an intermediate code
called Microsoft Intermediate Language (MSIL). As a programmer one need not
worry about the syntax of MSIL - since our source code in automatically
converted to MSIL. Complete specifications of MSIL can be found at http://msdn.microsoft.com/net/ecma/part_3_IL_inst_set.pdf
. The MSIL code is then send to the CLR (Common Language Runtime) that converts
the code to machine language which is then run on the host machine[7]. MSIL is
similar to Java Byte code. A Java program is compiled into Java Byte code (the
.class file) by a Java compiler, the class file is then sent to JVM which
interprets it and runs it on the host machine.
go to top
All this time we have been talking about language
interoperability, and .NET Class Framework. None
of this is possible without all the language sharing the same data types. What
this means is that an int should mean the same in
VB, VC++, C# and all other .NET compliant languages. Same goes for all the other
data types. This is achieved through introduction of Common Type System (CTS).
CTS, much like Java, defines every data type as a Class. Every .NET compliant
language must stick to this definition. Since CTS defines every data type as a
class; this means that only Object-Oriented (or Object-Based) languages can
achieve .NET compliance. Given below is a list of CTS supported data types:
Data Type | Description |
System.Byte | 1-byte unsigned integer between 0-255 |
System.Int16 | 2-bytes signed integer in the following range:
32,678 to 32,767
|
System.Int32 | 4-byte signed integer containing a value in the following
range:
-2,147,483,648 to 2,147,483,647
|
System.Int64 | 8-byte signed integer containing a value from
-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807
|
System.Single | 4-byte floating point. The value limits are:
for negative values:
-3.402823E38 to - 1.401298E-45
for positive values:
1.401298E-45 TO 30402823E38 |
System.Double | 8-bytes wide floating point. The value limits are:
for negative values:
-1.79769313486231E308 to - 4.964065645841247E-324
for positive values:
4.964065645841247E-324 to 1.79769313486232E308 |
System.Object | 4-bytes address reference to an object |
System.Char | 2-bytes single Unicode Character. |
System.String | string of up to 2 billion Unicode characters. |
System.Decimal | 12-bytes signed integer that can have 28 digits on either
side of decimal. |
System.Boolean | 4-Bytes number that contains true(1) or false (0) |
go to top
Lets look at the following Visual C++ code extract.:
CView
myView;
myView.MessageBox("Hello
World", ".Net Article", MB_OK);
::MessageBeep(MB_ICONHAND);
The code above first creates an object of CView
. u is a
built in MFC class. In second line the code calls CView
method MessageBox()
to
show a dialog box containing an OK button and a "Hello World" message.
The caption of the dialog box is ".Net Article". In the third line the
program makes a direct call to a windows API, the scope resolution symbol
"::" before a method indicates that it is a direct API call.
MessageBeep()
uses a system defined wave file "
MB_ICONHAND
" to play
the appropriate sound. The above three lines uses two different types of
functions - one that the MFC provides and the other that the Operating System
provides. Remember that MFC is nothing but a group of wrapper classes that
encapsulate APIs. You can totally bypass MFC and develop an application solely
using APIs. How about writing the same code in Visual Basic ?. The MFC
equivalent of Visual Basic is VBrun. Although you may be able to use the
MessageBeep()
API in VB; but the Class
CView
does not exist in VBRun. You will
have to learn VBRun in order to use an equivalent of
CView
. The same holds for
other programming languages; and to further complicate the situation various
vendors have their own names and hierarchy of the wrapper classes. What this
means is that MFC is Microsoft wrapper classes for C++; Borland has their own
wrapper classes. Same goes for Java. Microsoft provides a powerful wrapper
classes package named WFC to be used with Visual J++, other vendors have
their own wrapper classes.
In addition to this, if your application uses a COM component
then you code would look radically different in different languages - this is
because different languages have different implementation of COM, and have
different data types. Given below is an extract of a COM component code (this
has been taken out from SMTP.Server application). The
code below returns a String. But in the world of COM, there is no string data
type; instead the equivalent is "BSTR
". The MFC implementation of
string is the class CString
(very similar to String class in Java). CString
provides a function AllocSysString()
that does the necessary conversion to
BSTR
.
BSTR CServer::GetCcTo()
{
return m_strCcTo.AllocSysString();
}
Now if a COM component was to be developed in VB. The above code
would need to go through serious changes. Based on the above discussion we come
to the following conclusion :
Every Windows application language has their own implementation
and interfaces for the following:
-
COM Components,
-
Operating System Specific APIs (e.g. Win32API, Win16 API,
Windows CE APIs)
-
Wrapper Classes (e.g. MFC, VBRun, WFC)
The above mentioned differences create unnecessary work
for a programmer; and hamper interoperability between various languages.
Many Visual C++ programmers are reluctant to learn Visual Basic
despite the fact that VB is much easier than VC. Although VC applications are
faster, and this may be the reason why programmers may prefer VC, but in case of
a simple COM component the increased productivity in VB more than make up for a
slight penalty in speed. Personally I prefer to stick to VC, mainly because of
the fact that I will have to learn VBRun, VB specific data types, and VB
specific COM implementation. It would be great if VB and VC had common
data types, and if MFC was also present in VB. This would reduce my learning
curve to almost none, and would encourage thousands of programmers like me to
embrace VB.
There is another problem with existing COM implementation. While
a COM component can be used in many languages irrespective of how they were
developed. These components can not be extended/inherited from. I have always
fancied the very idea if being able to inherit/extend from a COM component.
Unfortunately it is not (at least up till now) possible unless you have an
access to the source code of the component. So the need of the hour is :
-
A Common wrapper class implementation
-
A Common Data Type system
-
Ability to inherit/extend from COM Components.
And the solution to all this is - .NET Class Framework. Those of
you who are familiar with MFC/VBRun/WFC can look at this framework as a group of
wrapper classes that are shared across VC, VB, and any other .NET compliant
language (a language that follows the Common Language Specifications
"CLS" - set forth by Microsoft). So now we all have to learn
only one Class Framework and can use it whether we are working in VB or in VC or
in any other CLS compliant language. An important terminology related to
.NET Framework is Namespace. Since you would frequently come across this
term in any .NET article; its good if we formally define it. Namespace is a
logical grouping of related interfaces, structures and classes. Java programmers
are familiar with the package concept. The namespace is very similar to the
package concept. A Namespace may contain further namespaces. This would result
in a tree like hierarchical structure. .Net Class Framework is nothing but a
hierarchical structure of namespaces. In .NET Class Framework "System"
is the starting namespace. A few other namespaces within System are
System.Security
,
System.Data
,
System.Console
,
System.WinForms
etc.
If you want to program a .NET application you will have to learn
.NET Class Framework; just as a Java programmer learns the basic package
hierarchy (e.g. java.util, java.lang, javax.servlet etc.).
go to top
Web services is an extension of ActiveX. Those of you who have
used ASP and JSP both, know the apparent shortcomings of ASP. JSP has been
enriched with the concepts of Beans and Tags. ASP equivalent for Beans and Tags
was ActiveX Controls and ActiveX automation servers. Let me take a minute to
explain this point a bit further. Web Services is NOT a Microsoft proprietary
standard. It is a W3Consortium standard, and has been developed by Microsoft,
IBM and many other big names of the industry.
Functions are of two types. The ASP built-in functions, and the
programmer defined/implemented functions . In order to use the built-in
functions you just need to pass the appropriate parameters and make a simple
call to these functions. The functions are implemented by the ASP itself. The
string manipulation functions, Number conversion functions are an example of
built in functions.
The programmer defined functions are the functions that are
defined and implemented by the programmer. A programmer can either write these
functions in the same asp file or can write them in another file. If the
function code resides in the same asp file then the programmer can directly call
that function. In case the function resides in another file , say "func.asp";
then the programmer needs to include that file by writing a statement like
<!-- #include file="func.asp" -->
; and now the programmer can
use the function. The programmers can also make ActiveX automation servers, and
call various function of these ActiveX servers. But one limitation is very
obvious --
no matter which type of function you use, the function MUST
physically reside on the same machine. For
example your ActiveX automation server must be implemented either as a
.dll
or as an
.exe and then must also be registered in Windows Registry before
an asp code can call its functions. (you may
download
SMTP.Server - an ActiveX component developed by the author - to get a better
idea of how to use an ActiveX component from you ASP/VC/VB code.) In a world
where the Internet has become not only a necessity but also a way of life - it
is obvious that this limitation is a strong one. Microsoft's answer to this
problem is
"Web Services". The idea goes something like this :
-
The Web service provider develops a useful function(s), and
publish/advertise it. The Web Service provider uses Web Service
Description Language (WSDL) standard to describe the interface of
the function(s). This is much like the Type Libraries (TLB) and Object
Description Language files (ODL) that needs to be generated with the ActiveX
automation servers.
-
The programmer/client who needs the function does a lookup
by using a process called - Web Service Discovery or SOAP Discovery
(also called DISCO for Web Service DISCOvery)
-
The Actual communication between the client program and the
web service takes place through a protocol called Simple Object Access
Protocol (SOAP) - SOAP is an XML based light weight protocol used
for communication in a decentralized distributed environment.
As is evident from the above discussion that at the heart of all
the communication is XML. Both SOAP, WSDL leverage on XML.
We have all either used or at least heard of network
communication protocols like RPC (Remote Procedure Call); RMI (Remote Method
Invocation), CORBA, DCOM, IIOP. All these technologies have the same purpose -
to enable calling a function/Object on a remote machine. So
how is Web Service (or SOAP) any different than these existing technologies ? .
The main difference is that SOAP uses HTTP/HTTPS protocol; unlike all the other
technologies that uses specialized protocols for distributed communication.
Microsoft, with this simplified approach has tried to bring sanity and
unification to the world of distributed programming. Distributed applications
are heavily dependent on JNDI lookups, RMI, CORBA, IIOP, Serializability and
other intricacies. With Web Service and .NET development tools ; Microsoft have
provided us with a much simpler way of developing distributed applications. So
what is the catch ?. The obvious catch is that this is an ASP.NET specific
technology (at least for now); but with time SOAP, WSDL, DISCO will most
certainly gain wider acceptance.
According to Microsoft's tests an application developed ASP.NET
using ADO.NET and Web Services, is many times more efficient than an
equivalent application developed in JAVA, JSP, Servlets and EJBs. [1]
Note that .NET has no direct equivalent of EJBs. So considering
Web Services as an equivalent to EJB will be in correct. However some of the
functionality of an EJB can be provided by Web Services.
With .NET, Microsoft has followed one guiding principle - make
it as simple as possible. And Web Services is no exception to this ideology.
See the example below and judge for yourself as to how easy it is to develop a
Web Service. And compare this with how "EASY ?" it was to develop an
ActiveX automation server; or how "easy ?" it is to develop an EJB.
Web Service Example
Open any text editor and type in the following Visual Basic code,
and save the file under ".asmx" extension.
Imports System
Imports System.Web.Services
Imports Microsoft.VisualBasic
Public Class HelloWorld : Inherits WebService
Public Function <WebMethod()> GreetTheUser(strUserName as String) as String
Select Case strUserName
Case "Kashif Manzoor"
return "Hello Author"
Case "Amna Kashif"
return "Hello Ms. Amna Kashif"
Case "Ahmed Luqman"
return "Hello little Ahmed"
Case Else
return "Hello Stranger"
End Select
End Function
End Class
The first three lines import needed Classes. Import is similar
to the import used in Java or the #include in C/C++. The rest of the code is
self explanatory. Notice that the Class extends/inherits from the built in Web Service
class; this is mandatory. Also notice that the Function is declared
with the key word <WebMethod()> this indicates that this function
can be invoked from the web across the Internet. You may add other private
functions in your class but those functions will not be accessible to outside
word.
So that's it !!! you have successfully made your first Web Service. Although the service simply takes in a name and returns a greeting;
but it is enough to give you a flavor of Web Services. This Web Service can now be
accessed from your ASP.NET code. This article does not intend to explain either
ASP.NET or Web Services in details , the interested reader should consult ASP.NET
manual or visit MSDN site for more details.
Deploy your ".asmx" file on Web Service aware
Application Server like IIS. And open up a Web Service aware browser like IE.
Type in the appropriate URL for the file. If the file is in the default web
application folder then the URL would be "http://localhost/HelloWorld.asmx".
What do you think would happen ?. You will see a well formatted web page, giving
you the details of the GreetTheUser()
method. And at the bottom of the page you
will be given an edit box, where you can enter the "strUserName" and
then press a button beside the edit box. Once you do that, you will receive the
greeting string as an XML document. This is a new and a wonderful
feature.
Lets not be unfair with Sun's technologies here. Making an EJB
(at least a stateless and stateful EJB) is no more difficult than the above
example. What makes EJBs tricky is the deployment, the JNDI lookups, the Stubs and
the application servers that support EJBs. With Microsoft's "click and
ready to go" approach and easy to use utilities that come with Visual
Studio.NET, deploying any of .NET application is extremely easy.
In conclusion Web Services is an evolutionary idea as opposed to
being a revolutionary idea, its
just an other distributed development tool - which happens to be extremely
simple to use. Incorporation of Web Services in ASP.NET, has taken ASP to a new
level of respectability. Web Services has already started gaining popularity and
is also incorporated in the Java platform. Visit http://java.sun.com
to get the latest on Web Services support in Java platform.
go to top
Just as the Win Forms provide a unified way of developing GUI for
desktop application, the Web Forms provide similar tool for web applications.
Web Forms has been introduced in .NET as a part of ASP.NET. Web Forms are a
forms engine, that provide a browser-based user interface.
To appreciate Web Forms you may consider how GUI is rendered in
current Web applications. The GUI is rendered by using HTML tags. (e.g.
<input
type=text name=editbox1 maxlength=10 size=10 >
, will draw an edit
box on the web page) Web Forms can also have the intelligence to use HTML,
DHTML,WML etc. to draw the controls on the web page based on the browser's
capabilities. Web Forms can also incorporate the logic behind these controls.
Its like hooking up the code to a GUI control. Just like in your VB application,
you can associate a code with a button on the web page, this code will be run on
the server when the button is pressed. This is in contrast to the scripts that
run on the clients when a button is pressed. This approach is different to the
Java approach. In Java a programmer can simulate this functionality through JavaScript
and Servlets. But with Web forms this is done transparently. A Java programmer
may consider as if each HTML control has its dedicated "Servlet"
running in the background. Every time the control receives any event of interest
(e.g. button pressed, selection changed etc.) this specific "Servlet"
is called. This results in much cleaner code and an excellent logic separation
between presentation and business logic layers.
Web Forms consist of two parts - a template, which contains
HTML-based layout information for all the GUI elements and a Component which
contains all the logic to be hooked to the controls or GUI elements. This
provides a neat presentation layer and application logic layer separation.
The GUI will be rendered on the client side, while the code that
has been hooked to the GUI elements will run on the server side (very much like
a button being pressed on a JSP and a Servlet being called in response. But with
Win Forms this has been made extremely easy). The incorporation of Web Forms in
ASP.NET is an attempt to take ASP to a new level where it can seriously
challenge JSP.
Another good feature of Web Forms is that it can be built to
have enough intelligence to support a vast variety of browsers. The same ASP
page would render itself using DHTML, if the browser is IE 5.5. but if the
browser is Netscape the web page will be rendered using HTML tags; if the
page is being accessed through a WAP device the same page will render itself
using WML tags.
One of the obvious disadvantage of ASP over Java was that there
was that an ASP code was a maintenance nightmare. While a Java programmer can
use Java Beans, Tags and also Servlets to achieve presentation and business
layer separation - no such mechanism was present to a ASP programmer. With
ASP.NET Microsoft has provided such presentation-business layer separation - by
introducing the concept of Web Forms:
- ASP.NET Web Forms provide an easy and powerful way to build dynamic Web
UI.
- ASP.NET Web Forms pages can target any browser client (there are no script
library or cookie requirements).
- ASP.NET Web Forms pages provide syntax compatibility with existing ASP
pages.
- ASP.NET server controls provide an easy way to encapsulate common
functionality.
- ASP.NET ships with 45 built-in server controls. Developers can also use
controls built by third parties.
- ASP.NET templates provide an easy way to customize the look and feel of
list server controls.
- ASP.NET validation controls provide an easy way to do declarative client
or server data validation.
For those of you (like me) who turned to Java for web
development mainly due to spaghetti code of ASP- ASP.NET is worth exploring.
Since it introduces some exciting new ways to write clean code (Personally I
find Web Forms an exciting new concept - that does not have a direct equivalence
in Java platform)
go to top
Windows forms (also called Win Forms) are used to create GUI for
Windows desktop applications. The idea of Win Form has been borrowed from Windows
Foundation Classes (WFC) which were used for Visual J++. Win Form provide an
integrated and unified way of developing GUI. It has a rich variety of
Windows controls and user interface support.
Numerous classes and functions were used by programmers to
handle GUI. MFC in VC++, direct API in C++ and VB Forms Engine in VB are just a
few examples of different ways of handling GUI.
Simply put - Win Form is just another group of wrapper classes
that deal specifically with GUI. Win Form classes encapsulate the Windows
Graphical APIs. Now the programmers would not need to use the Windows Graphical
APIs directly; and since Win Form has been made a part of .NET
Class Framework; all the programming languages would use the same Win Form classes. This would rid the programmers of the need to learn different GUI
classes/tools. Win Forms in the part of the namespace
System.Winforms
.
With Win Forms we can make a single user interface, and use it in
VC++, VB, C#. Using Visual Studio.NET simply design the GUI, by dragging the
controls on a form (something that all VC++ and VB programmers are well familiar
with). Now you can use the same form either in VB, VC++ or in C#. And this is
all made possible because Visual Studio.NET uses the System.Winforms
namespace to draw the GUI. And any language that has the appropriate CLS
compliance can use this form directly.
go to top
Sun intended to present JVM - as a single language virtual
Machine. Meaning that only a Java program can be converted to a byte code
(.class file) and then presented to JVM, which interprets the programs and runs
it on the host machine. Although In concept, any language can be compiled to
Java Byte code and then fed to JVM; but Sun did not encourage such approaches.
Despite Sun's lack of initiative in this regard many researchers and companies
have developed languages following this approach. Sun's vision of Java being
"One language fits all" has both its advocates and its
critics[5]
With CLR, Microsoft has adopted a much liberal
policy. Microsoft has themselves evolved/developed/modified many of their
programming language to be compliant with .NET CLR.
Although
Visual C++ (VC++) , has undergone changes to incorporate .NET; yet VC++ also
maintain its status as being a platform dependent programming. Many new MFC
classes have been added; a programmer can choose between using MFC and compiling
the program into a platform specific executable file; or using .NET framework
classes and compile into platform independent MISL file. A programmer can also
specify (via directives) when ever he uses "un-safe" (the code that by
passes CLR - e.g. the use of pointers) code.
ASP, is another
language that has been improved markedly. Most programmers know that ASP did not
measure upto JSP; Microsoft has tried to turned the tables by introducing
ASP.NET. ASP.NET makes extensive use of Web-Services. Web-Services is an open
standard and JSP can use Web-services (Sun's official web site gives a detail on
Web services and how that are being incorporated in Java platform). There are
many other features that have been introduced in ASP.NET, to make it an ideal
distributed programming tool and to measure up against JSP. ASP code within
<% %> tag, is compiled into .NET Framework (similar to JSP code being
compiled into a servlet). This approach is different than how the <% %>
was handled in ASP ASP.NET has been enhanced by Microsoft.
Out
of ALL .NET languages, Visual Basic.NET (VB.NET) is one language that has
probably undergone the most changes. Now VB.NET may be considered a complete
Object-Oriented Language (as opposed to its previous "Half Object Based and
Half Object Oriented" status).
Microsoft has also
developed a brand new programming language C# (C Sharp). This language makes
full use of .NET. It is a pure object oriented language. A Java programmer may
find most aspects of this language to be identical to Java. If you are a new
comer to Microsoft Technologies - this language is the easiest way to get on the
.NET band wagon. While VC++, and VB enthusiast would stick to VC.NET and VB.NET;
they would probably increase their productivity by switching to C#. C# is
developed to make full use of all the intricacies of .NET. The learning curve of
C# for a Java programmer is minimal. Microsoft has also come up with a The
Microsoft Java Language Conversion Assistant - which is a tool that
automatically converts existing Java-language source code into C# for developers
who want to move their existing applications to the Microsoft .NET Framework.
Microsoft
has also developed J# (Java Sharp). C# may be similar to Java, but it is not
entirely identical. It is for this reason that Microsoft has developed J# - the
syntax of J# is identical to Visual J++. Microsoft's growing legal battle with
Sun over Visual J++ - forced Microsoft to discontinue Visual J++. So J# is
Microsoft's indirect continuation of Visual J++. It has been reported that
porting a medium sized Visual J++ project, entirely to J# takes only a few days
of effort.
Microsoft encourages third party vendors to make
use of Visual Studio.Net (launched on Feb 13, 2002). Third party vendors can
write compilers for different languages - that compile the language to MSIL
(Microsoft Intermediate Language). These vendors need not develop their own
development environment. They can easily use Visual Studio.NET as an IDE for
their .NET compliant language. A vendor has already produced COBOL.NET that
integrates with Visual Studio.NET and compiles into MSIL[3]. Theoretically it
would then be possible to come up with Java compiler that compiles into MSIL
instead of Java Byte code; and uses CLR instead of JVM. However Microsoft has
not pursued this due to possible legal action by Sun.
go to top
Although the Beta of Visual Studio.Net has been around for over
two years; it was officially launched on Feb 13, 2002. The future of .NET is
very promising. With .NET Microsoft has diverged from their age-old philosophy
of "proprietorship". Microsoft has always been coming up with good
tools - which unfortunately have used proprietary technologies. One reason of
unpopularity of DNA, COM, DCOM was that they were all based on proprietary
Microsoft binary format. Microsoft has learned from its mistakes; .NET has a
foundation of ASCII based XML. Microsoft submitted C#, and CLI for standardization
to ECMA which on December 13, 2001, ratified the C# and Common
Language Infrastructure (CLI) specifications into international standards.
The ECMA standards will be known as ECMA-334 (C#) and ECMA-335 (the CLI). There
is also a technical report on the CLI which will be known as ECMA TR84. In
addition, ECMA approved the fast-track motion of these specifications to ISO.
This is a huge step toward the Microsoft .NET Framework being widely accepted by
the industry.
As of now, CLR is only available on Windows
platform. .NET can only challenge Java, when the CLR becomes available for other
platforms. Corel is working on a "Port Project" - that aims to port
.NET framework to LINUX. Another company by the name of XIMIAN is also working
on a similar project named - "Mono". With third party projects like
these - we would soon have .NET versions for various non-Windows platforms.
In
future we would probably see J2EE and .NET chasing each other with no single
technology ever being able to replace the other. Historically Microsoft platform
is considered inappropriate for enterprise solutions - whereas it is
considered perfect tool for standalone applications. Java platform on the other
hand, has always been considered suitable for Enterprise applications, and has
been considered slow and at times inefficient for standalone applications. With
the healthy competition between Java and .NET we would probably see much better
application platforms. As a programmer - we stand to loose nothing. Whether .NET
gains more acceptance than J2EE or vice versa - the programming aspects remain
the same. Whether you program in C# or, Java or J# - the syntax (essentially)
remain the same - and with the similarity between the .NET and Java framework
classes it would take an average programmer only a month or so to switch from
one to another.
It is the author's opinion that .NET should
be treated as a valuable addition to a programmer's toolbox. In .NET we have
another tool at our disposal, how we use it, and when we use it is subject to
our discretion.
go to top
References:
The author would love to hear
your comments/suggestions/criticisms regarding this article. Products and technology names
used in this article are registered trademarks of the respective
developers/owners.
I have 8 years of industry experience and am currently pursuing my graduate studies at University of Illinois at Urbana Champaign.