1 .  HTML browser that support HTML version 3.2 which is the most commonly used version.
  2 .  Browsing images in the form of GIF & JPEG files.
  3 .  Supporting HTTP ( HyperText Transfer Protocol ) version 1.1 .
  4 .  Internationalization/ unicode 2.0 support.
   ( Unicode defines fully international character set that can represent all of the characters found
     in    all human languages. It is a unification of dozens of character sets as : Greek, Arabic,
     Latin, … ).
  5 .  Supporting tables and frames.
  6 .  Java applets support.
  7 .  Profile for each user to save favorite sites and locations.
  8 . History of  each user to store files and images downloaded before to
     save much time when needing them once more.
 
 

To explain the JavaBeans conceptual foundations of software components, which form the basis of the JavaBeans technology. Through its specific approach at providing a software component technology, JavaBeans enables software developers to design and create reusable pieces of software that easily integrate with each other, with applications, and even with development tools.

The best place to begin when uncovering the magic behind software components is to look at the reason why they were invented to begin with; in other words, what problems are software components trying to solve?

The most simple and direct answer to this question is software reuse, which is the challenge of leveraging as much previous work as possible in each new development project. Even though a variety of different software component approaches have evolved, until recently none have come far enough in offering a means to create fully reusable software.
 
The Need for Software Components
Change is embraced in the innovative world of software development probably more than in any other professional endeavor. Software enters a final commercial state for only a brief period of time, after which the next batch of enhancements and improvements is immediately planned and begun. For this reason, no other industry can more proudly boast of its products being "new and improved" than the software industry.
However, all of this innovation comes at a price; that price is the stress of trying to work miracles in short periods of time. Software developers are always under extreme pressure to work faster and deliver better results. No doubt this pressure is present in plenty of other professions, but the software development community prides itself on its ability to meet seemingly unattainable deadlines.

In their quest to deliver feature-packed applications in a short period of time, software developers often are forced to cut corners in the midst of turning out applications. These cut corners typically result in code that is highly dependent on the specific application, with little usefulness beyond that particular project. Although this is acceptable in most cases, the end result is that the efforts put into a finished project offer little to aid in the development of future projects. In other words, it's back to the drawing board, or keyboard, for each new project.
Wouldn't it be nice if you could somehow reuse similar features developed for one application in another application requiring the same functionality?
Of course it would, but I'm getting ahead a little.

Regardless of how careful developers are about not cutting corners throughout a project's development, the mere size of a project often can lead to a great deal of problems. The most careful and thought-out design can lead to utter confusion when a project grows beyond a certain manageable size. In this situation, it becomes extremely difficult to make sense of a bloated application that has reached an unmanageable state of confusion and complexity. More than a few software development teams have thrown up their hands and started anew on projects after realizing that they were heading down a winding path of complexity with an obfuscated code base. Even if the code is well written, there simply are limits to the degree in which organization can help in making sense of things at the code level.
 

None of the OOP  languages has truly answered the need for a fully reusable software standard. As nice as C++ classes are, they still are inherently limited by the address space in which they execute, the specific protocol within which they communicate, and the platform for which they are compiled. In other words, programmers can reuse C++ classes only within the specific context of the applications they are developing, which is sometimes useful but nonetheless limiting. The same thing applies to Java classes, which are functionally similar to C++ classes, although they do add the benefit of being cross-platform in most situations.

The problem is that object-oriented programming languages enforce an object paradigm only within the bounds of a particular programming model such as C++ or Java. Although this certainly enables you to reuse code easier when you are working within the same programming language on a specific target platform, it doesn't offer much for the wider view of software where there are many different programming languages and platforms. The problem is that the object-oriented idea hasn't been fully realized beyond the code level, which is a shame.

Software Component Beginnings
The software development community has been exploring the idea of reusable software for a while. The idea as applied to software is to build small, reusable components once and then reuse them as much as possible, thereby streamlining the entire development process.

Although component software certainly has its merits, fully reusable software has yet to really establish itself, for a variety of reasons. Not the least of which is the fact that the software industry is still very young compared to the industries carved out in the industrial revolution. It only stands to reason that it would take time to iron out the kinks in the whole software production process. If you're like me, you'll embrace the rapid changes taking place in the software world and relish the fact that you are a part of a revolution of sorts--an information revolution.

Perhaps the hardest thing component software has had to face is the wide range of disparate microprocessors and operating systems in use today. There have been a variety of reasonable attempts at component software, but they've always been limited to a specific operating system. Microsoft's VBX and OCX component architectures have had great success in the PC world, but they've done little to bridge the gap between other types of operating systems. Weighing in the amount of work required to get an inherently platform-dependent component technology running on a wide range of operating systems, it only makes sense that Microsoft has focused solely on the PC market.

Before the explosion of the Internet, the platform-dependency issue wasn't all that big a deal. PC developers didn't necessarily care too much that their products wouldn't run on a Solaris system. Some PC developers hedged their bets and ported their applications to the Macintosh platform, but most with considerably lengthy and resource-intensive development efforts. The whole scenario changed with the operating system melting pot created by the Internet. The result was a renewed interest in developing software that everyone could use, regardless of which operating system they happened to be running. Java has been a major factor in making truly platform-independent software development a reality. However, until recently Java has not provided an answer to the issue of component software--you'll get to that in just a moment, and in fact throughout the rest of the book.

As if the platform dependency issue weren't enough, some existing component technologies also suffer because they must be developed using a particular programming language or within a particular development environment. Just as platform dependency cripples components at runtime, limiting component development to a particular programming language or development environment equally cripples components at the development end. Software developers want to be able to decide for themselves which language is the most appropriate for a particular task. Likewise, developers want to be able to select the development environment that best fits their needs, instead of being forced to use one based on the constraints of a component technology.
Therefore, any realistic long-term component technology must deal with both the issue of platform dependency and language dependency. This brings you to JavaBeans: JavaSoft's JavaBeans technology is a component technology that answers both of these problems directly. JavaBeans is implemented as an architecture-independent and platform-independent application programming interface (API) for creating and using dynamic Java software components.
JavaBeans picks up where other component technologies have left off, using the portable Java platform as the basis for providing a complete component software solution that is readily applicable to the online world.

Visual Software Components
Visual components are software components that have a visual representation that requires physical space on the display surface of a parent application. Parent applications are sometimes more generally referred to as containers.

Possibly the most simple example of a visual component is a button, which is a graphical element completely distinguishable from the application within which it is contained. Many visual design tools, or application builder tools, provide support for graphically manipulating buttons, which is proof of the fact that buttons are separate entities that can be arranged and interacted with independently of any parent application. In this way, a button functions as a discrete self-contained unit, which just happens to be one of the key traits of a software component. Even though buttons are discrete units, the real power they provide is the capability to easily integrate into applications. Using an application builder tool, a button is as easy to add as clicking and dragging the mouse.

Many other types of visual components are supported in visual development environments such as Visual J++. These components include checkboxes, list boxes, and text edit boxes, to name a few. Keep in mind that the visual components used in Visual J++ are limited in that they actually are based on standard Java classes. One exception to this is the use of ActiveX controls, which provide some of the advanced capabilities required of true software components. Of course, JavaBeans components are an exception as well.

Non-Visual Software Components
If visual components sound like the ideal use for software component technologies, understand that there are also situations in which non-visual components can be very useful. A very popular Visual Basic control is the Timer control, which is completely invisible at runtime. The Visual Basic Timer control can be set to trigger an event at periodic intervals, such as once every second. The Timer control is very useful in creating timing loops such as those that control animations. Because the Timer control is used entirely at the programming level, there is no meaningful reason to provide a graphical view of the component at runtime. The nice thing about the Timer control is that an application using the control doesn't have to be concerned at all about how the control is implemented internally; the application lets the control take care of its own business. That's the beauty of software components!

Another good example of a non-visual software component is a hypothetical spell checker component that processes text and finds misspelled words. Because this spell checker is a self-contained component, it can easily be integrated into any application that might benefit from spell checking functionality. For example, the same spell checker component could be used in both a word processor and an e-mail application. This saves the developers of each application the trouble of designing and implementing their own spell checker from scratch. Instead, they are free to purchase the spell checker component from a third-party component vendor. Or, if they so choose, they can develop their own spell checker component and reuse it however they want. The point is that the spell checker functionality is isolated into a self-contained unit, a component, that can be plugged into an application with minimal effort.

Software Building Blocks
The bottom line to this discussion is that components, both visual and non-visual, are the equivalent of software building blocks. Using components, you can build applications one discrete, functional piece at a time. To get a better grasp of why this is such a significant leap in the evolution of software design, consider some real-world building blocks. If you wanted to take up masonry as a side profession, you would first buy bricks, mortar, and a trowel.

Component Models
At the heart of every software component technology is a component model, which defines the architecture of components and how they are manipulated and interacted with externally. The architecture defined by a component model is responsible primarily for determining how components are able to interact in a dynamic environment. Understanding component models and their related architecture is critical in seeing the big picture surrounding software components and how they work.

All software component models define two fundamental elements: components and containers. The component part of a component model lays the foundation for how different components are created and used. In other words, the component model provides the template from which practical components are created. The container part of the component model equation defines a method of combining components together into useful structures. Containers provide the context for components to be arranged and interacted with one another. For example, an application using a group of components acts as a container for the components.

Containers also are sometimes referred to as forms, pages, frames, or shells, and can serve as the basis for applications. Just to confuse things a little more, containers also can be components themselves. Even though this might sound strange at first, this capability is important because it enables components to be nested within each other, resulting in complex visual interfaces.

Besides defining the structure of components and containers, a component model also is responsible for providing a variety of services. More specifically, a full-featured component model is responsible for supporting the following six major services:

• Introspection
• Event handling
• Persistence
• Layout
• Application builder support
• Distributed computing support
 

Introspection
Introspection is the mechanism that exposes to the outside world the functionality of components. Through introspection, an application can query a component to find out its capabilities and then interact with the component accordingly. Introspection is one of the most critical aspects of a component model because it is responsible for dictating how a component appears to
applications and other components. For a component to be both self-contained and useable from the outside, it must fully support introspection.

Persistence
  Persistence is the means by which a component is stored to and retrieved from a non-volatile location, such as a hard disk. The information about a component that is actually stored and retrieved is the internal state of the component, along with its relation to a container or other components. Using this information, a component can be safely stored away and re-created at a later time. Persistence is a particularly important issue in design tools, which enable developers to modify component properties to suit a particular application.

Typically, the spatial requirements for a component consist primarily of giving the component a rectangular area in which it can render itself visually. A parent application enables the component to render itself within this area however it chooses. Likewise, the parent application provides a facility by which the component's rectangular surface can be managed in the context of a container that houses other components. This facility is typically used by application builder tools, where a developer lays out components while constructing an application.
 
Application Builder Support
Support for application builder tools happens to be a major requirement for component models. This support gives users the ability to graphically build complex applications out of components. The specific support required at the component model level is the capability for components to expose their properties and behaviors to application builder tools such as Visual J++. Development tools use these properties and behaviors to enable users to integrate and customize components in the context of a meaningful application.
Most application builder tools enable the user to not only lay out and edit individual components, but also to specify how the components relate to each other, both visually and programmatically. The layout support provided by a component model aids in laying out components visually, the introspection support helps application builder tools determine the capabilities of a component, and persistence enables the user to save components that have been customized. Specific application builder tool support often consists of dialog boxes that enable the user to graphically edit a component's properties.

Distributed Computing Support
The last major part of a component model is support for distributed computing, which has become important recently with the increased popularity of the Internet. It is now becoming not only realistic, but at times imperative, to build applications that are capable of executing in a distributed environment connected across vast networks. Consequently, it is important for component models to address the challenges inherent in building applications engaging in distributed computing.
Not surprisingly, distributed computing brings on a wide range of problems that aren't present in a single-system environment. Distributed systems are subject to both transmission errors and failure, along with limitations on communication speeds. The capability to handle these problems and limitations comes at no small cost; it requires significant overhead to deal with the problems brought on by distributed computing. The overhead is so significant, in fact, that adding it to an object model must be heavily weighed against the added complexity. Directly adding extensive support for distributed computing simply doesn't make sense when a developer is trying to make component models as lightweight and simple as possible.
 

There is also a normal Java class behind the bean that implements the methods. This class could also be used in Java applications. The danger with this is upward compatibility. If in the future browser functionality is provided as a collection of beans, rather than one, then the panel class becomes obsolete. Compatibility with the monolithic bean component will be maintained via bean aggregation, but the panel class, if used in Java applications, will have no such guarantee.

To support the possible future development directions, the intent is to keep this API as minimal as possible, while providing a full featured product. This is a difficult balance between making it easier to use, and providing an API that won't need to be broken in the future.

Security
There are two types of security concerns with the HTML component: The security manager, which determines what it can do, and dealing with secure connections.

An HTML component presents a difficult situation. The Bean specification says that security management is the responsibility of the bean container. Beans that are to be used everywhere need to be able to run under a security manager, while beans that are application specific may not need to. The HTML component is unique in that it is a bean that can have other beans or Java applets within it that can come from unknown sources, i.e. the web. If the HTML component were to just let its container worry about security, as recommended by the Bean specification, you could easily get into a situation where you are browsing the web and running applets totally unprotected.
To protect against this, when the bean is instantiated, if it doesn't detect a security manager it will install one. The installed security manager will only affect applets within the bean. This still allows applets to take advantage of a lenient container-supplied security manager, but it does provide good default security behavior. We also provide an option for the case where an application needs to have its own security manager in addition to the HTML Component's security manager. The application can have both managers running simultaneously by instantiating the DelegatingSecurityManager. The only drawback to this method is that the DelegatingSecurityManager assumes that the HTML Component Jar file is on the CLASSPATH.

To deal with secure connections, we need to handle authentication. Dealing with authentication means supplying a user interface, something we are trying to avoid in the bean. As a compromise, we are breaking the monolithic model, and supplying the HotJava Authenticator Bean. This release defines the interface used by this bean, and provides a default implementation. Developers may use this version or override its behavior. If the authenticator bean is not wired into the container, the HTML component will work fine, but it will not be able to connect to secure sites.

Providing a Pop-Up Menu
The right mouse pop-up menu is not implemented in the HTML component itself. If the client wishes to provide this functionality, they can listen for a right mouse button down event, display their own menu, and use the menu select information with the IndicatedElement property to perform any requested function.

Document History and Navigation
Also note that this bean doesn't directly support a history list or forward/back behavior. That functionality may be provided by the client, or by using the HotJava Document Stack.

Introspection
A BeanInfo class, HotJavaBrowserBeanBeanInfo, explicitly provides information for properties, events, and methods.

Customization
Rather than providing a BeanCustomizer class, the relevant state of the HTML component may be accessed through the use of the HotJava System State bean.

This is about as simple as a bean interface can get. Although is has a few properties, most are read-only and none are bound or constrained. Therefore, the component fires no events.

Introspection
No BeanInfo class is provided. Introspection relies on low-level reflection to identify the properties and events of the Authenticator bean. All public methods are exposed by default.

Example Use
In the beanbox or another JavaBeans-enabled builder application, simply instantiate a HotJava HTML component and Authenticator bean in the same container.

Overview
The document stack is an invisible bean intended for use with the HotJava HTML Component. It provides the record necessary for the "forward" and "back" navigation familiar to Web browsers.

The document stack bean is simply a collection of the "documents" visited by the user. It can process a number of history commands to push a document on the stack or clear the history. Methods are provided to go to the previous and next documents, and to indicate the existence of next and previous to allow enabling and disabling controls as appropriate.
 
Introspection
A BeanInfo class, HotjavaDocumentStackBeanInfo, explicitly provides information for properties, events, and methods.

Example Use
Instantiate a HotjavaDocumentStack, HotJava HTML Component, and two buttons. Label one button "Forward" and bind its buttonPushed event to the nextDocument() method of the document stack. Label the other "Back" and set it to activate previousDocument(). Connect the executeHistoryCommand event for HTML component to the corresponding method of the document stack. Do the same in reverse from the executeHistoryCommand event of the document stack to the method of the HTML component.

Overview
The HotJava System State bean is an invisible JavaBeans component intended for use with the HotJava HTML Component.

The browser maintains a fair amount of "system state." This state represents things like system properties (like the HTTP proxy settings), the URL pool, the Cookie jar, etc. There should be at most one HotJava System State bean for the entire VM. This bean simply exposes this state, which is stored elsewhere. If this bean is not included, reasonable defaults will be supplied, but state cannot be accessed. If more than one is instantiated, the last to write a value will take precedence in each case.

Security
Please note that it is extremely important to set the package.restrict.access and package.restrict.definition properties.

Color
The HotJava Browser supports the sixteen color names listed below from the HTML 3.2 standard (listed on p. 514 of HTML The Definitive Guide, 2nd edition) and not the extended list. Of course, explicit hex values may also be used.
 

black	maroon	green	navy
silver	red	lime	blue
gray	purple	olive	teal
white	fuschia	yellow	aqua

 

 Introspection
A BeanInfo class, HotJavaSystemStateBeanInfo, explicitly provides information for properties, events, and methods.

Reference :
  1 .  Presenting Java Beans  at  http://www.mcp.com
  2 .  Hot Java Component documentation.
  3 .  Java Beans Tutorials at  http://www.javasoft.com