JavaOne ? Day 2 Summary

Our BEA Engineer Gregory Brail hosted the session. Gregory focused on some important I/O related topics:

• How to achieve ?safe? writes?
• Larger is better.
• How to achieve the highest write performance for safe writes?
• How to achieve the highest read performance?
• Things you can?t normally do with the Java I/O API stack.

A lot of today?s I/O complexity is hidden for most of the Java users. Almost no one takes care about following fundamental aspects of I/O:

• What is the access pattern? Sequential or random file access?
• How much data is read/written at once?
• How much of the file is read/written in one I/O operation?
• Durability: Do we want to survive a system crash, a power failure?

Most of us don?t think about these issues when performing I/O operations, however? When performance and throughput become critical, these parameters play an important role. The nice thing is that almost all of them can be manipulated by means of the Java I/O APIs. As said? ?almost? all of them?

To come back to the topics;
How to achieve ?safe? writes?

• Not so easy? both OSes cache all disk write operations, as well do most of the disk drives.
• APIs let?s you perform ?force writes?, but be careful, this doesn?t work always. The behavior depends on the way the OS, filesystem and disks work.

?Larger? = ?Better?

• A few large I/O operations are better than many small ones. Every I/O operation has to pass through several software layers which introduces an overhead. Grouping of buffering data in order to reduce I/O calls will reduce this system overhead.
• Extending a file is slow. When creating a file on disk, the OS just write disk blocks, however, when extending a file, the OS also has to take care about the file size during the writes. This has to be done each time a write operation takes place. Therefore, writing large chunks of data will decrease the overhead involved with this.

How to achieve the highest write performance for safe writes?
Safe writes requires a ?forced write? operation. These can be explicit or implicit.
Explicit force

• RandomAccessFile.flush(): stores both contents (data) and file metadata (properties).
• FileChannel.force(): stores contents (data) and optionally file metadata (properties).

Implicit force (when opening a file)

• RandomAccessFile in ?rws? mode: stores both contents (data) and file metadata (properties).
• RandomAccessFile in ?rwd? mode: stores contents (data).

After testing and benchmarking, it turned out that RandomAccessFile in ?rwd? mode provides the highest write throughput. It has to remarked that performance may vary, depending on the OS, used hardware and VM implementation.

These days business requirements as well as technology is evolving fast. This market behavior defines a need for ?Agile J2EE?. ?Agile? is definitely one of the hippest words of the last decade. For those of you that missed that train, don?t panic, ?agile? is just synonym for ?fast changing? ?quick anticipation?. So, in order to quickly anticipate on these fast upcoming changes, we need a supporting programming model designed for it. In practice this means that the current J2EE model has to be simplified. Tools that hide the actual J2EE complexity are not a good solution.

?Frameworks? are central to modern J2EE development today, since out-of-the-box J2EE does not provide an ideal programming model. Overtime, this has resulted in
many ?in-house? frameworks, making them expensive to develop, expensive to maintain.
Modern open source lightweight containers/frameworks feature:

• POJO support
• Inversion of Control (IoC): This functionality provides sophisticated configuration of POJOs. IoC is often referred as the Hollywood principle, or ?Don?t call me, I call you?. It is the framework that calls your code.
• Dependency Injection (DI) is a specialized version of IoC. The container injects dependencies into objects using Java methods. This is also known as ?push config?. DI does not require a container API, nor is it depended on a specific container implementation. It provides abstraction of the underlying environment.
• Aspect Oriented Programming (AOP): APO provides declarative services to POJOs and out-of-the-box features like support for transactions and security.

It this cool or not? Great!!

The Spring Framework:

• Simplyfies Java development by allowing development based on POJOs.
• Declarative transaction management.
• Unique consisten approach to dataaccess with a common exception hierarchy. (Simplifies working with Hibernate, iBATIS, Toplink, JDBC, ?.)
• IOC/AOP integration
• Integtation with third party tools like BEA WebLogic Server Administration Console.
• Requires no deployment, so no deployment descriptors? Isn?t that nice?!

• Whole server migration
• WAN/MAN failover support out-of-the box
• Side by Side application deployment without service disruption. WebLogic Server migrates traffic gradually.
• Application rollback

Multi service platform:

• Support for: J2EE, Portal, BPEL, CFML, SIP, WLST, Web Services, Beehive, JFC/Swing, Spring, ?

Multi-programming model interface:

• Support for Native Web Services, Portal, ?.

Messaging: Messaging goes far beyond JMS. Serious effort has been done on the messaging framework.

• Store and Forward: enables messaging to potentially unavailable endpoints.
• Simple administration of remote endpoints.
• Fully automated migration of failed JMS servers
• Deployment of JMS queues, topics, JDBC datasources supported via deployment plans.
• Queue browser: Goes beyond seeing the number of bytes.
• Enhanced management features expressed via JMX.
• C API
• Signification performance increase due to read/write optimization.

SOA:

• Easy to author and deploy
• Flexible data binding
• Enterprise Web Services based on a new Web Services stack with support for WS-ReliableMessaging and WS-Addressing.
• Integration with the new BEA AquaLogic Service Bus.

Management:

• Full fledged scripting tool with support for on-line scripting via JMX, or off-line scripting via config.xml editing. The latter one is now also schema validated.
• Dynamic changes: Almost all configuration changes don?t require a system restart.
• Management console is BEA Portal based providing the possibility to reuse the management portlets in other applications.
• Extensible Management console. Easy to add user extensions to the management console.
• Server management accessible via JMX.
• Support for deployment plans (JSR-88)
• WebLogic diagnostics framework: Provides extensive WebLogic Server diagnostics information and allows WebLogic Server introspecting its proper health and adjust resource utilization when required (in order to meet SLAs).

Security: ?Security is a process, not a product?

• BEA is the sole application server vendor providing a fully pluggable security framework.
• Audit functionality has been enhanced.
• Support for Microsoft Identity Assertion (SPNEGO)

The BEA WebLogic Server 9.0 will be available in its final release on August 2005.

Before going to the BEA and SUN drink, the last presentation I attended today was dealing with SOA (again)
Tom Bayens of JBoss talked about Workflow, BPM and Java technology.

Actually, we can distinguish three different domain models:

• Workflow
• BPM (has to do with integration)
• Orchestration (BPEL and JBI related)

The jBPM kernel supports the common denominator of all three domain models, meaning the same kernel services all of the three domain model implementations.

The major limitation of the Java language dealing with one of the three domain models is that Java doesn?t support ?wait states?.

Problem:
Business users use a graphical representation that uses wait states; business analysts have a filtered view on the technical detail.

Traditional solution:
Defines a business language that has a set of constructs and nodes that have a graphical representation.
This approach has following issues:

• Monolithic
• Process language is never powerful enough
• No modeling freedom
• Turns into visual programming

Alternative solution: Graphic Oriented Programming

• Define a directed graph
• Define an executional model using tokens and signals. A token is a path of execution in a single system; a signal is the trigger that resumes resource execution.
• Aligned with transactions
• Thread safe; client thread is used for calculation
• No reinvention
• Existing Java APIs are leveraged (JMS API for asynchronous communications)
• ?Actions? hide technical implementation details.
• ?Actions? are stored in ?events?, and events are hidden from the process view.
• Implemented as jBPM

JBPM is available in a jar format and is accessible as POJO.

The jBPM implementation looks nice, but I?m missing support for exception handling. The answer to that question was to model the exception routine in the process. This makes things too complex to me. I had expected to see node en process exception handlers as we have in BEA WLI.

k

PS: Read my previous "James Gosling" blog, to see how I got this condom!!

This afternoon, curiosity push me to attend the Wicket session. I've heard about this framework only a week ago reading a post on TSS and as a Tapestry user I wanted to compare both.
The framework is basicly similar to Tapesrty, no JSP pages but plain html pages with special wicket:id in tags and Java code in page-linked classes (swing-like code) to fill the tags in the page with runtime values.

My Conclusion in a few words :

• Friendly and Fun
• Clear design
• Less XML config ... but more Java to write

I was wondering if there was any Wicket user in Belgium that could give his experience building an application with it ...

Thomas Kurian also presented what the Oracle Fusion Middleware will look like.
The good news is that this technology stack will be based on Java EE, we can expect the whole Oracle/PeopleSoft suite of applications going step by step into that direction.

He named this Fusion middleware a Dynamic SOA. It is composed of Java EE technologies (JSF, EJB3), BPEL, a n ESB and a Metadata repository. The innovative stuff in there is the Common Metadata Repository.

Today, when we add a new attribute to a database table and want to see that attribute on the screen, we have to change all the layers between the screen and the database. An Oracle product manager at the booth told me that this repository was about to manage that case by minimizing as much as possible redundant changes in the different layers.

It looks like Oracle is leveraging its experience in the applications area to J2EE infrastructure and that is really exciting.

But Oracle is also considered today as weaker than other vendors like BEA or IBM on the pure middleware connectivity level. Thomas Kurian has drafted what the future will be, Oracle will integrate a JBI compliant Enterprise Service Bus in this Fusion stack. No details were disclosed about this. Maybe Hugo will give us more info when available.

The first days of JavaOne where cloudy and I felt the temperature was cold for June. The situation seems to improve since yesterday afternoon but I am not here to blog about the Spring season but well about the Spring framework. I was a little bit disappointed when looking at the conference program on Monday. There were very few sessions dedicated to Spring planned. I was thinking that maybe Rod Johnson?s criticism against EJBs and Java Enterprise Edition was affecting his popularity amongst the conference selection committee. Rod is one of the cleverest person in the Java landscape and it was sad not to have him speaking much more here. But I must recognize that since Monday, I have seen Rod everywhere, from the BEA keynote to obscure JavaSpace-based applications used at Wall Street.

Spring is used in lot of successful Java projects that are presented here. I am blogging right now from the Spring-JSF technical session, the room is completely full!!

I really believe now that Spring is here to stay, this framework uniquely combines inversion of control, aspect-oriented programming and remoting amongst other things.

Spring is so successful that it is currently being ported to .NET, an interesting move that is opening doors for Java professionals to the .NET world (even if .NET might never become as important as Java is today I think).

I was wondering what would be Rod?s opinion about the recent Java (r)evolutions like the use of annotations. I will ask him the question.

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