网站运营seo文章大全提供全面的站长运营经验及seo技术!
.net framework for java programmers
author: ashish banerjee
objective
after reading this article java programmers should be able to decipher and de-jargonize the .net architecture and relate it with the proposed ecma standard.
target audience
java programmers and system architects. summary
this article outlines microsoft's proposed standardization of .net framework in ecma forum as cli (common language infrastructure), but the microsoft documentation refer this as clr (common language runtime). the clr and jvm are compared with respect to market forces which shaped the clr definition. components of clr are examined followed by details of microsoft's implementation of the clr as the .net framework.
all along .net framework is compared with java architecture.
the material is derived from author's own experience with java since early 1996, microsoft's msdn site and standard documents from sites like ecma and w3c.org. overview
.net framework is the microsoft's answer to java commune's objections to /"windonization/" of java.
microsoft introduces a new language c#, designed by the visual j++ team. but in the process it has done away with dcom and also have changed it's flagship language visual basic.
in a nutshell, .net constitutes presently of three compiled languages c#, vb.net and c++, a java like runtime virtual machine environment, five execution containers hosting this runtime, namely: asp.net, windows shell, vba scripting host for office suite, visual forms container and ie (internet explorer). much like java it contains a rich set of api and lib.
enhancements over java framework include use of soap (simple object access protocol) for remoting. version and security scoping using concept of application assembly (described later). a common type system is introduced for making mixed language programming easier. for example a vb component can inherit from a c# class.
in longer term java and .net will converge and therefore an overview of the new framework is presented here from java programmer's perspective. comparing clr with jvm
the .net framework's common language runtime (clr) is much similar to java virtual machine (jvm), in terms of garbage collection, security, just in time compilation (jit).
however, the fundamental difference arises from the variance in perception of the sun's java design team headed by james gosling and that of microsoft's c# designers spear headed by anders hejlsberg
sun viewed the internet as an heterogeneous network consisting of multiple operating systems. thus sun had to design the gui as the least common factor, supportable by all such platform. this was also the major reason of java's failure in client side applications. java has been successful only on server side where there is no great need for gui.
having failed at client side desktop application arena, sun is now targeting java to server side applications market, which is dominated by unix and linux flavors having approximately 60% of the server market, the rest 40% rests with windows nt.
but this view was not conducive to microsoft, which holds about 90% of client side desktop market. microsoft wanted to provide a window centric internet development platform. thus it added a few window specific features in it's java implementation, similar to what it had had done with it's c++ implementation. this along with microsoft's refusal to support java rmi, which competed with it floundering remoting technology called dcom, resulted a law suite. microsoft lost the law suite in late 2000, and had to pay usd 20 million to sun as settlement amount. this antagonist attitude made microsoft break away from java and float it's own language called c#.
the c# team was carved out of the microsoft j++ team, and it's effort finally led to the creation of .net framework.
microsoft intends to leverage it's desktop leadership, to shape the internet applications development by introducing the .net framework. thus the supported languages map the windows gui more closely in it's framework, much similar to c++ mfc and j++ wfc (windows foundation classes). in spite of the platform independence design claims, all the three supported languages produce windows .exe code by default.
microsoft played the standardization game better than sun. microsoft, though being an usa based company proposed the c# and common language infrastructure (cli), the back bone of .net framework, for standardization with ecma (european computer manufacturing association) tc39 technical committee in october 2000. ironically sun also happens to be a member of this standing committee, which looks after computer languages related standardization issues. see http://www.ecma.ch.
microsoft has also successfully standardized simple object access protocol (soap) through w3c (http://www.w3c.org). soap is a xml and http based remote object access protocol. soap competes with java's rmi and microsoft's own dcom. rmi has the limitation of being language specific, and dcom had limited acceptability outside the windows community, this was, despite the best of microsoft's effort to port dcom on unix platforms.
corba, another remoting contender, which even has internet specific transport namely iiop, is more or less dead, due to it's vendor non interoperability.
soap, by virtue of http transport can operate easily over firewalls and therefore can easily transident lan and internet. however, soap being xml based, burdens both client and server for xml parsing, which is relatively cpu intensive, compared to binary protocols like rmi and dcom.
java platform views the internet world as one language running on different operating systems (os), whereas .net framework views the world running on one os with a programmers having choice of multiple languages. therefore java platform interpolates multiple operating systems, and .net framework interpolates multiple languages.
apparently from the above discussion, the market forces are largely responsible for the state-of-the-art rather than technical design considerations. inside the common language runtime
the common language runtime (clr), is the runtime environment of the .net framework, which manages the execution of code and provides services.
the common language runtime (clr), is also proposed for ecma standard. however, the ecma documents refer the clr as common language infrastructure (cli). it has five components namely:
- cts - common type system
- cls - common language specification
- cil - common intermediate language
- jit - just in time compiler
- ves - virtual execution system
cli - common language infrastructure
the common language infrastructure (cli) provides a language neutral platform for application development and deployment. cli supports both object oriented paradigm (oop) as well as hooks for modeling procedural and structured languages.
cli provides languages with a framework for security, garbage collection, exception handling and also provides a platform for language interoperability. for example c# objects can inherit from c++ classes and vb procedures can use the c# components.
please note that the microsoft documentations refer cli as clr (common language runtime).
after reading through the ecma standard documents, like me, you will probably develop the feeling that cli is an attempt to standardize the next generation java framework for accommodating the older pre internet era languages like vb and c++.
the five components of the cli is briefly described below. cts - common type system
the common type system, support both object oriented programming like java as well as procedural languages like 'c'. it deals with two kinds of entities: objects and values. values are the familiar atomic types like integers and chars. objects are self defining entities containing both methods and variables.
objects and values can be categorized into the following hierarchy:
types can be of two kinds value types and reference types. value types can further categorized into built-in (for example integer types and float type) and user defined types like enum.
reference type can be divided into three sub categories: self describing reference type, pointers and interfaces. pointers can be sub divided into function pointers, managed and unmanaged types.
value types can be converted into reference type, and this conversion is called boxing of values. de-referencing the boxed value types from the referenced type is called un-boxing.
casting rules from one type to another, for example conversion of char to integer types are also defined within the common type system.
common type system also defines scope and assemblies. an assembly is a configured set of loadable code modules and other resources that together implement a unit of functionality. a scope is a collection of grouped names of different kinds of values or reference types.
cls - common language specification
the common language specification (cls) aids the development of mixed language programming. it defines a subset of common type system which all class library providers and language designers targeting clr must adhere to.
cls is a subset of cts. if a component written in one language (say c#) is to be used from another language (say vb.net), then the component writer must adhere to types and structures defined by cls.
cil - common intermediate language
all compilers complying with cli must generate an intermediate language representation called common intermediate language (cil). the cli uses this intermediate language to either generate native code or use just in time (jit) compilation to execute the intermediate code on the fly.
the microsoft documents refer this standard's implementation as msil (microsoft intermediate language).
jit - just in time compiler
the jit or just in time compiler is the part of the runtime execution environment, which is used to convert the intermediate language contained in the executable file, called assemblies, into native executable code.
the security policy settings are referred at this stage to decide if code being compiled needs to be type safe. if not an exception is thrown and jit process is aborted.
ves - virtual execution system
virtual execution system (ves), is more or less equivalent to the jvm (java virtual machine).
ves loads, links and runs the programs written for common language infrastructure contained in portable executable (pe) files.
virtual execution system (ves) fulfills it's loader function by using information contained in the metadata and uses late binding (or linking) to integrate modules compiled separately, which may even be written in different languages.
ves also provides services during execution of the codes, that include automatic memory management, profiling and debugging support, security sandboxes, and interoperability with unmanaged code, such as com components.
managed codes are intermediate language (il) code along with metadata contained in portable executable (pe) files, these may be .exe or .dll. this needs just in time (jit) compiler to convert it into native executable code. there is also a provision of pre compiled executable which is called unmanaged code. the advantage of unmanaged code is that is does not need to jit compilation but has the disadvantage of unportablity across different operating system (os) platforms.
microsoft's implementation of cli is clr
the microsoft's implementation and adaptation of the above standard has resulted in difference in terminology, for example common intermediate language (cil) is called microsoft intermediate language (msil) and common language infrastructure (cli) is referred to as common language runtime (clr).
these changes in naming convention, i believe, is to create a branding distinction while implementing the standards. this was probably intended to avoid the clash that occurred with the java the language standard, java the island, java the coffee brand and java the sun's trademark! but, in the long run, it will only lengthen the already long list of confusing acronyms and jargons in the programmer's dictionary.
we use cli and clr interchangeably, however, it will be more correct to say that clr is the microsoft's implementation of cli.
apart from scripted languages like javascript and vbscript, the .net framework presently supports three compiled languages, namely: vb.net, vc++ and c# (pronounced c sharp) these language compilers target this runtime. the type verifiable compiler's output is called managed code.
unsafe codes can also be generated by compilers, which is called unmanaged code. garbage collection is only handled for managed codes.
the managed code has access to common language runtime (clr) features such as multi- language integration, exception handling across language boundaries, security and versioning and a simplified deployment .
an interesting facility being experimented by microsoft is the cross language inheritance. for example, a c# class can inherit from a vb object! each of these features will be discussed in detail later.
the clr provides services to the managed code. the language compilers emit metadata, that describes the types, members, and references in the code. metadata is stored along with the code: every loadable common language runtime image contains metadata.
the metadata helps the clr to locate and load classes, lay out instances in memory, resolve method invocations, generate native code, enforce security, and set up run time context boundaries.
the clr, much like java virtual machine (jvm) provides automatic garbage collection facilities to the managed code, this garbage collection feature is called managed data. but unlike java vm, the clr also has mechanism to syntactically switch off automatic garbage collection called unmanaged data, where the programmer is responsible for garbage collection.
the clr has been designed to facilitate cross language integration. two kind of integration is possible: tightly coupled and loosely coupled, which is also called remoting. the tightly coupled inter language method call is achieved within the clr; this assumes that the two languages calling each other are both .net framework compliant like vc++, vb.net or c# or are at least com compliant. thus c# programs can talk to java programs through activex java bean bridge! this is assuming that both the c# and java codes reside on a single computer.
remoting or loosely coupled inter language interaction is suitable when the two interacting programs written in different languages are on different operating system (os) platforms, like c# client residing on windows ce talking to solaris based server side java code. this integration is achieved through an xml based protocol called simple object access protocol (soap) which was proposed by microsoft and is adopted by w3c consortium (http://www.w3c.org). an open source soap gateway implementation of java is available from apache.org at http://xml.apache.org.
soap has transport layer independent, xml formatted content and currently http and smtp transport implementations are available from both microsoft and apache.org for .net framework and java platforms respectively .
all .net framework components carry information about the components and resources they use, in a xml formatted document called metadata. the runtime, uses this information to dynamically link the components, ensuring version integrity and security controls; this makes the application theoretically more resilient against version changes. only time will tell if this innovation is successfully implemented.
another good feature introduced in this new framework is reduction of windows system registry dependency. registration information and state data are no longer stored in the system registry, but inside the metadata. this should make the server side component deployment much easier.
.net framework's common language runtime (clr) claims to have the ability to compile once and run on any cpu and operating system that supports the runtime. we will see if this becomes a real possibility in near future.
common intermediate language (cil)
the .net framework's implementation of common intermediate language (cil) is called microsoft intermediate language (msil). unless specified otherwise, we will use the terms intermediate language (il), msil and cil interchangeably.
managed code is produced by one of the three compilers which translate the source code into microsoft intermediate language (msil).
common intermediate language (cil) and therefore it's microsoft rendering called microsoft intermediate language (msil) is said to be a cpu independent set of instructions that can be efficiently converted to native code.
msil intermediate instruction set has instructions for loading, storing, initializing, object method calling , many conventional instructions for arithmetic and logical operations, control flow, direct memory access, and exception handling. all the three languages included in this framework have java like /"try catch/" exception handling facility.
just like java, before the managed code is executed, the intermediate language is converted to cpu specific code by a just in time (jit) compiler. the runtime supplies one or more jit compilers for each computer architecture it supports. however, the code can be compiled into native form during installation itself.
when a common language specification (cls) compliant compiler produces common intermediate language (cil), it also produces metadata, describing the common language types (clt) specific types used in the code, including the definition of each type, the signatures of each type's members, the members that the code references, and other data that the runtime uses at execution time.
the msil and metadata are contained in a portable executable (pe) file which is an extension of the microsoft portable executable (pe) and unix world's common object file format (coff) used for executable content. they appear to the user as the familiar .exe and .dll files.
one of the fundamental differences between java virtual machine (jvm) instruction sets and common intermediate language (cil) is that jvm is big endian ( most significant byte first) and cil uses little endian ( least significant byte first) binary representation. this difference will not be apparent to most of the programmers. only system level programmers would have to deal with it.
the file format, can accommodate either of common intermediate language or native code as well as metadata, a signature pattern enables the operating system to recognize common language runtime images.
the presence of metadata in the executable file enables the components to be self descriptive. this eliminates the need for additional type libraries or interface definition language (idl) used in dcom and corba. the runtime locates and extracts the metadata from the file as necessary during execution.
managed execution
there are two kinds of codes that can exist inside the executable files now, the old machine dependent codes, like existing activex controls, are called unmanaged
as mentioned earlier, there are currently three compiled languages c#, c++ and vb provided by microsoft, which target the common language runtime (clr). this runtime is a multi-language execution environment, and supports a common base of data types and language features. however, the language compiler determines what subset of the runtime's functionality is available, and the design pattern of the code is influenced by the features exposed by the compiler.
the coding syntax is determined by the compiler, not by the runtime. if the component is required to be completely usable by components written in other languages, it must use only language features that are included in the common language specification (cls) in the component's exported types.
application domains
application domains are light weight process. it can be visualized as an extension of java's sandbox security and thread model.
the common language runtime provides a secure, lightweight unit of processing called an application domain. application domains also enforce security policy.
by light weight it means that multiple application domains run in a single win32 process, yet they provide a kind of fault isolation, that is fault in one application domain does not corrupt other application domains. this aids in enhancing execution security against viruses as well as helps in debugging faulty codes.
the common language runtime relies on type safety and verifiability features of common type system (cts) to provide fault isolation between application domains. since type verification can be conducted statically before execution, it is cost efficient and needs less security support from microprocessor hardware.
each application can have multiple application domains associated with it. and each application domain has a configuration file, containing security permissions. this configuration information is used by the common language runtime to provide sandbox security similar to that of java sandbox model.
although multiple application domains can run within a process, no direct calls are allowed between methods of objects in different application domains. instead, a proxy mechanism is used for code space isolation.
assemblies
an assembly is the functional unit of sharing and reuse in the common language runtime. it is the equivalent of jar (java archive) files of java.
assembly is a collection of physical files package in a .cab format or newly introduced .msi file format. the assemblies contained in a .cab or .msi files are called static assemblies, they include .net framework types (interfaces and classes) as well as resources for the assembly (bitmaps, jpeg files, resource files, etc.). they also include metadata that eliminates the need of idl file descriptors, which were required for describing com components.
the common language runtime also provide api's that script engines use to create dynamic assemblies when executing scripts. these assemblies are run directly and are never saved to disk.
microsoft has greatly diminished the role of windows registry system with introduction of assemblies concept, which is an adaptation of java's jar deployment technology.
assemblies is an adaptation, but not a copy of java's jar technology. it has been improved upon in some ways, for example it has introduced a versioning system. however, since the .net framework is skewed towards the windows architecture some of the java's jar portability features may have been sacrificed.
again, similar to jar files, the assemblies too contain an entity called manifest. however, manifest in .net framework plays somewhat wider role. manifest is a metadata describing the inter-relationship between the entities contained in the assemblies like managed code, images and multimedia resources. manifest also specifies versioning information.
the manifest is basically a deployment descriptor, having xml syntax. java programmers can relate it with j2ee (java 2 enterprise edition) deployment descriptors for ejb (enterprise java beans) applications.
the microsoft documentation stress that assemblies are /"logical dlls/". this may be a reasonable paradigm for vb or c++ programmers, but java programmers will find it easier, if we visualize assemblies as an extension of jar concept. however, unlike jar, each assembly can have only one entry point defined, which can be either dllmain, winmain, or main.
as stated earlier, assemblies have a manifest metadata. this contains version and digitally signed information. this purports to implement version control and authentication of the software developer. version and authentication procedure is carried out by the runtime during loading the assembly into the code execution area.
again, much like java's trusted lib. concept, .net assemblies can be placed in secured area called global assembly cache. this area is equivalent to trusted class path of java. only system administrators can install or deinstall assemblies from the global assembly cache. there is a place for downloaded or transient assemblies called downloaded assembly cache. the assemblies loaded from global assembly cache run outside the sandbox and have faster load time as well as enjoy more freedom to access file system resources. the assemblies loaded from the downloaded cache area are subject to more security checks, therefore are slower to load and since they run inside the sandbox; enjoy much less privileges.
assemblies manifests also contain information regarding sharing of code by different applications and application domains.
to summarize, the operating system can have multiple applications running simultaneously, each such application occupies a separate win32 process and can contain multiple application domains. an application domain can be constructed from multiple assemblies.
execution
the common language runtime provides the infrastructure that enables execution to take place as well as a variety of services that can be used during execution. before a method can be executed, it must be compiled to processor specific code. each method for which msil has been generated is jit compiled when it is called for the first time, then executed. the next time the method is executed, the existing jit compiled native code is executed. the process of jit compiling and then executing the code is repeated until execution is complete.
as mentioned earlier, the recompilation can be avoided by compiling the code during installation into native executable code.
during execution, managed code receives services such as automatic memory management, security, interoperability with unmanaged code, cross language debugging support, and enhanced deployment and versioning support.
jit compilation
before intermediate language (il) can be executed, it must be converted by a .net framework just in time (jit) compiler to native code, which is cpu specific code that runs on the same computer architecture that the jit compiler is running on.
microsoft's designers insist that the runtime never interprets any language, it always executes native code, only conversion to native form may be deferred. even the scripting languages like vbscript are now compiled and executed!
the idea behind jit compilation recognizes the fact that some code may never get called during execution; therefore, rather than using time and memory to convert all of the msil in a pe (portable executable) file to native code, it converts the intermediate language as it is needed during execution and store the resulting native code so that it is accessible for subsequent calls.
the loader creates and attaches a stub to each of the type's methods when the type is loaded; on the initial call to the method, the stub passes control to the jit compiler, which converts the msil for that method into native code and modifies the stub to direct execution to the location of the native code. subsequent calls of the jit compiled method proceed directly to the native code that was previously generated, reducing the time it takes to jit compile and execute the code.
the compilation process (jit or during installation time) converts the intermediate language (il) to native code. the code however, must pass a verification process. verification examines the intermediate language (il) and metadata to see whether the code is type safe, that is, it accesses only the authorized memory locations, identities are what they claim to be and reference to a type is compatible with the type referenced. these features protects the application from bugs and viruses.
during the verification process, intermediate language (il) code is examined in an attempt to confirm that the code can access memory locations and call methods only through properly defined types.
due to design limitation of some programming languages, like 'c', it's compilers may not be able to produce verifiable type safe codes, such codes can only be executed from trusted area.
runtime hosts
the runtime is typically started and managed by environments like asp.net, ie or the windows shell. these hosting environments run managed code on behalf of the user and take advantage of the application isolation features provided by application domains. in fact it is the host that determines where the application domain boundaries lie and in what application domain user code is run in. the common language runtime provides a set of classes and interfaces used by hosts to create and manage application domains.
there are five common language runtime hosts:
asp.net - asp.net creates application domains to run user code. application domains are created per application as defined by the web server.
internet explorer - ie creates an application domain per site.
windows shell exe - each application that is launched from the command line runs in a separate application domain.
vba - vba runs the script code contained in an office document in an application domain.
windows forms designer - the windows forms designer places each form the user is building in a separate application domain. when the user edits the form and rebuilds, windows forms shuts down the old application domain, recompiles the code and runs it in a new application domain.
conclusion
.net is definitely an improvement over java framework, but it is not going to displace java any time soon. though in coming years java and .net will converge.
it currently lacks support for other platforms. since .net has been architected by microsoft, it is less likely to find the open source support base of free thinking programmers, which was one of the main reasons of java's popularity.
java has been there for more than five years now, and java programmers have already survived two waves of downturn. first in 1998 when most web sites weeded out applets and second in late 2000, when all the vc fueled dotcom hot balloons came down. scott adams' dilbert strips at http://www.dilbert.com has a good fill of vc and dotcom cartoons.
all remaining employed java programmers must have a good handle of .net architecture to continue to remain employable.
the party is over for dotcom, so let's party with dotnet !!!
