MICROSOFT.NET OVERVIEW - University of Windsor

basiliskcanoeSoftware and s/w Development

Nov 2, 2013 (3 years and 10 months ago)

75 views

MICROSOFT.NET OVERVIEW

By:
-

Rahul Puri

.NET OVERVIEW


What is .Net?


The .NET FRAMEWORK


Why is this Important?


Metadata


Language Neutrality


Safety


The class library


What it’s all for


Is this MS’s[latest] attempt to kill Java


.NET and COM


Visual Studio.NET


.NET and standards


Imagine Cup


Questions


What is .NET?



It is a "software platform".


It's a language
-
neutral environment
for writing programs that can easily and securely interoperate.


Rather
than targeting a particular hardware/OS combination, programs will
instead target ".NET", and will run wherever .NET is implemented.




.NET is also the collective name given to various bits of software
built upon the .NET platform.


These will be both products (Visual
Studio.NET and Windows.NET Server, for instance) and services (like
Passport, HailStorm, and so on).


What is .NET?


The components that make up .NET
-
the
-
platform are
collectively called the .NET Framework.



This article will concentrate on the .NET Framework; a
follow
-
up will tackle .NET
-
the
-
software.


Also within this
article will be discussion of the standardization process
happening in parallel, and a discussion of the differences
between .NET and its major rival, J2EE.

The .NET FRAMEWORK

The .NET Framework has two main parts:


1.

The Common Language Runtime
(CLR).


2.
A hierarchical set of class libraries


Common Language Runtime

The most important features are:



Conversion from a low
-
level assembler
-
style language, called
Intermediate Language (IL), into code native to the platform being
executed on.



Memory management, notably including garbage collection.



Checking and enforcing security restrictions on the running code.



Loading and executing programs, with version control and other such
features.

Common Language Runtime

Before talking in more detail about the CLR I would like
clear few bits of terminology:


1.
Managed code

2.
Managed data

3.
Common type system

4.
Assemblies

Common Language Runtime


When you target .NET with your compiler, what gets
generated isn't native code.


Instead, it's a small PE
wrapper around three blocks of data.


PE (Portable
Executable) is the binary format used to contain Win32
programs.

Common Language Runtime


The first block of data within the PE wrapper is the IL
itself.



The second is called the metadata.




The third is the manifest.



Common Language Runtime


When running the executable, the CLR uses Just
-
In
-
Time
compilation.


As each method within the executable gets
called, it gets compiled to native code; subsequent calls to
the same method don't have to undergo the same
compilation, so the overhead is only incurred once.



JIT compilation raises some issues.


One is that it demands
resources


memory and processor particularly.


To solve
this, MS have two JIT compilers: a normal one, that
optimizes compiled code fairly well, but can be processor
and/or memory intensive; and an "EconoJIT".



Common Language Runtime


A third kind of compiler has been hinted at (though hasn't made it into
the version 1 release), called the "OptJIT".


It will work a little
differently; it will use a subset of IL (OptIL) with additional
information to suggest to the OptJIT compiler how to generate its
output; there may also be greater optimization of the IL.


The idea is to
reduce the overhead due to the JIT compilation without sacrificing the
quality of the emitted machine code.



The other issue is, of course, performance.


JIT compilation can
provide good results once a program is up and running, but can be very
slow at load time (as it has to both load and compile the program), and
can't necessarily perform some of the more expensive (time
-
wise)
optimizations that optimizing compilers perform.


To tackle this,
there's a mechanism for compiling the executable and storing that
compiled form


ahead
-
of
-
time (AOT) compilation.

Common Language Runtime


A number of the core Framework files are compiled in this
way, to reduce their start
-
up overhead.


The IL version is
still kept around, and if the system is unhappy with the
PreJITted copy for some reason, it can fall back on JIT
compilation.


Unfortunately, version 1 of the CLR doesn't
regenerate AOT files should they become invalidated in
any way; they have to be manually generated instead.


Why Is This Important?


It eliminates ".dll hell".


Multiple versions of "the same"
assembly can co
-
exist in the GAC(Global Assembly Cache
), which means that libraries no longer have to maintain
backwards compatibility with their predecessors, and that a
program will always get the version it's expecting.


This
can be done even within the same program


if you have
a web server, you can run multiple versions of the same
application within it, side
-
by
-
side.


Why Is This Important?


The quite rigorous protection against tampering with files
provides some guarantees that the files won't be modified
after release; this should provide some protection against,
for instance, viruses (were a virus to infect a file it'd refuse
to run).



METADATA


An important feature of managed code is the metadata.
Metadata is data describing data
, and all manner of
metadata is used in .NET.


As mentioned, there's
information identifying a particular assembly, and the
assemblies that assembly relies upon.


The security
privileges required by the assembly are also listed.



There's detailed information about the types/classes
provided by the assembly, along with descriptions of
methods, interfaces, and members.

Language Neutrality


The ability to use any language that can target IL is a fundamental
feature of .NET.


This is achieved through the Common Type System
(CTS).


The CTS defines how classes (or "types", in .NET) are
defined.


It describes a number of different features a class can have;
member functions (methods), member variables ("fields"), events, and
properties (fields that silently use accessors to get/set their values,
which can, for instance, allow the creation of a read
-
only field).


It
defines the different kinds of "visibility" that these items can have (for
instance, whether a method is public, and can be called by any class, or
private, and only callable by the same kind of class).


And it describes
how such things as inheritance work for the class, with some
constraints; all classes must ultimately derive from System.Object, and
only single inheritance is supported.

Language Neutrality


The ideas that it formalizes should be familiar to anyone
who has programmed with an OO language.


This
standardization is important, because it allows different
compilers to create compatible objects.


Whether you
define your class in C#, VB, JScript, or any other
language, it'll generate the same output.



And because the output is known to work in a certain way,
it no longer matters what was used to create it.


You can
start off with a class written in C# and inherit from it in
VB.


Then you can seamlessly use it from C++.


It makes
no difference


it just works transparently.

Language Neutrality


Whilst the CTS was designed to be as transparent as
possible (to be compatible with existing language
constructs) it does enforce some constraints.


C++
programmers will lose multiple inheritance (like other such
systems, you can have only a single base class, but
multiple interfaces).


A number of languages will lose case
sensitivity (names exposed to classes in other assemblies
have to be differentiated by more than case alone; names
internal to a class's implementation can still be
distinguished only by case).


Language Neutrality


The language neutral aspects of .NET run deep.


There are
many languages that are in a beta (or better) state, and a
number of groups working on these languages have had
input into the design of .NET.


One repercussion of this is
that IL has certain specialized instructions.


An example of
this is that it has a "tail call" instruction.


A tail call is a
function call that is the final call of a routine (in imperative
languages, returning the unmodified result of another
function call would be a tail call).


They are of particular
importance to functional languages, which typically use
recursion instead of iteration.


When a recursive function is
written to use a tail call, a significant optimization of the
generated code can be performed.


Language Neutrality


IL can readily express such calls with its tail call
instruction.


This makes writing compilers that
perform such optimizations easier, and ensures
that the JIT can produce optimal code.

Safety


Another thing the CLR ensures is that programs don't
attempt to do anything dangerous.


The language most
changed by this is C++.


Regular C++ permits all sorts of
tricks and mistakes.


One can allocate a block of memory
and then write too much data to that block, overwriting
whatever happened to be lying beyond the allocated block
of memory.


Or one can pretend that one type is another
type (deliberately or accidentally).


And one can (attempt
to) access any location in memory and modify its contents.


Safety


Whilst some of these can be innocuous (deliberate treating
of one type as another type, for instance) a number can be
dangerous.


The most famous of these being the
buffer
overflow
.



To counter these problems, the runtime simply states that
you can't do that kind of thing (unless you have permission
to do so; one can run so
-
called unsafe programs that can't
be verified as safe


indeed, they may not be safe at
all).


If you try to write past the end of a buffer, it'll catch it
and throw an exception.


If you try to use types in a way
that isn't safe, it will catch it and throw an exception.


Safety


One issue with this is that there are ways of generating
code that is
safe

but which the runtime can't verify to be
safe.


To permit such code to be run, there's a privilege that
can be assigned to users to permit them to run, for
instance, unverified code from trusted sources.

The Class Library


.NET provides a single
-
rooted hierarchy of classes.


The
root of the namespace is called System; this contains basic
types like Byte, Double, Boolean, and String, as well as
Object. All objects derive from System.Object.


As well as
objects, there are value types. Value types can be allocated
on the stack (which is generally quicker to some degree
than allocation on the heap), which can provide useful
flexibility.


There are also efficient means of converting
value types to object types if and when necessary.

The Class Library


The set of classes is pretty comprehensive, providing
collections, file, screen, and network I/O, threading, and so
on, as well as XML and database connectivity.



The class library is subdivided into a number of sets, each
providing distinct areas of functionality, with dependencies
between the sets kept to a minimum.


The aim is to make
stripped
-
down implementations (for small devices) easier
to create, as an implementation need only provide those
sets of classes that it needs.

What Is It All For?



These two things


the CLR and its libraries


provide a versatile
platform for software development.


Whilst a lot has been made of the
server/web applications, .NET is aimed at client
-
side development
also.


This includes traditional applications (both bespoke business
applications and mass market off
-
the
-
shelf applications), but also more
powerful web
-
based applications; because finer control over security is
possible, as well as more powerful UI capabilities, more capable web
applications can be written, more easily; the insecure ActiveX
functionality that Microsoft said would change web applications has now
come of age, with a truly securable implementation.


.NET (using
Windows Forms) aims to provide an alternative to (and perhaps eventual
replacement for) traditional Win32 development using VB or MFC or
[your favourite GUI toolkit].

What Is It All For?


One key feature of server application development is Web
Services.


A Web Services is a component running on a
web server that is "consumed" (i.e., used) by a traditional
client application, a web
-
based client application, or
another Web Service.


Web Services are consumed using
Simple Object Access Protocol (SOAP), a remote
procedure call mechanism using XML over HTTP, as their
access protocol, in conjunction with WSDL (Web Service
Description Language).


WSDL is used to describe the
interface(s) published on the web, so that consumers of the
service know how to use it.


SOAP is used during the
actual execution of the consumer.


The .NET library
provides a number of classes to make this easy.

What Is It All For?


.NET is also happy to use code that exists outside the CLR,
and unmanaged code within .NET.


Unmanaged code can
still take advantage of .NET's class library, for instance,
and still compile to IL, but it doesn't, say, use the garbage
-
collected heap.


One can write native code and expose it to
.NET, for better performance


an example of this is the
Windows Forms classes, which are implemented as native
code.


What Is It All For?


The Framework has two components, the CLR and the
class library.


MS, however, views .NET as having three
main components (well, some of the time


they're not
entirely consistent on what the platform is).


The first two
are the CLR and the class library.


The third is
ASP.NET.


This is misleading.


ASP.NET is, as its name
would suggest, a version of Active Server Pages that use
.NET technologies.


ASP.NET provides a nice
environment for writing web applications.


However, it's
not true to say that it's a fundamental technology.


Instead,
it is an example of a .NET hosting application.


It runs
applications within the .NET environment, and provides
classes to those applications, but it isn't, in and of itself, a
key part of .NET.


What Is It All For?


This ability to host the CLR is open to other programs (in a
similar, but far more capable, way in which programs can
host ActiveX scripting languages to provide extensibility).


Is This MS Attempt To Kill
Java??


When one hears of what .NET is and does, a comparison to
Java seems inevitable.


The two platforms are similar in a
number of respects.

Is This MS Attempt To Kill
Java??


Java is used to refer to three distinct things.


The Java language.


An object
-
oriented C
-
style language.


The Java class library.


A comprehensive (if occasionally
inconsistent) class library hierarchy.


The Java Virtual Machine (JVM).


Source code is compiled to Java
bytecode, which executes inside the JVM; traditionally, it wouldn't
be compiled into native code; high
-
performance JVMs, however,
typically compile on
-
the
-
fly to instructions native to the underlying
hardware.


Is This MS Attempt To Kill
Java??


.NET was designed to be language agnostic.


One can
readily take a C# class, derive a VB.NET class from it, and
then use it in a Managed C++ program


the use of
different languages is invisible to the programmer.




Whilst a number of languages can compile to Java
Bytecode, this is not sufficient to make Java
-
language
-
neutral.


Many of those languages are merely script
interpreters written in Java (they do not create Java
bytecode, the scripts are not aware of running on the Java
platform, and hence, cannot use any Java features); many
of the projects are simply abandoned.

Is This MS Attempt To Kill
Java??


Whilst some (for instance, Jython) can interoperate with
Java classes, this represents the minority.


The ability to
mix and match the languages being used


to write a class
in one language, inherit from it in another, and use it in a
third


doesn't exist.



The class libraries have a fair degree of
commonality.


Java's is currently somewhat more
extensive; .NET's is arguably better
-
developed in some
areas (creating forms, for instance).

Is This MS Attempt To Kill
Java??


There are differences in the nature of the intermediate
languages.


IL would be unsuitable for interpreting
because, for instance, it uses generic instructions (for
instance, the instruction to add two numbers is the same
whether the numbers are integers or floating point), which
would require the interpreter to carry around all sorts of
type information


type information that with Java
bytecode is specified in the instruction itself; Java
bytecode has one instruction for adding integers and a
different one for adding floating
-
point numbers.


On the
other hand, Java bytecode is tied in some respects to the
constructs that the Java language have; IL is more generic.

Is This MS Attempt To Kill
Java??


These differences add up.




The first is the most obvious to developers


they can use
the language they prefer, or is most appropriate (assuming
it has a compiler targetting .NET) rather than the language
the environment forces upon them.


It should provide an
easy route for existing C++ or Visual Basic
programmers.


Further, MS have released betas of a
product called Visual J#.


It provides an upgrade for Visual
J++ programmers.


There is a .NET compiler and a set of
class libraries.


These implement the Java language and the
Java class library in their entirety as they stood at version
1.1.4.

.NET AND COM


MS have been pushing a language and platform
independent interoperability mechanism for some years
now.


It's called Component Object Model (COM).


There
is a degree of overlap between the two.


.NET hides many
of the messy details that COM makes programmers (or at
least C/C++ programmers; VB programmers will see far
fewer differences in this regard) deal with.


COM is all
native code, and requires programmers to be conscious of
many low
-
level details which make development using the
full power of the technology more burdensome.


.NET
makes these issues disappear.


It takes care of the details
for you.

.NET AND COM


On the other hand, COM still has some things in its
favour.


COM/DCOM has a huge installed base (it can be
used on pretty much any Win32 machine), and is used
quite extensively (particularly in newer versions of
Windows).


Lots of bits of Windows rely on COM
components (for instance, Explorer/Internet Explorer), and
lots of applications similarly rely on them.


For the time
being, at any rate, pure .NET can't replace COM.


It does
become, however, a legacy technology.

.NET AND COM


But the good news is, you can use COM components from
.NET, and you can expose .NET objects as COM
components.


The necessary details are worked out for
you; all the programmer needs to do is to add some
attributes to their code and their .NET classes can be used
just like COM components.


Thus the gap between .NET
and COM is bridged.


All the messy parts are taken care of
by the attributes (this is a demonstration of why attributes
are so powerful; two distinct technologies are painlessly
integrated using a few lines of code, despite the complexity
of what must go on to permit this).

Visual Studio.NET


The launch of Visual Studio.Net (VS.Net) marks the
official debut of Microsoft .Net
--

the ambitious, bet
-
the
-
company initiative that aspires to weave a fabric of XML
-
enabled software and services across the Internet. As
Microsoft's flagship integrated development environment
(IDE), VS.Net contains the first release versions of two
major new programming languages
--

C# and Visual
Basic.Net (VB.Net)
--

and signals the end of the old Visual
Basic line.

Visual Studio.NET


Together, VS.Net and its languages provide all the tools
necessary to build and deploy applications on Microsoft's
bold new platform.




For Microsoft developers, the best news is that VS.Net is
by far the best IDE Microsoft has ever produced.



The hidden gem of VS.Net, however, is Active Server
Page.Net (ASP.Net), a vast improvement over previous
ASP versions that takes the development, performance and
maintenance of interactive Web pages to a new level.

Visual Studio.NET


VS.Net also instantly establishes itself as the leading IDE
for developing Web services
--

a new breed of discrete,
XML
-
enabled software component now hailed as the
future of application development throughout the industry.
In VS.Net, developers can easily create Web services
without having to get their hands dirty with XML code.

Visual Studio.NET


Despite these benefits, the fact remains that the relentless
rise of Java has forced Microsoft to take a huge risk. With
C#, VB.Net, and the .Net framework, Microsoft is clearly
trying to retain its developer base by providing much of the
same functionality offered by Java and the J2EE
framework.



This is a dramatic break with the past
--

particularly for
Visual Basic developers, who will now be forced to
graduate to object
-
oriented programming.

Visual Studio.NET


Among developers, Microsoft has long been recognised as
a leader in creating fully
-
featured, easy
-
to
-
use
programming tools.




Visual Studio.Net represents a real breakthrough, enabling
developers to employ a single, richly appointed
environment to write, test and debug code regardless of
programming language.



Thanks to VS.Net integration and MSIL, a developer can
use a single, integrated workspace with a sole debugger
that minimises previous stability problems incurred by
developing multi
-
language applications that require
simultaneous use of several development tools

Visual Studio.NET


VS.Net contains numerous code
-
generating wizards to
help development projects get off the ground quickly and
to automate mundane tasks.



In large enterprises, where decentralised development
teams have diverse requirements, VS.Net offers a
substantial productivity boost. Code reuse can occur not
just within a single language, but also among various .Net
languages
--

a VB.Net shop and a C# shop, for example,
can easily integrate and reuse code. Language syntaxes
may be different, but when different languages instantiate
and manipulate the same base classes, shorter learning
curves result. As developers grow comfortable with a
single unified IDE and its tools, efficiency goes up and
training costs go down.


Visual Studio.NET


Big surprise for VB users



The C# language is clearly the star of the whole .Net
mega
-
production, with Visual Basic.Net as its sidekick. C#
and its 'Java
-
like' qualities
--

such as garbage collection
and hierarchical namespaces
--

have received lots of
attention. But VB.Net has had far less coverage, making it
easy to overlook a simple fact: VB.Net is so similar to C#,
it's worth wondering why Microsoft bothered to create two
separate languages. True, VB.Net syntax remains verbose,
while C# more closely resembles C
--

but both languages
access the same programming framework and compile to
nearly identical MSIL code.

Visual Studio.NET


VB.Net's similarity to previous Visual Basic versions can
only be called superficial. With VB.Net, Microsoft is
trying to position Visual Basic as a viable enterprise
application development language, adding such key
features as inheritance, namespaces, multi
-
threading, and
so on
--

while preserving some semblance of easy syntax.




Visual Studio.NET


Yet Microsoft can't conceal the difficulty of shifting from a
glorified scripting language to a truly object
-
oriented one.
The real question is: will millions of Visual Basic 6.0
developers decide that VB.Net is the way to go based on
some syntactic similarities? In fact, most Visual Basic 6.0
developers would find it just as easy or difficult to make
the leap to the more powerful C# or, for that matter, to
Java.

Visual Studio.NET


VS.Net comes not only with C# and VB.Net, but also with
Visual C++ .Net and Visual J# (actually, in the form of a
coupon redeemable when Visual J# launches late this
year). All of the languages included with VS.Net compile
to MSIL code as do 20 other languages that currently have
MSIL compilers, including COBOL, Perl and Python. But
by giving C# the most power, Microsoft has made it
absolutely clear that C# is the language of choice for
Microsoft .Net development.

Visual Studio.NET


Both C# and VB.Net protect developers from themselves
through managed code. This means that the code is
processed within a run
-
time environment (or 'sandbox'), in
which all calls to the underlying OS and memory addresses
are to an API
--

and therefore 'safe'
--

hiding some of the
more powerful, difficult features of C++. In a pinch,
however, expert C# developers can mark sections of code
as 'unsafe' and gain direct access to memory and
underlying OS libraries, trading some of the protection of
managed code for added power. For better or worse, Java
doesn't offer this option (nor, of course, does VB.Net).

Visual Studio.NET


The stated purpose of C# is to provide a language suitable
for building enterprise applications, yet with the syntax
simplicity found in Visual Basic. Cynics argue that C# is
just a Java knockoff, but that's tough to prove: both
languages claim C as their parent and run in a managed
run
-
time environment, which accounts for most of the
similarities, including syntax, garbage collection and
hierarchical namespaces. C# also preserves C++'s enums,
whereas Java does not. Where C# more closely resembles
Java is in the handling of components, including
properties, methods, events and attributes.

Visual Studio.NET


But the 'Java
-
has
-
this, C#
-
has
-
that' debate largely misses
the point. If a language provides object orientation, a
usable syntax and sufficient functions, its value should be
measured largely by the services provided in the
framework, not relatively minor differences in syntax.
After all, C# has only 60 statements but can use thousands
of .Net framework classes. And because both .Net and
J2EE were designed for building enterprise
-
class
applications, no one should be surprised at the close
resemblance between the two
--

from a sandbox to run
managed code, to a standard method for database access, to
a scheme for creating interactive Web pages. When it
comes to Java versus C# or J2EE versus .Net, far more
similarities than differences emerge.

The Web Wins Too


VS.Net's most welcome improvements may be found in
the functionality of ASP.Net and Web Forms. Those
familiar with ASPs know that creating interactive Web
pages has always been something of a kludge, with HTML
and (usually) Visual Basic scripts cobbled together in the
same unwieldy file. By contrast, with ASP.Net, the HTML
and executable code reside in separate files
--

a boon for
development, performance and maintenance.

Visual Studio.NET


The most immediate benefit of this separation is obvious:
ASP developers and HTML jockeys simply avoid stepping
on each other's code. Instead of writing scripts mixed in
with HTML, developers can roll event handlers and
business logic into compiled, object
-
oriented code on the
server, increasing performance and
--

thanks to object
-
oriented structure
--

reducing the chance that dynamic sites
deteriorate into spaghetti code. By the same token, the
HTML can be customised independently to support
multiple browsers and devices. Finally, the form state is
automatically managed during posts back to the server,
whereas before this required additional ASP scripting.

Visual Studio.NET


As in previous Visual Studio versions, you use a visual
development environment called a Designer to create UIs.
When you create a Web Form, VS.Net generates two files:
one to store the HTML and a second to handle the VB.Net
or C# code behind the Form.



This is rapid development at its best: you drop widgets
onto a blank Form, set widget properties and code the logic
to react to user
-
driven events in the .Net language of your
choice.

Visual Studio.NET


When you're done, you're left with two separate files: an
ASPX file to store the HTML (along with ASP tags to
represent the widgets) and a second file to handle the code
behind the Form. When the user requests an ASP.Net page
for the first time, the Web server merges the two files into
one on the fly and delivers the HTML to the browser. After
the initial request, the page is stored in compiled code on
the server, speeding the performance of subsequent loads.

Visual Studio.NET


It's worthwhile comparing the new ASP.Net approach with
that of Java Server Pages (JSPs). JSPs contain HTML
merged with Java code, but they're compiled into servlets
when deployed on the server
--

which overcomes some of
the limitations associated with script code, such as
performance and maintenance. But all page elements are
still combined into a single file, retaining the problems
associated with mixing content and code. For good reason,
JSPs have been the favourite for developing interactive
Web pages, but for now at least, Microsoft is offering a
better solution.

Visual Studio.NET


VS.Net seems intent on proving how easy Web services
can be, providing a complete, transparent environment for
Web services development. Developers basically just flip a
few switches to make component applications available as
Web services, with no XML coding required.



The .Net framework uses XML for data representation by
default and enables you to expose Simple Object Access
Protocol (SOAP) interfaces easily. Special .Net Web
services classes enable developers to turn ordinary
methods into Web services simply by adding the attribute
'WebMethod' before each method declaration.

Visual Studio.NET


That's it
--

method implementation remains exactly the
same as it was before the method became a Web service.
In addition, .Net automatically takes care of creating a
Web Services Description Language (WSDL) document to
describe services. Developers simply modify the XML
namespace by changing the namespace attribute prior to
making the Web service public. All the plumbing required
for the Web service is automatically created by .Net.

Visual Studio.NET


Microsoft is in the unique position of controlling its own
universe. All the pieces of its Web services framework are
pretty firmly in place
--

not only the programming
environment, but also .Net MyServices; server applications
such as BizTalk and SQL Server, and even a Web services
tool kit for Office XP. VS.Net stands at the centre of all
this. No matter what you think about the viability of Web
services, Microsoft has provided both the tools and a
broad
-
reaching environment to make the creation and
consumption of Web services extremely simple.

Visual Studio.NET


On the Java side, tool kits such as Sun's Java Web Services
Developer Pack have been released that offer Web services
ease of use and functionality similar that of VS.Net. What
gives VS.Net an edge is that the J2EE framework for Web
services isn't cooked yet.

.NET AND STANDARDS


NET uses a number of open standards extensively; Web
Services use SOAP(which uses XML data over an HTTP
transport) to interact, UDDI for learning about Web
Services, and others.



One thing that needs to be made clear is that .NET itself is
not "open".


.NET is an
implementation
, and the notion of
"open" does not apply.


However, it is an implementation
of open standards.


Its core is an implementation of the
standards that ECMA et al. are working on.

References


www.arstechnia.com



www.zdnet.com