Microsoft’s vision of .Net Framework
Distinguished Engineer Anders Hejlsberg discusses .Net’s evolution
AS MICROSOFT’S DISTINGUISHED engineer of its developer division, Anders Hejlsberg has been a central figure in the development of Microsoft’s .Net Framework. The author of Borland’s Delphi and .Net’s new C# language, Hejlsberg sat down with InfoWorld Test Center Director Steve Gillmor and News Editor Mark Jones to discuss .Net’s evolution from idea to implementation.
InfoWorld: How do the HailStorm technologies integrate — or not integrate — with the vision of .Net Framework?
InfoWorld: Groove Network’s Ray Ozzie calls the Web Services Security specification [part of Microsoft’s GXA work] an important step in making “edge services” a viable proposition. Is the GXA stack a requirement for rich services at the edges of the network?
Hejlsberg: Every one of those protocols that we’re building through GXA will bring more people into the fold and will bring us closer to our realization of the vision. But next you’re going to want reliable messaging or transactions or authentication. We know that we need them, we have a very good idea of how to build them, we’re working on it — and certainly security is probably the first one, which is why we led with that.
InfoWorld: What is the most important factor in terms of productizing these technologies?
Hejlsberg: It’s just time. How do you build a framework for messaging with authentication and security? What does your message pipeline look like? How do you integrate with existing messaging systems and servers and distributed transactions, and on and on? It’s a big space and it takes time to build the right architecture. We have some great foundations in place with the .Net Framework, but it’s essentially [a question of] evolving that.
InfoWorld: Has the HailStorm project or any other work inside Microsoft had any impact on .Net Framework’s evolution?
Hejlsberg: [Yes, in] the whole notion that the framework isn’t just a framework or a new VBRUN [Visual Basic run-time] … it’s actually the new way that we build system APIs at Microsoft, the new way that the Windows API will surface to the end developer. It used to be that our APIs were readily available to the developer base, but over time all these layers in between the API and the developer [have emerged]. They’re all going through Framework — be it MFC [Microsoft Foundation Class Library] or tools through VB [Visual Basic] or whatever — and the richness of the API is not directly available anymore. It needs to first be encapsulated and shaped around a particular programming model. What we’re actively trying to do is elevate the Windows API to that higher abstraction level, where the richness is directly available if you’re writing Script or VB or whatever, [so] you don’t have to first wait for some vendor to create an encapsulation that you can then talk to.
InfoWorld: How would that manifest itself in an application such as Exchange?
Hejlsberg: Any interfaces to Exchange — be they CDO [Collaboration Data Objects], MAPI [Messaging Application Program Interface], or whatever — will be .Net Framework-managed interfaces. You should be able to talk directly to these objects. They’re not COM objects or strange APIs that first need to be imported, they’re just there. There’s complete parity or an impedance match between the language and the underlying server technology. And this will be true for all of our servers and [for] the OS itself.
InfoWorld: How are you attacking the problem of security in .Net Framework?
Hejlsberg: Today we take the notion of I/O and streams and whatever completely for granted. But at one point in time, someone actually sat down and thought “Wow, how could we come up with a common abstraction?” And then over time you [had to] build the appropriate abstractions and encapsulations. The same is true of what we’re talking about with GXA. We need a security abstraction in the framework and that security abstraction needs to be used by all of the other pieces of the framework. … The same is true for authentication. For example, we should have a shopping cart abstraction — not build a black box, but rather make it open-ended.
InfoWorld: Is the UDDI [Universal Description, Discovery, and Integration] model a realistic model for scaling up to a dynamic Web?
Hejlsberg: You can talk to UDDI through the Web services interface, but it’s not what I would characterize as a high-traffic, high-throughput kind of site. That needs big industrial strength behind it, really.
InfoWorld: Are you working on anything that is [a realistic model]?
Hejlsberg: Are we working on anything industrial strength that has Web services behind it? A lot of our products [have Web services behind them], like SQL Server. But in a sense, we’re one instance removed. Yes, the customers will use that, and therefore we’re working on it through our customers.
InfoWorld: What’s your assessment of BEA’s WebLogic Workshop Cajun development environment? How does it compare with Visual Studio.Net?
Hejlsberg: It’s a very nice tool. I was quite impressed. Cajun is really about building Web services, but that’s about it. It’s the tool that you would use for Web services, but then when you’re going to build the rest of your app or do remote debugging or all of these other things, it doesn’t really do that. It’s a cockpit for writing a Web service.
There’s a lot of boring stuff that has to be in a development environment today. It is amazing how much stuff goes into Visual Studio and how you can just keep digging. Take the whole data design environment, for example. You can look at all your tables in the hierarchy. All of those things are actually important when you’re building apps. We tend to be very serial in our thinking, in our marketing. [We think] it’s all about Web services and forget about everything else. Well, no, [you can’t] forget about everything else. You’ve got to be able to do all of that and then you’ve got to be able to do Web services. It takes a lot to be a grownup development tool today.
InfoWorld: How does Visual Studio handle the kind of asynchronous, coarse-grained transactional conversations that Cajun is designed to generate?
Hejlsberg: When I import a Web service — point at a WSDL file and suck it in — I get methods such as “Get data” where I can synchronously send my query over. I also get asynchronous versions of those methods — a “Begin get data” that calls “Get data” asynchronously — and then it’ll call me back on a call-back delegate or whichever way I want to be called back when the method completes. Asynchronicity is there, built in.
InfoWorld: Is Cajun more about rationalizing the jumble of J2EE [Java 2 Enterprise Edition] APIs?
Hejlsberg: Yes. When we set out to build the [.Net] Framework and Visual Studio, we knew that we were heading right down that path of XML Web services. With Java, it’s more of an afterthought. It’s just a historical fact that there were no Web services around when the Java platform was created, and so they invented a bunch of other technologies — RMI [Remote Method Invocation], CORBA, and so forth — for building these heterogeneous distributed systems. Now they’re faced with peppering on XML and Web services later, and that’s harder. And there are more impedance mismatches.
InfoWorld: [In] the [same] way you’re peppering on COM+ services into .Net?
Hejlsberg: Our enterprise services? It’s totally integrated into .Net Framework. But yes, we’re still calling the Win 32 API [for COM+]. In that case, everything’s peppered on.
InfoWorld: That’s my point.
Hejlsberg: What I’m saying is that we are not selling you a platform where you have to do a careful reading, but you have to avoid anything that refers to RMI, and then you have to conceptually substitute the XML Web services in there, and so on. This is a historical thing that happens: As you grow older you accumulate more and more, and then there [are] things that you want to de-emphasize and that’s a hard problem.
InfoWorld: Are you taking advantage of the innovations of Java coming later?
Hejlsberg: No, we’re taking advantage of the innovations in Web services, and the fact that from a timing perspective we’re right there to execute [them], because that is the distributed application technology that underlies any kind of app you build with the .Net Framework. It’s not some other technology that you then have to remap and make look more XML-ish or Web service-ish.
InfoWorld: How do Web services evolve to more effectively cache data at the edges of the network?
Hejlsberg: Web services [are] about making remote procedure calls over the Internet. I don’t know what you can do other than move the machine you’re calling closer to you. I suppose you could assume that the services are invariant, that given the same input they produce the same output. But that’s not necessarily the case. Certainly in the database world, it is specifically not the case.
InfoWorld: Intel’s vision is to bake SOAP [Simple Object Access Protocol] acceleration, the Web services stack, into silicon.
Hejlsberg: Oh yes. Today the vision that you can execute on, so to speak, is running SOAP over HTTP. But that clearly, down the line, with DIME [Direct Internet Message Encapsulation] and so on, is not going to be the only way you run Web services. There’s ample opportunity to optimize in places; I’m sure XML is more verbose than some sort of binary encoding. It’s funny to talk about all of that, the verbosity of XML, and yet here we are talking about using XML for a kind of application that we could have never envisioned if it had been based on some close-ended binary standard. It’s a fine dial — you can’t just crank it all the way over, because then everybody leaves the table. It’s super-efficient but no one’s interested. There’s a balance there, a tightrope that we’re trying to walk.
