General Java

The fifth anniversary of the inaugural JavaOne conference is upon us, and there can be little doubt that Java has had a profound impact on the way that applications are developed and deployed.

Over the past few years, Sun has continued to refine the Java specification, culminating in the groundbreaking release of the Java 2 Enterprise Edition (J2EE). Much of Sun's effort has gone toward the establishment of consistent application programming interfaces and technical infrastructures. The promise of multiplatform interoperability is certainly a heady goal, but it's a goal that seems more attainable now than at any time in recent memory. The combination of Enterprise JavaBeans, servlets and JavaServer Pages offers a powerful platform on which to build applications ­ but it may not be enough.

The IT industry is undergoing some powerful shifts that are beginning to garner press. The days of large, long-term projects lasting several years and with unlimited budgets ­ such as ERP implementations ­ are fast fading. Instead, corporations are favoring short (90-day) development efforts with near-term implementation goals. Large, complex applications are being built using a series of smaller projects that can be attacked in more realistic timeframes.

While this shift certainly improves the success-to-failure ratio of IT projects, it also requires developers to become much more disciplined about standards. After all, subsequent phases of a project must be able to build off the earlier phases in as seamless a fashion as possible. Corporations are finding themselves faced with the task of integrating their code into other applications managed by their partners and customers. This integration often involves the need to move applications to new platforms and environments. The result of these trends is a "Write once, build quickly and deploy everywhere" (WOBQDE) strategy that's quickly transforming the entire industry.

Many of the developers building these new applications will hail from the fourth-generation language (4GL) camp. While the J2EE product offers these developers a powerful platform for developing applications, it represents a fairly radical departure from the 4GL world. Java itself is a much lower level language for developing applications than traditional 4GL environments. Fourth-generation development environments (and languages) provide productivity improvements by handling many routine tasks such as optimistic locking, data caching and application deployment ­ freeing the developer to concentrate on business logic. The downside to most 4GLs has been their proprietary nature; developers needing to "go outside the bounds" of the language often find themselves faced with a formidable task.

Herein lies the problem. Is it possible to build enterprise-class applications in an incremental fashion along 4GL timelines using the J2EE? The answer just may lie with application frameworks.

Application frameworks are prebuilt libraries of core functionality used as a basis for developing higher-level software. Most object-oriented programmers tend to think of frameworks as nothing more than sets of class libraries but, while it's true they do generally include class libraries, they also provide tools to capture something of the flow of the business logic as well. While a class library that defines the attributes and methods of a "customer" object is certainly useful, a true framework will likely define how customers interact with other objects in the system.

The concept of frameworks isn't new, and many consulting firms and service organizations have developed their own custom frameworks in the past for other programming languages. Having prebuilt blocks of application logic available from project to project allowed these firms to reuse development work across multiple client companies. Instead of re-creating a solution for (say) order entry or error handling on a project-by-project basis, they built a framework for such tasks and used this framework in each individual application. With the popularity of the J2EE it's now possible to apply this same technique to the Java language.

Framework Definitions and Recommendations
There are no hard and fast rules as to what constitutes a framework. In general, it should provide the skeleton of an application and will either be horizontal or vertical in nature. Horizontal frameworks provide a basic technical skeleton for operations such as:

• Locking (optimistic and pessimistic)
• Master/detail coordination
• Caching

Vertical frameworks on the other hand generally provide precooked business objects that may or may not include a technical skeleton. A vertical framework might include the following types of components:

• Inventory module
• Customer module
• Orders module

Horizontal frameworks provide the most flexibility. You can use the basic framework to build yourself a set of customized objects that can serve as your own "vertical" framework. Conversely, vertical frameworks are extremely effective for business problems that match the content of the framework. For example, if you need to build an inventory control system, you might find that a precooked inventory framework is a good way to jump-start your development effort. If you find yourself making extensive modifications to the base vertical framework, however, a horizontal model might be a better option ­ you can use a horizontal framework to build your own vertical framework.

In either case, you'll want to be able to modify the framework as necessary and you'll want to be able to upgrade the framework without making manual modifications to production applications that have been deployed using it. Let's say that the framework includes some base logic for caching data and that you use it to deliver your own order entry application. Over time the vendor improves the caching techniques in the framework. Ideally you'd want to be able to deploy the updated framework without having to modify your production application. At a bare minimum, you'd want to be able to have your specific modifications persist through an upgrade to the framework.

Historically speaking, this is one of the basic flaws in most 4GLs that can be addressed by a good Java-based framework. 4GLs provided productivity through their own proprietary framework managed by the language itself. While this generally made programmers more productive, there were almost always some severe limitations that couldn't be overcome. Since the framework was proprietary, there was often no way to modify or disengage it. With a Java-based framework it should be possible to overcome this problem. A good framework will allow you to override methods (or replace them) as necessary on a class-by-class basis.

It's important that any framework be tightly integrated with your development environment. While you'll want to have flexibility in deployment, it can be counterproductive for your programmers if they're required to "jump through hoops" to work with the framework. It's a double-edged sword: on the one hand, you'll want to be able to use the framework directly in your developer IDE because this will help you to maximize programmer productivity; on the other hand, you don't necessarily want to see all of the low-level details of the framework when you're debugging or testing the application.

Above all, you'll need the manner in which applications are deployed with the framework to be flexible. Frameworks too tightly bound to a single deployment methodology (or server) will cause headaches in the long term. In today's marketplace it's important to be able to address two critical server markets, EJB and CORBA. But while you may develop applications that are strictly tied to either EJB or CORBA, there's no guarantee that your business partners will follow the same model. Being able to deploy your applications into either model from a single framework can thus pay dividends down the road. You'll also need to access your framework objects from a variety of client applications including Java client applications, wireless devices, JavaServer Pages and Java servlets.

In the remainder of this article I'll be taking a more detailed look at frameworks using Oracle's Business Components for Java (BC4J) product.

Business Components for Java
Oracle's BC4J is a Java-based programming framework that enables programmers to develop, deploy and customize multitier database applications. It is intriguing in that it's actually a framework designed to create other frameworks.

A BC4J application comprises three tiers ­ client, business logic and database. The client tier can range from a full-blown desktop workstation running Java applications all the way to ultra-thin devices such as a PDA or cellular phone. The business tier contains business rules, application logic and predefined views of business data ­ and can be deployed as EJB session beans or CORBA server objects or used as a simple set of local classes. The database tier contains the persistent store for the application (such as an Oracle8i database).

BC4J is both a development framework and a deployment framework ­ all written in Java ­ and provides a suite of design-time wizards and editors providing you with the tools to define the base characteristics of your components. Each component (constructed of attributes, relationships and business rules) is then implemented as Java source code and XML metadata that implements the behavior you've specified during the design phase. The generated code inherits from the BC4J framework, keeping the Java source files relatively concise, thus making it easier to modify the components as necessary.

BC4J applications are constructed from six framework components (see Figure 1):

• Application modules
• View objects
• Entity objects
• View links
• Associations
• Domains

Entity objects encapsulate the business logic and attribute (column) information for database objects. The underlying database objects themselves can be tables, views, synonyms or Oracle snapshots. Within the BC4J developer environment you can either define new entity objects and then use them to create new database tables or you reverse-engineer them from existing database objects. In the sample donor management application shown in Figure 1, Alumni, Pledge and Donation are all entity objects. By default the attribute names will match the table column tables, but you're free to change the attribute names to better reflect the needs of your business within the BC4J entity object. Since the entity objects are derived from database objects, they inherit database information such as primary/foreign key relationships, data type, length, precision and scale information.

Relationships between entity objects can be defined through associations. Consider the Alumni and Pledge entity objects in Figure 1. Although it's likely that a referential relationship already exists in the database between the Alumni and Pledge tables, you can define an association at the object level with BC4J as well. (In fact, BC4J will reverse-engineer these associations for you if they exist in the database.) Associations provide you with the tools to define accessor methods in the model. For example, you could create an accessor method in the Alumni entity object called getPledges that would retrieve the Pledge records automatically.

View objects are logical definitions of data that are used to join, filter, project and sort business data for a specified scenario. Although they're similar in concept to database views, they provide for a much higher level of abstraction. Figure 1 shows two view objects in the form of BigSpenders and LatePayers. View objects use SQL under the covers to fetch their data, but client applications are insulated from these details. Application code manipulates the data by "getting and setting" attribute values, and changes are persisted to the database by the framework when transactions are committed. When you define a view object you can determine which underlying attributes are read-only and which ones support read/write operations. BC4J caches view objects at the entity object level and all view objects referenced within a single transaction share the same cache, so that changes to one view are visible to all other views within the same transaction. Many business intelligence-style applications offer "click-through" capabilities for drilling down into detail data from master records and the view cache can simplify the development process for these applications.

BC4J allows you to define relationships between multiple views through the View Link component. The View Link wizard provides a tool for specifying the relationship, either one to one or one to many. View Links provide restrictions against detail data (much like adding a WHERE clause to SQL) and are particularly useful in designing master/detail and master/detail/master relationships in your application.

Data definitions and validation logic for attributes can be specified using Domains. The base Domain component is provided by the BC4J framework itself, but the developer defines the data type, Java class and validation built into the constructor. Many common validations (primary key, mandatory, unique, persistent and default value) are provided within the domain wizard. Domains can also serve as base data types for new attributes. For example, creating an "alumni ID number" domain in the donor management application.

The Application component is a Java class that inherits from oracle.jbo.server.ApplicationModuleImpl ­ and the Application wizard generates this class for you. The application component provides an overall container for your application. As with any framework, you'll want to have the ability to customize this class. BC4J allows you to specify a custom class (which must extend from the ApplicationModuleImpl class) for this operation as well. If your organization already has some application-specific logic in place, you can use this technique to include your own logic in the generated framework. This is a critical area in which Java-based frameworks diverge from classic 4GL-style frameworks. Whereas a 4GL framework tended to force developers to accept the generated framework, the Java-based framework is extensible.

Working with BC4J
The BC4J is included with Oracle's JDeveloper IDE. While you can create complete applications from scratch using a framework, many applications are constructed from preexisting data models. A horizontal framework can be particularly useful in such cases. Since you already have the data model in place, there's no value in having preconfigured entity objects as you would with vertical frameworks. In-house we use an existing data model as a starting point for technical testing. This logical model is based around a fictional university database of student and alumni data. In order to get the most out of a framework it's important to have a reasonably well-defined data model. For example, the NETU model (see Listing 1) makes extensive use of primary and foreign keys to map the relationships between the various tables. If we'd ignored declarative integrity constraints and built the data integrity into our application using database triggers and stored procedures, it would be much more difficult for the framework to interrogate the data model.

The NETU data model is composed of 15 tables, but the logical donor management application concerns itself with the Alumni section of the data model as shown in the UML diagram in Figure 2.

Each UML entity in the UML model corresponds to an entity object in the BC4J framework. From this simple data model you can see the power of using a development framework. The BC4J development environment created a complete application skeleton implemented in Java and XML from the data model. Many of the most common processing tasks have been implemented as a series of Java classes. For example, each Alumni record is connected to zero or more Pledge records that are in turn connected to zero or more Donation records. This is a fairly complex master to detail/detail relationship that would normally require a significant amount of basic coordination code to implement. This is exactly the situation in which a framework can provide significant value. In the case of BC4J, the framework includes a significant number of generated routines for working with your data such as those listed in Table 1.

One of the more interesting built-in capabilities is that multiple views of the same data within a single session are automatically synchronized. Figure 3 shows the test interface for the generated application with the Alumni table joined to the Pledge table.

The test interface provides a simple mechanism for working with the generated code in an interactive fashion. You can navigate through the Alumni records and they're automatically coordinated with the proper Donation records. Even if you open multiple Alumni views and modify data, it will remain consistent within all of the interfaces. Experienced 4GL developers are most likely accustomed to getting this type of default behavior out of their development tools, but this type of automated development might be new for Java developers. The key difference with the BC4J framework versus a proprietary 4GL is that the generated application is Java and XML. Changes to attributes are handled with get and set methods, and navigation through rows is handled by built-in navigation methods. The objects and attributes themselves are implemented as XML documents, as shown in Listing 1.

All of the attributes for each object are implemented as XML documents in the BC4J framework. Some of the elements in the XML descriptor will be immediately familiar, such as the base data type for each field in the table/view. BC4J implements all of the extended attributes in the XML file as well. Foreign key connections and field validations are also generated into the XML document for each component.

The combination of Java code and XML component definitions makes it easy to modify any behavior of the framework. Developers can also modify the application easily with minimal impact to the code by leveraging the Java language's "extend" capability. (You can also extend your business components by modifying the XML metadata.) As you roll out new versions of the base application, these customizations are preserved. Thus, if a client were to create a modified version of the Alumni table that supports additional attributes, new versions of the base application could be deployed subsequently without losing these customizations.

Deploying Applications
The last critical element of any framework is the ability to deploy the application in a flexible manner. While you might standardize on the J2EE as your deployment platform, you may need to deploy the same logical application as a thick Java client program using Java servlets and JavaServer Pages. You may also find it necessary to deploy the application to a CORBA environment in order to connect the application to an external application controlled by one of your business partners. For example, in the sample NETU case we might decide to use a third-party telephone calling service to contact the Alumni and solicit pledges and donations. While we may implement the donor management application as an EJB application internally, we could deploy portions of the application externally as a CORBA service (or as a set of local classes). Our telephone solicitation partner could connect to the Alumni data through their own internal CORBA applications (for example). Listing 2 shows the partial results of generating an interface for our NETU application as both an EJB application and a VisiBroker CORBA application.

All of the necessary code for the application is deployed along with the custom code. With BC4J the client code is designed to work against interfaces, so it's not necessary to modify developer-written application code when deploying the application to multiple tiers. The default deployment model with BC4J uses a very coarse-grained application model. In the NETU example case the application was deployed using a single remote interface for CORBA/EJB (see Listing 2). While you are certainly free to expose additional business methods as remote interfaces, all of the core functionality that we've discussed thus far is provided in the default BC4J framework.

Summary
In record time we were able to construct a complete application with a JSP front end against our NETU database model by leveraging the power of a framework. The application provided read, write, update and delete functionality across all 15 tables ­ including the coordination of multiple master/detail relationships, query by example and foreign-key validation. Using the BC4J framework provided us with the luxury of concentrating on the business logic without regard to the underlying plumbing. Unlike traditional productivity solutions, however, we can easily modify the base functionality of the application using standard Java coding techniques. Frameworks such as BC4J provide enterprise developers with the tools to tackle complex development efforts with short deadlines ­ a requirement of the new e-business economy.