- A Peek at SOAP
- Web Services and Internet 3.0
- .NET: How Evil Is It?
This chapter is from the book
This chapter is from the book
This chapter is from the book
.NET: How Evil Is It?
.NET may indeed be evil. But it's also pretty cool. .NET is Microsoft's way of saying, "We think Web services are cool, and we want to make it easy for developers to create Web services." Of course, there's more to .NET than spreading developer-love. Microsoft wouldn't pour this much effort and money into something unless they planned to make a ton of money on it later. Remember earlier in the chapter when we discussed how software companies could stand to make more money from a subscription model of selling software? I'm going to hazard a guess that's a major reason .NET exists—Microsoft thinks it will make money. I'm not casting judgment, since businesses must make money, but it's useful to understand the motivations behind such things.
So what is .NET, exactly? .NET can be seen as a new run-time environment and a common base class library. If that doesn't make much sense to you, keep reading—there isn't a quick answer. For those of you who already understand compilers and runtimes, you can skim the next section.
Here's what we'll be examining in .NET:
Microsoft Intermediate Language (IL)
Common Language Runtime (CLR)
Common Type System (CTS)
Common Language Specification (CLS)
Background: Compilers and Runtimes
When you write a program in, say, Visual Basic, it exists as source code. Source code is what you write in a text editor. No computer in the world can run a program that exists only as source code. You have to translate the source code, which you understand, into a language that the computer can understand. That's what a compiler does: It takes your source code, and squeezes it into something that's almost impossible for people to understand, but computers have no problem with.
Well, almost no problem. Compiling a program from source code is a necessary step, but a computer needs something else that will actually run the compiled program. This something knows how to take the compiled code and force the computer to actually follow the instructions in that code. This piece of software is called a runtime environment.
So, in order to get your source code actually executed, you need both a compiler and a runtime environment.
Usually, each language has its own runtime. The runtime for Java (also known as the Java Virtual Machine) can only force a computer to run a chunk of compiled Java code. If you give a Java compiler some compiled C++ code, it won't know what to do with it.
For clarification, it's important to note that Java and C# compile code into bytecode that's understood as native language by a virtual (imaginary) machine. Visual Basic, similarly, compiles into pseudocode that an interpreter executes. C++ compiles into native machine language. In this sense, C++ does not have a runtime environment other than the operating system itself.
Intermediate Language
A huge part of the .NET program is the creation of a common intermediate language. What does this mean? First, an intermediate language is the computer-friendly language your source code is compiled into. When you compile a program using a .NET compiler (like the upcoming Visual Studio.NET), your source code is compiled into a language called Microsoft Intermediate Language (IL). .NET compilers compile all languages into this Intermediate Language, and it tacks on a little metadata as well. Figure 1–2 illustrates this:
)
FIGURE 1–2 Compiling source code into a common intermediate language
New languages are being added to this list all the time. At last count, there are 18 languages that can be compiled into IL, and by the time you read this, hopefully a few dozen more.
How do you get a hold of one of these compilers for your language of choice? A number of vendors are creating .NET-aware compilers, so by now, the most common languages have several .NET-aware compilers available.
As you can see from Figure 1–2, the IL files are given the extension DLL or EXE. This is just like a COM (Component Object Model) binary, but internally, the two are nothing alike.
Metadata and Assemblies
When some source code is compiled into IL, a .NET-aware compiler does a little bit more than just a translation into IL. It also creates some metadata, or data about the compiled program. This metadata describes in exhaustive detail all of the types of data that are in your code, including base classes, methods, properties, and events. You don't have to worry about creating this metadata yourself—a .NET-aware compiler will do it for you.
When a .NET compiler translates your source code into IL and creates some metadata, this creates something called an assembly. We won't be going into more detail here about assemblies.
For those of you with experience in Windows programming, you know about a metadata language called IDL, which sometimes was present and sometimes wasn't. This ambiguity isn't part of .NET—you must have metadata. In fact, you can't help it, since the compiler always creates it.
Common Language Runtime
Since all .NET source code is compiled into a single intermediate language, IL, it should only require a single runtime to execute anything in that intermediate language, right? That is, since a runtime can only run a certain kind of compiled code, if you compile different languages into that same compiled code, then a runtime could execute all of them. You would have a single runtime that could execute compiled code from multiple languages. In fact, the runtime wouldn't even care if the compiled code started out as C#, Eiffel, or COBOL. The runtime just sees the IL and runs that. This runtime is called the Common Language Runtime (CLR), and it's a hugely important part of .NET.
The CLR basically has two components: an engine and a base class library.
CLR Engine
One component of the CLR is the actual execution engine (also known as mscoree.dll). This engine examines the metadata of the assembly, makes sure everything is where it should be, and then compiles the IL instructions into something that's platform-specific (for example, into something that's Windows-based or UNIX-based), which is then finally executed.
Base Class Library
The CLR's base class library essentially contains all the rules for all allowable kinds of data types. In other words, every data type that is in any compiled IL file has to have some equivalent in the base class library. A language can't have any old data type it wants and then expect the CLR to be able to run it. .NET languages have to follow certain rules, and the base class library contains most of those rules. That means that some languages will have to be tweaked slightly in order for them to compile into IL properly. However, this isn't expected to be much of a problem—the base class library has many, many types in it, so whatever language you're working in, chances are you're fine.
Common Type System (CTS)
The CTS describes all of the data types that the CLR can understand. That is, since the Common Language Runtime isn't all-knowing and can only understand a limited number of data types, the CTS is needed to define exactly what types the CLR understands. In addition, it also defines how those types interact with each other and how they should appear in the metadata.
To get a more thorough understanding of what this actually means, let's look at some broad categories of data types that are part of the CTS. These include:
Class types: The notion of a "class" is necessary for any object-oriented programming, so it's logical that classes are supported by the CTS. A class is composed of any number of methods, properties, and events.
Structure types: Structures are also supported by the CTS.
Interface types: Interfaces are collections of methods, properties, and event descriptions—they're more abstract than classes.
Type members: A member is either a method, a property, a field, or an event.
Enumeration types: An enumeration allows you to create a list of variables that can exist under a single name.
Delegate types: For those of you from the C world, this is the equivalent of a type-safe C style function pointer.
Intrinsic data types: These data types are different forms of integers, strings, Booleans, objects, decimal numbers, and so on.
Common Language Specification
Different computer languages can have different levels of functionality. Some will let you overload operators or will support unsigned data types, while others will not. However, in order for the IL and Common Language Runtime to work, all languages must share at least a certain subset of functionality. The purpose of the Common Language Specification is to define a set of explicit rules that provides a baseline for all languages that wish to be .NET-aware.
Rules of the CLS include how to represent text strings, how to use static types, how enumerations are represented, and so on.
.NET and SOAP
So .NET involves a common intermediate language and a common language runtime (among some other things). What does this have to do with SOAP?
Well, one thing we didn't cover is how to actually create Web services in your .NET-aware language. As it turns out, this is amazingly easy in most languages. In some cases, all you have to do is add a single line of code:
[WebMethod] your method code
When you add this code, you automatically create a method that is capable of acting as a Web service. Well, the compiler and the runtime actually make your method a Web service. Now this Web service can read and write SOAP messages. Microsoft decided to use SOAP as their way of communicating between Web services. For example, if you want your .NET web services to communicate, they must communicate via SOAP messages. Microsoft has decided that SOAP is the glue that will hold Web services together.
NOTE
.NET and HailStorm
You may have heard about HailStorm but not completely understood it. HailStorm is a bunch of Web services that Microsoft is developing. These Web services have different functions, like keeping track of calendar events, schedules, contacts, document storage, email and voicemail inboxes, and so on. Microsoft would like you to keep all of your important information with them, and that you would communicate with this information via Web services. The fact you're using a Web service shouldn't be part of the experience, though.
The upshot of the above is that if you only plan to use Microsoft's tools, you don't really need to know anything about SOAP—Microsoft will take care of it for you. While this will save you time, you'll be stuck in case anything goes wrong, because you won't know enough to debug anything. Besides, how much do you trust any software vendor to know what's best for you? Learning SOAP gives you another tool in your programming tool chest, and as most of us know, the more tools we have, the better off we usually are.
Recap
.NET is an aggregation of several things, but its most interesting feature is the ability to write programs in any language. Since they're all compiled into the same intermediate language, these programs can now talk to each other as Web services, and it doesn't matter what language they were written in, where the applications are, or what platform they're on.