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