Sponsored Link •
Bill Venners: A year ago, Microsoft invited me to a .NET seminar for Java authors, and I was shown something called Windows Forms. For me, Windows Forms were somewhat reminiscent of Java applets in that they were user interface components you could download across the network and run in Internet Explorer. When Java first appeared, it generated excitement because of what applets represented: untrusted code flying across the network and running in a sandbox on the client. One of my goals in attending the .NET seminar was to try and ascertain whether the CLR could support that mobile-code model. And my conclusion was that it could, but nevertheless, all the buzz I hear about building distributed systems with .NET is centered on SOAP and the exchange of XML. In other words, all the talk is about mobile data, not mobile code. What is the place of mobile code in the CLR vision? Why does the CLR support mobile code if what you're planning to send across the network most of the time is XML?
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?
Dan Fernandez: You see a lot more people wanting to exchange information, rather than code, across the network. And because of firewalls, you often in practice just can't exchange code. We had a heck of a time with DCOM because of firewall requirements, and these were internal firewalls within an organization. It's very difficult to challenge the firewall policies. Security experts will open only port 80, and on port 80 they will allow only HTTP requests through. They won't allow any other protocol through.
Because SOAP uses the HTTP protocol, you can exchange and act on messages. I can call a web service from anywhere and get the message across, whether it is within an organization or across organizations. That's the grand vision. We have this great thing called the internet. Everybody's using it. It's very popular. We want to leverage that capability, that network, but that means we have to play with certain constraints. We have to use HTTP as the messaging protocol, over port 80. Basically, we must define a programming model within these confines.
Bruce Eckel: The way I see web services, it's almost like you're saying the machine is the object. I can call methods on the machine, which can be anything. And the machine can be implemented in anything.
Eric Gunnerson: Yeah, exactly. That's really the web services model.
And I think there's one other issue. It's going to sound strange when I say this, but I think we actually care more about not constraining whom you are talking to than Java does. When you send mobile code in Java, you're assuming the other side has a JVM that supports what you want to do. That brings up the same sort of issues you had with DCOM and CORBA. Anytime you're doing something that presumes what's on the other end...
Dan Fernandez: It is more tightly coupled.
Bruce Eckel: It's over-constrained.
Eric Gunnerson: It may be over-constrained. I think it really depends on the scenarios you are looking at. If you know what's on the other end, in Java you might pass classes across, in .NET you might use .NET remoting. You might pass assemblies across. I just think in a lot of cases you don't want to make that decision, because of the constraint it will put on you later.