An Oracle JDeveloper Statement of Direction, October 2001
In JDeveloper 2, Oracle introduced a series of Swing-based controls modified to bind to data sources. These specialized controls along with the supporting framework for building Java clients — Applications or Applets — are collectively known as DAC (Data-Aware Controls). Developers build DAC applets or applications by utilizing the controls exposed on the infoSwing and infoProducer tabs of the component palette or by using the Business Components Data Form Wizards. At the time of DAC's initial implementation, Sun was working on a standard called InfoBus, a promising standard for building reusable and high-performance data-bound controls. DAC was designed to utilize InfoBus with the expectation of widespread adoption of the new standard.
Over time, DAC has evolved to a sophisticated framework composed of numerous controls and services which provide the user full control over navigation, validation, and error handling on the client. When Business Components for Java (BC4J) was introduced in JDeveloper 3, DAC was modified to allow binding to BC4J as well as to database tables and columns. BC4J makes it easy for developers to cleanly separate building user interfaces from implementing business logic and validation, and reduces the learning curve associated with building Java-based database applications.
Unfortunately InfoBus has not enjoyed the popularity we anticipated, and our customers have indicated that the benefits of InfoBus are outweighed by the complexity of the controls. Meanwhile, BC4J has become a focal point of JDeveloper; Oracle is committed to enriching the feature set of BC4J and of BC4J clients. These two major factors have led us to re-evaluate how to support Java clients for BC4J. In Oracle9i JDeveloper we will leverage the full power of Swing to provide a rich set of controls which provide seamless integration with BC4J.
JFC/Swing components are based on a Model-View-Controller (MVC) architecture, popularized by the Object-Oriented language SmallTalk. With MVC there is a logical separation between the model, view, and controller of each UI component.
Figure 1: The Model, View, and Controller aspects of the MVC architecture.
The Model represents the data or state of the component. The View represents the visual aspect of the component, for example, the look and feel. The Controller provides the interaction with the client. For example, a JCheckBox is a Swing component which has a defined Model, View, and Controller. When the user interacts with the controller by clicking it, the controller notifies the model that it should change its state (from false to true or vice versa in the case of a default JCheckBox). The view, which is listening for changes in the state of the model, can then update itself (for example, by making the checkbox appear checked). An important point about this architecture is that model is not aware of the view or views displaying it, nor of the controller(s) being used to update it. This independence yields the flexibility of MVC.
Note: Due to the complex nature of the communication necessary between the view and the controller, Swing tends to logically combine these two aspects into an object called a Delegate. If you wish to learn more about MVC and how JFC/Swing implements it, there are a number of good references on the internet such as the online training from Sun.
Since DAC controls are generally based on Swing components, the MVC architecture is present. However, in order to make our controls use the InfoBus, we customize some of the controller aspects in addition to the model.
Figure 2: The MVC architecture as it applies to DAC and binding to BC4J through InfoBus.
In DAC, InfoBus serves as the rendezvous point between the UI components and BC4J. InfoBus consists of objects which make data available (Data Producers) and objects which can display and manipulate the data (Data Consumers). Objects such as SessionInfo, RowSetInfo and AttributeInfo are instantiated in a DAC client to be Data Producers on the bus, and the controls themselves act as the Data Consumers. In this manner, InfoBus manages the exchange of data between DAC controls and BC4J, and any developer wishing to access data programmatically in a DAC client does so using the InfoBus API. For more information on InfoBus, visit Sun's Java web site.
DAC also includes a navigation manager and validation manager, which are a series of predefined events and listeners which give the developer full control of the application. In some cases these events are generated by Data Producer objects, and in other cases by the controls themselves. In certain situations, the developer utilizes the base Swing component to capture events.
With the next generation of Java client for BC4J support in Oracle9i JDeveloper, we provide customized models based on the JFC/Swing default models. These models define the interaction between the client and BC4J.
Figure 3: The MVC Architecture as it applies to JUI and binding to BC4J.
For virtually every type of UI component model identified in JDK 1.3, JDeveloper supplies a specialized version of that model which knows how to communicate with BC4J. For example, JCheckBox uses a model called ToggleButtonModel (this model is also used by other Swing components such as JRadioButton and JToggleButton). When building a Java-based client for BC4J, the developer can bind a JCheckBox to BC4J by setting the model of the JCheckBox to JUButtonBinding (this can be accomplished using the Property Inspector and setting the model property). Without writing any code, the developer can build a Java client using standard JFC/Swing components which get and set values in BC4J.
For a given Java client, JClient maintains an XML file of information required by the client. This information includes details on which BC4J application module or modules to use, how to connect to the application module(s), and any extensions or customizations to the BC4J project the client needs. The XML file, called the JClient configuration file, is accessible to all of the classes that are part of the JClient project. This means that for a given application or applet, the developer only needs to select the application module(s) once, and can reuse the definition throughout the entire project.
Figure 4: The JClient Runtime details
At runtime, the JClient configuration file is read at startup by the first Frame or Applet class. The JClient configuration file provides a context for BC4J including where the Business Components are deployed and how to connect to them. This information is set at design time when the developer creates a JClient Data Model by selecting a BC4J project and a Configuration (which specifies the connection details). Depending on how the Business Components have been deployed, certain libraries will be required on the client. The JClient Data Model is responsible for including the appropriate libraries. The JClient Data Model may provide additional information to the client, such as overriding UI hints set by the BC4J project. For example, the developer may choose to override the format mask for a particular attribute. Since the JClient configuration file is in XML format, information in it can easily be changed at the installed site without requiring recompilation of the entire project.
The Business Components for Java framework manages all of the direct interaction with the database and provides numerous time-saving and performance-enhancing features such as object-relational mapping, transaction management, middle-tier caching, data synchonization, and business rule validation. For more information on Business Components for Java, please see the whitepaper on OTN.
The UI components in the JClient application bind directly to datasources in the Business Components. For example, a text field (JTextField) might be used to allow the user to view and modify an attribute's value, and a table (JTable) may be used to allow the user to view and modify all of the attributes in a given View object.
The following table lists the JFC/Swing controls in JDK 1.3 along with the model provided by JDeveloper for binding the control to BC4J. A description of the ways each control could be used to interact with BC4J is also provided.
Note: For Swing text components (for example, JTextField, JTextArea, JTextPane), the model is set via the document property.
| Control Name | Swing Model Name | JClient Model Name | Description |
|---|---|---|---|
| JButton | ButtonModel | JUButtonBinding | Invokes a list of values (LOV). Displays attribute data for the current row as the text of a button. |
| JCheckBox | ToggleButtonModel | JUButtonBinding | Displays attribute data for the current row as a checkbox. The text of the checkbox is fixed, but the state of the checkbox (checked or unchecked) is determined by the attribute's value. |
| JComboBox | ComboBoxModel | JUComboBoxBinding | Displays attribute data for the current row as a combobox. Depending on the value of the editable property, the control either allows the user to enter a custom value or not. The elements in the list may be hard-coded, or dynamically created from a View Object query. |
| JEditorPane | StyledDocument | JUTextFieldBinding | Displays attribute data for the current row in a JEditorPane. This is similar to JTextArea (multi-line text field), with the exception that it knows how to deal with certain types of content, and can be customized to work with other content types. The content type of a document is set using a MIME type, such as text/plain, text/html, text/rtf. |
| JList | ListModel | JUListSingleSelBinding | Displays attribute data for the current row as a list. If the number of values in the list is greater than the number than can be displayed, a scrollbar will appear. The elements in the list may be hard-coded, or dynamically created from a View Object query. |
| JPasswordField | PlainDocument | JUTextFieldBinding | Displays attribute data for the current row in a text field, with each character displayed as "*". |
| JProgressBar | BoundedRangeModel | JUProgressBarBinding | Graphically displays the current position of the View Object iterator as a percentage of the total number of rows. For display only. |
| JRadioButton | ToggleButtonModel | JUButtonBinding | Displays attribute data for the current row through one or more JRadioButtons, which are usually placed into a ButtonGroup. Only one RadioButton in a ButtonGroup can be selected at a time. Note that the JRadioButtons do not bind directly to a BC4J component. See JURadioButtonGroupPanel below. |
| JScrollBar | BoundedRangeModel | JUScrollBarBinding | Displays the current position of the View Object iterator as a percentage of the total number of rows. The user can change rows by using the scrollbar. |
| JSlider | BoundedRangeModel | JUSliderAttrBinding | Displays attribute data for the current row in a slider
control. The user can mnipulate the attribute's value by using the slider handle. Displays the current position of the View Object iterator as a percentage of the total number of rows. The user can change rows by using the slider handle. |
| JTable | TableModel TableColumnModel |
JUTableBinding | Displays multiple attributes and multiple rows in a table structure, usually with a scrollbar. |
| JTextArea | PlainDocument | JUTextFieldBinding | Displays attribute data for the current row in a multi-line text field, usually with a scrollbar. |
| JTextField | PlainDocument | JUTextFieldBinding | Displays attribute data for the current row in a text field. |
| JTextPane | StyledDocument | JUTextFieldBinding | Displays attribute data for the current row in a JTextPane. This is similar to JEditorPane (multi-line, content-sensitive text field), with the additional feature that components and images may be integrated with the text. |
| JToggleButton | ToggleButtonModel | JUButtonBinding | Displays attribute data for the current row in a two-state button (selected and deselected). Similar in behavior to a checkbox, but displays as a pressed or unpressed button. |
| JTree | TreeModel TreeSelectionModel |
JUTreeBinding | Displays attribute data from multiple rows from one or more View Objects in a hierarchical tree. |
In addition to support for all the JFC/Swing UI Components, JDeveloper will also ship with several composite controls commonly desired by developers. Each of these components utilizes a model property for binding to BC4J. The following table lists the Java client components provided in Oracle9i JDeveloper.
| Control Name | Model Name | Description |
|---|---|---|
| OrdMediaControl |
JUDefaultControlBinding. | Control for using intermedia and raw data whether it be Video, Images or Audio. Bound to a LONG RAW, BLOB, or InterMedia OrdSys.OrdAudio attribute. |
| JUChart | JUChartBinding | Displays View Object data as a Chart. The Chart is the Business Intelligence Beans Chart, and allows the user to visualize data in various chart styles (e.g. Pie, Line, Bar, Area, etc), and allows the user to interact with the chart to customize its appearance (Fonts, Colors, Style, etc). |
| JULabel | JULabelBinding | Displays attribute data for the current row as a static label. Used for display only. Note that since JLabel does not use a model, JDeveloper provides a control for this use. |
| JUImage | JUDefaultControlBinding | Control for displaying images |
| JUNavigationBar | JUNavigationBar | Displays a toolbar with iconic buttons representing common actions performed by the user during the running of a data-bound Java client, for example, First, Previous, Next, Last, Insert Row, Delete Row, Commit, Rollback, Requery, Help, and Exit. |
| JURadioButtonGroupPanel | JUButtonGroupBinding | Used to group a set of ToggleButtons (or a subclass, such as RadioButton) together on a panel. The ToggleButtons added to the control may be hard coded or dynamically created from a View Object query. |
| JUStatusBar | JUPanelBinding | Displays a status bar representing the current state of the application including current row, total row count, fetched row count, progress bar showing the current row's position relative to total number of rows, whether the transaction is dirty, message area, and working icon. |
There are many benefits to using JClient, most notably in terms of flexibility, reusability, performance, and usability.
By building upon the MVC architecture, JClient is able to provide flexibility in the types of controls that developers may use in their applications. In addition to the Swing and JClient components listed above, you can bind any model-based control to BC4J. If the control you wish to use is based on one of the standard Swing models, you can simply set the model of the control to use the JClient version of the model. If the control you wish to use is not based on one of the standard Swing models, you can write your own model using the JUControlBinding interface to provide the plumbing to bind the control to BC4J.
As part of the creation of a JClient Java client, an XML file is created which provides the information necessary to locate and connect to one or more BC4J Application Modules. This XML file can be reused within the application or applet, allowing the developer to easily create sophisticated applications consisting of multiple frame and panel classes. This is in contrast to DAC where the Data Producer objects of the application are implemented as part of the Java code in a given frame or panel class, making the information difficult to share across an entire project.
Because JClient binds directly to BC4J, any custom remote methods added to BC4J by the developer are immediately accessible to the Java client. Additionally, JClient has enhanced support for Oracle Objects. Component models can be bound to an attribute which is an Oracle Object Type (including collection types).
When developing a JClient Java client, the project is much more modular than in the past. For example, when running the Form Wizard to create a master-detail application or applet, the wizard generates several classes — one for a frame, one for a Layout panel, one for a panel containing the master control(s), and one for a panel containing the detail control(s). This means you can easily reuse one of these panels somewhere else in your application just by reinstantiating the panel with a different object name. The two panel instances can even bind to different View Object instances as long as the View Object instances are of the same type. For example, the developer may create a panel intended to show employees. The developer may point one instance of the panel to EmpView (as a detail of DeptView), and bind another instance of the same panel to EmpView1 (as a detail of EmpView, showing which employees report to a given manager). With DAC, a Frame or Applet is a monolithic object, containing all of the data binding and layout information, and making the possiblility of reusing components less likely.
Performance is greatly improved with JClient. First, JClient is able to take advantage of the numerous performance features implemented in BC4J, such as determining the number of rows fetched and the range size (which controls the amount of data cached on the client) and middle tier data caching.
In JClient queries do not get executed until they are required by the user interface. This reduces the startup time for Java clients without requiring extra coding by the developer. Additionally, JClient binds directly to instances of View Objects in BC4J, reducing the overhead encountered in DAC where the client creates new View Object instances in the middle tier.
Due to extra data marshalling requirements, DAC application and applets face a performance bottleneck with InfoBus. With JClient, this bottleneck is removed and the performance level is increased by removing the rendezvous point.
One of the goals of JClient is to reduce the amount of background information a developer needs to master in order to begin building an application. By removing the dependency on InfoBus and simplifying the framework for controlling user navigation and validation, the learning curve is greatly reduced. While a beginner can get started by using the JClient Wizards to build moderately complex applications, a basic understanding of Swing and familiarity with the BC4J API is all that's necessary for a developer to build sophisticated database applications with JClient.
Starting with Oracle9i JDeveloper, the recommended approach to building new data-bound applications or applets is to use JClient with BC4J. Therefore, the infoSwing and infoProducer tabs have been removed from the Component Palette and have been replaced with the JClient Controls tab. Additionally, the Business Components Data Form Wizards (for DAC) have been replaced with JClient Wizards.
For customers who have existing DAC applications, we will continue to support and apply bug fixes to the DAC framework and all of its components. The DAC runtime is shipped as part of JDeveloper, so you are able to open a JDeveloper 3.2 DAC project and use the Oracle9i JDeveloper IDE to edit, compile, debug, and test your applications. Note, however, that using the UI Designer for DAC applications or applets in Oracle9i JDeveloper will not be supported. If you need to use the UI Designer on a DAC application, we recommend that you use JDeveloper 3.2.3.
If you wish to upgrade your DAC application to JClient Oracle provide a utility and instructions for converting from DAC to JClient. Details are available on OTN
In terms of flexibility, usability, and power, JClient represents a huge leap forward for building data-bound Java clients. By leveraging the MVC architecture inherent in JFC/Swing, JClient with BC4J provides a productive and extensible framework for rapidly developing, debugging, and deploying scalable and high-performance database Java applications and applets.