All About .NET

Introduction

By now you have most likely heard of Microsoft�s .NET Initiative.� But what is .NET, really?� Next time you are at a cocktail party and someone asks you that question, just say, "Its 1 part marketing, 1 part paradigm-shift, and 3 parts cool new products!" �If they press you for details, tell them to go read the rest of this article.

Marketing and Paradigm Shifts

Microsoft will be releasing .NET versions of existing products as part of its .NET Initiative.� Of course a next version of these products would have existed with or without the .NET Initiative.� I have heard some folks suggest that this makes .NET nothing more than marketing.� I understand where they are coming from, and I disagree.

First, an important part of Microsoft�s .NET Initiative is a new and exciting platform called The .NET Frameworks, which I will be discussing shortly.� Second, Microsoft has re-focused across its various product groups to address software development in an interconnected world.� Lets talk about this for a moment.

Microsoft creates software.� This is what they are all about.� For over a decade now, the Internet has been changing the software industry right out from under them (and many of the rest of us!)� This is an unstoppable paradigm-shift that has the power to make or break even a goliath software company.� And Microsoft has decided that they are going to address the Internet, head-on, from every nook and cranny of their company.� So began the .NET Initiative.�

Before we jump headlong into the .NET Initiative, lets review how the software industry is changing.� Here is my take on the current thinking.

Software and the Internet

The purpose of computers is to manage information.� The nature of the information varies a lot from application to application, but at the core it is still all about information.� In recent years, the Internet has largely convinced the general public that computers, indeed, have the potential to simplify their lives in terms of information management.� As a result the consumer�s expectation of the Internet and technology in general has taken a huge leap!

People need to create information easily.� They need to move, share, and organize information flexibly.� They need to know what is going on, find the latest price, and get to their movie on time.� People have stopped being impressed merely by the fact that computers work at all.� They now want computers to tell them where they can get a New York steak in a semi-romantic setting within five miles at 7:30 tonight; "OK, now make a reservation for two."� They want their shipping information to be remembered from one web site to the next.� And each web site should be personalized to individual tastes as well.� All of these "needs" are about the organization and communication of information.� By the way, most of this information already exists without computers or the Internet (such as which restaurants have available tables, or the fact that a customer wants to make reservations), but customers increasingly expect technology to move and react to this information naturally.

For all of this to happen, somebody somewhere has to write software.� But this isn�t the software that you pick-up off the shelf and install on the computer.� Half of the software required to implement all of this doesn�t even run on the consumer�s computer.� This is called software as a service.� Remember this term.

People will pay to be served.� And if your company�s service deals with information or communication, then you need software as a service to serve your customer effectively.� People also want these services to come from thousands of vendors, not just one.� This will improve both the quality and the price of whatever it is they are buying.� Additionally many of these services will have to work together seamlessly no matter who implemented them.� Suddenly, the demands on the average software developer are getting pretty steep!

Before talking solutions, I want to describe a specific scenario.� Imagine that you are a realtor and you want to create a website that your client can use to keep track of their home buying or selling process.� I have seen real estate sights that offer some nice features such as up-to-date listings, mortgage calculators, and the like.� Now imagine that you want to integrate some more advanced features such as real-time loan-approval status, or escrow status.� Suddenly the computer that runs your website has to communicate information with computers from the escrow company and the bank.� This isn�t an impossible problem to solve, but it gets tougher when you consider that the customer wants to choose from a selection of escrow companies and you don�t want to lose their business just because you don�t support a particular escrow company�s data-protocol.�

Tough problems like these have been solved in the past by defining standards.� Standards are great, but they carry with them the burden of meeting everyone�s needs.� This often makes their creation slow, and their implementations tedious.� If you were this realtor, what you really want are a few general-purpose standards and a development platform robust and simple enough to meet your agile business needs.� Imagine that it only took your web-developer a half-day to understand and incorporate a new escrow company�s data interface and another half-day to test it.� All of the communication details just worked.� And your developer did the whole thing without once picking up the phone and calling a developer from the escrow company.� Now you are in business!

This is Microsoft�s .NET Initiative.� And in reality .NET is just the cherry on the tree that is an entire industry swaying in this direction.� Standard protocols like SOAP will make data exchange so simple that your software will be able to keep up with your business.� Simple data standards like XML will expose your businesses information to anyone who needs to consume it and vice-versa.� Finally, the platform that brings these features to developers in a simple, consistent, reliable, and scalable fashion will be a major contender for the foreseeable future.� This platform is The Microsoft .NET Frameworks.

The .NET Frameworks

Did I just call The .NET Frameworks a "platform"?� Did I mean development platform, or did I mean operating system?� Well, the answer to these questions are "Yes I did", and "Both".� So let me begin to describe The .NET Frameworks.

At the core of The .NET Frameworks is a component called the Common Language Runtime or CLR which is a lot like an operating system that runs within the context of another operating system (such as Windows ME or Windows 2000).� This is not a new idea.� It shares traits in common with the Java Virtual Machine, as well as the environments of many interpreted languages such as BASIC and LISP which have been around for decades.� The purpose of a middleware platform like the CLR is simply that a common OS like Windows is often too close to the hardware of a machine to retain the flexibility or agility required by software targeted for business on the Internet.� Software running on the CLR (referred to as Managed Code) is exceptionally agile!

Unlike interpreted languages managed code runs in the native machine language of the system on which it is launched.� In short, developers write code in any of a number of languages.� The compiler generates binary executable software in a p-code format called Common Intermediate Language or CIL for short.� When the software is launched, the CLR re-compiles or JIT-compiles (Just In Time) the CIL into native code such as x86 machine language.� Then the code is executed full speed ahead.� Again, p-code technology is not a new idea (Pascal p-code compilers have existed since the mid-seventies).� But as you will see the .NET Frameworks stitches together these tried-and-true ideas in some very exciting new ways.

Another component of The .NET Frameworks is a massive library of reusable object-types called the Frameworks Class Library or FCL.� The FCL contains hundreds of classes to perform tasks ranging from the mundane, such as file reads and writes, to the exotic, such as advanced cryptography and web services.� Using the FCL you get software as a service with trivial development costs.�

The CLR is intrinsically object-oriented; even its CIL (the p-code, which can be viewed as a virtual assembly language) has instructions to manipulate objects directly.� The Frameworks Class Library reflects the platform�s object-oriented nature.� In fact the FCL is the most extensive and extendible class library I have ever worked with.� I can tell you from personal experience that my end-to-end productivity has tripled since I have begun writing code targeted for the CLR.

Finally, The .NET Frameworks contains a collection of tools and compilers that help to make programming to this new environment productive and enjoyable.� Up until now I have made little mention of C# (pronounced See-Sharp) or Visual Basic.NET.� The reason is that the real guts of this new environment is the CLR.� However, over twenty language compilers are currently being designed for the .NET Frameworks, including five offerings from Microsoft:� Visual Basic, C#, C++, JavaScript and CIL.�

The CLR and the .NET Frameworks in general, however, are designed in such a way that code written in one language can not only seamlessly be used by another language, but it can also be naturally extended by code written in another programming language.� This means that (depending on the needs of a project�s work-force) developers will be able to write code in the language with which they are most comfortable, and continue to equally reap all the rewards of the .NET environment as well as the efforts of their coworkers!

Productivity.NET

I have described the requirements of the future; that is fast-paced and flexible software as a service.� I have briefly described the .NET Frameworks.� Now it is time for me to share some real-life specifics that translate to unparalleled productivity for developers.

Developers are comfortable with calling functions.� Developers are also comfortable (or can quickly become comfortable) with using "objects" in their software.� These things take little time and effort by comparison to difficult tasks such as memory management and network programming.� So the .NET Frameworks is designed from the ground-up to make the difficult tasks either automatic (such as memory management) or to expose them as objects and function calls.� Lets look at an example.

The real-estate example I described earlier in this article requires network communication with a third party to work at all.� Lets go back to this example, and assume that the "Acme Escrow Company" is on the cutting edge of technology, and exposes its business data via software as a service.� (Remember, you are a realtor developing a website that potentially includes information from various escrow companies.)� Here is the .NET code (written in C#) that your web-developer will need to write to retrieve status data from Acme.

Example 1 � Web-Service Client

  //Create a new object

  AcmeEscrowService escrow = AcmeEscrowService();

  //Call a method or function on the object

  String status = escrow.GetStatus("Clark", "Jason");

This example assumes that the Acme Escrow Company exposes a web-service method called GetStatus that takes a last name and first name as arguments.� What it returns is a string describing the escrow status.� Your web developer could display this string as web UI to the user, or use it in any way they like.

So as you can see, something as complex as network communication with a third-party has been boiled down to a simple object creation and method or function call.� But wait!� "Where does the AcmeEscrowService object come from?"� I am glad you asked.� It is automatically generated.� A tool, included with the frameworks, performs the work of interpreting a standard web-service description language called WSDL, to create the AcmeEscrowService object.� WSDL is an open standard that the .NET Frameworks just understands.� The WSDL data itself was created by Acme, so your web developer had to do very little to make this code work!

The .NET Frameworks makes very clever use of general-purpose standards like SOAP, XML, and WSDL to make advanced functionality simple.� It is worth noting that none of these standards have anything to do with the Real-Estate industry, and yet they can be used to transmit Real-Estate information (as well as any other kind of digital data) easily.

"But what if Acme�s competitor, the Foo Escrow Company, wrote their web-service with an entirely different interface?"� Again, I am glad you asked.� Ideally, two escrow companies will choose similar or identical interfaces to expose similar data.� But if they don�t (and you can bet that often they won�t), it is simple for your developers to adjust your company�s web code appropriately.�� Let�s assume that the Foo Escrow Company�s web service interface takes an "escrow ID" and returns a status code.

Example 2 � Another Web-Service Client

  //Create a new object

  FooEscrowService escrow = FooEscrowService();

  //Call a method or function on the object

  FooEscrowStatus status = escrow.GetStatus("JCLA777-12-7777");

In this case, perhaps the Foo Escrow Company provides more advanced "status" information in a special type defined by the WSDL for their web-service.� Either way, the .NET Frameworks tools and CLR work together to make your developers job a snap.� Bottom line is this code, and the previous example code take nearly no time to write and can co-exist happily in your web site.

So what if you are the Acme Escrow Company, and you are writing a web-service?� As you might have already guessed, the .NET Frameworks exposes this functionality as objects, which makes the programmers job a whole lot more fun.

Example 3 � A Web-Service

  class EscrowService : WebService {
  
  �� [WebMethod]
  �� public String GetStatus(string lastName, string firstName) {
  ����� String status;
  
  ����� // use ADO.NET or some other data access

  ����� // to access data about the requested user

  
  ����� return (status);
  �� }
  }

In this example, by deriving a new class called EscrowService from the WebService class, which is (of course) part of the Frameworks Class Library, your developer has created a completely functional web-service.� The GetStatus method is marked as a [WebMethod] and is automatically exposed from your web service.� Software as a service comes pretty cheap this way.

Again, the guts of network communication with the SOAP protocol are all handled by the FCL.� Meanwhile, the .NET Frameworks will automatically create the WSDL necessary to describe your new web service.� So, the hard stuff is automatic or exposed as objects and function calls.

The general idea is that services on the Internet should be as easy to access as traditional hardware peripherals.� So it should be as easy to develop code that dynamically retrieves data from a remote source on the Internet, as it is to write code that displays a window on the computer�s screen or reads keyboard input.� From the programmer�s point of view, this is all just business-logic where the software is taking advantage of a "service" offered by a third party.

To further pronounce this goal, the .NET Frameworks can be used to write traditional client applications (like word-processors and spreadsheets) as well as cutting edge software as a service.� Either way, the concepts and tools are the same, the languages are the same, and the classes and types that your developers use are the same.� This homogeneous view of development increases productivity.

Whether you use the .NET Frameworks to write the client or the web-service, you will interoperate seamlessly with clients and servers running on other platforms so long as they adhere to web-service standards like SOAP.

I think it is worth mentioning that the two web-client examples written before just work, so long as the Common Language Runtime is installed on the machine.� The web-service example, on the other hand, requires a little help from ASP.NET (now part of the .NET Frameworks) and Internet Information Services.� IIS and ASP.NET take care of the scalable network communication and "plumbing" while your code just deals with business logic.� This is an example of how the .NET version of an existing product like ASP or IIS fits seamlessly with the .NET Frameworks to create a complete solution!

Some Closing Words

Remember, The .NET Frameworks is the real guts of Microsoft�s .NET Initiative.� This new product will enable your company to produce software that exposes itself as a service and/or uses services in an interconnected world.� This is the next step.� Meanwhile Microsoft will be releasing .NET versions of their enterprise servers and other products, such as Visual Studio.NET, which take full advantage of and complete the abilities of The .NET Frameworks.� Microsoft will also be marketing their own web-services such as authentication services and personalization services.� This is all part of The .NET Initiative.

However, Microsoft does not corner this initiative.� In fact significant portions of The .NET Frameworks have been submitted for ECMA standardization, i.e. Microsoft would not retain control of the technology.� Meanwhile, third parties will release server products that tightly integrate with the .NET Frameworks.� Third parties will expose web-services using the .NET Frameworks.� Some of these products will compete with Microsoft�s products; others will be new innovative products that were never before feasible.

Software as a service is here with or without the .NET Initiative.� The .NET Initiative brings new tools, a new platform, and a cohesive plan designed from the ground up to exploit software as a service.� What we all get is an Internet that begins to meet its own potential.