8.5 JavaBeans | Internet-Enabled Business Intelligence


Team-Fly

	Internet-Enabled Business Intelligence By William A. Giovinazzo
	Table of Contents

	Chapter 8. Java

8.5 JavaBeans

We began our introduction to object-oriented programming by describing how years ago project managers would create libraries of common functions. We repeatedly used these functions throughout the project lifecycle, with the aim of increasing both productivity and system integrity. This is one of the aims of object-oriented programmingto increase the reusability of code. This is also one of the aims of Java. Up to this point, however, we have primarily focused on Java's abstraction of the underlying IEBI platform. The Data Mining API provides a means for clients to connect to a back-end data mining engine. The MDAPI provides a means of writing an application with a common set of objects that can be independent of the underlying multidimensional database.

In all of the cases, we still need to sit down and write the application. Wouldn't it be wonderful if we could leverage the reusability given to us by Java's object orientation to develop IEBI systems? Fortunately, the Java language designers have seen this need and provided us with JavaBeans. There are two types of JavaBeans, JavaBeans and Enterprise JavaBeans (EJB). JavaBeans are a specialized class of reusable components . They are self-contained objects assembled to form an application. We can envision these beans as the software entities that implement specific controls and widgets when developing an application. We will see in the subsection to follow, however, that they can be used in the middle tier as well to implement application logic. Developers write the beans according to a set of rules that define how the tools interact with one another. By following these rules, the JavaBeans can be integrated into any Integrated Development Environment (IDE). Tools such as Oracle's Jdeveloper, IBM's Visual Age, Inprise JBuilder, Sybase's PowerJ, and Symantec Visual Caf all work with JavaBeans. The IDE is able to inspect the JavaBean and understand its methods and attributes. The tool can then manipulate the bean just as it would any other entity.

Application developers benefit from JavaBeans in two ways. First, organizations can use beans for their internal software development projects. This is similar to what we did in the old FORTRAN days. The first thing a development team does is create a base-level set of beans. These beans can implement such functionality as the User Interface (UI) components or application logic. With standardized beans for the UI, applications have the same look and feel throughout the organization. Beans can also be used in the development of applications. For example, a department may develop beans that read and write to a file according to some specific standard. Application developers use the beans to interact with the file, thus ensuring that the standard is enforced.

Application developers also benefit from the use of prebuilt JavaBeans developed by the Independent Software Vendor (ISV). An ISV may offer a data mining or OLAP tool. Along with the actual software, the ISV may distribute a set of beans that interact with the application. One could assume that since the ISV developed the tool, it will also know how to optimize the beans to use the tools in the most efficient manner. Application developers can then simply take the beans provided by the ISV and plug them into their homegrown application. This of course results in inexpensive, efficient applications specifically tailored to the needs of the organization.

These two benefits combined solve another issue faced by many organizations. We discussed in Chapter 5 the differences between information dictatorships, anarchies, and democracies. We noted how the Internet-enabled structure gives us the benefit of centralized control found in information dictatorships, while giving individual departments the independence found in information anarchies. This led to information democracies. JavaBeans are one of the features of the Internet that enabled us to develop such a democracy.

Departments that wish to develop their own applications often are not concerned with enterprise standards. This causes endless problems on an enterprisewide scale. When the developer of the department's application disappears, IT is handed the task of supporting it. There are no UI or coding standards, so applications vary greatly from department to department. To resolve this issue, IT can simply release to the departments JavaBeans that meet the corporate standard. The departments can use these beans to develop their individual applications as they see necessary. The IT department is able to enforce its standard, while the department's application development effort is simplified.

The second class of beans we can discuss are EJBs, which address the ability to deploy component-based, distributed applications. The EJB architecture is defined by Sun as "a component architecture for the development and deployment of component-based distributed business applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user secure. These applications may be written once, and then deployed on any server platform that supports the Enterprise JavaBean specification." ^[4] We can envision EJB as an application framework for the development of application server components. Where JavaBeans support a component model, EJB support reusable components designed to run in an application server. These application server components are referred to as server components.

^[4] Sun Microsystems' Enterprise JavaBeans Specification, v1.1, Copyright 1999 by Sun Microsystems, Inc.

At first we might be tempted to look at EJB as an extension of JavaBeans, but this would be incorrect. JavaBeans use java.beans defined in the Java API. EJB uses the classes and interfaces in the javax.ejb package. JavaBeans define components such as UI interface objects and widgets. EJBs address the management of distributed objects in a multitier environment.

The concept behind EJB is that objects residing on a middle-tier server appear to be residing on the client. The actual location of the object is transparent to the client. Figure 8.9 shows how this works. In this figure, we have a simple distributed object called OLAPSERVER. Applications interact with the OLAPSERVER object via the OLAP interface, which is separate from its implementation. The OLAPSERVER object, however, supports the interface, providing to it the actual business logic and state. A stub on the client, in this case OLAP_STUB, resides on the client so that it seems as if the OLAPSERVER resides on the client. The stub communicates with the skeleton on the server to fulfill requests made by the client.

Figure 8.9. EJB remote method invocation.

graphics/08fig09.gif

To understand how this works, let's follow the request demonstrated in Figure 8.9. When a method, such as AGGREGATE, is invoked on the stub, a token is created and sent to the OLAP skeleton, OLAP_SKEL. The skeleton parses the request and invokes the appropriate method on the object. The object in turn passes back the results of the request, in this case the aggregate values. The skeleton passes the results back to the stub, which in turn passes it to the client. As far as the client is concerned, the request was made to and fulfilled by the client stub.

As we discussed in relation to JavaBeans, there are benefits to the use of EJB. Just as with JavaBeans, applications are standardized through out the organization. We can envision ISVs implementing their applications on the middle tier and distributing the appropriate stubs for further development by the user.

We discussed how JavaBeans can help ease the struggle between individual departments within an organization and IT. EJB takes us another step towards this goal. In Chapter 3, we compared IEBI environments in which a central data warehouse supports dependent data marts. Departments resist such centralized system because they want to maintain control of their applications. With EJB, departments are able to integrate their applications into a central system while still maintaining their freedom.

One of the concerns with giving the departments free access to the centralized data warehouse is the integrity of the data coming into the warehouse. In addition, standards need to be maintained for data access. Since the actual implementation of the object is on the server, the central IT department can maintain standards, yet turn over application development to the individual departments.

8.5.1 ORACLE 9i BUSINESS INTELLIGENCE BEANS

In this section, we examine the use of JavaBeans in an IEBI environment. Oracle has developed Oracle 9i Business Intelligence Beans, a set of standards-based BI beans that take advantage of the Oracle 9i OLAP. These are exactly what we discussed in the previous sectiona set of building blocks upon which developers can quickly and easily build complex BI applications. These beans fall into three basic categories: Presentation, OLAP, and Catalog services. Figure 8.10 shows the architecture in which these beans fit together.

Figure 8.10. Oracle Business Intelligence Beans architecture.

graphics/08fig10.gif

At the topmost level, we have the Presentation beans. Developers can choose to present data in three different modes: graph, table, or crosstab. Graphs provide complete analytical support for drilling, changing the graph layout, and providing data tips. Tables provide the traditional row-oriented data views. Crosstabs offer a multidimensional view of the data, providing such multidimensional capabilities as drilling and pivoting. Presentation beans are either Java-based for users with high-speed connections or HTML-based for users with slower dial-up connections.

Recall from our earlier discussion of object-oriented programming that we can build applications by reusing prebuilt objects. This is part of the motivation for designing Java as an object-oriented language as well as the concept behind JavaBeans. To achieve this objective, JavaBeans must be replicable, able to be used over and over again in different applications, and adaptable, able to be modified to meet the specific needs of the application. This poses a challenge, since the two goals seem to conflict with one another. How do we create objects that we can customize and still maintain repeatability ? Oracle 9i Business Intelligence Beans uses presentation beans that provide customizers that enable end users to format the presentation of the data. The presentation beans customization allows the end user to modify all the aspects of presentation, such as formatting and filtering of the data.

Again, we see another example of replicability and adaptability in the second type of Oracle 9i Business Intelligence Beans, OLAPBeans. Out of the box , as they say, the OLAP Beans support the OLAP features integrated into the Oracle 9i database. Developers, however, are able to adapt the default functionality through a set of APIs. Additional OLAP functionality can be created via the Query Builder and the Calculation Builder. These tools allow the decision maker to create advanced calculations through templates. We discussed in Chapter 3 the importance of creating an environment in which the decision maker can truly interact with the data. These builder tools are important in this regard. They provide simplified access to the advanced OLAP features in Oracle 9i while freeing the decision maker from the necessity of understand the underlying SQL.

The Business Intelligence Beans Catalog manages the metadata definitions of all the developer and user defined BI objects. An XML-based catalog saves the definitions of all reports, graphs, favorite queries, and custom measures. These object definitions are organized into folders with security features that enable users to securely share reports and calculations. All client types, such as Java and HTML, support the definitions within the Business Intelligence Beans Catalog. The application logic can be deployed on any of the different tiers, such as a thin client or Java client, yet all the logic resides on the middle tier.

In Figure 8.11 we see how the Oracle 9i Business Intelligence Beans work together. The presentation beans are downloaded to the client's browser. Proxy objects are also downloaded to the client's browser to provide a stub for the OLAP Beans. The actual implementation of the beans occurs on the middle tier. By implementing the objects on the middle tier, applications can be written to support a variety of clients. The proxy object communicates with the middle tier via the Oracle Business Components for Java, eliminating the need for the developer to deal with a CORBA connection.

Figure 8.11. Oracle Business Intelligence Beans.

graphics/08fig11.gif

Oracle 9i Business Intelligence Beans demonstrate two important features of Java and JavaBeans. They have been able to successfully leverage the object-oriented aspects of Java to provide a scalable, portable BI environment over the Internet. They have also shown how software providers can use beans to extend the functionality of their products. Since it is Oracle, they are able to develop beans that are more fully integrated into the underlying OLAP engine. This of course results in better performance, greater functionality, and a higher level of integration. As other software vendors follow suit, the benefits of JavaBeans and EJB will become more pronounced in the general software industry as well as in the world of IEBI.


Team-Fly

Top