The growing size and complexity of enterprise applications
in Java have catalyzed new approaches and models for simplifying the code used
to build these applications. 'Beehive' programming model by Apache aims at
achieving the same and is an object model built on Java EE and Struts. A quick
example of this is the annotations based representation of beans, classes and
methods to provide metadata for easier deployment and configuration while
working in Beehive. This is in contrast to the Java EE approach where building a
web service on top of the beans tier invariably requires an exposure of
control-logic of the beans to the programmer. The model also provides
integration with other known frameworks and specifications such as Java Server
Faces, MyFaces and Spring Framework. The latest release, viz. 1.0.1, has NetUI
Framework for handling page-flows and providing user interface constructs,
Controls Programming Model for providing light weight client components and Web
Services Metadata.
|
NetUI architecture
The NetUI framework provides annotations based web programming and is built
on top of Struts. JSP pages make up the 'View' in this framework and the
'Controller' class takes up page-flows. Controller class has to be a
subclass of the 'PageFlowController' class provided by the framework.
Additionally, the controller must also contain the 'Jpf.Controller' element,
which is the annotation for a controller. This single class also handles page
flow, navigation rules, metadata and exceptions. The framework also includes a
set of JSP tags and user interface components such as grids and trees. A page
flow in the framework contains a single controller and multiple JSP pages.
The general structure of a NetUI application resembles a
standard Java EE application. Next we implement the 'Controller' and 'View'
components as aforesaid. You need to import the following JAR to your build-path
for this:
beehive-netui-core.jar
As you can see above, the directory structure can take 'Controller' class in either 'src' or 'web' unlike other architectures |
Make sure that the corresponding JAR files for Java EE
classes referenced by the above JAR file are also in your build path. This
can be 'servlet.jar' in case you are using Eclipse or 'j2ee.jar' if you have
Enterprise Java installed on your system. The general syntax of a controller
class is:
import
org.apache.beehive.netui.pageflow.annotations.Jpf
import org.apache.beehive.netui.pageflow.PageFlowController;
@Jpf.Controller{
// define action for controller. Assuming a simple action
simpleActions={
@Jpf.SimpleAction(name=
,
path=
}
}
public class
PageFlowController{
//code
}
However, it is not mandatory to put the Controller class
files in the Web directory as above. You can place it in the Src directory as
well, but NetUI will assume JSP pages to be in the Web directory even if you put
the Controller in Src.
We described a simple action over here. However, actions in
NetUI can both be 'Simple' and 'Complex.' The latter would do tasks such
as validate user input, contact back end resources and forward results to some
JSP page.
NetUI provides a rich set of tags for rendering HTML/XHTML
pages. NetUI tags have syntax similar to normal HTML except for a 'netui'
prefix. For example '
It is the same with other tags as well. You need to place Java classes
implementing storing data from your JSP pages or other logical purposes after
you have implemented the controller and view components.
Data binding in NetUI allows for reading and writing of
data in web-tier by JSP and other UI technologies. Binding is supported for both
read-only and read-write data. The latter generally appears in an HTML form tag
and is bound to controls such as text boxes and buttons and other widgets. The
tags use 'JSP 2.0 Expression Language' for expressing binding of JSP tag to
a data value represented as a Java Bean property, map member, list item, or
other such entities.
Implicit objects in NetUI include:
-
'actionForm' for accessing properties of a JavaBean
-
'bundle' for accessing message strings contained in
Java properties file
-
'container' for accessing Java Beans properties as
exposed by 'IDataAccessProvider' interface
-
'pageFlow' for accessing the page flow controller
as a JavaBean
-
'pageInput' for providing a contract between page
flow action and page
-
'sharedFlow' for allowing access to Java Beans in a
shared flow to JSP pages.
Controls architecture
Controls aim towards easing out the complexity of Java EE apps by providing
a model that is unified and collaborates with an
existing design of back end components to create web services and application by
an application programmer. Thus, it aims at keeping the application programmer
free from the complex series of steps required otherwise for integrating web
user interfaces and services over an existing layer of Java Beans. The Controls
way of doing things is a unified client model that can provide access to various
diverse and mostly complex resources.
A Controls client removes complexity by encapsulating
lookups and home/remote interfaces while allowing an EJB's JNDI name to exist
as a property that can be edited using metadata annotations. This methodology
provides reduction of code and provides a unified view to different clients as
all of them view the JNDI name as a metadata property. A 'Control' would sit
between a Java EE resource and its 'Client' and provides an interface
between them. It would allow the Client to communicate to it directly and use
metadata annotations to talk to the resource. Additionally, it provides an
external configuration model for binding properties from external
configurations.
The Control itself often holds a reference to a resource
proxy associated with the accessed resource, and uses the proxy to enact
operations requested by the client. Examples of resource proxies are EJB home or
remote stubs, JMS connections or sessions, and web service client proxies. The
Control manages the state and lifetime of this proxy reference coordinated by a
set of resource management notification events. A resource definition in control
includes three classes, viz., Control Public Interface defining the set of
operations and events that are exposed for the resource type, Control
Implementation Class for providing the implementation of resource operations as
well as proxy resource management and The Control Bean Class-the Java Bean
wrapper around the implementation class that provides the property accessing
ability implementation.
Another notable feature in the framework is the extended
'property/value' features. Unlike enterprise beans where you typically have
getter and setter methods for reading and writing on a bean respectively, the
framework allows assigning properties by annotations based on metadata. This
means that you can add/edit properties in your 'Controls' rather than
surviving with getter/setter methods or going through adding source code for
adding a property. The same flexibility migrates into 'Contexts' as well.
Controls can be accessed from contexts within web tier containers (including JSF),
web services, standalone Java applications, and also EJBs. This helps in
integrating 'Controls' into different existing architectures.
Having outlined the basics of both these frameworks, we
will move a step forward to code a few samples using these frameworks. Eager
already? Watch out for the same space in the next issue!
Anadi Misra