Welcome!
Index
Next
| Writing ActiveX Controls in Java: Ultimate Interoperability |
Welcome! |
Index |
Next |
In March of 1996, Microsoft announced Component Object Model (COM) support for the Java language. This support allowed developers to use and expose COM interfaces from Java classes, applets, and applications. While that support added a level of truly cross-language and cross-application interoperability to Java, it still proved difficult to write full-featured Microsoft® ActiveX™ controls in Java, which could be used in a variety of applications. Microsoft will now provide a very simple framework for Java developers to expose applets and components as ActiveX controls; these applets and components can then benefit from all the features of ActiveX technology.
Fortunately, while designing the property, method, and event exposure models for Beans, Sun used almost exactly the same architecture as the ActiveX automation model. This, effectively, allows Microsoft to focus on the details of exposing the richness of the ActiveX interoperability architecture to Java.
This document explains how ActiveX automation features are implemented in Java. It assumes a basic knowledge of both Java Beans eventing and the ActiveX COM. The following specific topics are addressed:
This includes:
By exposing Java methods to automation, a developer can use script languages such as JavaScript or VBScript to automate Java objects. For example, a Java multimedia display could be scripted to load, play, and configure various presentations.
Events and properties allow Java objects to initiate actions and provide parameters for those actions to other objects or containers. For example, a Java process control object could fire events or property change notifications to all ActiveX objects interested in those notifications.
The Microsoft framework makes communicating with ActiveX objects simple through other interfaces such as IObjectWithSite, IPersistPropertyBag (useful for getting parameters from non-browser containers), IServiceProvider, or any other interfaces.
To understand this framework, it helps to understand the COM concept of object identity. In COM, an object can expose any number of interfaces that all implement one, root interface known as IUnknown. To access interfaces of an object, use QueryInterface, which is one of the methods of IUnknown. For interfaces to be considered implemented by the same COM object, all interfaces, when queried for IUnknown, must return exactly the same interface.
A COM object is considered to have a fixed set of interfaces, which are determined when that object is instantiated. If an object reports that it does not implement a particular interface, it cannot later report that it does. This implementation requires that a Java applet be part of the ActiveX framework's identity to implement its own additional interfaces.
The ActiveX framework is provided as part of the Microsoft Win32 VM for Java. This means that any Java applet or component (control) can be exposed as a full-fledged ActiveX control with a minimum of additional work from the Java developer. If a developer wants to expose methods for automation, they can be written as standard applets. With Microsoft's ActiveX control framework, any Java class just needs to be registered in the system registry to be instantiatable by Microsoft® Visual Basic® or other ActiveX control containers. Newer containers can instantiate Java controls without registration. In addition, Java Beans compatible information or design patterns are used, where possible, to expose methods, events, and properties that can be accessed by other ActiveX objects or script languages.
To support extended functionality or compatibility with containers, Java developers can implement COM interfaces on their controls by implementing those interfaces on the root class of their applet or control. These implemented interfaces will automatically be exposed to containers or other COM objects that use the COM method QueryInterface to check for the existence of those interfaces. By implementing IPersistPropertyBag, a Java developer can retrieve parameters from containers such as Visual Basic or Forms3.
The Microsoft VM for Java uses Java Beans introspection to enumerate the methods and properties that are exposed through IDispatch (by default). Unless a Bean provides its own BeanInfo, all public methods are exposed, as well as properties discovered using standard design patterns (such as setText and getText). For better control of which methods and fields are exposed and how method parameters are marshaled, a developer can add attributes to the class file using a tool like Microsoft® Visual J++™ or the Microsoft SDK for Java. For more detailed information about the specific attributes, see the "COM Attribute Specification" in the SDK for Java.
ActiveX controls have the concept of a default, outgoing event set in addition to exposing event interfaces. A control developer defines this default event set, but it is often the only event source connected to by ActiveX containers. To provide the greatest flexibility to Java developers, the ActiveX control framework allows use of design patterns to define this default event interface.
Since the Beans eventing model is sufficient for many eventing needs and, especially with last minute revisions by Sun, maps well to the ActiveX, IConnectionPointContainer model, we recommend that events be exposed using the Beans eventing specification.
When an ActiveX component attempts to connect to the default event interface of an ActiveX control for Java, the Microsoft VM will introspect that control and look for event listener interfaces that are marked as inDefaultEventSet. Unless a Bean provides its own BeanInfo, all outgoing events are in the default event set. This combination of interfaces provides the easiest possible interoperability with existing ActiveX controls and containers.
Mapping Java events to COM events is done through machinery in the Microsoft VM that shields a Java developer from the C++ model of ActiveX eventing. The entire mapping to an outgoing IDispatch compatible event set is managed by the VM. This means that while C++ ActiveX developers see the Java control as exposing an IDispatch default event source through IConnectionPointContainer, Java developers know that they are adding a listener to their event source.
The following diagram illustrates the mapping of a Java event source to an IDispatch event source.
For example, a developer could define the following interfaces in Java to define its outgoing default event set.
interface mouseListener
{
public void mouseEvent( int ButtonState,
int x,
int y );
}
interface buttonListener
{
public void clickEvent( Object ButtonSource );
}
interface keyListener
{
public void keyEvent( int shiftState,
int key );
}
These interfaces define events that could be sourced from three different Bean event connections in a Java control. The Microsoft VM will combine them into one interface that is exposed through ActiveX. Be aware that the methods in the interface freely define parameters, which are not event objects. The Beans specification states that this free-form method specification is fully supported but not necessary. Microsoft encourages its use because it can improve performance in passing events in and out of Java, as well as improve the remote ability of events.
To attach an outgoing event sink to the Java control, the Microsoft VM will call the addListener methods of the outgoing event sources and pass the instance of an object, which implements the appropriate interface.
That's all of the Java development required to expose events to ActiveX! For compatibility with Visual Basic and other containers that require registered components for design time support, Microsoft provides a utility that properly registers ActiveX controls for Java. Newer containers, such as Microsoft® Internet Explorer version 4 do not require control registration.
Properties allow control developers to expose state variables that can be queried, set, and monitored by other controls or control containers. Again, the Java Beans model provides a one-for-one mapping with ActiveX property concepts and change notifications. The Microsoft VM exposes ActiveX properties based on design patterns and BeanInfo information as detailed in the Java Beans specification.
To source out property change events (equivalent to ActiveX OnChanged) and vetoable property change events (equivalent to OnRequestEdit events), all that a developer needs to do is support add/removePropertyChangeListener and/or add/removeVetoableChangeListener methods, which accept the propertyChangeListener and vetoableChangeListener interfaces as parameters. The Microsoft VM will automatically connect to these property change event sources and handle them appropriately. To ActiveX clients of the object, these events will map to IPropertySinkNotify and IPropertySinkNotify::OnRequestEdit.
Property change notifications will be available in the second beta of the Microsoft SDK for Java, version 2.0.
The persistent state of a ActiveX control for Java will be serialized through an ActiveX IStream interface or, alternatively, IPropertyBag in some containers. This maps to Java streams used in serialization and the setting and getting of the exposed properties. If an ActiveX control in Java can persist itself both through the serialization interface and having its properties set, it will operate in more containers than if it only supports one method of persistence.
Persistence will be available in the second beta of the Microsoft SDK for Java, version 2.0.
Implementing COM interfaces in Java that extend the ActiveX control framework might be required by developers. For example, ActiveX Accessibility is implemented through an interface on Component that is exposed by the COM support in the Microsoft VM.
A Java control might want to natively implement interfaces like IOleCommandTarget to access advanced control features and container information. Microsoft will continue to expose control functionality to Java controls in a Java-oriented manner. The ability to implement your own first-class interfaces, however, can prove invaluable for adapting controls to different hosts, and adding new, unanticipated feature support.
Microsoft's ActiveX control framework for Java is the first component model that provides security support for individual components. This means that ActiveX controls written in Java can have a persistent security state associated with them. Even when an ActiveX control written in Java runs in a trusted application, the Microsoft security framework will maintain a "sandbox" around the control. This prevents the control from accessing any resources beyond its allowed capabilities. For example, if Beans are downloaded and used locally in trusted appliucations, they do not have access to any system resources.
Full support for this level of component security will be in the second beta of the Microsoft SDK for Java, version 2.0.
© 1997 Microsoft Corporation. All rights reserved. Legal Notices.