JavaOne ? Day 3 Summary

In the context of service orientation there is a clear convergence between the .Net and Java platform. Both platforms are converging on:

• Common protocols
• Common metadata (full XML Schema support)
• Development simplification by means of annotations based development and GUI support
• Service protocols: Core SOAP bindings, SOAP Attachment bindings and further QoS bindings
• Web Services management.

Solving the interoperability issue allows developers focusing on the actual implementation instead of spending effort to solve connectivity issues.

The next ?leading edge? session I selected ?Evolving the Java language? had to to with future language extensions on the Java language. Keep in mind that the Java language is not the same as the Java Platform. The language is part of the platform, but not vice versa.

The Java language has been designed with C++ as one of its major source of inspiration. Lessons learnt from C++ where that Java:

• Should focus on code ?reading? instead of code ?writing?; meaning priority to readability over easy of programming language constructs.
• Simplicity matters. However I liked C++ a lot and found it not complicated at all, ?pointers? where for some friends of mine a struggle of life.
• One language with the same meaning everywhere. No ambiguity.

There will definitely a natural evolution of the Java language, but it will be a slow en controlled process. Things we will probably never see in the Java programming language are:

• Multiple inheritance
• Operator overloading
• AOP
• Continuation
• Pre processors
• Multiple dispatch
• Multiple return values

Things that we shall probably see in the future releases are:
XML support:
XML support will become part of the Java language. Specific language extends will be added for this. The compiler will do all the necessary work to make it happen.
Coming soon to a JSR near you:

• Syntax validation
• Type checking
• Name spaces
• Document types
• Processing instructions
• Mutability

Other language ideas:

• Method references/closures
• Friends: Access control is to strict new; the ?friend? notation à la C++ would make it a lot relax.

New byte code format
What: Better support for other languages, like scripting languages, natively in the JVM.

Why:

• To broaden the community
• Performance: Currently other languages run on top of the JVM

How: Still under construction, but by means of dynamic byte code invocation. Currently, the JVM has 4 bytecodes for method invocation:

• invokevirtual (normal method invocation on an object)
• invokeinterface: Guess what this does?
• invokestatic
• invokespecial (Used for constructor invocation)

The current, not fully worked out idea, it to add a fifth bytecode called ?invokedynamic? to support the dynamic byte code invocation required for native language support in the JVM.

Back to the Java - .Net interoperability. The next session I attended, ?Multiple Platforms, Single Identity: Interoperable Identity?, dealt with single sign on (SSO) solution models for heterogeneous environments.

Some security basic terminology:

• Identification: Who are we talking to?
• Authentication: Are you sure, you are who you are? Requires the user to provide a credential. After being authenticated, the server provides a short-life token to represent an authenticated identity
• Authorization: What am I allowed to do?

In java we have two ways of setting-up security:

• Declarative security: Delcalred in ejb-jar.xml, web.xml
• Programmatic security: getCallerPrincipal(), isCallerInRole(), getUserPrincipal(), isUserInRole()

A typical enterprise runs dozens of web applications having different ways of authentication. From a management perspective, this makes it very difficult maintain it. A Singe Sign On solution heavily reduces the maintenance coming along with enterprise wide authentication.

SSO: The web agent/proxy inserts identity information as HTTP headers, accessible from the HttpServletRequest. Identity information can be stored in the EJB context as well. We distinguish Enterprise SSO and web-based SSO.

Desktop SSO:
The user experience:

• Authenticate to OS desktop
• Browse to the protected resource
• Use desktop crendetials
  Standards exist in GSS-API and SPNEGO
  Domain SSO possible on Windows, Solaris, Max OSX
  However? Web SSO using cookies has limitations.

Federation:
Loose coupling (.Net/Java/?) and strong interaction
Federation is the solution to span SSO across domains.

• Security is built from the ground up
• Privacy is built in. Mechanisms have been put in place to only reveal the information that is required.
• Standardized
• B2B/B2C/B2E scenarios particularly well suited
• J2EE and federation: Seamless integration! Code can continue run ?as is?.

Identity Federation Frameworks:
SAML 1.x ? 2.0
Standardized by OASIS
Platform independent
Basis of federation:

• Specification for representing identity assertions in XML
• Request-Response protocols
• Browser based SSO

• Liberty Alliance Project:

• Leverage existing standards: SOAP, SAML, WS-Security
• Extends SAML: Single logout, Account linking, Pseudonyms
• The basis for Identity Federated Web Services (JSR-196 in progress)

The last but least session today, ?Introduction to the Eclipse Web Tools Platform project? by Dr. Tim Wagner, BEA Systems Sr. Manager, focuses on some valuable extensions on the Eclipse IDE.

Why has BEA chosen to join Eclipse?

• Eclipse is open and transparent
• Provide collaborative solutions wit other vendors.
• BEA is board member and contributor

The Web Tools Platform (WTP) will serve as basis platform for the BEA Workshop IDE based on Eclipse.

WTP Themes (0.7 release)

• Extend Eclispe into the J2EE domain
• Define servers, runtimes, modules
• Provide platform tools
• Provide useful tools for developers

Well done: For a full featured list, I recommend to checkout: http://www.eclipse.org/webtools/

The last session today I selected fits perfectly in one of my favorite Java domains: ?Speculative locking by Azul Systems? in the JVM! Hurrah! Speculative locking deals with postponing or avoiding actual locking to favor performance when multiple threads operate at the same time in the same locked region. Locking takes only place when it?s really required. Normally the first should lock, setting other threads in a wait state, so resulting in a performance and a scalability penalty. Sometimes it turns out that there actually was no real need for locking?

Why do we care?

• Java applications naturally multi-threaded
• Multi core CPUs from all major vendors.
• Amdahl?s law: efficiency = 1/(N*q + (1-q)) where N = #CPUs and q the portion of serialized code. For high efficiency, the amount of serialized (= synchronized blocks) has to be reduced.

Locks are typically too conservative. Locking is done to avoid contention (=interring access to a resource). In practice it turns out that locking takes place without having contention. However, it?s difficult to predict contention.

Let?s take a look how Optimistic/Speculative locking behaves by database transactions:

• Transaction: atomic group of db operations.
• Data contentions result in a rollback
• Software re-executes until successful
• Optimistic/Speculative locking does scale!

The same principle will be applied in a multi-threading context when the thread want to access a synchronized block.:

• Uncontended synchronized blocks: Run as fast as before
• Data contended synchronized blocks: Still serialize
• Speculative synchronized blocks: Executes in parallel, when collision, a rollback takes place and a retry takes place

Since all the locking logic is handled by the VM, it?s transparent to your Java code, meaning that no code changes are required when replacing a traditional VM by the Azul Systems VM.

This is definitely an improvement in a specific area in the JVM, which will definitely lead to a performance gain. I?m really curious to see in what order performance figures are, compared to the fastest JVM currently available, BEA JRockit?

k