Interfacing a service component to a native API

Details Interfacing a service component to a native API Interfacing a service component to a native API

2000-05-31

2004-02-10

Ingberg, Todd (Department: 2124)

Data processing: software development, installation, and managem

Software program development tool

Programming language

C717S136000, C717S148000

Reexamination Certificate

active

06691302

ABSTRACT:

TECHNICAL FIELD
This invention relates to systems and methods for interfacing a service component to a native operating system application program interface (API).
BACKGROUND
A computer system typically includes an operating system that provides an environment in which one or more application programs may run. The operating system generally controls the operation of the computer system and the allocation of system resources. The operating system also exposes system services to the application programs, which, in turn, use these services to perform one or more computing tasks. In the Windows NT Server operating system, for example, a Win32 subsystem makes a 32-bit application programming interface (API) available to application programs. Typical operating system services include memory services, process creation services, and processing scheduling services.
Operating systems, such as the Windows NT Server operating system, make extensive use of dynamic link libraries. A dynamic link library (DLL) is a computer code module that contains functions to be linked with application code. A DLL may be loaded and linked to an application at run time, and may be unloaded when its functionality is no longer needed. A DLL usually consists of a set of autonomous functions that any application may use. In 32-bit Windows operating systems, such as Windows NT, Windows 95 and Windows CE, all of the functions in the Win32 API are contained in DLLs. Further details about the Win32 API may be found in “Advanced windows,” Third Edition, Jeffrey Richter, Microsoft Press (1997), which is incorporated herein by reference.
In the 32-bit Windows environment, for an application (or another DLL) to call the system service functions of the Win32 API, the application must conform to a standard C-based interface. Accordingly, most service components operating in a 32-bit Windows environment are written in the C or C++ programming languages. In order to invoke the functionality of service components written in other programming languages, each component must provide its own customized operating environment in which the component may operate. For example, programs written in the JAVA programming language must operate in an environment provided by a JAVA virtual machine (JVM). The JVM is an abstract native computing machine that runs within an operating system to interpret and execute JAVA applications. Further details about the JVM may be obtained from “The Java™ Virtual machine Specification,” Tim Lindholm and Frank Yellin, Addison Wesley (1997), which is incorporated herein by reference.
SUMMARY
The invention features systems and methods for interfacing a service component written in any one of a variety of programming languages to a native operating system application program interface (API). In one aspect, the invention features an interface module configured to load a service component written in a non-native programming language. In another aspect, the invention features an interface module configured to retrieve service component information from a configuration database.
Embodiments may include one or more of the following features.
The interface module preferably is configured to create an application operating environment in which the service component application is operable. For example, in one embodiment the interface module is configured to create a JAVA virtual machine for executing a service component application written in a JAVA programming language. The interface module preferably is configured to treat the application operating environment and the service component application as a single process during execution. In particular, the interface module preferably is configured to create an application thread on which to create the application operating environment. The interface module may be configured to create a main thread for monitoring and blocking the application thread.
The interface module preferably is configured to retrieve service component information from a configuration database. The interface module may be configured to retrieve from the configuration database the identity of a service component application to be executed. The interface module preferably is configured to load, run and control the identified service component application, and to obtain information about the run-time status of the component application.
The interface module preferably includes a service component interface dynamic link library (DLL). In one embodiment, the interface module is operable under the Windows NT Server operating system, and is configured to interface a Win32 API to service components written in C, C++ and JAVA programming languages.
Among the advantages of the invention are the following.
The invention provides a generic interface between a native operating system API and service components written in different programming languages (e.g., C, C++, and JAVA). By separating service functionality from other aspects of the system, the invention enables developers to create services more easily and with greater flexibility. Furthermore, services developed in accordance with the invention may be more easily maintained and tested because service maintenance and testing may be performed separately from other components of the system. For example, a dependability system implemented with services designed in accordance with the invention may be replaced or updated without modifying the underlying service modules. Furthermore, new services may be readily added to the system without changing the dependability system. For example, with the invention a system designer merely has to replace the appropriate DLL or JAVA class with a new service module that implements the desired functionality. The inventive use of the system configuration database (registry) enables system designers to readily implement service functionality with existing service modules regardless of the programming language used to create the service modules. The invention also enables developers to generate service modules without having to worry about the details of the native API interface.


REFERENCES:
patent: 5655154 (1997-08-01), Jain et al.
patent: 5721876 (1998-02-01), Yu et al.
patent: 5802367 (1998-09-01), Held et al.
patent: 5907701 (1999-05-01), Hanson
patent: 5987517 (1999-11-01), Firth et al.
patent: 6014666 (2000-01-01), Helland et al.
patent: 6185609 (2001-02-01), Rangarajan et al.
patent: 6229537 (2001-05-01), Sobeski et al.
patent: 6405216 (2002-06-01), Minnaert et al.
patent: 6496865 (2002-12-01), Sumsion et al.
patent: 0371941 (1990-06-01), None
patent: 0770958 (1997-02-01), None
patent: 1 126 685 (2001-08-01), None
patent: 2 278 468 (1994-11-01), None
patent: 2354092 (2001-03-01), None
patent: WO 00/687790 (2000-11-01), None
Friesen, Jeff, “The Win32-Java Hybrid”, JavaWorld, Jul. 1999, p. 1-5.*
Friesen, Jeff, “Merging Java and Win32: A New Way to Develop Windows Applications”, JavaWorld, Jul. 1998, p. 1-12.

Affiliated with

Also associated with

Rating

Interfacing a service component to a native API does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Interfacing a service component to a native API, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Interfacing a service component to a native API will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3289872