|
|
True interoperability between Java and Dot Net.
Posted On October 31, 2007 by Anush filed under Miscellaneous
R.S. Ramaswamy salutes ASP.NET and advocates that even J2EE developer should learn ASP.NET. He further advocates true interoperability between Java and Dot Net.
I have no doubt in saying that the Best Feature of Dot Net is ASP.NET along with its WebForm & WebService technologies. WebForm technology is excellent and a tremendous advance over previous offerings from Microsoft. XML web service also is a good 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 (the author has met a few, who are 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 too difficult! So, it will be advisable for students and programmers 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. Everyone should learn ASP.Net using C# (yes! including J2EE programmers). They should learn to appreciate its programmer-friendly features in ASP.net and C#. Those who are capable of contributing to the development of programming tools should strive to create equally friendly software in Java.
How about the J2EE camp? A Java Server faces a technology similar in intent to web forms is to be released shortly and web service for Java also has been created.
But, ASP.NET is much more elegant in its implementation of these two technologies and is definitely more programmer-friendly, even without VisualStudio. There are some security problems yet to be solved in XML web service, but it unifies the Language-agnosticism of Microsoft and the Platform-agnosticism of Java world. J2EE is best suited for Enterprise level where a myriad of platforms exist and ASP.net is better suited, where non-java programmers can develop and expose their services to other platforms, without the difficult techniques based on CORBA. They can and will co-exist.
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 are 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 void. And does not Microsoft now expect every programmer to forget the past and adopt the new technology? If everything 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 upon it. The ultimate solution is still far off. Let us now see the events that led to this entire leap-frogging race.
During the decade from 1990 to 2000, so many changes occurred in the Windows world. For one, Visual Basic introduced in 1990, gradually matured into a powerful development platform of unparalleled ease with VB6. When first introduced, many Windows SDK programmers described it as a stunning miracle! So many versions of Windows such as Windows-3.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 was offered in the form of ActiveX components, controls and containers. 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, i.e., 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, it never caught up.)
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). An example of OLE is embedding 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 Enterprise computing as 'Interface-based' programming, rather than 'Class-based' programming. Of course, we still need Class and Objects of the Class but only as implementation of the Interface. At the risk of repetition, it is worth stressing that Interface based programming enables distributed objects to be used in an environment different in either Language or Platform or both.
Writing the marshalling and unmarshalling code by hand is an onerous task and it is the job of IDL compiler to translate the IDL file into a real language file and also to create the stub and skeleton files (or proxy & stub files in Microsoft parlance).
As long as Microsoft was thinking of Desktop only, COM was no problem at all. Still, as anyone 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 that entire Hungarian notation thrust on the programmer by the wizard and the company's coding standards, it resulted in many anomalies!
The 'arcane' and unnecessary grammar of Windows SDK and even MFC cannot go unnoticed by VB and C# programmers. With all that 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 and so on. The famed wizards of Visual 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 Windows SDK and MFC if Microsoft had not offered them, along with 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 wizards were more interested in creating buttons of irregular shape than in interacting with Enterprise world!
Microsoft grew and prospered because of Visual Basic and the wizards to a great extent. 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 VC++, then the 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. 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 torturous the environment was. And on top of it all, MFC and Windows SDK 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 that 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 Macros? A great variety of arrows, dots, double quotes, angle brackets, header files, resource scripts, underscores, semicolons, double semicolons and 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 it looks like it very much wants to do away with legacy COM, Registry and Windows API. The practice of using Windows SDK 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 which is the next best to Java!
When Java came in 1996 with its AWT, even Microsoft was happy! That is perhaps one of the reasons why it licensed 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 realize how much of Microsoft was captivated by Java.
Any Java class is automatically a java bean if compiled with jdk and it becomes a COM component if compiled with Microsoft java compiler and registered in Windows registry. It is that simple and elegant!
Evidently, Microsoft could not have been happy with the fact that Java class files were platform-independent. During 1996 Applets 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 now being touted 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 or COM. So, Microsoft carefully excluded RMI packages in its implementation, and vociferously demanded that the entire programming world adopt their version of ORPC, which is 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 the 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. However a bit of caution is to be taken here. 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 the same. That is, I can develop a java program in a windows machine if I feel more productive on Windows (most programmers are!) and then deploy that in Unix/Linux without any extra work.
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?
Even otherwise, there are a 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 compilers 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’s 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 applet viewer locally.)
As David Chappel observes, the emergence of XML web service paradigm, in no way, makes irrelevant what is being exposed as a web service, 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 Enterprise.
But, all the three solutions (DCOM, EJB and CORBA) falter on the question of 'Interoperability'. That is, they work very well in pre-arranged situations but fail when we want to connect a CORBA service with EJB service and so on 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 that easy in all the cases. If we wanted 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 Don Box on this theme (available in Dot Net documentation).
Is Dot Net platform a solution then? Not as such. That is 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.
Dot Net offers a possibility for interoperability, because of ASP.NET's XML web service, which is based on public standards like SOAP, WSDL and UDDI. Moreover, XML transformations of data from relational model to XML and vice versa are very easy and elegant in ASP.NET.
Microsoft has done a tremendous job in hiding all the complexities of creating SOAP, WSDL & UDDI, and creating web service using ASP.NET is a 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 these are the following:
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 on server side and send it to the browser.
7. The main problem in web applications is Session-tracking, and 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 when they are absolutely essential.
8. Separation of code from presentation has become complete due to 'Code-behind' feature.
This article is being presented mainly from the viewpoint of J2EE and these are the points that should strike an observer as being special merits of ASP.NET from the Java angle. There may be many more if we delve deep into ASP.NET., from the Windows viewpoint. One relevant example would be the new and faster method of connecting to SQLServer with special driver.
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 validators. 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 data grid?
That is also available in ASP.NET. Admittedly, Data grid 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 the 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. A creative ASP.NET programmer can tap the facilities offered by SQLServer. 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-operate, through XML web service. Hence, interoperability has become very important.
This article is written by R.S. Ramaswamy and he can be reached at rs.ramaswamy@gmail.com
(Originally printed nearly three years agao, the article is still relevant today)
I have no doubt in saying that the Best Feature of Dot Net is ASP.NET along with its WebForm & WebService technologies. WebForm technology is excellent and a tremendous advance over previous offerings from Microsoft. XML web service also is a good 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 (the author has met a few, who are 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 too difficult! So, it will be advisable for students and programmers 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. Everyone should learn ASP.Net using C# (yes! including J2EE programmers). They should learn to appreciate its programmer-friendly features in ASP.net and C#. Those who are capable of contributing to the development of programming tools should strive to create equally friendly software in Java.
How about the J2EE camp? A Java Server faces a technology similar in intent to web forms is to be released shortly and web service for Java also has been created.
But, ASP.NET is much more elegant in its implementation of these two technologies and is definitely more programmer-friendly, even without VisualStudio. There are some security problems yet to be solved in XML web service, but it unifies the Language-agnosticism of Microsoft and the Platform-agnosticism of Java world. J2EE is best suited for Enterprise level where a myriad of platforms exist and ASP.net is better suited, where non-java programmers can develop and expose their services to other platforms, without the difficult techniques based on CORBA. They can and will co-exist.
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 are 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 void. And does not Microsoft now expect every programmer to forget the past and adopt the new technology? If everything 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 upon it. The ultimate solution is still far off. Let us now see the events that led to this entire leap-frogging race.
During the decade from 1990 to 2000, so many changes occurred in the Windows world. For one, Visual Basic introduced in 1990, gradually matured into a powerful development platform of unparalleled ease with VB6. When first introduced, many Windows SDK programmers described it as a stunning miracle! So many versions of Windows such as Windows-3.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 was offered in the form of ActiveX components, controls and containers. 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, i.e., 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, it never caught up.)
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). An example of OLE is embedding 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 Enterprise computing as 'Interface-based' programming, rather than 'Class-based' programming. Of course, we still need Class and Objects of the Class but only as implementation of the Interface. At the risk of repetition, it is worth stressing that Interface based programming enables distributed objects to be used in an environment different in either Language or Platform or both.
Writing the marshalling and unmarshalling code by hand is an onerous task and it is the job of IDL compiler to translate the IDL file into a real language file and also to create the stub and skeleton files (or proxy & stub files in Microsoft parlance).
As long as Microsoft was thinking of Desktop only, COM was no problem at all. Still, as anyone 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 that entire Hungarian notation thrust on the programmer by the wizard and the company's coding standards, it resulted in many anomalies!
The 'arcane' and unnecessary grammar of Windows SDK and even MFC cannot go unnoticed by VB and C# programmers. With all that 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 and so on. The famed wizards of Visual 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 Windows SDK and MFC if Microsoft had not offered them, along with 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 wizards were more interested in creating buttons of irregular shape than in interacting with Enterprise world!
Microsoft grew and prospered because of Visual Basic and the wizards to a great extent. 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 VC++, then the 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. 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 torturous the environment was. And on top of it all, MFC and Windows SDK 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 that 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 Macros? A great variety of arrows, dots, double quotes, angle brackets, header files, resource scripts, underscores, semicolons, double semicolons and 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 it looks like it very much wants to do away with legacy COM, Registry and Windows API. The practice of using Windows SDK 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 which is the next best to Java!
When Java came in 1996 with its AWT, even Microsoft was happy! That is perhaps one of the reasons why it licensed 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 realize how much of Microsoft was captivated by Java.
Any Java class is automatically a java bean if compiled with jdk and it becomes a COM component if compiled with Microsoft java compiler and registered in Windows registry. It is that simple and elegant!
Evidently, Microsoft could not have been happy with the fact that Java class files were platform-independent. During 1996 Applets 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 now being touted 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 or COM. So, Microsoft carefully excluded RMI packages in its implementation, and vociferously demanded that the entire programming world adopt their version of ORPC, which is 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 the 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. However a bit of caution is to be taken here. 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 the same. That is, I can develop a java program in a windows machine if I feel more productive on Windows (most programmers are!) and then deploy that in Unix/Linux without any extra work.
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?
Even otherwise, there are a 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 compilers 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’s 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 applet viewer locally.)
As David Chappel observes, the emergence of XML web service paradigm, in no way, makes irrelevant what is being exposed as a web service, 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 Enterprise.
But, all the three solutions (DCOM, EJB and CORBA) falter on the question of 'Interoperability'. That is, they work very well in pre-arranged situations but fail when we want to connect a CORBA service with EJB service and so on 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 that easy in all the cases. If we wanted 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 Don Box on this theme (available in Dot Net documentation).
Is Dot Net platform a solution then? Not as such. That is 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.
Dot Net offers a possibility for interoperability, because of ASP.NET's XML web service, which is based on public standards like SOAP, WSDL and UDDI. Moreover, XML transformations of data from relational model to XML and vice versa are very easy and elegant in ASP.NET.
Microsoft has done a tremendous job in hiding all the complexities of creating SOAP, WSDL & UDDI, and creating web service using ASP.NET is a 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 these are the following:
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 on server side and send it to the browser.
7. The main problem in web applications is Session-tracking, and 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 when they are absolutely essential.
8. Separation of code from presentation has become complete due to 'Code-behind' feature.
This article is being presented mainly from the viewpoint of J2EE and these are the points that should strike an observer as being special merits of ASP.NET from the Java angle. There may be many more if we delve deep into ASP.NET., from the Windows viewpoint. One relevant example would be the new and faster method of connecting to SQLServer with special driver.
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 validators. 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 data grid?
That is also available in ASP.NET. Admittedly, Data grid 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 the 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. A creative ASP.NET programmer can tap the facilities offered by SQLServer. 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-operate, through XML web service. Hence, interoperability has become very important.
This article is written by R.S. Ramaswamy and he can be reached at rs.ramaswamy@gmail.com
(Originally printed nearly three years agao, the article is still relevant today)