ASP.NET .THE JEWEL IN DOTNET CROWN
by
R.S.RAMASWAMY
(rs.ramaswamy@gmail.com)
( 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.