Dynamic mapping of component interfaces

Details Dynamic mapping of component interfaces Dynamic mapping of component interfaces

1998-07-15

2002-08-20

Chaki, Kakali (Department: 2122)

Data processing: software development, installation, and managem

Software program development tool

Translation of code

C717S106000, C717S107000, C717S108000, C717S116000, C717S117000, C717S118000, C717S162000, C717S163000, C717S164000, C717S165000

Reexamination Certificate

active

06438744

ABSTRACT:

FIELD OF THE INVENTION
This invention relates generally to software component interfaces, and more specifically to dynamic mapping of such interfaces.
BACKGROUND OF THE INVENTION
The evolution of computer software development has included the introduction of new development techniques and methods. These techniques and methods have included new programming languages, new libraries, new development methodologies, and new development environments. Often these techniques and methods are produced to improve software development productivity or to extend software development capability.
Software components are one technique to improve software development productivity and program flexibility. Reusable software components are designed to apply the power and benefit of reusable, interchangeable parts from other industries to the field of software development. Software components have standard interfaces making them interchangeable and reusable. Examples of software components tend to be oriented toward user interface elements. They can be simple like familiar push buttons, text fields list boxes, scrollbars and dialogs, or they can be more complex, such as calculators and spreadsheets.
Microsoft's ActiveX and the JavaBeans specification are two examples of software component models. ActiveX is a component environment commonly used by applications written in Microsoft's Visual Basic and Visual C++ programming languages. ActiveX can generally be defined as a specification for a software development methodology and an API that allows software components to be dynamically interchanged. ActiveX makes use of the Component Object Model (COM). Further details of COM are described in Dale Rogerson, “Inside COM,” 1997 (ISBN 1-57321-349-8) which is hereby incorporated by reference.
The JavaBeans specification for the Java programming language defines an environment for developing components known as “beans.” The JavaBeans specification defines a bean generally as a reusable software component that can be manipulated visually in a builder tool.
ActiveX components (also known as “controls”) and beans share the quality that when used within their intended environments, new or alternative components can be substituted for old components without requiring any changes to the application using the component. In addition, software components can be easily incorporated into new programs using software building tools, thereby freeing the developer from writing code to implement the functionality provided by the component.
Unfortunately, the interfaces provided by differing programming environments are not always compatible with one another. The reasons for the incompatibility vary, but common causes are incompatible function parameter passing protocols, incompatible data structure definitions and incompatibilities between programming language conventions between different languages or between different vendors' compilers for the same programming language. As a result, it is necessary to convert from one interface to another when incompatibilities are encountered. The process of converting the methods, properties and events of a source class, library or language to methods, properties and events of a differing target class, is generally known as mapping. A specific example where mapping is required because of an incompatibility exists when an application designed to use an ActiveX control desires to use a Java bean component.
There are three main reasons why ActiveX controls are incompatible with Java beans. First, the data structures representing ActiveX controls and beans, while containing similar information, are defined differently. These differences include the order of elements in the data structure and the naming convention used for the elements. In addition, elements appearing in one data structure may be missing in the other or may appear in combination with different elements.
Second, the data contained within the object data structure are populated at different times. All of the data required to define an object representing an ActiveX control can be determined at the time the source code is compiled or interpreted. However, in JavaBeans, the data required to define a bean interface object cannot be completely determined through the source code alone. The data that cannot be derived via the source code must be supplied at run-time when the source is interpreted by the Java Virtual Machine (VM). The information that must be supplied by the Java VM generally relates to data type identifiers for the methods, properties and events defined by the bean.
Third, the interfaces defined by the two component models are different. Interfaces are used to connect objects defined by the component model. ActiveX and the JavaBeans specification define their own interfaces to connect their respective objects together. While they perform similar functions, the two interfaces are different and operate on different objects, and are therefore incompatible.
Alternative attempts to allow an ActiveX client to interface with a Java bean have used a technique known as “static mapping” to map between ActiveX controls and Java beans. Static mapping involves invoking a packager application that gathers data based on user input. The packager application also reads the user specified Java source code and scans the source for bean definitions. When a bean is found, the packager application generates three types of files. The first file type is a Java class file that can be interpreted by the Java VM (Virtual Machine). The second file type is a registry file that must be imported into the registry of the computer running an ActiveX client. The third file type is a type library file that contains a COM compatible definition of the methods, properties and events defined by the bean. The files generated by the packager are populated with data gleaned from scanning the source, and include items such as the public methods, properties and events for the top-level class defined in the bean.
Static mapping has several disadvantages. First, the packager application can only generate mappings for those classes representing beans defined in the Java source code scanned by the application. It is common in object-oriented languages for a class to propagate its methods, properties and events to lower-level classes that inherit from the top-level class. The end result of static mapping is that only the top-level, or explicitly called out Java classes, have ActiveX compatible objects generated. Mappings can only be generated for top-level classes within the bean, mappings cannot be generated for lower-level classes. As a result, it is possible that a significant number of the methods, properties and events that define classes will be inaccessible to a ActiveX client application.
A second disadvantage to static mapping is that the mapping is incomplete. Static mapping methods scan the source code at a particular point in time, and then generate interface files based on the source code. In effect, static mapping produces a snapshot of a bean's state at a particular point in time. A developer may add methods, properties and events to the bean after the snapshot has been produced by the static mapping method. An ActiveX client using a statically mapped interface will be unable to use the newly defined methods, properties and events.
In addition, as discussed above, there is a significant amount of information about a bean that must be provided by the Java VM, and as a result the information is available only during the run-time of a Java program (i.e. while the Java program is executing on the computer). Since the static mapping method scans the files before the Java program is run, not all of the information that must be supplied at run-time is available to the packager application. As a result, a significant portion of the data describing the bean will not be available when the ActiveX client instantiates the bean, resulting in reduced bean functionality.
A third disadvantage is that static mapping requires addition

Affiliated with

Also associated with

Rating

Dynamic mapping of component interfaces does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Dynamic mapping of component interfaces, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Dynamic mapping of component interfaces will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2914280