My intention is to give a daily overview of the highlights and some thoughts of the sessions I followed at JavaOne. This morning was the official opening of the event. I has expected some queuing lines in front of the Moscone Convention Center, but everything went fine. No queuing, good coffee and comfortable seating. Every day starts with some general sessions, prior to the parallel individual sessions. As like the previous years, John Gage is the acting master of ceremony for the general sessions. The morning sessions where ?easy listening? sessions in general injected from time to time with a well intended joke. After a couple of hours listening, I was convinced that this JavaOne is THE conference of the year dealing with ?lightweight? and ?SOA?. As long as you don?t mix them together, you don?t miss the point.

Also not to forget, Duke is celebrating its 10 anniversary this year! Yes yes yes? Hip hip hoera for Java! The language celebrates its 10 anniversary. The ?green team? has been brought on stage. Nice to see the innovators of what created a multi billion dollar/euro industry.

Still sitting in my chair, I was thinking what I was saying roughly 11 years ago? At that time, I was a hardcore assembler programmer, preferring to program directly the CPU registers instead of using a ?high-level? language like C. At that time other languages where even inexistent to me. One of my statements that put me into trouble with one of my previous employers was declaring Visual Basic as ?a program for graphical artists?. I?m still quite convinced about that. When I heard that there would be a new language that would not be native and that would have an additional layer (byte code) that would be interpreted, I said ?No way! This will be even slower than BASIC!!!?. Today, 11 years, 15kgs and less hair later, sitting in San Francisco, looking around to the huge crowd of Javaists, thinking to who pays my salary actually?. I firmly have to admit that I was totally wrong about Java, 11 years ago.

Some figures illustrate the immense popularity of Java. Consider them for a moment. I was quite impressed?..
4.5 m Java developers
1 b Java cards
2.5 b Java devices
708 m Java operated phones
600 m Java handsets for manufacturers

Another nice Java based thing to see was the Panasonic Blu Ray disc. The next generation storage solution on a DVD size optical disc. Storage capacity ranges from 50 ? 200 GB per disc! This makes it ideal for archiving purposes, but also for consumer usage in a HD DVD recorder/player. The latter was demoed at the Panasonic booth: A HD DVD player powered by Linux and Java.

The session was followed with some product updates from SUN Java Studio. Nice to see, nice to have, but not chocking. This is what we have already a couple of years in BEA WebLogic Workshop.

Another interesting utility was DTrace for Java on Solaris. This tool analyses during program execution what amount of time is spent in native, kernel or Java code. Based on the results, some tuning actions may take place to improve performance. I firmly believe this is a valuable tool, but it?s also worthy to notice that a lot of the Java code that is executed during program execution is not controlled by the developer. Application servers might also be written in Java, etc.

A lot of time has been spent on the updates of the J2SE and J2EE roadmaps. Serious effort has been done for both environments. The feature list contains some really cool topics!

Jave SE 6 ?Mustang?

• EoD: Extensive use of annotations
• Web Services client stack + lightweight server stack to serve callbacks
• JML support
• JMX upgrades
• JConsole. This allows real-time JVM monitoring (see JRockit)
• Scripting language framework support. ?Rhino? scripting engine is included.
• Longhorn support, incl. Avalon look and feel.
• JavaDoc update.
• JDBC 4.0 support. XML data type and database support. Annotations model
• Updated license model: easier + added new models
• GUI upgrades: LCD font rendering support, Windows System tray support, Graphics pipeline boost (Open GL & DirectX)

Java SE 7 ?Dolphin? (tentative)

• Direct XML support in the VM
• ?friends? for cross package refs
• Method references (event handlers)
• New JVM byte code for better support of dynamic languages (eg. Jython)
• Bean shell scripting language (JSR-274)
• More new I/O APIs (JSR-203). Pluggable file systems, file permissions, free disk space
• New packaging and deployment architecture: Circumvent limitations of JARs and/or EARs, metadata like versions part of the distribution

Java EE 5
Goals:

• EoD improvements: POJO support; annotations used: to reduce the need of deployment descrptiors, external dependencies, Web Services, DB Mapping, EJB development; resource injection (inversion of control); new APIs and frameworks
• Simplified Web Services support
• Simplified EJB development
• New persistence API (resolved EJB/JDO conflict)
• Interceptors

Java EE 5 new content: JSP STL (JSR-52) STAX (JSR-173) Web Services Metadata (JSR-181) New persistence API (JSR-220) JAXB (JSR-22) JAX WS (JSR-224) Common (language) annotations (JSR-250) JSF (JSR-252) Java EE 5 updated content: EJB 3.0 (JSR-220) JSP 2.1 (JSR-245) Minor updates: Mail API, Servlets, ? Beta: Q4 2005 Final: Q1 2006 SUN also announced to provide a free Java EE 5 compliant application server. This project is called ?Glashfish?.

SUNs Mark Harpner talked about SOA and Java Business Integration (JBI). One of the key building blocks for a SOA is the Enterprise Service Bus (ESB). The ESB are the tools and middleware to develop/manage/deploy and manage composite services. Most of the ESBs are built on a Java platform. Today, several vendors provide an ESB solution each having a different:

• Tooling
• Service packaging
• Service deployment, packaging, management and monitoring
• ESB extension mechanism
• ESB monitoring and management.

These bullets are the actual paint points of today?s ESB solutions. Therefore, there is an emerging need for a ?SOA AND the Java platform? standard, which provides support for composite services:

• Standard service assembly and service wiring
• Extend ESB collaboration through standard normalized message routing and standard component pluggability.
  The benefits of the approach are modular services and ESBs
  JSR-208 defines a standard for Java Business Integration.

After lunch I went listening to (our) BEAs Mark Carges. Mark talked about two major topics: BEA support for lightweight frameworks and JVM innovations implemented and planned in our BEA JRockit VM.

Investigation proved that most of enterprise developers find that enterprise application development is too complex. In order to resolve that, over 70% use frameworks on the different tiers (web, business, data) of the enterprise application.

Today there is also an increased demand for:

• POJO support: Allows the use of lightweight containers and a simple component model.
• Dependency injection: Allows to resolve dependencies in a declarative way, to simplify the source code and to perform fast iterative unit testing
• Metadata support: Allows to define infrastructure concerns in a declarative way and to code annotations
• Aspect Oriented Programming support: Enabling technology and code simplification.

Today there are open source frameworks fulfilling above described needs. Hence, BEA provides as from WebLogic Server 9.0 support for Struts, Beehive and Spring.
WebLogic Workshop will be based on Eclipse and will support additional deployment models to support, in addition to WebLogic Server 9.0, Geronimo and Tomcat.

BEA worked together with Interface21 to optimize the Spring support in WLS 9.0. Spring will use the BEA optimized transaction API and the Springbeans can be monitored from within the BEA WebLogic Server Console.

The second topic was dealing with JVMs. Where JVMs where initially built to support multiple platforms with a ?one size fits all? concept in mind, today?s JVMs focus on performance, specialization and ?always on?. BEA provides with their JRockit JVM, the fastest (28% faster) JVM available on the market. The JVM has been optimized for Intel architecture CPU and a Sparc version is in the pipeline. Strong points of the JRockit JVM are: Optimized garbage collection Operational diagnostics support by means of a management console, runtime analyzer, production memory leak detection and trouble spots linked to source code. Stepping into utility computing: Where a cluster provides an answer to scalability to meet SLAs, with CPU virtualization we can take it one step higher.

Just pas the SLAs to the JVM and the JVM will allocate the required resources to fulfill the SLA requirements! Is it good, or is it good?!?!

Next session on the list had to do with the inner details of the JBI spec.
I wanted to see how SUN approached ESB interoperability issues and in what way the SUN architectures matches the BEA AquaLogic Service Bus architecture. Today there?s a lot of hype around ESBs. I think it?s the seasonal buzzword. Next season we?ll have something else? quite sure. From an architectural point of view, an ESB is quite simple. Support for multiple protocols, some routing, and some transformations, stick a label on it and put it in a box.

The heart of the JBI is a ?normalized router?. The router routes based upon ?normalized messages? can be enriched with plug-ins to add addition functionality to the ESB like:

• Orchestration via BPEL
• Transformation via XSLT
• WS-I (Basic SOAP)
• Business Logic (EJBs)
• JMS
• Binding components: Proxy for remote service providers
• ?

The plug-ins:

• Can be providers or consumers
• Supply self describing using WSDL for: Messages, operations and message exchange patterns, services, end points
• Translate the messages to/from an ?abstract message? model

Normalized message consist of:

• Abstract message
• Message metadata: message properties dealing with transactions, security, protocol info

The message itself will not survive a system crash. Persistence should be provided elsewhere in the process. This has been done for performance reasons.

The advantages of a JBI compliant ESB:

• Portable installation and deployment
• Services are portable across JBI implementations
• Plug-ins can operate/integrate across JBI implementations

Next session was dealing with EJB 3.0
The major concerns of EJB 2.1 are the complexity to use it. This is underwritten by an awkward programming model, complex deployment descriptors and al lot of entity bean anti patterns.

EJB 3.0 addresses the pain points and provides an alternative to it.

• Fewer classes and interfaces:
• Dependency injection: Use metadata annotations to specify where resources have to be injected.
• No required container interfaces: No need to code EJBHome and EJBObject methods.
• No required deployment descriptors: Default behavior requires no deployment descriptors. Alternative behavior can be described via annotations. Deployment descriptors are still supported as well (to override annotations).
• Focus on the business logic instead of implementation logic
• No JNDI look-up for client applications. Business methods are defined in an interface. A POJO provided to the client implements that interface.

The EJB 3.0 entities are POJOs. These can also be used detached from the container and used across transactions. So there is no further need to map Entity beans in DTOs.

The EJB persistence layer has been drastically changed with the focus on simplification. Knowledge of JDO, Hibernate and Toplink has been merged to define the new APIs.

O/R Mapping support: Mapping is expressed using metadata annotations or XML. Default mappings are provided.

The last but least session I attended was ?A hitchhikers guide to SOA orchestrating loosely coupled services with BPEL and BPMN.?
A great sounding title with less content. After giving a definition of what BPEL and identifying its shortcomings (BPEL only orchestrates, does almost nothing more), we went over to ACDC worker services triggered by BPEL (Asynchronous Conversational Document Centric) that do the actual business logic execution.