The Artima Developer Community
Sponsored Link

Articles Forum
Insights Into the .NET Architecture

4 replies on 1 page. Most recent reply: Feb 11, 2004 8:28 AM by Joe Cheng

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 4 replies on 1 page
Bill Venners

Posts: 2285
Nickname: bv
Registered: Jan, 2002

Insights Into the .NET Architecture Posted: Feb 8, 2004 9:00 PM
Reply to this message Reply
Eric Gunnerson, the C# Compiler Program Manager at Microsoft, talks with Bruce Eckel and Bill Venners about several architectural design decisions in .NET, including multiple inheritance of interface, the emphasis on messaging over mobile code, internal access in assemblies, and the side-by-side execution answer to DLL Hell.

Read this interview with Eric Gunnerson, C# Compiler Program Manager at Microsoft:

What do you think of Eric's comments?


Posts: 10
Nickname: sakesun
Registered: Aug, 2003

Re: Insights Into the .NET Architecture Posted: Feb 9, 2004 9:13 PM
Reply to this message Reply
Ouch ! three .net-related interviews in a row !

Bill Venners

Posts: 2285
Nickname: bv
Registered: Jan, 2002

Re: Insights Into the .NET Architecture Posted: Feb 9, 2004 9:59 PM
Reply to this message Reply
> Ouch ! three .net-related interviews in a row !

Yeah, I ran a survey in December and one of the themes of the feedback was that people didn't like the way I split up the interviews. So I went back to doing them consecutively. First I finished Matz's interview about Ruby (two in a row), then I finished the last two installments of Ward Cunningham's interview, and then the last two installments of Anders Hejlsberg's interview. This week I decided to publish Eric Gunnerson's interview, because it took place the same day as Anders' interview, and that was six months ago. I don't want to get to the point where I have to introduce articles like, "Approximately five years ago I interviewed someone at Microsoft. I'm not sure who, because the records were destroyed through the natural decay of time, but here's what I kind of half remember was said...."

Next week it's back to Bjarne Stroustrup, creator of C++. I plan to publish those back to back. I have probably four more weeks worth. After that, I'll finish publishing the Bertrand Meyer interview.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Insights Into the .NET Architecture Posted: Feb 10, 2004 8:06 PM
Reply to this message Reply
Eric Gunnerson: I'll give you my opinion, which may not be the opinion of the CLR guys. First of all, the idea of exchanging code across the network scares the hell out of me from a security standpoint. One of our big focuses is trying to allow people to write stuff that is more secure than what they're writing now. But I guess my big question is, what is the architectural advantage of using mobile code? Maybe I haven't played around with it enough, but I just don't see a lot of need for doing that on the fly. If I want to do that in .NET I can. I can go across the network and fetch some code. I can load the code out of memory, I don't have to write it out to disk first. In other words, the package of a component is an assembly. I could read a byte stream and from that create and load an assembly. So I can do that sort of thing, but why would I want to architecturally?

One of the primary advantages of mobile code is the ability to change the clients interface to the server when you really need to, and not have to introduce a new client. With Java RMI, you might start out with a whole collection of simple stubs that provide remote proxies that client software uses to talk to a 'service'. If you need to optimize caching or provide some other change in protocol, you can convert those 'stubs' to 'smart proxies' which are just more downloaded code (other than the proxy) that can carry an object reference to the new stub, but provide the old interface in addition to a new interface, or changed caching or interaction strategies.

In particular, it is very vital in a mobile network environment to allow a client to try multiple servers. You can either deploy this code as part of the client if you don't have mobile code, or you can deploy it from the server as mobile code so that you can administer the set of alternate servers, change the parameters or change the implementation at will, with all clients getting the changes automatically.

The 'agent' crowd has a whole other set of examples of how mobile code can be used to allow you to do things that are not possible with simple messages.

And still the primary issue with SOAP is that everyone has to write code to convert the SOAP transported data into a set of objects specific to the platform that the data is received in. If you just use Java and the RMI model, you get a Java language object that is ready for use, and this means that as the originator of the object you have more choices of how to transport and represent the internals, and as the receiver, you just know that the object implements a particular interface or is extended from a particular base class.

The Jini lookup server uses interface/class equivalence for finding services. This makes it possible to ask for things based on what they do for you instead of based on where they are, or who created them. The deployers of such Jini services then have the ability to change everything as long as the same interface or class is presented to the users. This makes the system much more flexible, and lets you deploy services in trials more readily, and to change them at will without worrying about how they'll be located. In fact, moving services between machines becomes completely invisible to clients because they are using multicast to find lookup servers and asking for services by implementation instead of by name.

Also, the Jini 2.0 security model allows the LUS to demand proper identification to register services, and allows clients using the lookup server to demand proper identity before using offered services. Thus, you really can secure your systems on a public network by using application level security without having to worry about what the network is letting through...

Joe Cheng

Posts: 65
Nickname: jcheng
Registered: Oct, 2002

Re: Insights Into the .NET Architecture Posted: Feb 11, 2004 8:28 AM
Reply to this message Reply
Correct me if I'm wrong, but .NET assemblies cannot be unloaded from app domains once they're loaded; you have to unload the entire app domain. This is in contrast to Java where you can setup a hierarchy of classloaders that you can (IIRC) swap in and out as you please.

Wouldn't this architectural difference alone make it difficult for .NET to support mobile code a la Java? You can load assemblies dynamically, but you can never then reload the same assembly within the lifetime of that app domain?

Actually, that doesn't make sense, does it? ASP.NET pages are compiled the same way JSP's are, and I would find it hard to believe that the app domain needs to be restarted each time an ASP.NET page changes... so is there some way to change a .NET class within the lifetime of an app domain?

Hope someone can shed some light on this for me. I've always been interested in the tradeoffs between .NET AssemblyLoader vs. java ClassLoader but never really grokked them.

Flat View: This topic has 4 replies on 1 page
Topic: To Plan or Not to Plan Previous Topic   Next Topic Topic: Working the Program

Sponsored Links


Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use