|HOME PATTERNS RAMBLINGS ARTICLES TALKS DOWNLOAD BOOKS CONTACT|
May 11, 2007
Gregor = Booth Babe
As last year, Google had a booth at the JavaOne Pavillion, i.e. show floor. This year, though, the focus extended beyond just recruiting and giving out swag to include demoing some of our developer-focused products. Most of the GWT team were here to give demos and answer questions and Patrick (also a presenter at JavaOne) showed off Google Checkout. Google is also holding a developer day later this month, underlining the increased focus on the developer community (aka the people we have not hired yet).
Real Lessons Learned
Being a booth babe equipped me with a mere "Pavillion Only" pass. So I decided to put my fame to test and request a press pass. Sure enough, I was allowed into the super-secret (and super not exciting) press lounge and into the actual sessions. Going to a large conference is always a good chance to catch up on all the technologies that you may have heard off but never had the time to have a closer look at. JavaOne always presents me with a particular challenge, though (besides having to get up in the morning after the late night socials): I typically attend sessions based on the speaker more than the topic. At JavaOne, however, many of the speakers are Sun engineers or product managers, so my usual filter function did not work very well. Accordingly, my biggest learnings were what to do and not to do in conference presentations. Because I surely committed one or more of these offenses during my talks, I have the more reasons to remind everyone here:
My first session I attended was "Blueprints for Mashups". For a Googler I am embarrassingly ignorant on the whole RIA (Rich Internet Application) topic space, so this seemed to be a good way to catch up, reconfirmed by the incredibly long line (see picture). The content wasn't even that bad -- the presenters offered solution recipes for issues developers tend to encounter when building mashups. For example, accessing external servers from a client-side mash-up is often restricted through cross-site scripting constraints. To solve this problem you can proxy through your server, which in turn accesses the external resource. This "pattern" allows you to keep control of any developer keys you need to access the external site and also allows you to cache data. The main drawback is that you have to deal with two HTTP hops (unless you get a cache hit). They also showed a variety of approaches to deal with developer authentication for your APIs. A lot of the examples used jMaki but I did not pay enough attention to really form an opinion on it. I also took note of the recently established JSR 311 (JAX-RS: The JavaTM API for RESTful Web Services). Sounds interesting but I gave up trying to follow every proposed Java API years ago. Again, the overall content was a little high-level but not bad. However, somehow this ended up being one of the presentations that just seemed to trickle along in a steady stream, putting people to sleep one by one (see advice above). So I decided to wander down the hall and stumbled upon...
Designing Service Collaborations
Walking down the hall I realized that a talk on conversations was going on at the same time. Naturally, I wanted to catch as much of it as I could. Getting to this talk 15 minutes before the end, I was warned by the people scanning badges that everybody left the talk saying it was boring. I snuck into the room to find Mark Hapner presenting to a hard core of 100 or so people. I love Mark, but it would not be unfair to say that his IQ outweighs his charisma as a speaker by about 10 : 1. Of course this topic is close to my heart, so I tried to make the best our of the short time. In brief, Mark is urging developers to focus on what's going on the wire (as opposed to inside your apps). You'll be thinking about conversations, correlation, Message Exchange Patterns, etc. He left us with a pointer to Open ESB, which I am going to check out.
SCA != SOA
The Panel "SCA/SDO and Java Technology: Complementary Technologies That Drive Open SOA Environments" was well attended and featured a promising line-up of panelists from BEA, IBM, Oracle, SAP, Sun, and TIBCO, who are all implementing the SCA Specification. David Chappell (the one) moderated while David Chappell (the other) spoke for Oracle. You can easily tell them apart by their attire: David Chappell (the other) is dutifully wearing his company logo shirt as not to be mistaken for the (late) David Chappell who worked for Sonic, while David Chappell (the one) will not be caught without European designer fashion. David (the one) has been focusing on writing lately so it was fun to see him live again. He made an excellent moderator, quickly pinpointing two key issues around SCA:
The programming model, much like Microsoft's WCF, provides a unified API for all kinds of distributed systems communication. In the Microsoft world this is a big deal, and rightly so. So it was a little surprising that the vendor support for SCA's programming model is at best luke warm. Even a lot of the "official" documents seem to downplay this aspect of the spec. Only IBM and BEA are really supporting both aspects while the others openly stated that the programming model is not their focus. A poll to the audience ("who would like to see a new programming model") seemed to confirm this attitude (no hands went up) but I think this might be misleading. I agree that learning a new model is always a liability, unless it replaces multiple outdated programming models and makes developers more productive and code easier to understand. I don't think this aspect came out in the question to the audience.
When I looked at SCA before it totally escaped me that the spec assumes that a composite has to run in a single vendor environment. This limitation means to me that SCA has relatively little to do with SOA, which has to deal with an environment that is heterogeneous and not controlled by a single vendor. This does not mean that SCA is useless, but it means that it targets "programming in the middle" (wiring components in a single vendor environment) as opposed to "programming in the large" (wiring services in an enterprise setting). This makes all sense because the "programming in the large" is the realm of the WS-* specs but it was still surprising to me that I missed this critical part.
David has summarized his take-away in more detail and, as expected, more eloquently.
Highlights and Lowlights
Brian Goetz and Bill Pugh gave a nice talk on testing concurrent systems. The definite low-light for me was Advanced Java Programming Language Refactoring: Pushing the Envelope. The only pushing I observed were the people being pushed out of the room by the never ending introduction into the topic material. We all agree that having benefit outweigh cost is a good thing, so no need to reiterate that. If you spend half your talk leading into your topic you run the danger of boring and/or insulting your audience to death, not to mention being biled. How about "Who here does not want to be more productive?" as an opening, followed by an impressive demo? Sadly, this talk reconfirmed my impression that NetBeans is not really worth looking at. Go IntelliJ!
I only attended two BoF's due to the intense social schedule. I caught the tail end of "Debugging BPEL Processes" because it somehow took us 20 minutes to settle the dinner bill (software engineers and Dollar bills do not seem to mix). I followed up by Alex Ruiz presenting an open-source GUI testing framework. It was nice to see that a fair number of the presented projects are hosted on code.google.com.
Another low-light must have been the wireless network. Full signal, but no IP or no gateway :-( No wonder Sun dropped The Network is the Computer from their corporate vocabulary. At JavaOne the network was a piece of crap...
What would JavaOne be without the social events? The Tangosol party was attended by the usual suspects, which made for an entertaining evening. Sadly we missed the moment where the bouncer denied Cameron admission to the party as he was lacking an invite. As usual, we were booted at 1am or so, aimlessly wandering the streets. Carlos reported back from a taxi that they are heading for The Stud. A few minutes later reported that they are coming back from Studs. And I thought Carlos is not even that bad looking...
Weds night sported a host of company receptions and the exclusive-yet-not-so-exclusive reception Google reception at the (trying to appear exclusive) W Hotel. First i stumbled through Jillian's, hitting TerraCotta, Eclipse, Amazon, and IBM. The blogger event at Thirsty Bear was kinda lame, so we headed off to the Google party. They actually had poor Bob check for tickets at the door so I had to pull people in continually (somehow the people we really liked to be there were beaten by the swag hunters in the race for a ticket). The party was good fun but somehow ended a little early. A hort trip to House of Shields provided one more drink. Somehow the whole gang felt a little old and tired when compared to last year. Maybe we are actually getting old and tired. The only thing open after 2am appeared to be Denny's. Eating there was the penalty we morons paid for not knowing that there is a 24 hour Naan 'n Curry just a few blocks away. But then our stomachs may have thanked us.
The guiding theme for Thursday was provided by James observing that he "has not gotten properly drunk yet". After dinner and two BoF's ("Debugging BPEL Processes" and "Simplifying GUI Testing") it was time to hit the bar. We walked all the way to the Starlight room to join forces with James, Hani etc (who skipped the BoF's in favor of AsiaSF). In usual fashion we were booted at 1:30 or so. After the crowd thinned a little, six of us hopped into cabs to see how long the 15 beers in my fridge would last us. About 6am...
See you all next year!
Gregor is the Chief IT Architect of Allianz SE. He is a frequent speaker on asynchronous
messaging and service-oriented architectures and co-authored Enterprise Integration Patterns (Addison-Wesley). His mission is to make integration and distributed system development
easier by harvesting common patterns and best practices from many different technologies.
|© 2003-2016 • All rights reserved.|