|
http://in.geocities.com/rsramsam/coverstory.htm |
ASP.NET .THE JEWEL IN DOTNET CROWN
by
R.S.RAMASWAMY
( published as Cover-Story in DeveloperIQ…
Feb-2004)
---------------------------------------------------------------------------
The Best Feature of DotNet is
ASP.NET and
it's WebForm
& WebService technologies. WebForm
technology is excellent and a tremendous advance. XML webservice
also is a fine technology. These two technologies enable Microsoft programmers to continue to
code in their own language and yet expose their service to other platforms
through SOAP. Java programmers need not lose heart because, despite the
surprising lack of confidence in many of them , very sound in Java but fearful of C# as yet
another language to be learnt! any Java programmer can
immediately understand C#. But, people who do all their work in VB or even
VC++, may find the transition to C# and Java , a bit
difficult! So, it will be advisable for students to learn as much as possible
of Java and simultaneously see how the same job is done in C#. They will find
it delightfully similar and also gain insights. Every one should learn ASP.net using C#( yes! even
J2ee programmers). They should learn to appreciate its programmer- friendly
features. Those who are capable of contributing to development of programming
tools should strive to create equally friendly software in Java.
How about the J2EE camp? Java Server Faces , a technology similar in intent
to webforms is to be released shortly and webservice also has already been created.
But , ASP.net is much more elegant in its implementation of
these two technologies and is definitely more programmer-friendly, even without
the VisualStudio.
There are some
security problems yet to be solved in XML WebService,but
it unifies the Language-agnosticism of Microsoft and the Platform-agnosticism
of Java world. J2EE is best suited for
For a true appreciation of this assertion, we need to go back to the developments
in Windows world since 1990.Any critical comments here should not be seen as
biased Microsoft-baiting but facts which any experienced Microsoft programmer
will agree with. After all , let us not forget that ASP.net and C# were
developed by Microsoft to fill up a gap. And does not Microsoft now expect
every programmer to forget the past and adopt the new technology? If every
thing had been fine with the legacy, why should they bother, to invent a new
technology with so much effort and expenditure? The same thing holds good for
J2EE camp also. There are deficiencies in their offerings too and there is a
continuous effort to improve. The Ultimate solution is still far off. Let us
now see the events which led to all this leap-frog race.
------------------------------------------------------------
During the decade from 1990 to 2000, so many changes occurred in Windows
world. For one, Visual Basic
introduced in 1990, gradually matured into a powerful development platform of
unparalleled ease with VB6.When first introduced, it was described by many
Windows SDK programmers as a stunning miracle!
So
many versions of Windows such as Windows3.1,Windows-NT, Windows-95, Windows-98
, Windows-ME, Windows-XP and Windows-2000 were offered in quick succession.
COM/DCOM was offered as the
recommended solution for Distributed Computing. ActiveX Technology in the form of ActiveX
components, controls and containers was offered. An entire generation of
programmers grew on the strength of Visual Basic coupled with powerful ActiveX
controls. Till 1995, Microsoft grew from strength to strength and became a
monopoly in Desktop.
When Java was released in 1996, Microsoft
was one of the earliest licensees of the technology from Sun! Why?
From 1990 onwards, COM had been the
mainstay of all development work in Windows world. COM was a binary standard.
It was language-neutral (ie) a COM component can be
written in any language in Windows platform and once it is compiled into a
windows-compatible format, and registered in Windows registry, it can be used
in any other program, written in any language. But, primarily, it was possible
only in Windows platform.( Though , theoretically , it could be adopted in DEC unix too, but it never caught on.)
COM was primarily, a solution for
inter-process communication,
within windows. When it was first
introduced, it was known as OLE Document technology.(Object linking and
embedding).(ie) how to embed an Excel chart in a Word
document and also provide for features like linking and in-place editing. It is
evident that here we are dealing with two different processes. This entailed
Marshalling and unmarshalling of parameters. This in
turn required Microsoft's version of Interface Definition Language.(IDL).
In an earlier part of this tutorial, we had
seen the primary requirement of
( or proxy & stub files in Microsoft parlance).
COM objects can be written in any language but should
be compiled according to Microsoft
compiler layout. Thus, COM/DCOM was platform-dependent.
So
long as Microsoft was thinking of Desktop only, COM was no problem at all.
Still, as any one who has worked with Microsoft Windows SDK , and MFC will testify,
they were not among the easiest or most elegant
of languages to learn! With all that Hungarian notation thrust on the
programmer by the wizard and the company's coding standards, it was rather the
exact opposite! The 'Arcane' and unnecessary grammar of Windows SDK and even
MFC cannot go unnoticed by VB and C#
programmers. With CFrameWnd
,CWinpp & CButton etc,
it was enough to make the programmer 'sea-sick' as an author once remarked, in
a lighter vein. If you wanted a font, you had to specify 14 parameters! 'No
default behavior, thank you!'.Try creating a button in MFC by coding, without
specifying all the details about the style of window, ( that it is a child
window and should be visible- as if anyone wants a button to appear as invisible to begin with ), and the
rectangle's dimensions for the button,etc.The famed wizards of Visuall
C++ , were in fact a necessity rather than an embellishment.For,
it is a moot point, how many programmers would have gamely stuck to raw WindowsSDK and MFC
if Microsoft had not offered them , its Resource editors and wizards. As
DON BOX, a co-creator of SOAP , (the root feature of
ASP.net) jocularly remarks, there was a time when windows wiz-kids were more
interested in creating buttons of irregular shape than in interacting with
Microsoft grew and prospered MOSTLY because of VB and the wizards.
The wizards with the drag and drop feature,
concealed much of the ungainly features and dependencies of the VC++ world. If
this was the case with simple MFC, COM was only much more difficult. To write a
simple COM component in raw C++ was and
still is a challenge to even
seasoned Windows hands. Microsoft then came out with MFC-COM wizard. But, this
was not a suitable solution , for downloading COM controls from the web was a ver heavy process and time-consuming. So, they introduced
ATL and a whole new set of naming conventions and variable types such as
VARIANT, SAFEARRAY and BSTRING, making the scene even murkier. For programmers
accustomed to creating COM components using the VB wizard, all this may sound
as mere mud-slinging! But, let them forget VB and its wizards for a while and try to do some really complex work in raw
COM to see how tortutous the environment was.And
on top of it all, MFC and WindowsSDK were not
standard C or C++ but proprietary extensions. The more of an expert you were in
Windows SDK and MFC, the less you were capable of doing any work in ANSI
C/C++ and Unix world.
MFC programmers will remember the use of
Dialog editor, Menu Editor etc. These editors made the job slightly
easier for the programmer , but behind the scenes , they created a Resource
script which was just a text file & proprietary and could be compiled
only by Microsoft's script compiler! How
could it be claimed then that we were doing C/C++ gui
programming? And how about those MACRO's? A great
variety of arrows,dots,double quotes,angle
brackets,header files,resource
scripts, underscores, semicolons, double
semicolons, stars!!Just compare the clean syntax of Java AND NOTE THAT IT HAS BEEN
ENTIRELY ADOPTED IN C#.
Microsoft has painstakingly created a huge class library and very much
wants to do away with legacy COM,Registry and windows API. The practice of using WindowsSDK through pInvoke also is not recommended. The most pressing need for
traditional Windows programmers now is to unlearn most of what they know and
switch over to C# paradigm...(ie) Java idiom!
When Java came in 1996 with its
AWT, even Microsoft was happy!
That is why it got license for the
language. Moreover, Java offered
Automatic garbage collection and freedom
from pointer-caused errors.
And
it also so happened that Microsoft Java
compiler automatically
lent itself to COM binary layout. Creating
COM components without
using wizards became a breeze, instead of
being bizarre, for the first time. We have only to go through the online documents of Visual J++ , (which included the
book by the creator of Java , JAMES GOSLING),
to realise , how much Microsoft was captivated by
Java. Any Java class is automatically a javabean if compiled with jdk and
it becomes a COM component if compiled with Microsoft java compiler and
registered in Windows registry. That simple and elegant!
Evidently, Microsoft could not have been
happy with the fact that Java class files were platform-independent. Applets at
that time (1996) posed a challenge to Windows programs ,for with just a
java-enabled browser , any user can download the required applet, execute it
and get done with it.( The irony is that
SOA of the present days(Service-Oriented-Architecture) is being touted
now by the very same Microsoft!)It was almost the extreme thin client of today
, except that the browser had to be java-aware.
When Sun introduced RMI in jdk1.1(1997),
Microsoft felt much more
threatened, because RMI being platform
independent posed a challenge to Microsoft's platform dependent Distributed
objects technology (ie) COM. So, Microsoft carefully,
excluded RMI packages in its implementation .
and vociferously demanded that the entire
programming world adopt their version of ORPC (ie)
DCOM.[ It is altogether a different matter that Microsoft 's Dr.Gopal Kakivaya, a co-creator
of SOAP, is on record saying that DCOM failed even within windows world!].
The tainting of Java by implementing only those features convenient to
Microsoft led to the famed legal battle which was won by Sun, albeit , as out
of court settlement & the birth of C# as Java-clone.Be
it console-mode program, gui program, network program
or even Remoting ,the C# version is
very easy to learn for a java
programmer. This is a very well known fact and is not worth belaboring.
It is claimed that as C# has been ported to Unix/Linux platform now,C# also is platform-independent like Java. A bit of
caution here, however. When we say that Java is platform-independent , we mean
that a class file obtained by compiling in Windows platform can be interpreted
and run in Unix/Linux platform., without recompiling in that platform. Mere
availability of C# compiler for Linux platform should not be meant here. From
the viewpoint of a developer, one more feather in the cap of Java is that the
development platform and deployment platform need not be same. (ie) I can develop a java program in a windows machine if I
feel more productive there( most programmers are!) and then deploy that in
Unix/Linux without any extra work.
Even otherwise, there are myriad of platforms. We are fast entering into
wireless and embedded system space and all notions about the desktop may become
irrelevant very soon. Are we going to create compiler for each of these
operating systems? It cannot be stressed too much that 'Platform-independence'
is more important in Enterprise Environment than 'Language-independence'
of COM.[ J2ME for the wireless space is
better suited for this requirement] .Microsoft ASP.net admits this fact by
moving away from desktop to the server. It is on the cards that Microsoft is
thinking of abolishing the 'Windows.Forms' package
altogether and uniformly adopt 'Web.Forms' package
even for Desktop applications.(It is similar in concept to doing away with Java
frames and using applets and viewing them through appletviewer
locally).
As, David Chappel
observes, the emergence of XML webservice paradigm
,in no way , makes irrelevant what is
being exposed as a webservice, and how secure, how
scalable and how transaction-suitable that service is. Though, there is a
section even in Java camp, (especially
from FSF/OSF )which feels that EJB
should be sparingly used and plain javabean is better
for most purposes,it is hardly,the view of any serious developer for the
EJB is more about the Container's
infrastructure for Load Balancing, Resource Pooling, Transactions, Security
etc. In Dot Net, we get these as COM+ within wrappers as pointed out by Arjun Mukherjee in his articles
in December and January editions of Developer IQ. Do we get these in MONO?
But, all the three solutions
(DCOM,EJB,CORBA)falter on the question of 'Interoperability'. (ie) they work very well
in pre-arranged situations but fail when we want to connect a Corba service with EJB service etc without such
contract.(It is well to remember that EJB does not offer any solution for
creating a client for a well-written C++
service , as it is!.We have to create a jni wrapper . But it may not be all that easy in all cases.If we want to talk to DCOM world from either EJB or Corba world, it became very difficult. All these systems
communicated over pre-defined ports and system-administrators blocked these
ports by firewall for security. So, in this aspect, all the three systems, failed. Kindly read DonBox on
this theme(available in DotNet documentation).
Is DotNet platform a solution then? Not as
such. (ie) Not because of its
Language independence; Not because of its Common Language RunTime;Not
because it is made available in
Linux/Unix platforms. None of these tackle the problem of True
Inter-operability.
DotNet offers a possibility for Inter-operability, because of ASP.net’s
XML webservice ,
which is based on public standards like SOAP,WSDL and UDDI. Moreover, XML
transformations of data from relational model to xml and viceversa
are very easy and elegant in ASP.net.
Microsoft have done a tremendous job in hiding all the complexities of
creating SOAP,WSDL & UDDI, and creating webservice
using ASP.net is very enjoyable exercise. So, is the job of converting tables
into XML format.
That is so far as comparison with Java
goes. But, when it comes to comparison with legacy
ASP, the advantages offered by ASP.net
are very great.
Specifically,
1) Uploading of files (even image
files)
2) Creating dynamic graphics in
server side and sending to client
3) Creating network connections
from server side
4) The standard shopping-cart
exercise becomes ridiculously
simple, as if we are dealing with an applet or a vb
program.
5) There are other advantages
like in-memory database.
We
can now bring , not just a table into memory but an
entire database and disconnect it
from its
source, view them and create new relations and save them if so
desired.
6) The entire class library is available
from the server side and
just like Servlets, we can do whatever we want
in server side and
send it to the browser.
7) The main problem in WebApplications(ie) Session-tracking , is
not so very crucial in ASP.net because of ‘viewstate’
feature.
So,
though, we still have Session and Application objects,
we
can use them only where absolutely essential.
8) Separation of code from presentation has
become complete due
to ‘Code-behind’ feature.
9) This article is being presented , mainly
from the view point of j2ee and these are the points which should strike an
observer
as being special merits of ASP.net from
Java angle. There may be many more if we delve deep into ASP.net., from Windows angle. For example,
the new and faster method of connecting to SQLServer with
special driver.
10) Another, welcome feature is
Introduction of Validation controls.
True, there are such tags in STL of Java
also, but the implementation is not as easy as in ASP.net. There is provision
even for Regular expression validator.
11) If we are dealing with a very large
table of financial nature
with a lot of similar looking columns , and
we want to edit the records, what better method than a visual representation of
that data as an editable datagrid? That too is
available in ASP.net.
Admittedly, Datagrid
in ASP.net is very complex to master but it cannot be denied that it is
extremely powerful.
It is hoped that by all these points,
ASP.net is clearly a winner
within the Windows world if not in
comparison with java world.
Moreover, ASP.net offers a set of controls
for mobile computing.
It automatically adjusts its output to suit
the receiver. So development and testing becomes far easier as we can use
ordinary browser to test our mobile code.
SQLServer offers OLAP facilities.and these can be tapped
by a creative ASP.net programmer.
When we consider all
these points, we will understand that J2EE and ASP.net have their own
distinctive roles and they should co-exist and co-opearate,
through XML WebService. Hence, Inter-operability
has become very important.