Throughout this book you've learned just about everything there is to know about the JavaBeans technology, at least in terms of what there is to know today. Like most software technologies, JavaBeans is rapidly growing and evolving to become more powerful and extensible. Because of this, it's only fitting that the last chapter of the book focuses on the future of JavaBeans. This chapter takes a look at what the future holds for JavaBeans from a few different perspectives.
You start off the chapter by learning about some of the enhancements planned for the bean component model. Few software technologies are perfect, and JavaBeans is no exception. Therefore, a few enhancements are already in the works for a future release. From there, you move on to learn about application builder tools that will support JavaBeans in the near future. These builder tools are expected to provide visual bean construction support similar to that provided by the BDK's BeanBox test container. You then turn your attention to JavaBeans and how it will integrate with other component models such as ActiveX and OpenDoc. Finally, you finish the chapter by taking a close look at how JavaBeans fits into the software component marketplace with ActiveX. These two technologies are being pitted against each other in many ways; you get the inside scoop as to how they really rate.
You learn about the following topics in this chapter:
This entire book so far discusses the JavaBeans technology with respect to version 1.0, which is the initial offering from JavaSoft. Although JavaBeans 1.0 implements a wide range of functionality that addresses and solves many problems inherent in component software, there are still a few areas in which it needs improvement. JavaSoft is fully aware of JavaBeans' shortcomings and is already working on enhancements that will solve many of them. In this section you learn about some of these new enhancements, which will appear in a future release of JavaBeans.
Keep in mind that everything you read about in this section, and in this entire chapter for that matter, is preliminary and therefore subject to change. The main goal here is to give you an idea about where JavaBeans is headed so you can start gearing up for the changes.
The primary usage of JavaBeans components is as building blocks of large, complex applications. It has become standard for applications to include a menu as part of the main application interface. It is fully expected that developers will want some beans to somehow alter the menu for an application, either to hide existing functionality or, more likely, to add new functionality. This extra menu information would be provided by the bean and would integrate directly with the parent application based on the bean's activation. The 1.0 release of JavaBeans provides no support for menus at the bean level, but JavaSoft is working on APIs to provide this functionality in a future release.
The JavaBeans persistence support you learned in Chapter 7, "Persistence: Saving Beans for a Rainy Day," is directed toward providing an automated means of saving and restoring the internal state of a bean. More specifically, JavaBeans are currently automatically persistent based on their nontransient member variables. Even though this automatic approach to persistence is very nice for the vast majority of beans, there will certainly be situations in which bean developers will want fine control over how a bean is serialized at the binary level. This approach of using an external means of persistently storing and retrieving a bean is known as an externalization mechanism, or externalized persistence.
New Term: An externalization mechanism is a means of storing and retrieving an object through some type of custom, externally defined format.
JavaBeans 1.0 currently provides no direct facility for implementing externalized persistence. Recall that the automatic persistence functionality in JavaBeans 1.0 is really just the serialization support in Java 1.1. In other words, JavaBeans itself isn't responsible for implementing the automatic approach to persistence. However, support for externalized persistence will probably come in the form of a future JavaBeans release. Fortunately, the Java 1.1 serialization support is designed to enable an externalized approach, so the underlying mechanism is in place.
Many popular object-oriented programming class libraries are based on the concept of views. In these types of class libraries, one class represents the data for a conceptual object and another set of classes represents multiple views on that object. As a simple example, consider an object that models weather measurements made over a period of time. In a class library that supports multiple views, you could have different types of views on that object that graph the data in a variety of ways. In this way, a single conceptual object is modeled by a group of classes (a data class and multiple view classes).
In JavaBeans 1.0, beans map to classes on a one-to-one basis, which means that a bean is always represented by exactly one class. Of course, a bean can have an associated information class as well as a customizer class, but these are helper classes and don't directly affect the internal functionality of the bean itself. What I'm getting at is that JavaBeans 1.0 doesn't provide any support for multiple views on a bean. This is another area in which JavaSoft is working on enhancements for inclusion in a future release of JavaBeans.
Much has been said throughout the book about application builder tools and the importance of them in terms of visually laying out and editing JavaBeans components. Even though JavaBeans provides comprehensive support for enabling the visual manipulation of beans, it is ultimately up to development tool vendors to directly add features to their tools that enable the visual integration of beans. Tool vendors must be willing to adopt the JavaBeans application builder support to their tools for users to benefit.
Fortunately, several development tool vendors have already pledged support for JavaBeans and have promised to integrate the application builder support provided by JavaBeans into their tools. Although none of the tools themselves were ready as of this writing, many were nearing completion. In fact, it is quite possible that some of them are available now as you are reading this. Following is a list of the development tool vendors that are planning an integration of JavaBeans into their visual environment:
Some of the development tools listed here will be available for download by the time you read this, so be sure to stop by their respective Web sites if you are interested in trying them out.
Symantec's Visual Café is slated to include full support for visually building beans, applets, and applications from a library of standard and third-party beans without writing any code. Visual Café will present beans to the user in the form of a tool palette, much like the one used in the BDK's BeanBox test container. For more information on Visual Café, check out Symantec's Web site at www.symantec.com.
Borland plans for JBuilder to integrate much of its Latte Java technology, including full support for visually constructing beans, applets, and applications using standard and third-party beans. The open and extensible development environment provided by JBuilder aims to give you complete flexibility in incorporating third-party beans and wizards. JBuilder is interesting in that several of its major subsystems are implemented as beans, meaning that the tool itself is designed around the JavaBeans technology. For more information about JBuilder, drop by Borland's Web site at www.borland.com.
Penumbra Software's Mojo takes a little different approach than some Java development tools by providing two interfaces to the development process: a high-level visual interface and a lower-level coding interface. Mojo 3.0 will include complete support for JavaBeans, which means that you will be able to create and use JavaBeans components in the context of either of its two interfaces. For more information on Mojo, stop by Penumbra Software's Web site at www.PenumbraSoftware.com.
SunSoft's Java Workshop is an interesting development tool because it is written entirely in Java. The result is a Web-centric tool that provides extensive Java support based on its being implemented in Java. A new release of Java Workshop will provide a host of new features, including full support for JavaBeans component development and use. In addition, Java Workshop will ship for the Solaris, Windows, and Macintosh platforms, which is a pretty big accomplishment for a development tool. For more information about Java Workshop, check out SunSoft's Web site at www.sun.com.
Beyond Java Workshop, SunSoft has another development tool that will fully support the JavaBeans technology: Project Studio, a visual application construction tool similar to an HTML authoring tool in that it is geared toward the completely graphical creation of Web content. Project Studio will ship with a rich set of reusable JavaBeans components that can be easily integrated with HTML content to enable a high-level development solution for the Web. Project Studio is geared toward Web developers who want to benefit from Java and JavaBeans without writing any code. To get the latest news on Project Studio, stop by SunSoft's Web site at www.sun.com.
Surprise--IBM is now in the Java development tool business. That's right, IBM's Applet Author, which is itself written entirely in Java, will give Web developers a visual development environment that boasts full support for JavaBeans. Applet Author is geared toward the visual construction of applets using JavaBeans components. For more information about Applet Author, take a peek at IBM's Web site at www.ibm.com.
If Applet Author doesn't quite suit your needs, IBM is also working on a new version of its Visual Age development tool that will integrate complete support for JavaBeans. Visual Age is geared more toward client/server enterprise development, an area of software development in which JavaBeans will eventually have a significant impact. Visual Age is scheduled to ship after Applet Author; for more information, visit IBM's Web site at www.ibm.com.
NOTE: You might be wondering where Microsoft stands in regard to JavaBeans, especially because it is the largest development tool vendor of them all. Because JavaBeans is a clear competitor of Microsoft's ActiveX component technology, Microsoft has been careful not to pledge any specific support for JavaBeans. Even so, I think the popularity of JavaBeans will be enough to persuade Microsoft to eventually support it in a future release of Visual J++, and potentially even Visual C++. Microsoft wants to protect ActiveX, but not at the risk of producing substandard development tools.
One of the key concerns of the JavaBeans architects was how it relates to and integrates with existing component technologies. Although the JavaBeans technology is powerful in its own right, it is foolish to think it will replace existing technologies overnight, if ever. For this reason, JavaSoft specifically designed JavaBeans with the integration of other component models in mind. JavaSoft is currently in the process of working with industry partners to develop bridges that enable JavaBeans components to work seamlessly with other component architectures.
Following are the major component technologies JavaSoft is targeting with its initial JavaBeans bridge:
ActiveX and its related technologies are quickly headed toward becoming a wide standard not just for the Windows world, but for computing in general. Microsoft has too much at stake and has a technology with too much clout to lose with ActiveX. For this reason, it is of utmost importance to JavaSoft that JavaBeans be interoperable with ActiveX. A bridge is in the works that will enable beans to act as first-class ActiveX components, which basically opens the door to using beans just as you would ActiveX components.
It's important to understand that part of the integration of JavaBeans with ActiveX is necessary to fulfill the requirement that JavaBeans reside as closely as possible to native APIs. JavaBeans is fully expected to rely on some native support in its implementation for each different platform. On platforms on which ActiveX is the dominant object model, JavaBeans will naturally rely on ActiveX to some degree under the hood. Beyond that, the ActiveX bridge will enable beans to be used as ActiveX components.
Another important component technology is OpenDoc, which is an open, multiplatform architecture for component software heavily backed by Apple and IBM. JavaSoft is currently working with Apple, IBM, and Component Integration Laboratories to solidify the integration of JavaBeans with OpenDoc. With the OpenDoc bridge that is under development, beans will be able to be integrated as OpenDoc components inside OpenDoc containers such as CyberDog, Apple's integrated software suite that provides easy and intuitive access to Internet resources.
JavaSoft is also working with Netscape to ensure that JavaBeans components will integrate with Netscape Navigator and the LiveConnect technology for interconnecting executable content. LiveConnect enables Web developers to use Java applets, JavaScript scripts, and Navigator plug-ins together. The successful integration of JavaBeans into this mix is an important one for JavaSoft.
The last component model that is of great importance for JavaBeans to integrate with is CORBA (Common Object Request Broker Architecture), which is the industry standard for representing distributed objects. JavaSoft is working with SunSoft and other industry partners to provide full support for CORBA integration with JavaBeans.
Even though JavaBeans will ultimately integrate peacefully with ActiveX as a component technology, don't be misled into thinking that JavaBeans and ActiveX have a truly peaceful relationship. It's true that concerns over ActiveX competing with Java were misplaced when ActiveX first hit the street, but this was because Java itself had no provision for components in any real sense. JavaBeans, on the other hand, is nothing but components. JavaBeans is JavaSoft's Java-enhanced answer to ActiveX, and as such it will be viewed in the software component market as a direct competitor of ActiveX. And make no bones about it, the mud is already slinging in terms of Microsoft and JavaSoft promoting their respective technologies.
Even though JavaBeans and ActiveX are competitors and ultimately aim to solve the same problem, they are very different technologies. ActiveX is a language-independent component technology based on Microsoft's popular OCX technology. ActiveX in its current implementation is entirely dependent on the Windows platform, which is a critical weakness, especially in regard to the Internet. Microsoft is busily working on versions of ActiveX for both UNIX and Macintosh, but it isn't clear when they will ship.
JavaBeans, on the other hand, is a component technology that is language-dependent
in its current implementation. However, JavaBeans is platform-independent in that
it will run on any platform that supports Java. The
platform independence of JavaBeans makes it an ideal candidate for the Web because
it is dangerous to handcuff Web content to a particular platform. The language dependency
of Java might sound like a negative at first, but it really isn't simply because
Java is becoming widely accepted as a powerful and useful programming language in
its own right. There are no signs of Java losing ground as a programming language,
which means that being forced to use it to create JavaBeans components isn't too
much of a restriction. Even so, the bytecode nature of Java executables opens the
door for supporting JavaBeans development in other programming languages in the future.
From the discussion thus far, it's clear that JavaBeans has a significant edge over ActiveX because it is cross-platform. This isn't to say that Microsoft can't release a cross-platform version of ActiveX in the near future, but the clock is ticking in a sense that JavaBeans will be gaining Internet market share until that day arrives. So, JavaBeans is the clear winner over ActiveX, right? Not quite.
The area in which Java and JavaBeans are both weak is the one area in which ActiveX shines: existing code base. ActiveX has a significant advantage over JavaBeans in this regard because its underlying OCX technology is widely used in the Windows software community. Granted, Windows is only one platform, but it is by far the dominant platform and one that drives the software market. So, JavaBeans is in for a fight when it comes to competing with the millions of lines of code out there that are heavily based on ActiveX-derived technologies.
Where this issue will come into play heavily is corporate intranets, which rely a great deal on existing ActiveX technologies such as Microsoft Office applications. It will be a tough pill to swallow for intranet builders to throw out all their existing code and switch to JavaBeans. The integration possibilities of JavaBeans and ActiveX muddy the water a little at this point, however, because who's to say you couldn't keep your ActiveX code base and still integrate new code that is based on JavaBeans?
To sum things up, the answer as to which technology is better or which technology will beat the other is a clear "I don't know." On one hand, Java has a clear advantage because it has a cross-platform design and is an ideal technology for the Internet. On the other, however, the sheer depth of the ActiveX code base makes it an ideal candidate in situations in which it just isn't feasible to develop everything new, such as corporate intranets. Based on these conflicting positives for each technology, it simply isn't clear which technology will emerge as the dominant one.
The fact that JavaBeans and ActiveX have their own unique advantages can be seen as a positive in some ways. Consider the likely outcome of neither technology dominating the other. If they are able to coexist with each other and integrate together, who cares which one wins? If you can leverage the use of each technology in situations that warrant their unique advantages, we all might be better off if both technologies succeed.
This chapter peers into the crystal ball and paints you a picture of the future of JavaBeans. Although the topics covered in this chapter vary considerably, they all somehow tie into the future of JavaBeans and what it means to JavaBeans developers and users. You started the chapter by learning about some of JavaSoft's planned enhancements to JavaBeans, which will appear in a future release. You then learned about some application builder tools that are adding support for the visual layout and editing of beans. From there, you shifted gears a little and looked at how JavaBeans is being integrated with other popular component models, which is critical to JavaBeans' success. Finally, you finished the chapter by learning about the differences between JavaBeans and ActiveX and where they fit into the future of component software.
This chapter marks the end of your foray into learning the JavaBeans technology. It should give you a few things to think about as you move on to use JavaBeans in your own development projects. Keeping tabs on the future of JavaBeans is a critical part of using the technology with success. I encourage you to check JavaSoft's Web site occasionally at www.javasoft.com to find out the latest information on JavaBeans. Good luck in your JavaBeans endeavors!
