Java Technology for Business Intelligence

Print-friendly Version

 

Java Technology for Business Intelligence -- Sun Technology Guide Draft 4.0

Introduction

Business intelligence can mean the difference between success and failure in e-business. The ability to successfully leverage operational data and networked applications into new Business Intelligence systems requires a solid architectural framework that simplifies complex development and increases product time to market. These systems must provide industrial strength scalability, rich levels of functionality and meaningful integration of data across disparate hardware and software platforms. Java technology, and more specifically the Java 2 Platform, Enterprise Edition (J2EE) can provide key benefits in building scalable, reliable, and secure BI applications, tools, and services. Building a successful Business Intelligence system requires more than just assembling the right hardware, software and networking components that comprise the solution. The demands of e-business have put unprecedented stresses on IT compared to the previous generation of Data Warehousing and Analytical systems. Access which was previously restricted to small groups of trained professionals is now expanded to a potentially unlimited community of customers, partners and suppliers. Warehoused information is now opened up to the unpredictable ebb and flow of 24x7 demand and global supply chains causing system scalability and availability to be of utmost concern. Data which was confined within a single application or Data Warehouse must be consolidated and integrated with customer clickstream and web data as well. Without the ability to respond quickly to changing business conditions, companies risk losing competitive advantage by taking a piecemeal approach to building Business Intelligence systems. The Java language, with its pure object orientation and universal portability has proven to be a highly popular language for developing applications for the Internet. The demands of e-business have led to the creation of J2EE, which brings the benefits of Java to the Enterprise Network. J2EE is designed to support multi-tiered architectures where tiers of application logic and code are integrated between the data and the client user interface, bringing high levels of scalability and reliability to web-enabled applications. Additionally, the Java platform provides a way to manage and access metadata through the new Java Metadata Interface (JMI) API, a set of interfaces for the creation, access, and interchange of metadata. Today most applications define metadata using proprietary schemes with different and incompatible semantics, structures and syntax. The lack of metadata interoperability prevents sharing of data between applications and limits the functionality of Business Intelligence systems. J2EE therefore can provide an end-to-end infrastructure for developing robust, mission critical Business Intelligence systems that can manage millions of transactions while encompassing all of the data within an organization through a common metadata model.

This Technology Guide explores these issues in detail and offers the reader some guidance in creating business intelligence applications using the J2EE platform.

Business Intelligence and What's Happening

Business intelligence (BI) is widely presented as a corollary activity to data warehousing, with more emphasis on integration, heterogeneous data sources, and delivered end user functionality. Although these are all essential elements of BI systems, the potential value of a BI system is much greater than what any Data Warehousing system can offer. BI systems are essential to successful participation in the Internet economy, with its radically compressed timeframes, global reach, and unlimited growth possibilities.

What is Business Intelligence?

A business may be Web-enabled for electronic commerce and have a Data Warehouse full of data and still not have business intelligence. Business intelligence means taking advantage of these data assets to make better business decisions, not just at the top of the organization chart, but throughout the entire enterprise. Business intelligence requires tools that can turn large data collections from heterogeneous sources into knowledge.

A business intelligence application should help you better understand your business and your customers. Employees throughout the entire enterprise should make better decisions as a result of having access to business intelligence applications. It has become obvious that Internet technology provides a perfect channel for the communication that BI requires. The existence of browsers on every potential user's desktop has vastly simplified the problems of communication and presentation.

Enterprises are accumulating data from a variety of sources at an incredible rate and trying to increase the utility of this data by allowing full-time access over networks. As enterprises put more and more data online, and support growing numbers of users, a typical application now requires integration of multiple heterogeneous sources in a multi-tier architecture. The middle tier must supply security and scalability as well as be able to deal with a variety of legacy systems as data sources and a variety of clients as customers. Furthermore, the middle tier must be capable of rapid adaptation to new requirements.

A short while ago, Internet access was restricted to browsers on desktop PCs. Now consumer electronics manufacturers are building Internet access into everything from watches and pagers to microwaves and refrigerators. Keeping up with customer expectations for information access will require exceptional flexibility on the part of developers.

Challenges For BI Developers

A software developer contemplating the design of a business intelligence application is faced with a number of hard decisions. Although the basic standards of the Internet are well established, higher level standards for integration and interoperability are only now being defined. In the following section we consider some of the challenges facing a developer who wants to create a BI application for the modern networked enterprise.

Historical BI Development: The Challenges of Building It Yourself

Developers, ISVs, and even sometimes end-users have in the past had to develop BI systems almost completely on their own, due to the lack of a standard development and deployment framework.

Lets look at some of the elements you have to be concerned with if you are creating a complete framework in-house.

• Connections to Databases. Not only do you have to create the code to connect to the large variety of databases that your clients may have, but you also have to provide for caching and connection pooling for optimum response time.
• Security at Multiple Levels. Every week seems to bring news stories of security holes in popular desktop software or hacking of Internet sites. However, in order to be of any use, a BI application must provide for access to sensitive materials by appropriate users. Security is going to be one of your users main concerns.
• Providing Scalability. Any BI development must necessarily start out with a small group of users. How can you be sure the architecture will work when it suddenly has to support orders of magnitude more users.
• Robust Thread and Memory Management. In the server environment, code should be able to run flawlessly for weeks or months without being restarted. Programming errors that accidentally "leak" memory or contain hidden flaws in thread synchronization may go unnoticed or ignored during development in the small scale but could crash the system when the product is used in a production environment.
• Session Management Due to the basically stateless nature of web server transactions, additional programming will be required to keep track of a single user's session.
• Presentation Design. Keep in mind that your best BI programmers are not likely experts at web page presentation and user interface design as well. You may have to add new members to your team. Furthermore, your customers may have their own ideas on presentation.
• Marketing. Your marvelous complete BI application is all finished, now how do you convince a potential customer to deploy it into their existing system, and what tools have you provided to make this easy?

Proprietary Servers

In an attempt to solve some of the previously-outlined challenges, and to take advantage of the fact that the Web has turned into a major channel for business applications that require more functionality than simple HTML can provide, software vendors have created their own proprietary application development and deployment frameworks. These frameworks solve many of the issues mentioned above with respect to database connection pooling, scalability, and resource management, but they unfortunately also lock the user into a proprietary architecture that is usually restricted in the number of hardware platforms it supports. Each application server vendor has their own scheme for creating add-ons and plug-ins.

Adopting a particular server vendor's approach can get you started quickly, but then you are locked into a proprietary architecture, unable to take advantage of other vendor's offerings, and dependent on your vendor for feature enhancements and porting to different hardware platforms. Investing man-years in a project tied to a proprietary application server architecture could be disastrous if the server vendor's priorities with respect to system enhancements, extensions, and the platforms they wanted to support are substantially different from your own.

The Advantages of Java Technology

The Java programming language has exploded onto the developer scene. According to a study by Bloor Research in January of 2000, Java is the most requested development language of all programming job advertisements surveyed. This is not just because coding in Java programming language is 40% more productive than C++ (IDC study, "Java Technology Pays Positively," May 1998) while providing superior object-oriented capabilities and high performance. Nor is it just because the reference implementation of the Java programming language and its libraries are freely available for download, making the barriers to entry the lowest of any professional programming language. Although these facts certainly help, the magnitude of Java’s success can only be explained in terms of the Java platform's design goals filling needs that were not met by other platforms:

• Accessibility to a wide audience. Because the reference version of the Java language and its libraries are freely available for download, it is effectively universally accessible. Additionally, the language's native use of Unicode for text representation gives it unprecedented support for internationalization.
• Platform independence. Java Virtual Machines (JVMs) are available at every scale, on virtually every platform, from palmtops, laptops, desktops, and workstations, to mainframes. The goal of "Write Once, Run Everywhere" is now a reality.
• Integration with other systems. The Java platform in general, and the Java 2 Platform, Enterprise Edition, in particular, is designed to work with the broadest possible set of software systems. Technologies such as Enterprise JavaBeans, CORBA, and XML, provide components and services for interoperability and integration. Standard and extension APIs such as those for database access, networking, servlets, mail, messaging, and naming and directory services, provide additional facilities for the development and deployment of powerful, robust, and platform-independent, solutions.
• Multi-tier Support. The Java programming language was designed from the beginning to be network aware. Many features of the language, such as object serialization and remote method invocation, make it easy to create applications that distribute functions across multiple systems.
• Scalability. The Java 2 Platform, Enterprise Edition provides a unified platform for the design, development, and deployment of applications that can scale from handheld devices to large scale distributed systems. Additionally, BI systems usually involve ad hoc combinations and transformations of large amounts of data, hence scalability on any single platform is crucial as well. J2EE implementations are being built on existing world-class enterprise middleware servers, guaranteeing highly scalable and reliable performance.
• Extensible. One of the guidelines for a successful software development process is incremental development, often expressed as a strategy to “plan a little, build a little, test a little.” Incremental development, and even more significantly, incremental roll-out, is made much easier by object-oriented programming and by a powerful object model. The Java programming language, JavaBeans, and Enterprise JavaBeans are truly object-oriented, not “object-based” nor “object optional.” The benefits of object-oriented programming have not been fully realized by most IS departments largely because of the confusion that results from adding object-oriented facilities to a procedural development language or object model. Most C++ systems are type-safe C systems, and the same observation applies to systems designed for APIs and object-models that were primarily designed with C programming in mind. Pure object-based development provides a level of extensibility and re-use hitherto unrealized in commercial application development.
• Cost. Java’s 40% productivity advantage over C++ directly translates to time and cost savings. This is especially significant when considering BI functionality, whose true value is typically apparent only as the system is integrated with significant data resources. Because Java systems are also scalable and extensible, business intelligence functionality can be brought online and prove itself without risking the devastating costs associated with “Big Bang integration” problems.
• Safety and Security. The ever-increasing importance of intellectual assets is the defining characteristic of Internet-era corporations. Not only do those assets walk out the door every night, their accumulated value is sitting on hard-drives throughout the company, protected only by the security model of the systems at the boundary of the corporation and the Internet. However, to succeed in the Internet era, the corporation must expose specified business intelligence (whether it be product details, technical support knowledge, or direct access to shipping status) to the outside world.

The Java Editions: Different Platforms for Different Scales

The Java 2 Platform, Enterprise Edition

The Java 2 Platform, Enterprise Edition (J2EE) exists to provide the following benefits for computing at the enterprise scale.

• Simplified development with reusable components to enable more efficient product development.
• "Write Once, Run Anywhere" compatibility tests to assure that solutions will run on any J2EE branded product.
• Industry support for J2EE ensures customers a choice of products, eliminating the risk of vendor lock-in and enabling customers to assemble best-of-breed solutions.
• "Wrap and embrace" vs. "rip and replace"; J2EE enables an environment that extends existing architectures, preserving previous investments with minimal disruption.
• Industrial-strength scalability with enterprise-class middleware services; J2EE provides a complete range of ready-to-use services, such as database connectivity, messaging, transaction management, and so on.
• Secure solutions; the J2EE security model guarantees the integrity of enterprise data.

The Enterprise JavaBeans (EJB) component model is the core technology for J2EE. Version 1.0 of the EJB architecture, developed by Sun and industry partners, has been the basis of numerous products. The lessons learned with this initial version have been applied in the version 1.1 specification and are combined with the new features of the Java 2 Platform in J2EE.

The J2EE Platform defines three types of “containers” that provide support for the various components of an enterprise system. A container provides an execution context and services for a certain set of component types. The Enterprise JavaBeans container supports business logic components encapsulated as EJBs, and provides back-end access to enterprise data sources plus other standardized services. The Web container supports components such as servlets and JavaServer Pages (JSP) that accept HTTP requests, connect to EJB resources, and respond with either HTML or XML. The third type of container, the client container, provides a Java 1.2 execution environment that includes support for JNDI, the Java Naming and Directory Interface that enables applications to locate and connect with services. In addition to guaranteeing access to Java 1.2 and JNDI, the Web and EJB containers guarantee access to a variety of other services such as JavaMail, RMI/IIOP, and JDBC. The containers are tied together with comprehensive security, transaction, resource management, and deployment models.

The Java 2 Platform, Enterprise Edition represents not just the potential to do great things in Java technology, but it lays down the API roadmap. In addition to providing a comprehensive software base, J2EE delivers additional elements to guide implementation teams.

Sun has developed the Sun Blueprints best practices program to provide the information essential to creating high performance, highly available, highly reliable applications using Sun technology. The "Sun BluePrints Design Guidelines for J2EE" provides an integrated set of documentation and examples that describe and illustrate best practices for developing and deploying component-based enterprise applications using J2EE. These design guidelines will evolve next year to include an Addison-Wesley book, "Designing Enterprise Applications with the Java 2 Platform, Enterprise Edition", as part of the Sun BluePrints series. The Sun BluePrints Design Guidelines for J2EE are intended to help developers of e-commerce applications in the areas of component design and optimization, division of development roles, and allocation of technology resources. It will do this by providing examples, patterns, and templates for providing services in a multi-tier application.

Multi-Tiered Architecture

The J2EE framework is designed for a multi-tiered architecture. In a multi-tiered architecture, one or more tiers of application logic and code are sandwiched between a data tier and a presentation or user interface tier. The multi-tiered architecture is especially important for BI systems, because it makes scaling up to larger databases and larger client bases easy.

In a multi-tier system, the client is thin, although not necessarily dumb. Client programming becomes primarily a matter of user interface, data presentation, and function navigation controls. Although this can still be challenging, especially when designing interfaces based on HTML, the J2EE platform allows the designer to choose between a client-side Java 2 applet or web pages dynamically created using JSPs or servlets that draw data from EJBs.

This is a good example of the sort of architectural issues that the J2EE design simplifies. Because Java technology is so easy to learn and extend, there are low barriers to entry for a development house interested in creating user interfaces using applets, servlets, or JSPs. The appropriate development kit can be downloaded from Sun for free. Using the examples provided, an intermediate Java programmer can be writing server-side Java programs in just a day. This is characteristic of the Java programming experience - new packages “just work,” and the developer is naturally tempted to start integrating the power immediately. There is no apprenticeship period where the developer is effectively forced to study the design of and ramifications of a technology.

Although the J2EE platform involves two tiers for the presentation layer (the applet and Web containers), it effectively leaves the data layer to database vendors. It does not specify implementation technologies or even the use of relational or object-oriented databases. Rather, the J2EE platform specifies a comprehensive set of access and transactional capabilities that must be provided by the J2EE platform provider. J2EE platform providers will undoubtedly compete on both scope and quality of their integration with various data-layer technologies, including database replication facilities for high performance in data-intensive environments such as BI systems. The resulting competition lowers the risk that a J2EE development shop will face a scaling or integration issue.

Many corporate data resources are held in large relational databases. The Java standard library provides the Java Database Connectivity (JDBC) API, for access to relational database via SQL. This well developed API is supported by all major development environments and all major relational database vendors.

Where J2EE shines is in the middle tiers. Although the Web container is conceptually a presentation-layer tier, because it is primarily involved with system navigation and the user interface, it physically is a server-side component. The elements of the Web container (static Web pages, servlets, and JavaServer Pages) are easily replicated in a dynamic environment, allowing load-balancing and scalability. Although dividing the presentation layer into two tiers (the applet container and the Web container) increases the number of pieces in the security infrastructure, J2EE simplifies administration by separating the roles. Fine grained security control is the responsibility of the J2EE platform provider, not the business intelligence development team.

Metadata Management

It is becoming increasingly important that in addition to platform independent, vendor-neutral access to data elements, the ability to store, access, and interchange metadata is crucial to managing the many heterogeneous data sources that organizations are faced with.

Metadata is very simply, data about data. Examples of metadata include information about the structure and organization of data, details about how it was acquired, processed, and updated, and what business rules went into producing it. It is essential when seeking to exchange data between tools, or operate on sets of very divergent data sources (such as what is being done now with enterprise portals) that the metadata describing the objects be accessible and interchangeable. A metadata framework simplifies the integration of applications, tools, and services, and enables interoperability and interchange among disparate data sources.

The Java Metadata Interface (JMI) Specification currently being developed through the Java Community Process Program (JSR-000040) will provide this functionality. It is a comprehensive, vendor-neutral metadata API that is based on the industry-standard Meta Object Facility (MOF) from the OMG. The MOF is a set of IDL interfaces that define an architecture for creating and sharing semantically rich metadata. It has been endorsed by over 30 vendors and has been or is being implemented by major vendors in the repository space. JMI is a pure Java API that implements the functionality of the MOF in a platform-independent, vendor-neutral specification. The Expert Group working to develop the JMI specification includes representatives from IBM, Unisys, Oracle, Hyperion, SAS Institute, EDS, and Inline Software. These companies are working with Sun to develop not only the JMI specification, but a reference implementation and a compatibility test suite as well. The specification will be available in the fall of 2000. Details can be found at the Java Community Process website at java.sun.com/jcp.

Connecting To Legacy Systems

A BI application involves a great deal of interaction with back-office and legacy systems. Enhancing and supplementing the functionality of these systems will be among the earliest concrete benefits of BI development efforts. Increasingly, these systems will be connected into the J2EE environment by way of a Connector. The J2EE Connector Architecture (JSR-000016 in the Java Community Process) defines the contracts that need to be fulfilled between the back-end system and the J2EE platform to support security, transactions, and resource management. A Connector implementation for a particular back-end system will thus allow J2EE component developers to treat back-end services as extensions to the platform. Some Connectors will be purchased and configured by System Integrators, whereas other Connectors will likely have to be custom built. However, the Enterprise JavaBeans developer does not have to worry about these details because the Connector architecture specifies the protocols.

Because Connectors are interfaces between the controlled and consistent J2EE platform and the outside world, implementing them is not likely to be trivial. Transactions, security, and resource management facilities must be propagated out to the external systems. Connector Providers must be intimately familiar with both the J2EE platform and the systems to which it is connected. Such expertise will be rare and it will be common to outsource the development of custom Connectors. Aside from the inherent exposure to existing legacy systems, there is no need for Connector Providers to be exposed to or apprised of corporate intellectual property associated with the business intelligence facilities under development. This makes outsourcing and the use of contractors a viable choice for the role of Connector provider in those situations where an existing, commercially available Connector is not available.

Implementing clients

It is important to consider the changing face of client-side technology. New types of BI systems may well exploit technologies such as smart pagers, intelligent wireless phones, and handheld devices. It is a fairly easy matter to have a Java component that can characterize a login session in terms of browser and connection capabilities and thus can provide client-side interfaces optimized to the particular session. A future application might be to create a Web-container-based proxy for the client-side browser that used text-to-speech technology to deliver business intelligence functionality over a regular phone connection.

The main point is that the Enterprise JavaBeans that constitute a BI application can be completely independent of these client presentation issues. No matter what the future brings in terms of client technology, the BI developer of an Enterprise JavaBean that encapsulates some particular business logic is insulated from these changes, and further, can expect to see that functionality accessible through the new client devices without making any source code changes.

Security

Security is going to be one of the biggest concerns for any potential BI application customer. Just within the last year there have been major news stories on web sites that could be made to reveal such things as customer credit card numbers. In order to sell a BI application for use on the Internet, you are going to have to convince the customer that it is secure.

More than any other programming platform, the Java platform has been designed from the ground-up with security considerations as a central feature. Because Java source code has been publicly available, constant probing by hackers and academics has made it more secure than any other platform. The security refinements in Java 2 reflect the lessons learned from this constant scrutiny.

The security architecture of J2EE is not an implementation model, but rather, defines simple but flexible relationships between protected resources, the roles that have access to those resources, and users and components (the entities that generate the request for access). The Enterprise JavaBeans security model allows the BI application developer to build beans without being concerned with the security model that the final customer will impose. Creating security management is the responsibility of Application Assemblers and Deployers - we will touch on these roles in more detail later.

Transaction Management

The Java 2 Platform, Enterprise Edition moves beyond Enterprise JavaBeans by extending transactions to the level of servlets and JavaServer Pages. This transparent support of transactions spans multiple components and transactional resources within a single J2EE platform. Whether the J2EE platform is implemented within a single JVM in a single process or is a large scale platform spanning multiple network nodes, a standard interface specifies a set of contracts that systems can rely on. Although transactions are not always a central part of BI systems, any system that involves the manipulation of large data sets, as a business intelligence system will, generally has at least some areas where transactional support becomes important.

Interoperability

One of the most important functions that the Java 2 Platform, Enterprise Edition provides for BI developers is interoperability. Corporations have existing software resources ranging from Visual Basic programs deployed at the department level to decades-old mainframe systems. J2EE is designed to communicate with all such resources. Additionally, the technologies that guarantee interoperability between Java and non-Java resources also are used to bridge the tiers of the multi-tier architecture characteristic of J2EE systems.

The Java DataBase Connectivity (JDBC) API provides a standardized way for Java programs to interface with large or small SQL database engines. All major SQL database suppliers are now supporting JDBC connectivity to their systems. This common interface means that the developer of an Enterprise JavaBean does not have to worry about the peculiarities of various databases.

The Java Metadata API previously described will provide a standard way for Java components to create, store, access, and interchange metadata models and model instances. This will enable increased interoperability between different tools and services, and will allow for disparate data sources to be integrated and interchanged.

J2EE uses CORBA’s Internet Inter-Orb Protocol (IIOP) as the transport layer for software intercommunication when a fairly high level of coupling is appropriate between components. Java Remote Method Invocation using IIOP (RMI/IIOP) is considerably more than a technique for distributed Java systems. RMI/IIOP allows for developers to access services not only from local or remote Java components, but also allows access to CORBA services that are distributed across a network.

On the presentation or client side of a BI application, many systems will be able to use the simple and widely available web browsers that are already in place on potential users desktops. JavaServer Pages and servlet technology can create dynamic web pages to interact with Enterprise JavaBeans implementing BI functions. However, if a specialized client program is needed, Java technology makes the creation of such clients easy.

For communication where loose coupling between sender and receiver is desired, a common situation in BI systems, the Java Messaging Service (JMS) should be used. JMS allows asynchronous communication between components and applications in either publish-subscribe or reliable queue modes. Because Business Intelligence systems often involve the combination and recombination of existing services and data sources, JMS is likely to play a major role in development.

Finally, although software-to-software communication can be enabled using HTTP, RMI/IIOP, or JMS, asynchronous software-to-human communication is often done via e-mail. A subset of the JavaMail API is supported by the J2EE platform to enable components to author and dispatch e-mails automatically.

Application Logic Development

One of the major advantages of using the Java platform to implement a BI system is its extensibility, which allows business intelligence functionality to be developed and deployed over time. For example, by proper application of object oriented programming principles, an application could start with relatively simple statistical processing capability and later add more complex calculations without requiring a complete redesign of the application.

Creating J2EE Applications

By thinking of the total problem of creating large scale distributed applications in terms of components, the J2EE platform is able to clearly separate the responsibilities involved into three distinct areas. In the spirit of the "the right expert for the right job" the Enterprise JavaBeans specification defines three different roles, the Bean Provider, the Application Assembler and the Deployer. The Bean Provider creates individual EJB components, the Application Assembler takes components from a variety of sources and assembles an application for a specific task, and the Deployer installs an application into a working system.

The mechanism for facilitating communication and interaction between these roles is the deployment descriptor. Deployment descriptors are created in the precise language of an XML document following the document type definition (DTD) in the J2EE specification. A deployment descriptor specifies attributes and features of the product defined at each step in the process of creating an application. The deployment descriptor file accompanies a component during the assembly and deployment process, and is the mechanism by which the various roles previously discussed (e.g., security) are assigned.

Component Developers - the Bean Providers

Everything starts with the development of individual Java components. The EJB developer is typically an expert in a particular problem domain, and creates EJB components encapsulating business logic that solve problems in that domain. The classes that create one or more components are packaged together with a deployment descriptor to create a J2EE module. The deployment descriptor makes explicit all features and dependencies of a J2EE module. In combination with the use of Java interfaces as the “public face” of Enterprise JavaBeans, this makes it possible to view a J2EE module as a single component. A J2EE application consisting of several J2EE modules will have a single application deployment descriptor, but may also have internal descriptors that “wrap” the deployment descriptors of the included modules.

The creation of a J2EE module is the unit of development effort within the application programming model. The deployment variables and dependencies of Web container and EJB container modules are specified in the deployment descriptor, an XML dataset that is stored in the module’s Java ARchive (JAR) file. Dependencies, security aspects, and run-time configuration parameters are specified in the deployment descriptor. Application Assemblers

An application assembler understands a particular BI problem domain, locates the required J2EE components (or “modules”) and builds a single J2EE application deployment descriptor. The deployment descriptor provides scalable assembly of J2EE modules and precise deployment control. An application is packaged using the JAR file format into a single file with the ".ear" (Enterprise ARchive) filename extension. During assembly, the directory structure for the application is established and embedded in the file.

The deployment descriptors for the modules are edited to establish links between internal dependencies and resolve any naming conflicts. The result of the application assembly phase should be entirely contained in the single ".ear" file that carries all of the necessary information for deployment of the application.

Deployers

In recognition that the final deployment of an application is a specialized task, the J2EE specification makes a clear separation of this role from the creation and assembly functions. The deployer makes those decisions that are specific to a particular installation. These include security settings and configuring connections to databases.

The deployer starts by reading the deployment descriptor associated with the packaged application, then the deployment descriptors of the individual modules. This information is used to install the various components in the appropriate container environment of the server. A variety of tools have been built to assist in this phase. One area of competition for vendors of application servers will be in the elegance and ease of use of the deployment tools.

Commercial Systems Using EJBs

The list of commercial vendors of application servers and tools using J2EE and EJBs is growing so fast that any listing here would be out of date.

A current listing is maintained at: http://www.java.sun.com/j2ee/industry.html

Some comments from industry leaders about their commitment to EJB based development can be found at:

http://www.java.sun.com/pr/1999/06/pr990615-03.html

Now lets walk through a hypothetical example of solving a business intelligence problem with J2EE. Our customer is a corporation that has made an extensive investment in a corporate web site and has been using TV advertising that publicizes the site. Now the marketing department wants to determine the extent to which this advertising has influenced the web site traffic. This will involve correlating information from two widely disparate sources, web site traffic logs and advertising department commercial broadcast records.

The BI developer tackling this problem recognizes that time-series analysis will be the tool most likely to shed some light on this problem. Furthermore, she realizes that the ultimate users of this system will require flexible graphic output in order to visualize the results. She locates one commercial vendor of an EJB component for time-series analysis and one for generating graphics. The development of an EJB to combine the two data sources into data sets suitable for input to the analysis EJB will be a custom programming job. Since these formats are well known, she can farm out this EJB development to an outside contractor if necessary.

Custom development required for the web based interface used to control the process and present the data will have to be done in house. As the system users come to understand the capabilities the application provides, they will undoubtedly be asking for changes. However, these changes can be handled at the level of the web interface forms, servlets and JSP, with the core of EJBs remaining unchanged.

Summary

In this paper we have explained how J2EE and EJB are ideally suited to the development of business intelligence applications in the modern networked environment. Sun's Java based architecture is flexible, widely supported, leverages and wraps existing resources, and is independent of particular hardware platforms. A quote from an early adopter says it very well:

"We believe the Java 2 platform, Enterprise Edition (J2EE) standards are as important to the growth in the Web application server market as SQL was to the relational database market in the 80's," said Scott Dietzen, chief technology officer for WebXpress, a BEA company. "For our customers, who have already deployed a diverse range of e-commerce and other Web-based applications, J2EE is key to protecting their investment."

Glossary

• Application Programming Model (APM). A programming model that defines how to use and combine the features of the J2EE platform to create solutions for common application domains in the enterprise.
• Common Object Request Broker Architecture (CORBA). An industry standard from the Object Management Group, this standard provides for communication between distributed objects that may be running on different platforms within a network.
• Components. In the J2EE scheme, application developers concentrate on components such as EJBs, JBs, and servlets, whereas J2EE platform providers concentrate on containers and connectors. Freed of the need to handle extraneous details, application developers can concentrate on their specialties, such as business intelligence.
• Containers. Containers on the server side provide the runtime environment for EJBs, servlets and JSPs. The container manages all interactions between a component and the outside world. On the client side, the Web browser is the container that supports HTML pages and applets.
• Connectors. A connector is an interface between J2EE components and existing information systems in the enterprise.
• Deployment Descriptor. An essential feature of the 1.1 release of the EJB specification is the use of XML to describe how an EJB or collection of EJBs and other components works in a Deployment Descriptor document.
• Enterprise JavaBeans (EJB). The Enterprise JavaBeans specification creates a component architecture for creating portable server applications. Enterprise JavaBeans constitute the core of J2EE applications which execute on a J2EE platform. There are two distinct types of EJB, session and entity beans.
• Entity Bean. One of the two types of EJB, an entity bean persists between user sessions and typically represents a database or business object. A J2EE platform must provide support for creation and persistence of entity beans.
• Extensible Markup Language (XML). XML is a standard for communicating data structure and contents that is rapidly gaining in popularity. As a text-based markup language it is simpler to learn and use than programming languages. The Enterprise JavaBeans specification switched from Java classes to XML for deployment descriptors on moving from the 1.0 to 1.1 specification.
• Interface Definition Language (IDL). IDL is a language used to described objects in a CORBA distributed object environment. In J2EE, the JavaIDL allows applications to access any CORBA object using the IIOP protocol.
• Internet InterORB Protocol (IIOP). This is the standard for connectivity through the Common Object Request Broker Architecture. Support for IIOP is required in the J2EE version 1.2 specification.
• J2EE Compatibility Test Suite. A set of compatibility tests to ensure that a J2EE platform product complies with the standard.
• >J2EE Platform. A J2EE platform is a server system that supports the full range of containers and interfaces required by the specification. A platform can run on any hardware and may connect applications in a variety of languages. A platform should support connection to legacy systems using CORBA or low-level Socket interfaces. The idea is that any BI application that runs on one J2EE platform should run on all.
• J2ME. The Micro Edition of Java 2 is a subset with reduced memory requirements designed for use in consumer products such as hand held devices. J2ME applications are upward compatible with J2SE and J2EE platforms.
• J2SE. The Standard Edition of Java 2 is typically used to create clients, JavaServer Pages and servlets. A J2SE development or runtime platform does not have to support Enterprise JavaBeans.
• JAR file. The JAR or Java ARchive file is a standard for packaging Java class files and other resources. Enterprise JavaBeans are distributed to application builders as JAR files. The JAR file format is also used for Enterprise ARchive files.
• Java Community Process. A process formalized by Sun in 1998 to enable the community of Java users to participate in the rapid development of new Java APIs.
• Java DataBase Connectivity (JDBC). The JDBC API provides access to a wide range of databases and is now widely supported by database vendors. A J2EE platform must provide JDBC version 2 for access to databases.
• JavaMail API. This API provides for creation and transmission of Internet standard MIME messages as well as access to messages in standard email storage. A J2EE platform must provide support for JavaMail.
• Java Message Service (JMS) This API provides for guaranteed message delivery between applications asynchronously. Using this API, you can be sure that vital information won't be lost if a single server is temporarily unavailable.
• Java Naming and Directory Interface (JNDI). This API provides a single interface to multiple naming and directory services. This means that an EJB can locate all the resources it needs through a consistent interface supported by the container.
• JavaBeans (JB). The JavaBeans API is the framework for user interface components used on the client side of J2EE applications. Basing client-side interfaces on the JavaBeans standard simplifies interface design and promotes development of reusable components. All major Java development systems provide for rapid interface development using JavaBeans.
• JavaServer Pages (JSPs). The JavaServer Pages API provides for embedding Java code in the context of a Web page. This allows dynamic web page generation based on information provided by Enterprise JavaBeans. A web page designer does not need to know how to program in Java in order to make use of JSPs. All J2EE platforms are required to support JSPs.
• Module. A J2EE module is a collection of one or more components of the same type plus a deployment descriptor in XML.
• Meta Object Facility (MOF). A set of IDL interfaces that define an architecture for creating and sharing semantically rich metadata. A pure Java MOF is currently under development.
• Object Management Group (OMG). The standards group responsible for many standardization efforts in the information processing industry such as CORBA and MOF.
• OnLine Analytical Processing (OLAP) One name for Business Intelligence applications for the rapid online analysis of data, typically summarized from massive databases.
• Remote Method Invocation (RMI). This is the Java standard API that allows Java programs to invoke methods in remote objects, subject to security restrictions.
• Secure Socket Layer (SSL). A J2EE platform is required to support this form of secure Web communication via HTTPS.
• Servlet. The Java servlet API provides for Java programs that execute in the context of a Web server, respond to HTTP requests, and generate HTML formatted replies. In a J2EE application, servlets and JavaServer Pages provide the connection between clients using Web browsers and Enterprise JavaBeans implementing business logic. Servlets are rapidly replacing CGI scripts on Web servers due to their greater flexibility and ease of programming. A J2EE platform is required to support servlets.
• Session Bean. One of the two types of EJB, a session bean works with a single client during a session and is removed when the session ends. An example would be a "shopping cart" bean.
• XML. See Extensible Markup Language.