As I recently mentioned, I have been back in the Java world after a few years of almost exclusively .NET development. The client I am working with had a list of jdk5 bits to look into, and one of the things was "TestNG". I hadn't heard of it, so I did a little googling and ended up at TestNG's site. It is kind of a cross between JUnit and NUnit using JDK5 annotations. Cool.
I can't count the number of people in the past few years that have asked me to weigh in on the Java vs. .NET debate. You'll find my answer here, and the answer is simple. It is the only answer I know.
It does depend, but--for the most part--it is all about choice. In Java, you get a lot of choices. Open source vs. commercial, this platform, that platform; EJB, Pojo; Spring, Struts, Pico, foo, bar, blah blah blah. And therein lies one of the biggest problems with Java -- you have to make choices. And those choices can be non-trivial in light of the intricate version dependencies that can ensue.
With .NET on the other hand, you don't have nearly so many choices most of the time. Most of the time, you eat what Microsoft puts on your plate, and you like it, or you go to bed hungry. Most of the time, though, it is good enough.
And so you can focus on bottom-line, droll things like your business domain. You still have to focus on those things in Java, of course, you just have to after you have selected your platform, container, and so on.
That being said, it sure is nice to have some of the choices you have readily, freely available to you in Java. Like Active MQ.
So, given a choice between .NET and Java, I'd rather be doing Ruby.
My good, good friend Chris Wensel [whom I never get to see since I am DFW, he is SFO] over at manamplifiedblogs about Mule -- a new open-source J2EE-based ESB. (fair warning, I am not sure that link is going to work as expected, so you might have to poke around, though it will be good for you). What I find notable about it is that it is apparently the brain child of [almost exclusively] one person. The best products often seem to start that way.
The Recommended.Reading.1 entry is reserved for Enterprise Integration Patterns, the most excellent book by Gregor Hohpe and Bobby Wolfe. The book is all about using messaging to address enterprise integration issues. Although the book talks primarily about messaging, it is, in my opinion, the best book on service-oriented architecture on the market today. The material covers the depth and breadth of techniques related to messaging solutions, and references while stopping short of diving into the details of business process management systems [and rightfully justifying that as beyond the scope of the book].
The authors have maintained a website throughout the writing of the book, publishing early versions of the patterns for feedback, so you can get a little bit of the "try" before you bite off on the "buy."
As with most pattern books, the two most tangible benefits are codifying implemented, working and workable solutions to common problems and providing a common vocabulary by which to discuss the application of the solutions to new problems. For instance, if you are familiar with the patterns in the book, then I can make a statement like "The transaction aggregation system consolidates transactions from all of the lines of business (LOB). To increase the reliability of the solution, we will use Guaranteed Delivery with an Idempotent Receiver. To minimize the server utilization, the receiver will be an Event-Driven ConsumerService Activator. The messages will contain a Correlation Identifier to allow the LOB applications to correlate the acknowledgements, and will utilize a Messaging Bridge to connect the WebSphere MQ on the AS/400 and the Windows 2003 MSMQ.