But I digress... Rick Palkovic's blog

Dateline: JavaOne 2007, San Francisco

I write to you from a hotel room after experiencing a healthy dose of JavaOne's After Dark bash. The creative chaos featured "SwampThing's" domination of "Angry Asp" in the Battle Bot middleweight competition. Or was it "Sewer Snake" over "Sub Zero?" To tell the truth, my memory is beginning to blur into a virtual mindspace filled with flying Dukes and portal mashups. Finally, a week of intellectual overload was compounded (did I say pounded?) by sensory overstimulation as the Sun Taiko Corps heaped drumming on top of Ajax roundtrips in a wonderland of server-based acronyms.

Let's just say it's been a furious and fascinating 2007 JavaOne. And, if you missed it.... well, you missed it. And, sad to say, even if you were here, you missed a lot. That's because a whole lot is happening at once, and you have to pick and choose which events to attend and which to blow off. To help fill in some of the gaps, I'll be blogging in the coming week, trying to summarize what I witnessed in a few of the technical sessions you may have missed.

Let me point you to a couple of articles already published in JavaOne TODAY. First, there was the "Technical Overview of GlassFish v2," presented by Dhiru Pandey, Senior Staff Engineer at Sun, and Larry White, Architect of High Availability for Sun in Project GlassFish. Larry's comments in particular will be expanded in an upcoming article about clustering and high availability in the GlassFish server. If you missed the review in JavaOne TODAY, you should be able to find it in the online version here. Covered in the same article is Jerome Dochez's session, "GlassFish v3 Architecture Review."

I also reviewed in JavaOne TODAY is the session "Guidelines, Tips, and Tricks for the Java EE 5 Platform". Read the review here.

I dropped in on the session "JavaServer Faces Technology, AJAX, and Portlets: It’s Easy if You Know How!" presented by Brendan Murray, Software Architect at IBM. I didn't know Brendon (hey, I don't get out much), so took a chance. Brendon not only gave us a highly cogent presentation, but also performed a solo lion-taming act while getting a recalcitrant demo to behave before a crowd of savvy developers. We should take a poll of how many planned demos actually worked as expected at JavaOne – I'll bet it wouldn't be more than 50%. How, I wonder, can a local demo work fine, but 20 minutes later fail miserably? Many presenters ask that same question every hour at software presentations around the globe.

Anyway, I'll try to write up a review of Brendon's presentation on the train home from San Francisco. Stay tuned.

Summer Reading
Some interesting recent articles:
Working With Multifile Schemas,
Migrating Web Applications From Apache Tomcat 5.x to Sun Java System Web Server 7.0, and
Creating Dynamically Generated Charts in Portlets. [Read More]

"Implementing SOA with the Java EE 5 SDK" is published!
At last, "Implementing SOA with the Java EE 5 SDK" is available on-line. [Read More]

Solar Season in California
Time for solar cooking! [Read More]

My review of the last session I attended at JavaOne on Thursday

TS-1076 Practical SOA Business Integration Using OpenESB: A Distributed Java™ Business Integration Composed Services Application How-to and Demo
Presenters: Ron Ten-Hove, Michael Wright, and Keith Babo (standing in for Mark White)

I'm pleased to see Keith at this presentation. He's a contributor to the soon-to-be-published article "Implementing Service-Oriented Architectures (SOA) with Java EE 5" (see the review of TS-3175 below). He's a member of the JSR 208 Expert Group and contributes to the 208 RI and to Project OpenESB.

However, I'm not pleased to learn that Mark White, the originally scheduled presenter, has been hurt in a motorcycle accident. Heal quickly, Mark.

Waiting for the presentation to begin, we are assaulted by rap music with the refrain "I'm an engineer, respect my mind!" Maybe it just feels like I'm being assaulted because I'm sitting next to the loudspeaker. I suppose people actually program with this stuff playing in the background, but I'm feeling my IQ drop with each machine-gun verse.

Mercifully, Ron opens the session. He presents an overview of SOA concepts. Not having his charts and diagrams on hand, I won't try to summarize.

Next, Keith introduces Project OpenESB. Although Project OpenESB is an implementation of JSR 208, it addresses some shortcomings of the specification by introducing a Java Open Enterprise Service Bus built with JBI technology. In essence, OpenESB enables a set of distributed JBI instances to communicate as a single logical entity that can be managed through a central interface.

Now, Mike presents the demo. The demo is built with open source tools, including the web server GlassFish, the NetBeans™ IDE, and Project OpenESB.

Mike shows how to build OpenESB from scratch. Next, he shows how to build custom components. These plug-in components are useful in many different application areas. They can be used in other projects and are a way to build value over time. Most important, they can be shared with the Project OpenESB community.

To avoid the uncertainties Gopalan encountered in TS-3175, Mike and company have canned parts of the demo in video rather than doing it all live. This is certainly a safer approach, but the audience, robbed of the sense of high-wire drama, begins to grow restless.

Just in time, Mike fires up the the composite application resulting from an earlier build and deployment. After some fancy footwork, the demo works nearly as expected. Pretty good, considering that the OpenESB bits are only two days old.

In his closing remarks, Ron urges us to learn more about composite applications are and to contribute to OpenESB.

Here are my takeaways from the session:

• The big win in a SOA composite application is flexibility. During the demo, Mike replaced a local rules engine service provider with a remote SOAP implementation. The composite application clicked right along, obtaining its services from the remote provider.
• The organization of an SOA composite application makes it easy to reuse services.
• An SOA composite application is easily scalable.
• The Enterprise Service Bus (OpenESB) based on JBI fits in well with the world of Java Programming. For example, inside GlassFish is a service engine that allows Enterprise JavaBeans to be services within the JBI system.

As with most of the sessions presented at JavaOne, slides and sample code will be available for download. The content of this presentation will be made available on the Project OpenESB site as well. It's well worth a look.

Also, much of this material will be covered in "Implementing Service-Oriented Architectures (SOA) with Java EE 5," due for publication on May 25. I'll give you a heads-up when it actually hits the cybersphere and tell you where to find it.

Another JavaOne Session Review

Here's a review of another JavaOne session:

TS-3175 Building a Service with BPEL and the Java(TM) EE Platform: How Composite Applications and JBI Simplify SOA Development
Presenters: Gopalan Suresh Raj, Ron Ten-Hove, and Peter Walker

Now, here's a presentation I've been looking forward to. Service-Oriented Architecture (SOA) has been around for a decade or more, but the promise of widely distributed composite applications hosted on web servers has made it the hot topic in programming recently.

I've only recently been exposed to SOA, having helped Gopalan Raj and others author an article on the topic, scheduled for release later this month. The man clearly knows what he's talking about -- and here is Gopalan now, ready to deliver in the flesh. His task, we quickly learn, is to present a demonstration SOA application that will make all the high-level descriptions concrete.

But first, Ron gives us some background on SOA. He points out that the "services" in Service-Oriented Architecture can do just about anything you can think of -- transform data, query databases, integrate existing assets, and so on. Furthermore, they can be implemented in almost any technology -- XSLT, BPEL, SQL, and many other acronyms. The integration technology that holds them together is what turns them into a SOA composite application. For this session, the integration technology that holds them all together is BPEL, the Business Process Execution Language.

Ron steps in to describe BPEL as "a flowchart for a conversation" between an application's service providers and consumers. BPEL processes are expressed in XML notation. Using constructs like partner link definitions derived from the Web Service Definition Language (WSDL), BPEL describes inbound and outbound service interfaces. When combined with Java Business Integration (JBI), which provides the messaging infrastructure, these technologies let you re-use existing Java EE code transparently so that it can easily be integrated into other processes or applications.

Finally, Gopalan is called upon to do his thing. Using the NetBeans 5.5 Beta IDE, he shows how to put together a composite application with Java EE platform tools and an application server that supports JBI. Everything is going fine until he tries to build and deploy the application, when he is betrayed by beta-level software and falls into some sort of infinite loop. You can see the smiles of sympathy in the audience as Murphy's Law takes over the demo. Everybody, at one time or another, has been there and done that.

The presentation is effective nonetheless. My take-away is that you can begin using the NetBeans 5.5 IDE and other downloadable tools to create SOA composite applications now. So, why wait?

Keep an eye out for the forthcoming article, "Implementing Service-Oriented Architectures (SOA) with Java EE 5" by Gopalan Suresh Raj, Binod PG, Keith Babo, and Rick Palkovic. I'll post a URL on this blog when it's published, around May 25. It provides a detailed SOA composite application example.

Rick Palkovic goes to JavaOne

Like any big trade show, JavaOne is crowded and noisy. Kind of like a busy airport, except people mostly walk in circles. And they've left all their kids at home.

All those crowds can make things a little confusing, and I'm here to tell you that it's possible for JavaOne attendees to get lost -- even brilliant ones such as myself.

For one thing, I can't find the first technical session I'd scheduled. Somehow it had been moved to Tuesday, and, since it's Thursday already, it looks like I won't be in attendance. Suddenly my choices seem to be a session describing peer-to-peer communication in the battlefield of the future or a discussion of the HotSpot optimizer for the Java SE 6 Virtual Machine (code name Mustang). Being a war-weary civilian still trying to forget his sojourn in the military-industrial complex, I opt for compiler optimization.

TS-3422 New Compiler Optimizations in the Java HotSpot (TM)) Virtual Machine
Presenters: Stephen Dever, Steve Goldman, and Kenneth Russell

As an Otmar Liebert tune flows out over the PA system to soothe me, I find myself wondering just why a developer would want to know how his compiler optimizes code. This session really has nothing to do with my area of expertise or my job assignment. Writing a good compiler is somebody else's job, right? I just run the compiler -- hey, I'm trying to write an application here! Still, I suppose it doesn't hurt to know these things. As a minimum, it might help when setting compiler flags if something goes wrong that can't be explained in any other way.

When Ken starts his presentation, my inner nerd awakens and I become interested in spite of myself. The HotSpot VM has roots in Smalltalk and Self. The goal of the project is aggressive optimization and dynamic deoptimization, the focus is on new optimizations and lightweight locking.

For one thing, the HotSpot optimizer tries to address the issue of a single thread locking a Java object repeatedly, which turns out to be the common case. Letting a thread lock an object, release it, and immediately relock it again and again is a waste of cycles -- why not introduce a bias that keeps the object locked a bit longer, eliminating the need to relock? Sounds good. But, what if keeping the object locked unnecessarily keeps other threads from accessing it? Like other attempts at sophisticated optimizations, things can get very complicated quickly. HotSpot designers have given Some thought to developing a lock bias algorithm that favors an object's being locked a bit longer by a single thread while avoiding penalizing other threads that also want access to the object.

Steven Dever now describes Escape Analysis, which tries to figure out how to allow different threads to make arbitrary changes to an object without creating chaos. Solutions include eliminating the locking of objects altogether, optimizing field references, and allocating objects on the stack frame instead of the heap. Steven finishes the discussion and I'm left with the barest inkling of how these solutions might work (barriers to understanding, I must add, are entirely my own).

Now it's Steve Goldman's turn. In ten minutes, he tries to make us understand Tiered Compilation and other optimizations. Tiered compilation results from the recognition that most client-resident compilers run fast, but produce code that runs slowly. On the other hand, most server-resident compilers run slowly because they perform a lot of optimization, but produce code that runs quickly.

Tiered compilation means you compile the parts of your application that benefit from optimization on the server-based compiler, and quickly compile parts that don't need to be optimized on the client-based compiler. Easy to say, but hard to do -- mostly because the result of one compiler can't call methods produced by the other one.

When the session is over, I come away with the feeling -- freely acknowledged by the presenters -- that HotSpot is a work in progress. Those who labor in the dusty basement workshops of compiler optimization deserve our thanks. Join the forum at https://mustang.dev.java.net/ to offer your own views.