Viewpoint

Gopalan Suresh Raj

This is an archive of how my opinion has evolved in response to changes in the Software Industry in North America from 1997 to date. The information here is presented (with dates) in the reverse chronological order, i.e., latest opinion first ...

Microsoft's .NET Strategy...

October 13, '00

The Microsoft .NET Platform targets a framework called the .NET Base Class Library (BCL). .NET compilers don’t produce native machine code; instead, they generate a pseudo-machine code called Intermediate Language (IL) that’s executed by the .NET run-time. This new programming paradigm simplifies the Windows programming model and makes Web applications easier to write. It also claims to enable a new generation of software that runs on every conceivable type of computing device, from the most powerful Web server to the lowliest hand-held PC.

Most people believe that the component services that are now provided by COM+ (MTS) will be rewritten in future versions of the .NET Platform. It seems that it was not fully done yet due to time and resource constraints. According to some, COM+ 2.0 evolved into NGWS (Next Generation Windows Services), which at the last minute (a few or two before PDC) changed to .NET. (http://www.wrox.com/beta/misc/naming.asp)  But certainly there are already many things implemented in the .NET Platform replacing the COM+ infrastructure:

Corel porting .NET to Linux ?

According to regulatory documents filed Wednesday, October 11, 2000 with the SEC, Corel has granted Microsoft the option to direct Corel to port part or all of Microsoft's .NET architecture to run on Linux. As you may recall, Microsoft recently invested $135 million in the financially troubled software maker and announced that the two companies would jointly develop products for Microsoft's .Net effort, which lets customers "rent" software over the Internet (the marketing way of saying that .NET facilitates writing web services, which may be charged for). When the investment was announced it was greeted with surprise -- Corel had long been a vocal critic of Redmond and its outstanding legal issues with the software behemoth suggested that a partnership was out of the question. But Corel's financial woes following the collapse of a proposed merger with Inprise were apparently dire enough to merit inking a strategic relationship with Microsoft. Microsoft, of course, has long been struggling to develop a strategy for Linux, which many analysts believe could compete with or supplant Windows in certain areas over the next five to 10 years. It's now apparent that Corel may well be the first phase of that strategy...

Click here to go to my Advanced C#/.NET Tutorial

Microsoft Proposes a New Language...
C# (pronounced 'C Sharp')

June 28, '00

The Background

On June 26 '00, Microsoft announced that it had submitted a new language called C# (pronounced 'C Sharp') to the Geneva-based standards committee "ECMA" (http://www.ecma.ch/).

C# is intended to be packaged with the next version of Visual Studio (version 7) which will now be called Visual Studio.NET. According to Microsoft, C and VC++ provide the programmer with tremendous amount of fine-grained control and flexibility over their code while sacrificing ease of development. Visual Basic, raises productivity and sacrifices flexibility by omitting a mechanism for low-level code control. VB neither interoperated with pre-existing systems, nor did it always mesh well with current Web programming practices.

Visual J++ occupies that middle-ground between Visual C++ and Visual Basic, offering both fine-grained control over low-level OS features, programming flexibility, and improving productivity multi-fold. It is the BEST environment to program in COM (Microsoft's Component Object Model). The lawsuit with Sun has changed a lot of things. Microsoft seems to be contemplating on deprecating Visual J++!!

C# from Microsoft may be a replacement for Visual J++ and an attempt to replace the void which will be left by its non-inclusion in VS.NET. According to Microsoft, C# would provide programmers with rapid development, combined with the power to access all the functionality of the underlying platform without sacrificing the power and control that have been the hallmark of C and C++. It will provide an environment that is completely in sync with emerging Web standards and one that provides easy integration with existing COM applications. Additionally, it would allow the ability to code at a low level if and when the need arises.

The Reality

In my opinion, C# will do extremely well within the Windows camp. Microsoft makes excellent tools for developers. C# will be integrated into Visual Studio.NET so it’s IDE will be top-notch. However, on other platforms, C# may just be another programming language. While C# is indeed being handed over for standardization, what is being standardized is nothing more than the core programming language. The true meat, the new Visual Studio COM libraries, are not described in the C# language specification. The COM library that ships with Visual Studio 7.0 is what is going to have all the punch in it. With this library you will be able to kick out killer Windows apps in VC++, C# and VB by using something called the "Common Language Subset" (CLS) interface. C# is a thin language core that sits somewhere between Visual C++ and Visual Basic. Visual J++ now has the spot but it is safe to assume that it is, in Java terms, being deprecated.

There are some things about C# that sound neat:
1. Automatic garbage collection
2. Everything is an object (including the primitives! which means I can code 10.toString () !!!).
3. Multi-dimensional array support (the [,] notation)
4. Support for operator overloading
5. structs are held and passed by value on the stack. These have the same properties as classes, except that they are accessed by value rather than by reference.
6. C# allows XML data to be mapped directly into a struct data type, rather than a class, for greater efficiency.
7. Supports conditional compilation
8. true and false are both keyword and boolean literal
9. a foreach statement
10. "delegates" are a language feature.
11. Will be better than VB
12. With C#, every object is automatically a COM object
13. C# supports methods with variable number of parameters.
14. interfaces are part of the C# language. Interfaces are defined in C# as having methods and properties, and generating events; but there is a new twist in that C# interfaces can derive from more than one interface, which is not possible with MIDL. The actual interface implementation is in classes or structs which can implement one or more interfaces.

Heated Good/Bad Debates Surround these features:
1. It uses a preprocessor
2. The preprocessor has no support for macros
3. Compiles to platform native executable (without second step)
4. Doesn't compile to platform independent ".class"-like file
5. Lots of attempts to remove 'unnecessary' brackets. Dangling else is solved by using the nearest corresponding if.
6. There is no distinction between caught and uncaught exceptions
7. goto
8. switch statements follow the "no-fall-through" mechanism.
9. switch statements can also be applied to strings (case-sensitive)
10. Properties are supported, i.e., what looks like a variable assignment or access in client code can have get and set methods associated with it.
11. The addition of all of the unsigned types doesn't look like a win, but when you discover that the only implicit conversions are those which preserve information, it looks okay.
12. You can turn on or off overflow checking for arithmetic operations in a code block. Not sure if this propagates to the methods that are called within that code block
13. Inside a specially marked code block, developers are allowed to use pointers and traditional C/C++ features such as manually managed memory and pointer arithmetic (these blocks are qualified by the keyword unsafe)

Some folks feel these things are sad:
1. Far less dynamic than Java. (i.e. no dynamic class loading)
2. Has C++ style namespaces
3. break and continue can't have a label.
4. Event handlers are less general than anonymous classes and aren't cleanly integrated.
5. no covariant return types
6. Provides large primitive data types and overflow checking constructs, but does not appear to convert to unbounded representations.
7. The name resolution rules look too involved, although there are some interesting features with respect to interfaces.
8. Methods are not virtual by default.
9. C# doesn't seem to have built in security
10. No template-like mechanism available

Other Features:
1. Looks very similar to Java.
2. The entry point into an application is the static Main() function of a class, and your code interacts with the operating system through instances of a standard class library.
3. You can write your own classes, which supports single inheritance from other classes, but can be derived from several interfaces.
4. The language supports value types (such as int and double) and reference types (e.g. instances of classes, arrays and strings). Just as with Java, C# reference types are 'managed' - in other words, the memory they consume is maintained by a garbage collector.
5. It also allows you to define 'indexers', which are essentially like the C++ operator [], and it has C++-like destructors.
6. All COM interfaces have to indicate the direction of data transfer and the meaning of all pointers that are passed. C# uses the parameter modifiers ref and out to indicate if a parameter is passed by reference, or is an 'out' parameter. However, since pointers do not exist in C# code, interface definitions are not concerned with them.
7. C# has been designed with the ability to change the language through 'attributes'.


Far back in December 1997, Mary Kirtland wrote an article in the Microsoft Systems Journal (MSJ) called "The COM+ Programming Model Makes it Easy to Write Components in Any Language". It makes me wonder if C# was what she was referring to then. Whatever be the case, I for one, and hordes of Java/COM developers like me, will miss Visual J++ for a long time to come...

References
http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp

Click here to go to my Advanced C#/.NET Tutorial

The latest SOAP Opera

October 24, '99

Last month, Microsoft submitted a new specification to the Internet Engineering Task Force (IETF). This new XML-based specification for distributed applications has been christened SOAP. Simple Object Access Protocol (SOAP), is being touted as a way to handle remote procedure calls (RPC) across the Internet. SOAP is useful for inter-object communication between disparate components. I would go ahead and argue that this is a master-stroke from Microsoft

It is nice for a few reasons:

1) You can use it to bridge between any two component models. It is a relatively easy process to write RMI stub/skeletons, COM proxy/stubs, or CORBA stub/skeletons to allow interoperability between say, your desktop COM application and your EJB enterprise backend system.

2) It makes WAN deployment really nice. You don't have to worry about firewall configuration issues.

3) It makes it easy to install security filters (as a simple web server extension).

4) It makes it easy to transform a synchronous system into an asynchronous system. Calls can be sent using MQSeries or a JMS provider.

5) It makes for a really open standard. For example, if a competing standard emerges (from say OMG), there is a good chance (barring causality problems or other protocol intricacies) that it could interoperate with SOAP (or any other XML RPC) via a simple XSLT filter.

The list goes on. This is just a sample. SOAP has almost nothing to do with whether you are creating an EJB or an MTS based application (other than Microsoft is the underdog in the space and they want an easy way to interoperate).

SOAP will be bundled into Windows 2000 and will be used transparently when you make calls over the internet.

At least the way I understand it they intend this to be a communication mechanism to allow rich clients (i.e. VB clients) to communicate with server components over the Internet, and to allow easy integration of server-side applications over the Internet.

Using DCOM for this is virtually impossible, but the same is more or less the case with RMI/IIOP because of firewall problems, although in a controlled extranet configuration one could configure the firewall to let through IIOP packets. SOAP is a way to package a DCOM call as an XML message and thus overcoming the firewall problem, while COM components running on an intranet would still use DCOM to communicate.

A similar approach would IMHO be very useful also for the EJB/CORBA world.

Some vendors have this capability in their CORBA orbs. Visigenic's orb, e.g. can (pretty much transparently) wrap IIOP in HTTP or HTTPS to tunnel through client firewalls. Over the Internet, HTTP tunneled IIOP is 25% slower than native IIOP.

My concern about this approach, whether it's SOAP or HTTP tunneling of IIOP is that it's a cobbled together solution for what should be a non-problem. We need to do a lot of evangelism in the corporate security community to convincingly demonstrate that properly configured, IIOP channels in their firewalls (and around their proxy servers!) are no more (and probably less), dangerous than the ubiquitous HTTP on port 80. The only reason we're even tempted to migrate to doing RMI/RPC via HTTP is because it's the lowest common denominator for security.

However, As far as SOAP as a way to tie together CORBA, RMI and DCOM is concerned: I doubt that's Microsoft's goal. Even if it is, XML is a small part of the solution. Any of us could write code to re-marshal and un-marshal IIOP or DCOM into XML very easily. But these three protocols are not semantically equivalent, and you can bridge them only with significant effort, or by applying (again) a least common denominator approach that throws away as much as it salvages.

IMHO, a *better* approach is to figure out how to solve the firewall "problem". The lemming strategy is not always a good one. Let's be innovative. However, even if we did come out with a new protocol, and assuming for a moment that every company in the software industry supported it (!!!!), how do we convince all the web masters around the world, who ever owned a Web Server to support it? Even if 20% did not support our new innovative protocol, our components will not be able to communicate with that 20% of the machines through the internet. So ultimately, it comes down to, Who's to bell the cat??!! Which goes back to the point I made early on in the article about this being a master-stroke by Microsoft. Is this the only way out?

The Battle for the Enterprise (contd...)

July 28,'98

Microsoft is promoting its Distributed interNet Applications Architecture (DNA) as a platform for developing fully distributed enterprise applications. There are six core fundamental technologies which are part of Microsoft Component Services without which DNA would not be possible. They are,

COM - the ability to define components,
DCOM - the ability to take these components and move them onto another machine,
MTS - the component runtime environment in which components live, which watches requests coming into components and participates in processing them, providing security, automatic transaction management and a scaleable environment.
MS DTC - Distributed Transaction Coordinator which is very similar to CORBA's Object Transaction Service which automatically handles distributed two-phase commits in enterprise applications.
MSMQ - code-named The Falcon, which is the asynchronous messaging capability and is somewhat similar to CORBA's dynamic invocation interface.
MSCS - Microsoft's Clustering Technology code-named The Wolf Pack - which allows bringing together very small little server machines in a bunch with Wolfpack as a good glue that holds them together for creating highly robust and very scaleable applications

While Microsoft today is a one-stop shop for a viable set of distributed object application tools, Sun's JavaSoft has created an environment where an industry of third-party distributed tools-and-platforms have started to flourish.

JavaSoft is promoting its Java Platform for the Enterprise (JPE) as a core technology for developing multi-tier distributed applications. There are six fundamental technologies that are part of this.

EJB - the ability to develop and deploy scalable, transactional, multi-user secure, distributed enterprise-level server application components.
Java/RMI - the ability to remotely invoke Java objects and their methods on different virtual machines
JNDI - which provides Java applications with a unified interface to multiple naming and directory services on the enterprise.
JDBC - the Java version of ODBC for database connectivity
JTS - the ability to provide the transaction system infrastructure required to support an application run time environment.
JMS - Java's messaging capability.

Update: JavaSoft has since renamed Java Platform for the Enterprise (JPE) to Java 2, Enterprise Edition (J2EE) and has come out with a Reference Implementation for it.

Sun vs. Microsoft

May 17,'98

On May 12, Sun filed a new legal motion asking the U.S. District Court to require Microsoft to include a Sun compliant Java implementation in both Windows 98 and its MS software tools for the Java programming environment.

Sun asked that the court require Microsoft to either:

• Completely ship with Sun's Java VM on its environment including RMI and JNI or
• Remove Java altogether on all of Microsoft's environments or
• Include Sun's Java VM in addition to Microsoft's Java VM in the new Operating System Windows 98.

Microsoft dismissed all the options, calling the entire action a publicity stunt, and saying that its Java customers/developers would be hardest hit if the court granted the requested injunction.

While Sun talks of purity of Java implementations, there are people who argue that Sun should put the legal issues with Microsoft on the back burner and instead concentrate its resources on enhancing its own JVM to better compete in the marketplace (instead of the courtroom).

The Reality

As of today, Microsoft is the only company with a browser software implementation that is capable of running Java 1.1 applets. So I see no reason why Sun is so upset with Microsoft. If I need to run any RMI or JNI stuff, I always have the option of downloading it as a plug-in from the Microsoft site.

If you are not aware of this yet, I am sorry to inform you that even the latest version of Netscape Navigator 4.05 does not run Java 1.1 applets. To my utter disbelief, I found out that Netscape does not support the Java 1.1 Delegation Event Model yet. SO IF YOU ARE RUNNING NETSCAPE, YOU WILL NOT BE ABLE TO VIEW JAVA 1.1 APPLETS. THIS IS A FACT. Even Sun's Java 1.1 Plug-in has problems with Netscape. This came as a rude shock to me and I am sure it is the same case with most of you. I sincerely wish Netscape solves this problem at least in their next release. So if you use Netscape and want to view Java 1.1 applets, you will have to move over to Internet Explorer 4.0 !

If you want to see for yourself, go to your Netscape/Program/Java directory. You will find a single file called java_301. Give it a .zip extension, unzip it and try to use the javap.exe utility program that comes with your Sun 1.1.x JDK compiler on any of the awt component classes. You will not be able to find any of the Java 1.1 methods like add...Listener() etc. For your information, I compile all my programs using Sun's JDK 1.1.5 compiler.

By the way, Symantec's JIT which comes with Sun's JDK 1.1.6 has some serious problems. Every time I have to disable it to make my JDK 1.1.6 work fine. So I have removed it from my machine. Coming to think of it, as time goes on, I feel all these actions by Sun are helping segregate the market even further.

Think about it. If my Sun Java 1.1 compliant applets can only run on MS Internet Explorer 4.0x, why do I want to remove IE from my machine? To run Sun's plug-in on IE or Netscape, I have to first force the user's of my web page to install this ActiveX control (ironically, Sun's plug-in is an ActiveX control which has to be installed for running on IE). I don't need it for IE since IE runs my Java 1.1 code really well. I only need it for Netscape since Netscape does not run Java 1.1 code. However, the Sun plug-in has serious stability problems with Netscape. If you want to see for yourself, take look at http://java.sun.com Sun plug-in's download site. They say it right there just before you can download it.

And do you know what the Sun's plug-in has come down to? - ALL OR NOTHING - The same slogan which Sun used to beat MS ActiveX has now come to haunt them. I can write Java 1.1 applets which can read and write files to my hard-disk with Sun's plug-in. I am not trying to create a controversy here. I am just stating facts.

Let us not fight among ourselves trying to do a one-up on each other. While Sun, Netscape, Microsoft and all the "Biggies" have reason to protect their intellectual property, we the users of this technology should not be affected by all this. I have a lot more to say but I do not want to say it here. I am sure that people who really write Java code would have already found out the Caveats by now and those who haven't found 'em yet will get to very soon.

The implementers whether they be Sun or Netscape or Microsoft know the gotchas in their implementations and I am sure they are making all out efforts to rectify them. I do not want to rake up any more issues. I leave the conclusions to you.

Update: Netscape has since come out with newer versions of their browser and have been supporting JDK 1.1 fairly well since their 4.06 release. However, IMHO, Microsoft Internet Explorer 4.x and more recently IE 5.0 run JDK 1.1 code far better then Netscape. Unfortunately, at this time, neither browser supports JDK 1.2.

The Battle for the Enterprise

Feb 26,'98

Ever since Java came out, there has been a lot of talk that it will some day become a potential threat to the Windows Operating System. There has always been a long standing debate going on, with the Sun loyalists on one side and the Microsoft loyalists on the other, each camp trying to outdo each other and literally slugging it out.

Over the past couple of years, there has been a lot of applications that have been developed using Java. Each of these have tried their best at emulating the familiar look and feel of the Windows environment.

Java is an excellent and an extremely powerful language. Java enables developers to write secure applications faster. Cross-platform compatibility and Security have been the two most highly touted aspects of The Java programming language. The language as a whole is still evolving into maturity and there has been a lot of major revisions to the language as a whole.

However, we are yet to see really large and powerful applications entirely developed using Java. If one were to live by the 100% Java slogan, applications have to be cross-platform compatible. This will also mean that these applications may execute slower than code which uses native binary code. One of the first companies that caught on to the Java bandwagon was Corel. It's Java Office Suite package somehow never saw the light of day. Lotus' E-Suite sounds promising but no one knows how it will look like when it finally ships.

Windows and Microsoft are very strong on the desktop market. Instead of wasting their resources on trying to emulate Windows or killing it, wouldn't it be a better corporate strategy for the creators of Java to concentrate on the server side? If they are trying to make significant inroads, they may have to fight it from the server side where incompatibility rules. This is Java's home-turf! If we need compatibility, this is the place where more than anything else we need it most. Microsoft is not as strong on the server side as it is on the desktop.

Java is an excellent distributed programming language and a runtime environment. The server is one place where Enterprise JavaBeans will play a major role. ( For those who do not know, Enterprise JavaBeans is a set of specifications for developing distributed Java components). This will probably allow developers to create highly secure, imaginative server-side software that addresses and resolves complex incompatibility issues. Tools and Servers written to this spec should help developers build stateless server-side components, as well as persistent business logic and data objects that are portable across platforms. It will probably help standardize Java as a corporate server platform standard.

So, what has Microsoft been up to these days? Why hasn't Microsoft done anything on the server side? Well, you might be in for a surprise here. Microsoft's Transaction Server is the equivalent of Sun's Enterprise JavaBeans. MTS has been released for some time now and is now in version 2 while Enterprise JavaBeans is still a spec, yet to be released. So, am I saying that MS has a fully working implementation even before Sun has even released it's specs for server side development? I'm afraid that I am saying exactly that.

However, we do have an excellent battle on our hands here. Whoever prevails, the end-users are the real winners. Let us hope that we as developers bet on the right horse and see our fortunes grow.

The slogan should always be "Don't expend energy trying to kill it. Overcome it..."

This site was developed and is maintained by Gopalan Suresh Raj

This page has been visited times since March 13,1998.

Last Updated : June 28,00

If you have any questions, comments, or problems regarding this site, please write to me I would love to hear from you.