Let's take a short trip back to the past.

It wasn't too long ago that applications were designed, developed, and deployed on a single machine. For those of you that can remember the early days of the personal computer era, things like dbase, FoxBASE, and the like might ring a bell. Everything ran on the same machine -- the user interface, the business rules, and the database services.

Then along came local area networks, which ushered in the era of clientserver applications. Now the user interface and the business rules sat on the PC and sent requests to a client-server DBMS such as Oracle or SQL Server, while on the server side, records were processed and results were returned to the client.

As LANs matured and their reliability improved, application development went through yet another evolution, namely, the advent of 3-tier architecture. This transformation resulted in the user interface, business rules, and data services each becoming its own independent logical element in the application architecture. The physical world may have implemented each element on a separate machine, but that was not required.

The main advantage of the 3-tier model is that business logic could now be broken up into components, where they could be used not only in one but many applications. Additionally, changes to business logic in the server did not require the calling party or client to change at all. In other words, the details of the implementation of business logic or the function is not important, as long as the way it is called and the type of information that it returns do not change. Let's face it, the world is changing quickly and we need to be able to adjust without having to re-deploy.

Of course, the initial implementation of the 3-tier model (later to become the n-tier) was primarily on common machines and operating systems such as Intel, Windows, and Unix. Vendors each supported their own brand of components. Microsoft supported COM, followed by DCOM. IBM promoted CORBA, and Sun touted RMI. Each of these middle tier component flavors was proprietary and did not provide for inter-operability and communication among disparate pieces. In order for a Microsoft application to talk with a CORBA component another piece of software was required for translation. The same was true for apps trying to communicate with DCOM objects as well.

All of this made it difficult for diverse systems to talk to one another, creating an increasingly significant problem, as Internet business-tobusiness applications became the focus. The web, a relatively recent addition to the overall IT architecture, has dramatically changed the way we look at application development and correspondingly the deployment of

associated services.

If you log on to Land's End, for example, it's not unlikely that the underlying application will have to utilize components developed by a number of other parties such as AMEX, MasterCard, Visa, UPS, FedEx, along with a host of internal systems to provide the total consumer shopping experience.

Sun, with it's Java language, was in the right place at the right time. Java's ability to be compiled to byte code and run on any machine that had a Java Virtual Machine gave it portability. The fact that it was designed to be totally object oriented, target web-based applications, and observe security issues associated with distributed apps gave it tremendous appeal to corporate clients.

Visual Basic, on the other hand, earned its stripes in the Windows-based application development world. It's easy to develop apps that leveraged the Window's Operating System, and as it VB evolved it took on more and more features that made it increasingly object oriented, capable of creating reusable COM/DCOM objects, and a viable tool for web-based applications. Today, Microsoft claims that there are more than 3 million Visual Basic programmers in the world.

Introduced in 1991, Visual Basic has gone through 6 versions. Each oneincreased power, features, flexibility, and capability, leading up to two major programming languages -- Java and Visual Basic, with each camp feeling that their product is better.

The fact is that language is not truly the key. The winner will be the framework/platform that enables the design, development, and deployment of applications and takes advantage of services or

components distributed throughout the web.

With the pending release of the next version of Visual Studio (of which VB is a part), Microsoft has decided to radically change the way that their language suite works. The next version of Visual Studio will be called Visual Studio.Net or VS.Net, and the next version of Visual Basic will be titled VB.Net. There are many new features and capabilities, but in my opinion, there are two major changes that will move Microsoft to the center stage.

First, VS.Net will be a common development environment into which C#,C++, and VB along with about 14 other non-Microsoft languages will connect. Language will be a matter of preference. This is largely due to the fact that they will all compile down to the same level by utilizing a common run-time module. In addition, they will all share the same class libraries.

What this means is that an application comprised of components and services can be developed by a team of developers in several different languages with the assurance that it will all work together.

If one were to look closely, one could see that the general architecture that makes Java so popular is that the output of the compiler is not necessarily tied to the chip set or operating system. It would not surprise me if Microsoft made the run-time module, which is similar in nature to the Java Virtual Machine, available to the standards committees to be ported to other platforms. If this were to happen, VS.Net and VB.Net could take a major leap forward in the language race.

The second major event that parallels the introduction of VS.Net is the advent of SOAP. Remember our previous discussion concerning different types of components trying to work with each other? SOAP or Simple Object Access Protocol, is an open standard based on XML or Extensible Markup Language, that IBM, Sun, and Microsoft have agreed upon now makes it possible for components, developed with competing standards, to communicate. XML is used to describe the underlying elements of a class including the methods, associated arguments, and return values. While SOAP on the other hand, describes the interface including the path to the XML document. This will remove a significant obstacle to inter-operability in building applications using distributed web-services.

To summarize, Java and Visual Basic are currently in strong competition with one another. A recent check with ComputerJobs.Com shows that jobs requiring Java, Visual Basic, and C++, the distribution is 55%, 35%, and 10%. With VS.Net/VB.Net, SOAP, and the freedom to choose language independent of platform, one can expect this distribution to shift from Java to non-Java languages. In fact, with VS.Net hosting almost 20 different programming languages (including a Java implementation from Rational) and compiling to a common byte-code level, personal preference will surely rule the day.