-C H A P T E R

C H A P T E R 1

Overview and Component Architecture

Component-Based Development (CBD)

Component-Based Development (CBD) is a highly regarded engineering strategy whereby the production, distribution, and consumption of components contribute to more efficient and reliable application development. Mature CBD combines a robust component model with a component-aware IDE.

The producers of components (component authors) are responsible for developing components according to the specification of a particular component model (component architecture). A component model formalizes component structure and specifies a means of component distribution. A mature component model also allows each component to be self-describing, so that it can advertise its features to component consumers. Components are typically distributed as collections known as component libraries.

Components can come in a variety of flavors intended for use in different development scenarios. For example, components can be designed in a very generic, or horizontal fashion to cut across a range of specific development needs. These components tend to be the broadest components available, with their strength being flexibility and customizability. These types of components are usable by many different application developer populations, across projects and companies, and in the Web application space, and generally are not biased toward any particular look and feel. Alternatively, other components can be designed to satisfy a narrower, vertical set of development needs. These components are tailored to a particular usage scenario, allowing them to provide high-level features and high ease-of-use. These types of components are less broadly usable, but because their scope is more narrowly defined, they can keep parameterization to a minimum and use a particular look and feel.

The consumers of components are typically application developers. In CBD, application development consists primarily of aggregating or assembling a particular application from a collection of reusable components. The greater the coverage provided by the components, the smaller the amount of application-specific code.

A component-aware IDE is necessary to expose components to the component consumers. The IDE leverages the self-describing nature of components to dynamically present components for instantiation and configuration. The IDE is the final piece of the puzzle, but it is very significant. Without a component-aware IDE, the component model exists only on paper. Without a component-aware IDE, developers can only use a component as they would any other Java class, through its public API. A component-aware IDE, on the other hand, allows developers to browse through collections of components, visually assemble components into application entities, and configure components by declaratively filling in component-specific property sheets.

The rest of this document describes the Sun trademark ONE Application Framework component model, and the manner in which component authors can leverage that component model to create powerful component libraries.

What is a Sun ONE Application Framework Component?

Since its inception, the Sun ONE Application Framework application has supported a component model for certain types of objects. However, the prior component model relied on developers to learn each component's API and write code to use that component in their applications. Although this level of functionality was sufficient and provided a significant productivity advantage over contemporary competitors, the Sun ONE Application Framework version 2.1 has significantly extended its component model to encompass all types of primary Sun ONE Application Framework application objects (Views, Models, and Commands). Furthermore, the Sun ONE Application Framework module for the Sun trademark ONE Studio now provides a full featured, component-aware IDE that creates a visual development environment for Sun ONE Application Framework applications.

In Sun ONE Application Framework 2.1 terms, a component is one of the various types of supported component classes (Views, Models, and Commands) in conjunction with metadata information. This metadata is encapsulated in a Sun ONE Application Framework-specific class called a ComponentInfo class. At design-time, the Sun ONE Studio can inspect the ComponentInfo and present the component in an easy-to-use visual fashion.

The metadata stored in ComponentInfo classes is intended to enable automated use of the component in a development environment, such as the Sun ONE Studio. Developers can still manually create and use various types of components in their applications without defining a ComponentInfo class.

Sun ONE Application Framework Component Libraries

The Sun ONE Application Framework component model requires that components intended for discovery by the IDE toolset must be packaged into a specific component library format. A Sun ONE Application Framework component library consists of a standard JAR file containing the component classes, ComponentInfo metadata classes, and a single component library manifest file. The component library manifest file is described in detail later in this document.

Note - A component library JAR can contain any number of non-component related classes. It is just a standard JAR file with some component-model-specific additions.

Application developers make use of the Sun ONE Application Framework component libraries by placing them in their Web application's WEB-INF/lib directory. The IDE toolset automatically recognizes and mounts any component libraries placed in that directory. After the IDE toolset has discovered and inspected the libraries (it might take a minute or two due to background thread latency), the library components are available for use within the application. The components are then said to be registered with the IDE toolset.

Hint: The library manifest inspection and component registration process recurs every time a Sun ONE Application Framework application is remounted within the IDE toolset. This is natural and should be expected, because the component model is entirely dynamic. However, both component authors and application developers should be aware of this process and understand that the accidental or intentional removal of a component library from the application's WEB-INF/lib directory results in the expected omission of those components the next time the application is mounted.

Sun ONE Studio troubleshooting hint: A common mistake of newcomers to the Sun ONE Studio is to improperly mount a Web application. The Sun ONE Studio's Web application module (upon which the Sun ONE Application Framework toolset module is built) only recognizes a mounted file system as a Web application if the mount point corresponds with the root of the Web application structure. If you do not mount the Web application at its root directory, the Sun ONE Studio treats it as a conventional file system, and fails to provide the Sun ONE Application Framework application view that you expect. Keep this in mind as you build and test your first components. The easiest way to avoid any confusion in this regard is to use the Mount Sun ONE Web Application action of the IDE instead of the Mount File System action.

The Sun ONE Application Framework Component Library

The Sun ONE Application Framework Component Library contains the core interfaces, run-time classes, and many basic components that you use to create a Sun ONE Application Framework application. The standard Sun ONE Application Framework Component Library is packaged as a single JAR file, and should appear in your application's WEB-INF/lib directory.

When creating a Sun ONE Application Framework application using the IDE toolset, the current version of the standard Sun ONE Application Framework Component Library is automatically added to the application's WEB-INF/lib directory. If you open an application created in a previous version of the IDE toolset, you might be prompted to upgrade the application, including the Sun ONE Application Framework run-time library.

The Component Class

A Sun ONE Application Framework component class is the class which defines a Sun ONE Application Framework run-time type, a View, a Command, or a Model.

The author of the component class is only concerned with design-time considerations to the extent that a JavaBean developer would do so. That is to say, as a component author, you must anticipate the properties which you would like to expose to design time configuration and define appropriate get and set methods. However, unlike the JavaBean model, the Sun ONE Application Framework component model does not eagerly expose all get and set methods as properties. That is because the Sun ONE Application Framework recognizes that there are many get and set methods in the Sun ONE Application Framework core from which the components derive which are not appropriate for design time configuration. Therefore, the Sun ONE Application Framework component model limits the exposed properties to those which are explicitly specified in the companion ComponentInfo class.

The ComponentInfo Class

The ComponentInfo class is the heart and soul of the Sun ONE Application Framework 2.1 component model. Logically speaking, a Sun ONE Application Framework component can be referred to as a tuple comprised of a component class and a ComponentInfo class. The ComponentInfo class provides the metadata that is introspected by the IDE toolset to provide the component's design-time presence. When you author a ComponentInfo class, you can focus exclusively on design-time considerations. The ComponentInfo class plays no run-time role in the Sun ONE Application Framework.