一个很好的关于J2EE的interview, 有些观点很好

http://www.theserverside.com/events/index.jsp?News10_28_03

When should developers choose to use distributed architectures?

When they can抰 avoid it. I think that a lot of J2EE developers are far too eager to distribute their objects. I think it抯 something that they really should do reluctantly. There are quite a few costs with distributing objects which aren抰 immediately obvious. The first adverse cost is performance. And although that抯 relatively obvious people often neglect that.

The second really big cost is what it does to the ability to practice object-oriented design. For example, you get into the whole scenario of needing value objects to communicate between processes and value objects are not very object-oriented.

I really enjoyed reading Martin Fowler抯 'Patterns of Enterprise Application Architecture'. He formulates Fowler抯 first law of distributed objects: "Don抰 distribute your objects." And I think J2EE developers would be very wise to heed that advice.

Why are value objects evil?

Value objects are evil because they are not objects. Value objects, by definition, don抰 have behavior, and anything that doesn抰 have behavior is not an object. When there抯 a real need for value objects, such as in inter-process communication, you have to accept that trade off. I think it抯 a mistake to welcome value objects into the internals of your application, because once you have to marshall your application抯 domain objects into value objects, your essentially taking away the behavior; there抯 a true impedance mismatch there that developers don抰 always recognize. And you also face non-trivial problems such as how deeply you抮e going to navigate your relationships.

When should you use EJB?

I think we抮e learning that we抳e probably been much too eager to use EJB in the past. I think that EJB is probably going to eventually be seen as a transitional technology towards AOP-based middleware. The first indication for me that I should use EJB is, where I want containment managed transactions, where I want the EJB threading model, and if I抦 writing a message-based application, I抎 be inclined to use message driven beans. However, I think it抯 important to note that there are good alternatives to using EJB in many of those cases.

EJB solves some problems very well but it also has a very significant downside. For example, EJBs are quite difficult to test. So I think we抮e becoming more mature in our use of EJB. We抮e realizing that EJBs are usually best seen as coarse grain components, that EJB does have a value proposition but unless you抳e got multiple indications for using EJB, such as you need declarative transaction management, you need the thread management, you maybe need role based security, unless you got those multiple indications, you probably shouldn抰 incur the cost of EJB just for one facet of what EJB does.

What are the data access pitfalls that you have seen?

I think one of the biggest problems is na飗e object relational mapping. I think that the great majority of J2EE developers are actually facing problems of object relational mapping. It抯 true that entity beans and JDO are both designed to work with any persistent data store, but the fact is that we do generally work with relational databases and we have to accept the good and bad that flows from that.

So the biggest problem is that there is a na飗e mapping between Java objects and individual tables and also a distrust and dislike of relational databases. I think Java developers can be quite arrogant with respect to people with relational database skills. For example, they抮e very often unwilling to accept that an organization may have an investment in stored procedures, and they really want to impose their own view of how the relational model should work.

I think what works best is if you have a natural object model on one side and you have an idiomatic relational database schema on the other. And you try to a sufficiently sophisticated mapping between those two things that neither suffers.

Do we need entity beans?

Short answer: No. Longer answer: Read Chapter 7 of my book, and the answer is still no. Entity beans, I think, were misguided. They have held the cause of object relational mapping back severely, because when entity beans were first introduced into the EJB 1.1 spec as a required part of EJB, there was already sophisticated object relational mapping, such as, TopLink and Apple抯 WebObjects which were far more capable than what EJB delivered at that time. I think entity beans have been playing catch up ever since, but they still haven抰 really gotten to the level of a sophisticated mapping solution.

One of my prime problems with entity beans is they don抰 give you transparent persistence. They don抰 give you anything that remotely approaches transparent persistence and I think that抯 a nasty problem. I actually want to persist domain objects. I don抰 want to persist objects that are essentially dumb value holders. I want to persist rich objects which have behavior in them. And to do that I need to be able to test that behavior. And testing entity beans is extremely difficult.

Also, I don抰 see any good reason for tying persistence to the EJB container. If my persistent objects are in my domain model, I want to be able to use those domain objects in a variety of contexts. The J2EE server is one of those contexts, and I might want to use my domain objects in a J2EE server but outside the EJB container.

So I think that entity beans are the weakest link of the EJB spec. I think the EJB spec should focus on the problems that it solves well and leave persistence mappings to specialist solutions.

How do you decide where to store state?

In web applications, I抦 inclined to say store state in an HTTPSession object. I think the implementations for that are very robust and I think the implementations allow you significant optimizations by having relatively fine grained attributes. I generally don抰 advocate the use of stateful session beans. I think they definitely have a place, but I think they make fairly unusual requirements. For example you might use stateful session beans if you抳e got multiple client types, and you need a central place to store your session state.

In general, if I was writing a richer client, like a stand alone Swing or SWT client, I抎 be inclined to store the state on that client and pass state up to stateless session beans as necessary.

How do you handle writing portable J2EE applications?

I think there抯 several strategies that you can use; one of the most useful is the reference implementation verifier tool. Another useful technique is to ensure that anything that you know upfront is going to be non-portable, you put behind an interface. I think that抯 a very sound, object oriented design practice and that works really well in the J2EE context.

So, certainly, if you need to use a particular feature of your application server, very often you can do that, but you can hide it behind an interface. Where the reference implementation verifier tool helps you is it means that you don抰 end up with portability problems through carelessness. For example, you don抰 want to accidentally make your EJB bean implementation methods final. The reference implementation verifier is very good at picking up those kinds of problems.

Two other things that I would say is EJB is more of a portability problem than the web container. In my experience, servlet applications are very, very portable, EJB applications are much less portable. Finally, I would steer clear of any really unique features of your particular application server. For example, the JBoss 4.0 AOP features, sounds pretty cool, but at least at the moment you are going to get totally tied in to that server if you use those features. So I would tend to favor using, say, a portable AOP framework that isn抰 tied to a particular server rather than using that particular capability of the server. Likewise, I would prefer to use a portable JDO implementation, than to rely heavily, on say, WebLogic抯 enhancement to CMP entity beans.

When is it appropriate to use messaging?

In general, I抦 not eager to use messaging. I guess in the applications I抳e worked with, whether or not to use messaging has not really been dictated by business requirements. For example a lot of web applications that I抳e worked on have had virtually entirely synchronous requirements. In a lot of financial applications, you find messaging absolutely used everywhere. If I have a choice, I抦 inclined to go with the synchronous call. The reasons for that is, it makes the system easy to debug, it also can incur less overhead because , of course, message oriented middleware needs to do quite a bit of work behind the scenes. So, in general, I tend to be a bit skeptical about claims, that using messenging throughout your system will improve performance. I think there抯 no harm in fast rules. I think this is the kind of issue that you really need to resolve on a case by case basis, by doing a vertical slice and looking at benchmarks and maybe experimenting with how easy you could debug that application.

What is the open source project that started from your book?

It抯 called The Spring Framework. When my book was published, there were about 40 packages of infrastructure code that accompanied it. That infrastructure code was drawn from my experience, essentially consulting over the previous few years. It solved a lot of the problems that I抎 seen people grappling with again and again. I抳e been really pleased but since the book has been out, there have been a lot of people interested in that code and now it is a thriving open source project. We have about five active contributors and, I think, ten developers in total, and they抳e been very significant enhancements since the original code was published.

The Spring Framework, essentially goes to places that a lot of other frameworks don抰. For example, if you use Struts, you very often have some kind of home grown solution for people running business delegates to talk to EJBs. Spring gives you a really strong way to find your business objects in the web tier. That can either be in terms of delegates to EJBs, or Spring gives you a lot of support for actually implementing your business objects in the web container. The full range of Spring抯 capabilities is quite extensive now. It has an MVC web framework. It has a JavaBeans based configuration mechanism which means that everything about Spring applications, including Spring itself, is configured in a consistent way, usually in terms of XML files, setting JavaBeans properties. Spring also has a JDBC abstraction layer which makes JDBC exception handling, in particular, much, much easier.

Spring has integration with Hibernate and JDO and some other open source products. And Spring has an AOP framework which enables it to provide a very good substitute for EJB that抯 much lighter weight in many cases. Spring also provides a transaction abstraction. So, you can do programmatic transaction management without direct JDO calls.

I think one of the nice things about Spring is that it抯 layered. For example, if you prefer to use Struts because your developers are very familiar with Struts, you can still use Spring抯 configuration management, maybe AOP framework. Whatever kind of application that you抮e building, you could use Spring抯 JDBC abstraction. So it really provides a lot for developers to choose from, and if they choose a number of things, they抣l find that those things are very, very, consistent.

What are your thoughts about AOP and the industry?

I think AOP is going to be very, very important. I think in the long term AOP is going to change the way we design applications. I think in the short to medium term, it抯 going to have a significant effect on J2EE, primarily, as a replacement for EJB. As I抳e said, I think that EJB is a transitional solution to AOP middleware. I think AOP generalizes a lot of the ideas that we successfully applied in EJB, and makes them both more powerful, but eliminates a lot of the downsides of EJB.

For example, declarative transaction management is one of the nicest features of EJB. But, in fact, we can implement this in a simple way using an AOP framework. So I think we抣l be hearing a lot more about AOP, both in the next one or two years as it becomes a popular replacement to EJB and in the next 5 to 10 years when it really changes the way we design applications.

How have you used AOP in your projects?

Firstly, I抳e used AOP as a replacement for EJB. For example, Spring gives you a very lightweight framework which means that you can enjoy EJB services, such as container managed transactions without an EJB container. So container managed transactions are probably the AOP capabilities I use most often. I抳e also done a variety of things such as automated auditing. I抳e actually done this using AspectJ rather than using my own AOP framework. AspectJ, of course, is significantly more powerful, but I think there are real maintainability issues in introducing it into production systems. How I抳e used it is as part of the build process to insure that during unit tests, things are being called in an appropriate way, and it抯 certain bad usage patterns of our objects are flagged.

Your book, 慐xpert one-on-one J2EE Design and Development?was published with Wrox. Do you know what happened to Wrox authors when Wrox went under?

In my case, my book was picked up, along with, I think, the 30 best selling Wrox titles by Wiley. So Wiley are obviously looking after the Wrox authors and I抦 fully honoring the royalty contracts. Some of the other Wrox assets were acquired by Apress. Wiley now own the Wrox brand and are actually planning to bring out further Wrox books.

What is in your pipeline?

I think this is a really great time to be a J2EE application developer. I抦 actually really enjoying it at the moment with AOP and EJB 2.1. There抯 really a lot of interesting things going on. So, I抦 really enjoying working with the technology. I am definitely planning another book. It抯 still taking shape, so I can抰 actually tell you too much detail at the moment, but it抯 definitely going to relate to where I see the J2EE industry heading, and it will be about making life easier and hopefully more enjoyable for developers.

不知道你看了评论没有，和国内的论坛很像的，为了一些文字描述的问题争来争去。
个人觉得文章还是好文章，尤其是对一些概念有所了解的人。但对于概念不清得人，却有推销sping之嫌。