Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Heard on .NET Rocks!: Spring.NET

This installment of .NET Rocks! is an interview with Don Box, Ted Neward, and Mark Pollack about Swing.NET, a .NET implementation of the Swing project that had its roots in the open-source world and is used extensively with Java.


advertisement
am the host of ".NET Rocks!", an Internet audio talk show for .NET developers online at www.dotnetrocks.com and msdn.microsoft.com/dotnetrocks . My co-host Rory Blyth (www.neopoleon.com) and I interview the movers and shakers in the .NET community. We now have over 96 shows archived online, and we broadcast a new show every Friday night now from 7:30 PM to 8:45 PM, Eastern Time, and make them available for download (with podcasting support) on the following Monday. For more history of the show check out the May/June 2004 issue of CoDe Magazine, in which the first column appeared. Anyway, in each issue, I like to highlight some of my favorite moments from a recent show. Show number #89 published November 17th, 2004 was a discussion with Don Box, an architect on the Indigo project at Microsoft, Ted Neward, a technical lead and architect implementing client/server solutions using a variety of languages, tools, and operating systems, and Mark Pollack, a Partner at CodeStreet LLC, who is also the administrator for Spring.NET, about Swing.NET, a .NET implementation of the Swing project that had its roots in the open-source world and is used extensively with Java.

Carl: Mark, what is this new development in the Java world that you were telling me about? Mark: Well actually it's a conversion of the popular Spring framework to .NET. I find it interesting that ideas from a popular open source project [made its way] into .NET. Spring is an application framework that at its most base layer has a lightweight container, a glorified object factory that creates objects, configures them and resolves dependencies between them. But on top of that Spring offers things like AOP support (Abstract Oriented Programming), various helper classes for doing EJB (Enterprise Java Beans) development, and sort of a whole slew of transaction management facilities. In some sense there's a lot of the same stack that people find in EJBs that people can use in a sort-of a la carte manner.

Carl: So, Ted or Don, have you guys heard of Spring .NET? Ted: Well, yeah. Basically Spring has been a reaction, almost a rejection, of the EJB and the complexity therein. Because a lot of Java developers are not building these super high-end high-scaling systems. Most developers are building systems that are meant for 100-500 concurrent users, and want to develop them in a timeframe that doesn't measure in years and so forth. So, that's where Spring started from. And it's been interesting to watch because, and Don may disagree with me, but to a large extent the .NET enterprise development community has grown from the "we want to start from the departmental project and grow into the large-scale enterprise project" where the J2EE guys seem to be going the other direction. It's kind of fun to watch these two environments on a head-on collision course with one another at some point somewhere in the middle. So, it's going to be interesting to watch.



Mark: Exactly right. If you look at building an application using Spring, it more closely resembles the facilities that are in .NET than in an EJB application, at least before the EJB 3.0 specification came out. Ted: Even there, once EJB 3.0 ships I don't think it's really going to change much for your average Java developer. I mean, when you build a COM+ app you use attributes to indicate a transaction and so forth. Well, we didn't have any such facility in Java. Remember we just recently defined custom attributes for Java, which is actually how Mark and I met because he took over the open-source project that I had started to do that.

Mark: I got involved in Spring because they wanted to use the attribute [code] that I had developed. Ted: Right, so basically, in order to be able to do that equivalent you had to write this rather hideous looking XML file. And what EJB 3.0 is basically trying to do is make those XML files go away in favor of using—as COM+ has been doing all these years—custom annotations, or custom attributes to capture some of that stuff. There are a few other things but that's the big thing. That's why a lot of Java developers are interested in following the EJB 3.0 release.

Carl: So Don, what's your exposure to Spring and/or Spring.NET? Don: Well, I certainly have been observing the phenomena. It's pretty fascinating to watch the reaction to the heavier-weight containers. I'm not really sure what role these things play on the .NET side, although I think it's great that people are doing the methodic experiment if nothing else.

Mark: I think people pay attention a lot to the enterprise service aspects of Spring, but those are really the highest levels of the application framework. But at its heart there's just a conceptually simple object factory which really is more reminiscent of traditional abstract factories you might read about in the Gang of Four or whatever. There's a lot of value to that just to support basic OO concepts like separating interfaces from implementation and so on. So it really ends up structuring applications and giving you flexibility and plugability in ways that you wouldn't really have been led down that path before if you were just left to your own devices. Carl: Being left to your own devices I suppose is what the experience of most Java programmers is, isn't it? Because there isn't a base class library that's a sort-of a standard, right? My brother is a Java programmer and we sort-of compare notes once in a while. And he's using POJO—Plain old Java Objects, where he's developing every line of code from the ground up. Do you find a lot of [Java] developers have gone that way?

Ted: Well, you gotta remember, Carl, that the Java community does not have, you know, one large IDE that everybody uses. So we have to be somewhat careful in terms of what degree of support do you want. Now at the same time... Don: Ted, I should correct you. There are people who don't use EMACS on this platform.

[laughs] Don: It is not a monoculture. There are a few people who use alternative IDEs, but yes, you're right. The majority of us still use EMACS.

Ted: So anyway, the Java community is so anarchic it's almost organic in a sense that we do have some higher order tools and utilities and so forth. Remember MSBuild was basically considered a clone of ANT, which of course grew up in the Java community, because we discovered that make just doesn't cut it. So there's been a lot of cross-pollination back and forth, which is good. But the thing that the Java folks don't have is any sort of agreement between all these various projects. So you've got four or five of these different lightweight containers that are doing many of the same things that Spring is doing. So trying to get agreement... when you say there's no one Base Class Library you're right. There's like four or five, and that's where the fun begins. Carl: Do you think that sort-of environment yields better results but maybe over a longer term, where the cream rises to the top, whereas you know with Microsoft it is sort-of dictated that we all use the same framework? That's good, I think, but I don't have any experience in the other camp.

Ted: Well I think it yields a situation where...it's both a plus and a minus. There's a very old saying that says your strength is also your weakness and your weakness is also your strength. In the Java world, when you get a group of Java guys together and the first thing we have to agree on is what IDE are we going to use. The second thing we have to agree on is what Web framework we are going to use. The third question is what container are we going to use. We just get into all of this, you know, paralysis that you don't get in the .NET space. At the same time you get into this situation where you say "gosh I really wish ASP.NET did X, Y, or Z" Well, too bad. In the Java space there's probably at least one or two frameworks that does X, Y, or Z. And if not, you'll just go off and start your own. Carl: Well, nobody's saying you couldn't start your own in ASP.NET either, but...

Mark: Yeah. One of the developers I work with is developing master page support using ASP.NET 1.1 for example. Ted: Yeah, but it's more of a cultural thing, Carl, more than anything else. In the Java space if something doesn't do what I want it to do, I'll go and write something and contribute it back to the community. I just don't see that amongst the .NET developers that I talk to and hang out with [with a few exceptions]. In the Java space there are hundreds, if not thousands.

Don: Yeah, although Ted, I'm remembering back to the old days of the OS/2 vs Windows debate of the late 80s early 90s. And one of the classic characterizations was that the reason you had all this debate from the OS/2 side, and on the Windows side nobody would show up for the debates because the Windows guys were all busy solving problems. Carl: And making money, yeah.

Don: There is something to be said for, you know, people can use the New operator, and you know, if they have to change it they fix the code and it solves the problem, and sitting around contemplating how to add indirection to New isn't something that this culture is as conducive to. Unlike the Java world which is just ripe with that kind of experimentation. As someone who can just observe it from the outside, kind of like an archaeologist, it's great. I'm fascinated by it. But I'm pretty thankful that a lot of people I work with aren't twisted around that particular axle. Carl: Mark, you mentioned a couple things about Spring, let's dive into that in a little bit of detail. You mentioned some transaction support?

Mark: Yeah, in the Java world you're able to have an abstraction of transaction management. In some sense this is a reaction to the way things were done in EJBs where people like having declarative transactions where you can just annotate or use a configuration file to begin and stop your transaction. But you can't do that if you're using plain JDBC as your transaction management, you have to use JTA. So Spring allows you to plug in an implementation of a transaction manager. Most applications just have one single database and have no need to use a full-fledge distributed transaction service, but yet you could still get the features of declarative transactions. And if you need to scale up to use that facility, you could and you wouldn't be tied in to having to use [EJB]. Carl: That's pretty cool. What were some of the other things you mentioned?

Mark: Well just an abstraction of that is AOP in general where declarative transaction management is just one particular custom attribute that results in that particular behavior, but you're free to invent your own such as pooling, and such simple things as logging or security, if you want to impose a particular security policy on your code. Carl: Attributes are really the big story, then...

Mark: That's one way to express it, the idea being that you have the ability to pick a particular place in a very abstract way in your code saying that all methods that have this particular signature [and] will have this functionality attached to it. Don: So, since we have a live developer of one of these frameworks, I have a list of questions I've been dying to figure out. One is, I know that in the interception plumbing we've got around Microsoft, both MTS/COM+ and the context plumbing in the CLR, we have to bend over backwards to make sure that when an object reference is being intercepted, and floats out in the wild, that we never let raw unintercepted references get out. With these dependency injection frameworks, how are you guys plumbing it such that naked references don't seep out by accident?

Mark: Well the way it works in Spring is that you ask the object factory to create you a proxied instance. Don: Sure, but what happens if inside of my object that's being intercepted, I call out to someone else and I pass my this reference as a parameter?

Mark: Yeah, that's fine. Don: So how does the guy who I'm passing it to get the interceptor?

Mark: If the object you're passing originally was a proxied class he just gets a reference to that proxied class. Don: But if I need an Instance method on the proxied class, my this pointer is unadorned, it's unintercepted. And if I pass that to someone else I lose all of these dependency injection features.

Mark: The this pointer you're passing around is already the proxied class. Don: But at the language level inside my instance method the this variable is raw, it's not wrapped.

Ted: Mark, are these all dynamic proxies in Spring? Is that how it works? Mark: Spring uses dynamic proxies for interfaces but it uses tglib for classes.

Ted: So you're doing byte-code weaving then? Mark: Well it would do byte-code weaving if you wanted to apply an aspect to a class, but very commonly you can just apply this to an interface and then you can use Java's dynamic proxy facility which is very flexible.

Ted: So inside the object that got proxied, this still refers to that object, not the proxy. Mark: Oh, that is correct, yeah.

Ted: So how do you prevent me from returning this from inside the object? Mark: You don't. I mean you could potentially do that, I suppose.

Ted: So I guess the answer, Don, is don't do that. Carl: We have our own don't do thats in .NET, though, you know?

Ted: Well the point though, Carl, is still valid. This becomes one of those myths, legends, and lore that developers just have to learn. And when you're doing a project that's the size of COM+ or Indigo or something, you know, don't do that just doesn't fly very well. There were lots of don't do that's in COM and we all know how well that worked. Carl: Sure.

Mark: Usually all the references you'd have that you'd want to pass around typically would be set through the container itself through its dependency resolution mechanism. That doesn't mean there isn't enough rope [to hang yourself]. Really, in any sort of technique you're going to have best practices. For example in .NET Remoting you can do things in particular ways that aren't the best practice. Don: Although there's differences between best practices and will the plumbing actually work? And, while there's tons of things you don't want to do with .NET Remoting, certainly the Remoting and Context plumbing really went to great lengths to make sure that naked references never seeped out for any number of reasons.

If you haven't listened to our show, please do. One word of warning, however. The shows between January 1st, 2004 and November 15th contain adult-oriented humor. We started in January 2004 with Rory Blyth as the co-host and we delved into some comedy that had nothing to do with programming. I'm glad to say that starting in November, 2004, .NET Rocks! went back to its roots as an interview-only show. To fill our needs to be wacky, we started another show for a general geek-oriented audience called Mondays, which you can check out online at http://mondays.pwop.com.



   
Carl Franklin is a frequent contributor to CoDe Magazine.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap