Feature

Digg This!

Overview
WebLogic Workshop 8.1 included both an application framework and an IDE to support developing enterprise applications using Page Flows, Controls, and annotated web services. This post describes some of the differences between the 8.1 Workshop runtime and the Apache Beehive project.

The Community
Since 2003 when the WebLogic Workshop 8.1 application framework shipped, it has undergone significant change. Most notably, BEA contributed the framework to the Apache Software Foundation as the Beehive project. This donation was announced in May 2004, and Beehive underwent Apache incubation until August 2005 when it was converted into a top-level Apache project. This means that the code, community, bugs, development process, and future of the project is now open to the entire enterprise Java community. The change doesn't end there, however, as Beehive has made significant technical advances as well.

The Technology
The technology in the Beehive framework has undergone significant change since Workshop 8.1. Beehive Controls are now contained in a lighter, more testable, and more flexible container while maintaining a simple, metadata-driven user model. NetUI is more feature-rich and configurable with advances made in the programming model and presentation layer. The most apparent change from Workshop 8.1 to Beehive is the switch from Javadoc metadata tags to standards-compliant, Java 5.0 annotations.

Controls
The Controls framework is now a generalized, metadata driven POJO framework. The framework has been divided into two parts -- a core framework that supports developing annotation based JavaBeans and a set of system controls and services that specialize the core framework for abstracting access to J2EE resources like JDBC DataSources, JMS queues, and EJBs as well as transaction and security services.

While Workshop 8.1 Controls ran inside of the EJB container, the Controls core framework has no dependence on J2EE. This framework is also testable outside of the J2EE container meaning that business logic and resource access can be unit tested without starting an application container.

The Controls core framework supports loose copuling between a Control interface and one or more implementations -- an implementation can be bound to an interface dynamically. The metadata applied to a Control can now be overridden at runtime to make it easy to configure a control to execute in different environments. For example, the JNDI DataSource name of a database control can be overridden at runtime through this pluggable metadata mechanism.

Controls can be instantiated both declaratively using the @Control annotation and programmatically using a JavaBeans API call. Controls can even be used in the JSP container via the tag. In Beehive, a Control method is neither implicitly transacted or secured. These functions can be optionally added by a Control developer.

System Controls
The System Controls are extensions to the Controls Core framework that provide abstractions for J2EE technologies including EJB, JMS, and JDBC. If you're familiar with the built-in Controls in Workshop 8.1, you will likely be familiar with their successors in Beehive.

For example, the Beehive database control still setting a SQL statement on a method with dynamic binding to method parameters and mapping a ResultSet to a return type, but additional features such as pluggable ResultSet mapping, batch updates, retrieval of generated keys, out of container testing, and other features are now available.

NetUI and Page Flow
Both the Page Flow and UI frameworks in NetUI have evolved as well. Page Flow has evolved to support many new features including:

• Declarative validation via Jakarta's Commons Validator
• Struts Tiles
• Use of any JavaBean as an action form and support for validation of these forms
• Page Flow base classes and inheritable metadata
• JavaScript Popup Windows
• Integration with JavaServer Faces as a displaying UI technology

The architectural difference between a Page Flow and a Control has also been adjusted so that Controls can be contained inside of Page Flows similarly to their containment inside of Web Services. For example, when the Beehive database control returns a JDBC ResultSet to a Page Flow, the Result set will not be closed.

The user interface technology provided as the NetUI JSP tags now support validatable HTML 4.0.1 and XHTML 1.0 transitional / strict rendering. The JSP 2.0 expression language is used by virtuall all of the JSP tag attributes for data data binding. This exposes the full functionality of the JSP 2.0 container's expression language, implicit objects, and JSP functions to NetUI tag users. There is a new data grid that renders arbitrary data sets such as object arrays, XMLBeans, RowSets, and ResultSets. The data grid also supports a flexible sorting, filtering, and paging model, and there is a new AJAX-enabled HTML tree.

The Project Model and Project Builds
Another significant change in Beehive is the project model -- there isn't one! Beehive source files are just that, annotated Java 5.0 without any custom file extensions. They're just pure .java. The framework doesn't make any assumptions about the structure of projects that use the framework which can be used to build web applications, web services, enterprise applications, or even Controls that might run inside of a Java Swing application. Beehive also provides a set of Ant 1.6 macros used to build Controls and Page Flows; these can be combined in arbitrary ways to support any style of project. Finally, builds of Beehive-enabled applications just require the tools available in a Java 5.0 JDK and do not require use of an IDE. Though, use of Eclipse and other tools can certainly make the development experience easier.

Testing
Some of the Beehive source artifacts can also be tested outside of the application container. In the Workshop 8.1 framework, It was challenging to practice test-driven development with Controls as they required the application container and a test framework that could integrate into EJB. Today, Beehive Controls can be tested using a JUnit test container that can run without an application server and will ship with the next version of the framework.

Conclusion
Hopefully this provides a view into how the Workshop 8.1 framework has evolved into Apache Beehive. The changes described here highlight some major advances in Beehive; of course, there are many other new features that are worth a look.

Perhaps most importantly, the community and code are now open, and the Apache Beehive community welcomes involvement in developing the project. The best way to become involved is to subscribe to our mailing lists, download Beehive 1.0, build an application, and send us feedback. More information on getting involved can be found here.