Patent Application
20050268308
The present invention is related to software. More particularly, the present invention relates to a system and a method for providing a generic application program interface.
An application program provides computing devices with the capability to perform a wide variety of tasks including drafting documents, communicating with others, preparing presentations, locating information, etc. An application program is an organized list of instructions that, when executed, cause the computer to behave in a predetermined manner. Processing to prepare an application program for execution may include the use of an assembler, a compiler, an interpreter, or a translator depending on the implementation language.
An Application Program Interface (API) is a formalized set of software calls and routines that can be referenced by an application program in order to access the supporting system or network services. The API is the specific method prescribed by a computer operating system or by an application program by which a programmer in writing an application program makes requests of the operating system or of another application program. The API generally also receives requests from the operating system or another application program and routes these requests to the appropriate application program.
The operating system is the low-level software installed on a computer to handle the interface to peripheral hardware, to schedule tasks, to allocate memory, and to present a default interface to the user when no application program is running. The kernel is the core part of the operating system that is responsible for resource allocation, for low-level hardware interfacing, for security, etc. The operating system makes the resources available to application programs using functions collectively known as the API. The functions are often grouped in terms of what resource or service is provided to the application programmer. Thus, for example, an API may be directed to the computing systems security services. For example, the Security Services API provides application programmers with uniform access to security services atop a variety of underlying cryptographic mechanisms by providing a layer of abstraction over security mechanisms that perform authentication, message integrity protection, and message privacy protection.
Application programs request resources by calling individual API functions. API functions also serve as the means by which messages and information provided by the operating system are relayed back to the application program. The API is defined at the source code level and provides a level of abstraction between the application program and the kernel or other application programs to ensure the portability of the code from one machine to another, and thus, provide platform independence. An API can also provide an interface between a high level language and lower level utilities and services that were written without consideration for the calling conventions supported by the high level language. In this case, the API's main task may be the translation of parameter lists from one format to another and the interpretation of call-by-value and call-by-reference arguments in one or both directions. The calling convention is the arrangement of arguments for a procedure or function call such that the data transferred through the interface maps to the proper parameter. Different programming languages may require arguments to be pushed onto a stack or entered in registers in left-to-right or right-to left order, and either the caller or the callee may be responsible for removing the arguments from the stack or register in the proper sequence. The calling convention also determines if a variable number of arguments is allowed.
The API provides common functionality to satisfy specific underlying needs. Use of an API reduces the programming time and increases the reliability of application programs by providing a common interface to what may be an unknown operating system or application program to which the API interfaces. Thus, an API hides complexities from and provides portability and broader use of application programs across different computing devices with different software and hardware configurations.
A generic API provides common functionality that has been implemented to satisfy specific underlying needs. These generic APIs provide a common starting point for specific application implementations thus reducing the programming time and increasing the reliability of specific implementations built from the generic API. In the past, generic APIs have been developed to satisfy specific application areas by industry groups. For example, the Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. The GSS-API provides a layer of abstraction over security mechanisms that perform authentication, message integrity protection, and message privacy protection. The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis.
What is needed, however, is a common method to attach any implementation to a generic API rather than only a specific application area such as security services. What is further needed is a common method to select a specific API implementation when there are several implementations available for the same purpose.
An exemplary embodiment of the invention relates to a computer implemented method of attaching an application to a generic Application Program Interface (API). The method includes receiving a mapping request in an API, the mapping request having been triggered by an application, selecting one or more candidate mapping modules from a group of mapping modules registered with the API, accessing at least one of information and rules indicative of an association between the application and one or more mapping modules, and selecting one or more target mapping modules for use with the application based on the information and rules.
Another embodiment of the invention relates to an Application Program Interface (API) system. The system includes a module registry adapted to manage attachment, detachment and tracking of mapping modules associated with one or more applications, and a mapping module selector adapted to facilitate selection of one or more of the mapping modules in response to a mapping request triggered by an application.
Another embodiment of the invention relates to an electronic device having one or more application programs, a processor adapted to execute the application programs and an application program interface (API). The API includes a module registry adapted to manage attachment, detachment and tracking of mapping modules associated with one or more applications, and a mapping module selector adapted to facilitate selection of one or more of the mapping modules in response to a mapping request triggered by an application.
Other principal features and advantages of the invention will become apparent to those skilled in the art upon review of the following drawings, the detailed description, and the appended claims.
The exemplary embodiments will hereafter be described with reference to the accompanying drawings, wherein like numerals will denote like elements.
An API provides a level of abstraction between the application and the kernel or other application programs and lower level utilities and services that facilitates the portability of the software from one computing device to another. The API is used by a programmer in writing an application program to define the interface to the operating system or another application program or system service without needing to understand the details of the operating system, application program, or system service. These elements may be implemented in different forms, but the programmer need only be concerned with the interface. Thus, the programmer focuses on the information that is required as an input to the API and the information that is output from the API.
A generic API is a generalized API that provides a few, very generalized operations and parameters. These operations generally include, but are not limited to, operations to generate and to handle error codes and operations to handle generic event services that notify applications about module or API generated events. The API may provide a generic portion to deliver a set of implementation-specific parameters.
Quality of service (QoS) allows network administrators to use their existing resources efficiently and to guarantee that critical applications receive high-quality service without having to expand as quickly, or even over-provision, their networks. QoS operates across the network and allocates resources, such as bandwidth, to applications. This allocation is determined by giving some applications priority over other kinds of applications. QoS gives administrators control over their networks, and, consequently, the ability to provide better service to their customers. For example, a mission-critical application can be guaranteed the resources to complete its transactions within an acceptable period of time. Applications that require some level of QoS can be roughly categorized as either qualitative or quantitative applications. Quantitative applications have explicit requirements for how much QoS they need. Qualitative applications require some level of QoS, but the network administrator must decide how much they need to perform correctly. Two common types of quantitative applications are video streaming and IP telephony. Video streaming requires enough bandwidth so that packet loss will not degrade the image. It may also be desirable to clearly identify this traffic to block it from some parts of the network, such as low-capacity links. An MPEG-2 stream, for instance, might require 4 megabits per second (Mbps) of bandwidth. IP telephony is the classic example of a latency-intolerant application. Unless the conversation preserves its real-time character, the service is, from a customer's viewpoint, unusable. Qualitative applications require some level of QoS, but administrators must decide how those requirements will be satisfied. ERP applications, such as SAP, fall into this category. The traffic they generate does not occur in a continuous stream but is a series of transactions that occurs over a period of time. A common requirement is some sort of latency guarantee, so that a group of transactions occurs in a second, for example. How this requirement is met is up to the administrator.
The API 26 includes a generic operations module 28 to provide a set of generic services. As described above, such services may be context-specific services. The generic operations module 28 makes these services available to one or more application programs, such as application program 24.
A management API module 30 is provided within the API 26. The management API module 30 interfaces with one or more management applications, such as management application 32, to input data that may be required by the API 26 for management of various functions provided by the API 26.
The illustrated embodiment of the API 26 provides support for the management and selection of implementations of the application program 24. In one embodiment, the API 26 contains routines to perform the various management and selection functions. Specifically, the illustrated embodiment includes routines for mapping module registry 36, mapping module selection 40 and mapping support 42. The various implementations may be represented through one or more mapping modules 38a-c associated with each implementation.
The mapping module registry routine 36 provides management of the mapping modules 38a-c. For example, the mapping module registry routine 36 may manage the attachment and detachment of the mapping modules 38a-c, as described in detail below with reference to
Since the specific implementations are not part of the generic API, a mapping module 38a-c is provided to mapping between the relevant generic API operations and the operations of the specific implementation. The mapping modules 38a-c may be added, or attached, when the specific implementation becomes available. Similarly, when a particular implementation is removed, one or more mapping modules 38a-c may also be removed, or detached. When the specific implementation becomes available or is removed, the mapping module registry routine 36 updates the status of the corresponding mapping modules 38a-c as, for example, available or unavailable. All associated application may be notified as well. Thus, the mapping module registry routine 36 provides for easy attachment or detachment of the mapping modules 38a-c via a unified interface and enables and easy adaptation of new types of implementations without interfering with existing ones.
The API 26 may also provide transparent switching between mapping modules 38a-c when, for example, an application requests. The mapping modules 38a-c may facilitate the transparent switching process by providing information concerning changes in state, such as an upcoming inability to serve any applications. In order to support the transparent switching, the API may require sufficient information to select a new mapping module 38a-c. An internal control interface 45 is provided within the API 26 to provide a system interface offering sufficient services for the entities in the API 26 to request various system state information, as needed.
The mapping module selection routine 40 provides for the selection of appropriate mapping modules 38a-c for the application program 24. The selection by the mapping module selection routine 40 associates one or more mapping modules 38a-c with the application program 24, thereby selecting a specific implementation. In this regard, an embodiment of the selection process is described below with reference to
The mapping module selection routine 40 may operate based on a set of rules. The rules may be specified and dynamically updated by a management application, such as management application 32, through the management API module 30. The rules may be expressed through text-based encoding which can be parsed for dynamic selection in run-time, or they may be binary rules that are executable in certain runtime environments. Once received, the rules may be stored in an internal or external data store from the API perspective, such as a database 44.
The rules may be dynamically fetched from either an internal or an external entity, such as a data storage, by the management application 32 during the module attachment process. For example, the attaching mapping module 38a-c may provide sufficient information to allow the management application to determine what to fetch and from where.
The mapping module selection routine 40 can thus apply specified rules to select a mapping module based on certain inputs. The structure of the rules may be selected according to specific needs and desires. Each mapping module 38a-c may use a different structure. An exemplary structure is provided below:
Each “Action” may be a sequence of codes or steps. Thus, provided with the default “Action,” the structure provides a selection result for each given expression. Based on the parsed expressions and actions, a run-time selection may be generated and installed. For example, the “app-expression” in the above example may be “streaming, bandwidth=96 kbps, no-extra-payment-for-transport.” Thus, the filled structure may be expressed as:
Thus, the complexity of the selection rules may be maintained outside the generic API. Further, the selection rules can be updated dynamically and can be applied at the next selection opportunity.
Referring again to
Referring now to
The process 50 then requests additional selection information to narrow the possibilities (block 54). The request may be sent to an internal control interface adapted to provide system state information. The system state information may, for example, provide the context for the selection, thereby allowing certain candidate modules to be eliminated as possibilities. This system state information may include, for example, a status of interface corresponding on each mapping module 38a-c, so that all mapping modules with disabled or inactive interfaces may be eliminated in the selection process. In the illustrated example, mapping modules M2 and M4 are eliminated at this point as possibilities.
The process 50 then searches for stored selection rules (block 56). As noted above, the selection rules may be stored either within the API or in an external data store.
Based on the selection rules, a single mapping module may be selected for the specific implementation (block 58). In the illustrated example, mapping module M5 is selected. Once the selection is made, the selection information associating the implementation with the selected mapping module may be stored for future use.
In certain embodiments, it may be possible that multiple mapping modules are selected for the use of an application if it is indicated that it has multi-module support.
If the selection process, such as that illustrated in
The process 70 begins when a mapping request is triggered by an application (block 72). At block 74, a determination is made as to whether more than one module has been registered for the application. If the determination is made that only one module is registered, the lone module is selected (block 92), and the process is completed.
If the determination at block 74 indicates that more than one mapping module exists as candidates for the specific implementation of the application, the process proceeds to block 76 and obtains system data through an internal control interface. Based on the information obtained at block 76, a determination is made whether the set of candidate mapping modules requires redefinition (block 78). If a redefinition is required, the criteria for candidate module is redefined (block 80) and the process proceeds to block 81. If the determination at block 78 indicates no need for redefinition, then the process skips block 80 and proceeds to block 81.
At block 81, a determination is made as to whether more than one candidate modules remain. If the determination indicates only one remaining module, the process 70 may make the selection of the lone module (block 92), and the process terminates.
If the determination at block 81 indicates that more than one candidate mapping modules remain, the process 70 searches for and obtains selection rules (block 82). As noted above, the selection rules may be stored internal to the API or in an external data store, such as a database.
Based on the search rules obtained at block 82, a determination is made whether the set of candidate mapping modules requires redefinition (block 84). If a redefinition is required, the criteria for candidate module is redefined (block 86) and the process proceeds to block 88. If the determination at block 84 indicates no need for redefinition, then the process skips block 86 and proceeds to block 88.
At block 88, the process determines whether more than one mapping module remains as a candidate for the application. If the determination is made that only one candidate remains, the process continues to block 92 and selects the lone mapping module. If more than one mapping module remains a candidate at block 88, the process 70 proceeds to block 90, where a single mapping module is selected as the best target based on the information available. Thus, a selection is made of a single mapping module for a specific implementation.
If no active mappings are determined to exist, the process 100 proceeds to block 110. If active mappings are determined to exist at block 104, the process 100 performs a search for applications with active mappings (block 106). Each application having an active mapping is then notified through, for example, an alert that the mapping module is being detached (block 108).
At block 110, the process executes module-specific functionalities. For example, functionalities specific to the mapping module may include a controlled cache purging. Thus, when a module is detaching, the cache associated to the detaching module may be further processed and not ignored.
At block 112, the process executes generic functionalities. The generic functionalities are common for all mapping modules. These may include deregistering of the mapping module, for example.
In other embodiments, the event may be generated by an application. For example, if a QoS application determines that a parameter has either exceeded or been reduced below a predetermined threshold, the application may generate an event to be forwarded to other applications. The event may allow or instruct the other applications to adjust their functionality to accommodate the changes in the value of the parameter.
A determination is made as to whether the mapping module generating the event or a mapping module associated with the event generated by an application has any active mappings (block 124). If no active mappings are determined to exist, the process 120 terminates. If active mappings are determined to exist at block 124, the process 120 performs a search for applications with active mappings (block 126). The event is then forwarded to each application having an active mapping (block 128).
At block 130, the process executes event-specific functionalities. These functionalities may be specific to the event and to the mapping module. Thus, if two modules generate the same event, the process may execute different functionalities based on the different modules. For example, if an event is indicative of an interruption in a data stream to an ongoing stream application, a compressor/decompressor (codec) used by the application may react differently than other codecs. Some codecs may adapt to the interruption, while other codecs may request the application to switch to a different codec. Thus, a different mapping module is required for each codec.
It is noted that terms such as “module” or “routine” are used herein with reference to certain embodiments. It will be understood by those skilled in the art that such terms may, in other embodiments, refer to implementations of the invention in hardware, software, firmware or other. Further, functions performed by a module or a routine may be divided so as to be performed by two or more modules or routines. Similarly, functions performed by two or more modules or routines may be combined so as to be performed by a single module or routing. All such variations are contemplated within the scope of the invention.
While particular embodiments of the present invention have been disclosed, it is to be understood that various different modifications and combinations are possible and are contemplated within the true spirit and scope of the appended claims. There is no intention, therefore, of limitations to the exact abstract and disclosure herein presented.
