J2EE WebSphere Seminar
So here am in northern Baltimore at at a WebSphere seminar hosted by a local company, Noospherics. I actually know the speaker - George Kosmides - from way back. He was a Smalltalk guy back in the day, and is now working with Java. My presence here has already done some good - he's identified Smalltalk as the source of many ofthe ideas behind Java. This is going to be a stream of consciousness kind of report.
Now he's relating J2EE as a natural progression up from JSP and Servlets - i.e., something to simplify and scale the back end. The explanation offered is that the business model belongs in the EJB layer. Side note; I've heard this presentation. Heck, back in 1997 I was giving this presentation as D-Wave (Distributed VisualWave). There's truly nothing new under the sun; we just keep re-inventing the same wheels....
Hmm. Now we have some JDBC, and the fact that we can easily plugin any back end database. Well. One, that depends on the SQL being used. Two, what about O/R mapping? I'm not sure the explanation of JSP as a "refinement" of servlets is a good one; more of a complementary item, I think. Also no warning about the possible unmitigated growth of code on pages being a bad thing - something I learned the hard way in the implementation of this blog...
Now onto JTA - the transaction mapping piece. No mention that the vendors tend to value add this into proprietary heck.... JMS as a mapping on top of messaging services like MQ. Kind of amazing to me just how many of these things Sun has implemented. JMS actually sounds useful - having a standard messaging mapping for Smalltalk would be highly useful.
Now that we have the buzzwords out of the way, he's moving up to the architecture level. Heh. The supposed existence of XML standards between suppliers and vendors. I've got customers who live in the middle of the supply chain; they tell me that more than half the work is writing adaptors between systems, as standards are followed mostly in the breech. Ho ho - J2EE makes it easier to build a standard application architecture. Never mind the analyst reported high failure rates in this - which, I think, is more related to the attempt to build "the one true architecture" than to anything else. I think he over simplifies the "auto-scaling" of J2EE applications. Sure, if the application was written properly. Scaling is almost never a matter of "just" adding a server to the mix.
On to process. I don't take it as a great sign that RUP was on the last slide, and UML is on this one. Sounds heavyweight to me. Here we go - one must do modeling first (and I don't think this sounds like Scott Ambler's agile modeling). Here we have a big emphasis on UML and a process (RUP). We are about to cover the most commonly used diagrams in the UML. I've seen this before - a subset of the developers get so enticed by the diagramming that they never come back out..... So what are the most commonly used?
- Use Case Models
- Class Diagrams
- Sequence Diagrams
- State Diagrams
One of the things I disagree with here is that a design really can't be done withut regard to the implementation. You'll make different choices based on deployment platform (OS), network connectivity, language, database, etc. At the highest level, you can be abstract. Once you start getting to the level of specificity detailed in UML (down to class and sequence diagrams), it makes a difference.
Interesting. As the straw man for analysis and design, he's presenting waterfall as the alternative to be avoided. I'm sure there are still waterfall projects; but is anyone still advocating it? Ok, this sounds better - he's emphasizing testing and spiral development. On the other hand, RUP is what he's sayiing "we've all moved towards in the last five years". That was true from a mindshare standpoint 3 years ago. Is it still true? The supposed ease with which we can add new layers into our component model is being overstressed, IMHO. It almost never actually works out that easily. What about XP and Agile? Ahh - he's saying we need RUP, but we need testing from XP. Hmm. He doesn't seem to know a lot about XP/Agile - for instance, he's implying that test-first is optional. Bottom line, he's sure you need the RUP process.
