CN100570553C - Terminal and method for providing dynamic interaction between a pair of applications - Google Patents

Abstract

A system and method are provided for providing dynamic interaction between a pair of application programs including a requester application wishing to access a target application through a platform-independent interface of a terminal. A method includes registering access information of a target application, the access information includes published access information, and the published access information can be retrieved from a data structure through a platform-independent interface. The method further includes receiving an access request from the requester application through a platform-independent interface, where the access request includes request content corresponding to the access information published by the target application. The method also includes searching the data structure using the request content to obtain an interface component configured to implement communication between the platform-independent interface and the target application in an access format expected by the target application. The method also includes using the interface component to satisfy the requester application's access request through the platform independent interface for interaction with the target application.

Description

Terminal and method for providing dynamic interaction between a pair of applications

technical field

The present invention relates to application interaction using application programming interfaces.

Background technique

The number of terminals in use today is continuously increasing, such as mobile phones, PDAs with wireless communication functions, personal computers, self-service kiosks and two-way pagers. Software applications running in these devices increase their usefulness. For example, a mobile phone may contain an application that retrieves city-wide weather conditions, or a PDA may contain an application that allows the user to shop for groceries. These software applications utilize connectivity to the network in order to provide timely and efficient services to users. However, developing software applications for various devices remains a difficult and time-consuming task due to the limited resources of certain devices.

Currently there is no public standard for defining and publishing application access APIs. Currently, wireless platforms and devices provide some custom interaction solutions that use explicit knowledge of all available applications and corresponding APIs installed on the device. The ability of a device-hosted wireless application to interact is predetermined by the current runtime environment and the built-in knowledge of current applications in that environment. All decisions about interaction options and available external APIs are made during the design and development phases, where there is no possibility for runtime adjustments or extensions. Interaction between applications can currently be implemented using a native coding platform for supporting runtime environments and interactive applications.

Disadvantages with current application interaction methods include: a change in configuration or version of a single software part typically requires reinstallation of numerous related or related applications; previously installed software parts cannot communicate with software provisioned and installed at a later time; Inability to seamlessly update existing software or change components in interdependent software packages.

The systems and methods of the present invention are disclosed for customizing application interactions such that at least some of the above-mentioned disadvantages are eliminated or reduced.

Contents of the invention

Disadvantages with current application interaction methods include: a change in configuration or version of a single piece of software typically requires reinstallation of numerous related or related applications; previously installed software pieces cannot communicate with software provisioned and installed at a later time; Seamlessly update existing software or change components in interdependent software packages. In contrast to current interaction methods, the provided systems and methods are capable of providing dynamic interaction between a pair of applications including a requester application wishing to access a target application through a platform neutral interface of the terminal. One such method may include registering and/or automatically assigning access information upon request by the target application, said access information including published access information retrieved from a data structure via a platform independent interface. The term registration as used herein may refer to specific communications with/or a directory or repository and/or with automatic assignment upon request. In this method, an access request from a requester application is received through a platform-independent interface of the terminal, and the above access request includes request content corresponding to the access information published by the target application. The interface component is obtained by retrieving the data structure using the request content, the above-mentioned interface component is configured to implement the communication between the platform independent interface and the target access in the access format expected by the target application. The obtained interface components are used through the platform independent interface to satisfy the access request of the requester application interacting with the target application.

Also disclosed is a method of providing dynamic interaction between a pair of applications comprising a requester application wishing to access a target application via a platform-independent interface of a terminal, the method comprising the steps of: registering and/or assigning the target application's Access information, the access information includes the published access information, the published access information can be retrieved from the data structure through the platform-independent interface; the access request from the requester application is received through the platform-independent interface, and the access request includes the information corresponding to the target application The request content of the published access information; the data structure is retrieved using the request content to obtain an interface component configured to enable communication between the platform-independent interface and the target application in an access format expected by the target application; via the platform The independent interface uses the interface components to satisfy the access request of the requester application interacting with the target application.

There is also provided a terminal for providing dynamic interaction between a pair of applications comprising a requester application wishing to access a target application in a platform-independent environment provided by a runtime environment of the terminal, the application The terminal includes: a data structure for registering the access information of the target application, the access information including published access information; an interface module for providing a platform-independent environment, the interface module is configured to receive an access request from the requester application, the The access request is configured to include request content corresponding to the access information published by the target application, and the access information published by the data structure can be retrieved by the interface module; the interface component connected to the interface module can be retrieved by searching the data structure using the request content an interface module configured to implement communication between the interface module and the target application using an access format expected by the target application; wherein the interface component is used by the interface module to satisfy the access of the requester application in the interaction with the target application ask.

Also disclosed is a computer program product for providing dynamic interaction between a pair of applications including a requester application wishing to access a target application in a platform-independent environment provided by a runtime environment of a terminal , the computer program product includes: a computer-readable medium; a data structure module stored on the computer-readable medium for registering access information of a target application, the access information including published access information; an interface module connected to the data structure module , used to provide a platform-independent environment, the interface module is configured to receive an access request from the requester application, the access request is configured to include request content corresponding to the access information published by the target application, and the access information published by the data structure can be retrieved by the interface module; and an interface component connected to the interface module configured to contain the interface component retrievable by using the request content search data structure module configured to employ the desired The access format realizes the communication between the interface module and the target application; wherein the access request of the requester application in the interaction with the target application is satisfied by using the interface component through the interface module.

Description of drawings

These and other features will become more apparent from the following detailed description to which reference is made in the appended example drawings in which:

Fig. 1 is the block diagram of network system;

Fig. 2 is a block diagram of the universal terminal of Fig. 1;

Fig. 3 shows the processing frame of the terminal of Fig. 2;

Figure 4 shows application interaction for the framework of Figure 3 using a dedicated processor;

Fig. 5 is the replacement example of Fig. 3 interface module as integration engine;

Figure 6 is an example of a run-time flow for the integration engine of Figure 3; and

FIG. 7 shows an example of operations for interaction between the two applications of FIG. 1 .

Detailed ways

Network Systems

Referring to FIG. 1 , a network system 10 includes a plurality of terminals 100 interacting with one or more application servers 110 via a connected wide area network (WAN) 104. The application servers 110 are accessed through a management server 106, and the wide area network (WAN) 104 Such as but not limited to the Internet. Terminal 100 receives application program 107 from application server 110 via server 106 via network 104 . Universal terminal 100 may be a wired device such as, but not limited to, eg, desk terminal 116, wireless device 101, a PDA, a kiosk, or the like. Moreover, the system 10 may also have a gateway server 112 for connecting a desktop terminal 116 (or other wired device) to the server 106 via a local area network (LAN) 114 .

Additionally, system 10 may have a wireless network 102 for connecting wireless terminals 101 to WAN 104 . It will be appreciated that other terminals and computers (not shown) can connect via WAN 104 to server 106 and associated networks other than those shown in FIG. 1 . For simplicity, the general-purpose terminal 100 , the wireless device 101 and the personal computer 116 are referred to as the terminal 100 hereinafter. Furthermore, the networks 102 , 104 , 112 of the system 10 are hereinafter referred to as the network 104 for simplicity. It will be appreciated that there may also be multiple servers 106, 110 and/or the functionality of the servers 106, 110 may be combined if desired. It will also be appreciated that the servers 106, 110 may be implemented by a service provider 118 that provides a schema-defined service, such as a web service. Also, when acquiring and executing the application 107, the terminal 100 can also operate as a stand-alone device. For example, an application may be loaded onto a terminal via a computer readable medium 212 (see FIG. 2 ), as defined below.

The system 10 facilitates the interaction between a plurality of applications 107, for example, labeled "A", "B", "C" and "D", which are distributed on one terminal 100 (i.e. local interaction- eg between applications "A" and "C") and between terminals 100 (ie remote interaction - eg between applications "B" and "D"). The application 107 interacts through an interface and data structure module 312 (see FIG. 2 ) that is expressed in a platform-independent structured definition language such as but not limited to XML and/or a platform-independent script Language (such as but not limited to ECMAScript) to represent. Applications 107 communicate through an application program interface (API) 122 with access extensions 124 (hereinafter referred to as access handlers 124). API 122 and processor 124 may retrieve from repository or database 120 . It can be appreciated that the database 120 can be used by the service 118 or can be used by a stand-alone data server 126 . The system also takes into account the execution of API declared operations and the matching of APIs with application requests. For brevity and without loss of generality, the language used to represent the interface module 312 is hereinafter referred to as XML; it is specifically considered that in each such instance different platform-independent Structured definition language or scripting language.

universal terminal

Referring to FIG. 2, the terminal 100 is such as but not limited to a mobile phone (or other wireless device), a PDA, a two-way pager or a dual-mode communication terminal. Terminal 100 includes a network connection interface 200 , such as a wireless transceiver or a wired network interface card or a modem, connected to terminal infrastructure 204 via connection 218 . The connection interface 200 may be connected to the network 104 during operation of the terminal 100, for example, to a wireless network 102 (see FIG. 1 ) via an RF link, which enables the terminal 100 to communicate with each other and via the network 104 with external systems such as servers 106 - see FIG. 1 ) communicates and enables the terminal 100 to coordinate request/response messages 105 between the terminal 100 and the servers 106 , 110 , 126 . The network 104 supports the transfer of applications 107 in the form of request/response messages 105 between the terminal 100 and external systems, both of which are connected to the network 104 . The network 104 may also support voice communication for telephone calls between the terminal 100 and terminals outside the network 104 . Wireless network 102 may use a wireless data transmission protocol such as, but not limited to, DataTAC, GPRS or CDMA. It can be appreciated that the interaction between terminals 100 may also be referred to as remote interaction between applications 107 .

Referring back to FIG. 2 , the terminal 100 may also have a user interface 202 connected by a connection 222 to the infrastructure 204 of the terminal to facilitate interaction with a user (not shown). User interface 202 may include one or more user input devices, such as, but not limited to, a QWERTY keyboard, keyboard, trackwheel, stylus, mouse, microphone, and user output devices, such as an LCD screen display and or speaker. If the screen is touch sensitive, the display can be used as a user input device controlled by the terminal infrastructure 204 .

Referring back to FIG. 2 , terminal infrastructure 204 enables operation of terminal 100 . Terminal infrastructure 204 includes a computer processor 208 and an associated memory module 210 . Computer processor 208 handles the operation of network interface 200, user interface 202 of communication terminal 100, and infrastructure 206 (see FIG. 107; computer processor 208 may include one or more processing components, which may include one or more general-purpose processors and/or special-purpose processors (eg, ASICs, FPGAs, DSPs, etc.). Furthermore, it will be appreciated that terminal infrastructure 204 may include a computer readable storage medium 212 coupled to processor 208 for providing instructions to the processor to load and execute client application 107 . Computer readable media 212 may include hardware and/or software, and are, by way of example only, such as magnetic disks, tapes, optically readable media such as CD/DVD ROMs, and memory cards. In each case, computer readable medium 212 may take the form of a minidisk, floppy disk, magnetic tape cartridge, hard drive, solid state memory card, or RAM provided in storage module 210 . It should be noted that the computer readable media 212 of the examples listed above may be used alone or in combination.

processing frame

Referring to FIG. 2 , the client runtime environment is provided by the processing framework 206 . A variety of such runtime environments may potentially be used by the processing framework 206 of a particular terminal 100 . The frame 206 of the terminal 100 is connected to the infrastructure 204 by a connection 220 , which is the functional interface of the terminal 100 to the processor 208 and to the associated operating system of the infrastructure 204 . The client runtime environment of the terminal 100 is preferably capable of generating, hosting and executing the client application 107 in the terminal 100; if multiple runtime environments are available, for applications with a particular application 107, a specific A runtime environment. Referring back to FIG. 1 , the client runtime environment provided by terminal 100 may be configured to enable terminal 100 to operate as a web client for a web service (web service 118 ). It will be appreciated that the client runtime environment may also have the terminal 100 client as a client of all other generic defined-mode services offered by the service 118 .

The terminal runtime environment of the framework 206 preferably supports the following basic functions for the resident executable version of the client application 107 (see FIG. 2 ), such as but not limited to:

providing a platform-independent interface module 312 for facilitating local and/or remote interaction between programs 107;

providing communication capability to send message 105 to server 106 via network 104;

supplying the server 106 with the data portion of the output message 105 through data input capabilities provided by the user on the input means of the terminal 100;

Provides data representation or output capabilities to response messages 105 (input messages) or irrelevant notifications from server 106;

providing data storage services to maintain local customer data in the storage module 210 and/or the computer-readable medium 212 (see FIG. 2 ) of the terminal 100; and

An execution environment for scripting languages is provided for coordinating the operation of the application 107 .

Additionally, specific functions of the client runtime environment may include services such as, but not limited to, language support, coordinating storage allocation, networking, data management during I/O operations, coordinating graphics on output devices of the terminal 100 display as well as provide access to core object-oriented classes and supporting files/libraries. Examples of runtime environments executed by terminal 100 may include such as, but not limited to, Microsoft's Common Language Runtime (CLR) and Sun Microsystem's Java Runtime Environment (JRE).

Referring to FIG. 3 , the processing framework 206 may also have other modules such as, but not limited to, an application manager 206 and a provisioning manager 311 . Provisioning manager 311 manages the provisioning of software applications 207 on terminal 100 . Application provisioning may include storing, retrieving, downloading, and removing applications 107 , as well as configuring applications 107 to access remote applications 107 via an interface module 312 cooperating on linking terminal 100 . Application manager 306 may be used to interact with user interface 202 (see FIG. 2 ), manage the lifespan of applications, and the like. It will be appreciated that other configurations of the processing framework 206 of the respective managers 306, 311 in addition to or in addition to display may be implemented if desired.

Referring back to FIG. 3 , interface module 312 coordinates communications between requesting application 400 (see FIG. 4 ) and target application 107 using a series of interface components, such as API 124 . The interface module 312 may also run as a plug-in inside the interaction module 312 using other interface components such as the access handler 122, and act as an intermediary for the interaction between the interaction requester 400 and the target application 107, where the target application is represented as except Languages other than the platform-independent language of module 312 (e.g., converting a call from an XML-based standard interface in module 312 to an application-specific native call suitable for communicating with a native-based target application 107). It will be appreciated that the target application may be expressed in the native language of the runtime environment, or otherwise in a language other than the structured platform-independent language of the interface module 312 .

The access handler 122 can be developed to run as a plug-in inside the interface module 312 , the access handler 122 can act as an intermediary for the interaction between the application 107 acting as the interaction requester and the target application 107 . The processor 122 provides API support according to the internal configuration of the target application 107, which processor 122 is specific to the target application in its configuration. The processor 122 allows the interface module 312 to access the API 124 published by the associated application 107 , which is not expressed in the form of a platform-independent language of the interface module 312 . Interface module 312 provides the functionality to link new handler 122 to the application URI, or other suitable identifier to table 302 (see FIG. 3 ) via registry interface 504 (see FIG. 5 ). Processor 122 may verify the validity of the passed data and may optionally include some access level security regarding filtering and verification.

Referring back to FIG. 3 , the interface module 312 uses the application profile table 300 and the application API description table 302 for containing the access information of the application 107 , the API 124 and the processor 122 . The application profile table 300 contains application 107 information provided when a new application 107 is provisioned/installed or otherwise installed in the terminal 100 . The profile contains all the information needed for application publishing (such as but not limited to application URI, description, version, etc.). The knowledge (publication) of the application profile in table 300 and/or the descriptor of the application API in table 302 provides external access by other applications to the given application 107 through the interaction module 312 . The application API descriptor table 302 may include style descriptors for all APIs supported by a given application 107 . Descriptors can be expressed in any format understood by the execution runtime such as XML or other structured languages. These descriptors facilitate a dynamic API discovery mechanism, described below. It will be appreciated that tables 300, 302 may be combined into one table or other data structure.

Application Overview

The application profile of table 300 may be represented in any format understood by the execution runtime such as XML or other structured language. A profile contains an application identification, which may be in the form of a URI and additional information required for application publication (such as but not limited to version, description, etc.). Thus, after application 107 is registered with interface module 312 , application 107 can be addressed by other applications using the published application identifier associated with table 320 . It can be appreciated that application 107 publishing information should support addressing of local applications 107 (running on the same terminal 100 ) as well as addressing of remote applications 107 running on other terminals 100 . Remote access uses a server 106, 116 capable of managing remote access. For example, when the applications 107 are sent to the terminal 100, the application developer and/or the service provider may define and provide an application profile corresponding to each application 107, and the sending is realized in a manner explicitly or embedded in the content of the application 107 .

The following DTD fragment shows a sample application profile declared using XML:

Example: XML-based Application Profile Description Using DTD

<! ELEMENT appplication(publish,...)>

…

<! ELEMENT publish(#PCDATA)>

<! ATTLIST publish

uri CDATA#REQUIRED

version CDATA#IMPLIED

desc CDATA#IMPLIED>

…

The XML definition used in the application profile snippet above for the addressbook application can be exposed as:

<publish

uri="AddressBook"version="3.1"desc="Contacts manager fordevice user"/>

An application 107 attempting to access a local address book application 107 on a terminal 100 may use a "local (local)" URL: "//local/AddressBook", wherein an application 107 attempting to access an address book application 107 on another terminal 100 ( For example, to insert the terminal user as the new contact of the remote user), you can use "remote (remote)" to access: //remote/123987/AddressBook, where 123987 is the unique ID of the remote terminal 100.

Application API Descriptor

The application access API of table 320 may be expressed in any format understood by the execution runtime such as XML or any other structured language. Application API descriptors may be defined using a standardized subset of expressions. The requesting application 107 will have knowledge of how to match its internal structure with the standardized representation of the API descriptor. This shared knowledge facilitates the use of application API descriptor information and facilitates interactions with applications 107 that publish the API. For example, if the requester application 107 uses an internal construct "rendezvous", if it appears in the API descriptor published by the target application 107, it will be the same as a normalization like "meeting" or "appointment". term (standardized term).

Application APIs can publish descriptors for the following API categories:

■Information API124

Message (i.e. send information to target application 107)

Data (i.e. access to data managed by the target application 107)

■ Call API124 that supports the following call models

- Start called application 107 and terminate caller

- Start the called application 107 and keep the caller running

- Start the called application 107 and suspend the caller until terminated by the called

The following DTD fragment shows an example of an XML-based API descriptor:

Example: An XML instance-based API descriptor defined using a DTD

<! ELEMENT action(op)>

<! --type can be to call a function，send a message or retrieve

information data-->

<! ATTLIST action

api CDATA#REQUIRED

type(call|send|execute) "execute"

>

<! ELEMENT op(param?, result?)>

<! ATTLIST op

name CDATA#REQUIRED

>

<! ELEMENT param(#PCDATA)>

<! ELEMENT result EMPTY>

<! ATTLIST result

type CDATA#REQUIRED

>

Application API interaction interface

System 10 provides interaction between applications 107 according to two modes such as but not limited to, namely:

■ Mode 1 is implemented to conform to the standard interactive interface module 312 . The schema of the application 107 has been designed with knowledge of the interaction standards supported by the interface module 312, the schema of the application 107 executes the interface module to translate the request application 400 (see FIG. 4 ) calls to the internal operations of the platform independent environment of the interface module 312;

■ Mode 2 is implemented without knowledge of the standard interactive interface module 312 . This pattern of applications 107 covers a wide range of applications 107 (eg, currently existing applications) that do not conform to the standard interactive interface module 312 . In order to enable the interoperability of these applications 107, the interaction interface module 312 provides a plug-in service provider interface (SPI) 502 to the access processor 122 (see FIG. 5). For a specific application 107 or API 124, an access processor 122 can be developed that can support protocol conversion (such as not limited to converting an XML-based standard interface call to an application-specific native call).

Referring to FIG. 4 , application A belongs to pattern 1 . Application B belongs to pattern 2. A dedicated processor 122 is developed to support API publication and access to Application B. The requesting application 400 submits an XML-based request 404 to the interface module 312, which calls application A from an XML call 406 through an API-A 124 that corresponds exactly in a platform-independent environment 402 (e.g., XML), just as it does from the processing framework 206 provided by the interaction module 312. Optionally, application B is not expressed as an interaction in XML, but uses a different language, such as the language of the native runtime environment. Accordingly, the interaction module 312 converts the XML-based request 404 into a native call 408 using the appropriate processor 122 for application B.

The requesting application 400 utilizes the interaction module 312 to access the target application A, B (see FIG. 3 ) using the definition identifier published by the table 300 and/or the access API descriptor published by the table 302 . Interaction module 312 passes 404 the request to the target application (either directly 406 or via processor 408). Once the request 406, 408 is completed or otherwise executed, the interaction module 312 communicates the results (if appropriate) back to the requesting application in the language of the platform independent environment 402 . It can be appreciated that if the requester application 400 is expressed in a language other than the platform independent environment 402, the processor 122 will convert the response 406 back to the expression language of application B, eg, based on the native expression language.

Referring to FIG. 4 , an application A, B or its processor 122 may register with the interaction module 312 during provisioning in order to publish or register its API 124 . The registration of the application API 124 may include the following: API publication API instance registration. It will be appreciated that registration logic may preferably include keywords associated with dynamic queries to applications 107 and/or related APIs 124 .

For example, an application 107 can be developed with built-in knowledge of other applications 107 co-existing in the terminal 107, the application 107 knows the identifier and the API descriptor, which are identified by the tables 300, 302 of all applications 107 that can target access. express. In general, the application 107 development model is malleable, and a newly provisioned application 107 has no knowledge of the already deployed applications 107 on the terminal 100 . To enable communication with other applications 107, requesting application 400 can utilize a dynamic API query mechanism. For example, applications can be developed with optional capabilities to export or import data about external APIs 124, send messages, or call external applications 107 using dynamic discovery of required APIs 124 through search thresholds such as but not limited to Keyword scoring method.

When registering with the interaction module 312, the application 107 queries other external applications 124 (for both remote and local applications 107) for all required APIs 124 by submitting a predetermined set of keywords characterizing those APIs 124 . The interaction module 312 runs the query, matches the submitted keywords with the keyword sets of other applications 107 (or processors 122), submits these other applications 107 once their access API 124 is published using the interaction module 312, and places them in the corresponding of tables 300, 302. The interaction module 312 can utilize different matching algorithms to identify the best match for the requested API 124 . An example algorithm is Keyword Match Count, which returns the API 124 with the highest score. More advanced algorithms may also be used, such as weighted keyword scoring or combined matching. The example below shows an API124 query using a simple keyword scoring algorithm.

Example: Referring to Figure 3, an API query using the Keyword Scoring Algorithm.

1. Application A is the calendar application 107, and the calendar application 107 registers its API 124 in the table 302 specifying the API keywords "CALENDAR", "APPOINTMENT" and "MEETING".

2. Application B is the holiday browsing application 107, and the holiday browsing application 107 registers its API 124 that specifies the API keywords "CALENDAR" and "HOLIDAY".

3. According to the above content, the application C is the service call planning application 107, which performs a dynamic query by using the API 124 query keywords "CALENDAR" and "APPOINTMENT". Correspondingly, the interaction module 312 returns the API descriptor of application A from the table 302 as its higher score in keyword matching. Application C can validate the retrieved API descriptor, and if satisfied it can query the corresponding application 107 (or processor 122) identifier via table 300 for the returned API instance. In this example, application C then accesses application A (eg, best match) using the standard interaction protocol as described above with respect to interaction module 312 in FIG. 4 .

integration engine

Referring to FIG. 5 , another example of an interface module 312 is an integration engine (IE) 500 that is part of the framework 206's terminal execution environment. Integration Engine (IE) 500 can dynamically extend published APIs and handle interactions between applications 107 and API handlers 122 (see FIG. 4 ). The IE 500 is composed of a service provider interface (SPI) component or extension interface 502 , an API query and registration component 504 and an execution API logic component 506 . The integration engine 500 may be referred to as a set of software/hardware components designed to: allow the application 107 hosted by the terminal 100 to access all published APIs 124 through the table 302 to support interactions using standard interfaces (e.g. XML to native call forwarding) Role; provide dynamic API 124 publication, query and discovery; provide registration service provider extension interface 502 of embedded processor 122 and application 107 provided by new API processor 122 or application 107; expose published and registered applications through tables 300, 302 Interface component 504 for Profiles and API Descriptors.

In general, therefore, an integration engine 500 is a logical grouping of device execution environment components that handle the interaction of a device-hosted or remote application 107 . The integration engine 500 is designed to support platform-independent interaction patterns, interface publishing, and dynamic applications 107 and/or plug-in application processors 122 .

Service Provider Interface 502

3 and 5, after publishing the API 124, the application 107 or associated access handler 122 registers with the integration engine 500 as an API instance. API 124, processor 122 and application 107 publications are all registered in appropriate tables 300,302. The service provider extension interface 502 supports dynamic insertion of access processors 122 and applications 107, ie the integration engine 500 requests the application manager 306 to retrieve the tables 300, 302 of the appropriate requested applications 107 and/or processors 122. If not found on the local terminal 100, the terminal 100 can canvass the required processor 122, API 124 and/or knowledge base 126 of the application 107 (see FIG. 1). It will be appreciated that the extension interface 502 allows different types of plug-in of the access processor 122 depending on the specific locale of the external application 107 .

Query and Register 504

The query and registration interface 504 supports registration 508 of application profiles in table 300 and publication of access identifiers in table 302 . It also supports query access 510 to the table information for the caller. Query interface 510 is considered an optional function. Alternatively, the requesting application 400 may know the target application location and access API descriptor, and may not need to perform a query.

Application 107 or its processor 122 may publish API 124 in table 302 using this instance interface 508:

publishAPI[string:apiID, XML:apiDesc, string[]:keywords].

The application 107 or its processor 122 registers as an instance of this API 124 . The URI parameter is a parameter of the application 107 or its associated processor 122 .

RegisterAPIInstance[string: URI, string: apiID].

Application 107 can dynamically query external API 124 from table 302 using the following:

lookupAPI[string[]:keywords]returns[XML:apiDescription]

lookupInstance[string:apiID]returns[string[]URIs]

Implement API 506

Executing the API interface 506 can be defined as the following call, which includes request content related to the access information contained in the tables 300, 302:

submit[XML:params]; or

submit[string:URI，XML:params].

With the first call shown above, no application URI is specified. The integration engine 500 issues a broadcast call to all applications 107 registered as instances of the API 124 to enable access to the requested external application 107 . In the second case, the requesting application 400 (see FIG. 4 ) explicitly specifies the target application 107 through the URI. Accordingly, the API execution interface 506 of the integration engine 500 coordinates the request and provisioning of the selected API 124 according to the needs of the requesting application 400 (see FIG. 4 ).

Referring to FIG. 6 , an example interaction between applications A and B is shown illustrating the run-time logic flow of the integration engine 500 . Application B requests access to application A's API 124 via the execution interface 506 . Execution interface 506 queries the query and registration interface 504 to query processors 122 and/or applications 107 that have registered via table 302 with the requesting API 124 . Interface 504 retrieves a suitable processor 122 for the requesting application A based on the fact that application A is not represented in platform independent environment 402 as recorded in table 302 , and therefore processor 122 needs to operate in environment 402 . Integration engine 500 then uses registered handler 122 to facilitate application B's access to application A via a call to application A's appropriate API 124 . It can be appreciated that processor 122 and corresponding API 124 have previously registered as an instance of application A via interface 504 .

5 and 7, by adding processors to support the interaction of the application 107, operation 700 of the integration engine 500, API 124 registration steps, and steps are performed once the application 107 makes a request to the API 124. Note that this example does not use the select query retrieval functionality. The integration engine 500 on the terminal 100 may support an XML-based interaction protocol used as a platform independent environment 402, such as described in the examples below.

In step 701 , the terminal 100 is provisioned with a calendar application 107 "PersonalCalendar" which does not have built-in knowledge of the integration engine 500 interaction criteria. In step 702, the calendar handler 122 is inserted into IE 500 through the extension interface 502 as an instance of the "Personal Calendar" API, and the calendar handler 122 is designed to enable the calendar application 107 to implement IE 500 standard access (represented by the environment 402). For example, the API descriptor corresponding to the plug-in handler 122 may be as follows: The API 124 of the update calendar application 107 supports an operation "addMeeting" that implements adding a meeting. It is published in table 302 with the following descriptor "updateCalendarDesc.xml":

<! DOCTYPE action SYSTEM”api.dtd”>

<action api="updateCalendar">

<op name="addMeeting">

<param>Meeting</param>

<result type="boolean"/>

</op>

</action>

At step 703, the Calendar Handler 122 publishes through the API 124 interface 504 with API-ID "updateCalendar" as: publishAPI("updateCalendar", "updateCalendarDesc.xml"). Then in step 704, the calendar processor 122 is registered as an instance of the updateCalendar API 124 through the interface 504 as the "personalCalendarHandler" of the IE 500, which represents the following content: registerAPIInstance("personalCalendarHandler", "updateCalendar"). It can be appreciated that table 302 includes API 124 and processor 122 registered as instances of applications provisioned on terminal 100 . In step 706, the requesting application 400 (see FIG. 4 ) builds the request information "addMeeetingRequest.xml" so as to increase the meeting:

<action api="//updateCalendar">

<op name="addMeeting">

<param>

<Meeting>

<date>09/15/03 10:15:00</date>

<details>Conference call with John</details>

<note>To discuss the Idea of XML based interface</note>

</Meeting>

</param>

<result type="boolean"/>

</op>

</action>

At step 708, option 1 (directed access) provides for the application 400 to send the following request to the integration engine 500:

submit[/"local/personalCalendarHandler", "addMeetingRequest.xml"]. Additionally, at step 710, option 2 (broadcast) provides for sending the following request to the application 400 of the integration engine 500: submit["addMeetingRequest.xml"]. At step 711 , IE 500 passes the request to Calendar Handler 122 (and other registered "updateCalendar" API 124 instances with option 2), as recorded in table 302 . Calendar handler 122 examines 712 the data (eg, date) and builds input in the format expected by calendar application 107 (eg, builds native Date object, builds native Meeting object, etc.). The calendar handler 122 then calls 714 the calendar application 107 native API 124 call. Once complete, the calendar processor 122 passes 716 the results (if appropriate) to the integration engine 500 for delivery to the requesting application 400 .

It will be appreciated that registration and access for the API 124 would encounter similar steps as above (without the processor 122 ) without the need for the processor 122 (ie, the calendar application is expressed in a platform-independent environment 402 compatible language). Moreover, access to the calendar processor in step 708 can be implemented remotely if desired.

Considering the system 10 described above, publishing and accessing using the application API 124 through the interface module 312 (or denoted engine 500 ) provides general and extensible interaction between applications 107 and supports a dynamic environment for interaction with applications 107 . Application 107 is capable of interacting in a platform-independent manner using such as, but not limited to, structured languages (eg, XML) and/or platform-independent scripting (eg, ECMAScript). The application 107 can dynamically discover available APIs 124 and processors 122 using an optional query interface 510 such as but not limited to using a keyword matching scheme. Furthermore, the system 10 can provide the ability to dynamically extend the application 107 environment and provide API 124 collections using dynamic insertion through the extension interface 502 to access the processor 122 . It can also be appreciated that the interface module 312 can have similar interfaces 502 , 504 , 506 , 508 , 510 as the integration engine 500 .

Moreover, the communication between applications 107 is facilitated by the following constructs: application profile of table 300; application API and processor descriptor of table 302; application API interaction interface involves registration, query and access.

The foregoing description relates to an exemplary system and method. Many variations will be apparent to those skilled in the art, and such variations are encompassed within the scope of this application. For example, although XML and a subset of ECMAScript are used in the examples provided, other languages and language variants can be used as well. Moreover, it can be appreciated that the system 10 can be implemented in the form of hardware and/or software components, which includes: a data structure module, used to register the access information of the target application, and the access information includes publishing access information; an interface module, used to provide A platform independent environment, the interface module configured to receive the access request from the requester application; and the interface component module configured to contain the interface component retrievable by using the request content.

Claims (42)

1, a kind ofly be provided at the method for the dynamic interaction between a pair of application by the platform independence interface of terminal, this comprises the requestor application of wishing that access destination is used to application, and the method comprising the steps of:

Utilize the visit information of described platform independence interface registration intended application, this visit information comprises the visit information of announcement, and the visit information of this announcement is available in data structure;

In the request of access of platform independence interface reception from requestor application, this request of access comprises the corresponding request content of announcement visit information with intended application;

The platform independence interface obtains interface module by using this request content that the data structure is retrieved, and the configuration of this interface module is used to adopt the desired access stencil of intended application to be implemented in communication between platform independence interface and the intended application;

Use interface module by the platform independence interface, to satisfy the request of access of requestor application, so that carry out alternately with intended application.

2,, be arranged to the incompatible language of employing and platform independence interface and communicate according to the process of claim 1 wherein that interface module comprises application programming interfaces.

3, according to the method for claim 2, wherein incompatible language is the employed language of this machine environment working time by terminal.

4, according to the process of claim 1 wherein that interface module comprises application programming interfaces, described application programming interfaces are arranged to the language with the platform independence interface compatibility and communicate.

5, according to the method for claim 2, wherein interface module also comprises access processor, and described access processor is arranged to and is provided at translating between platform independence interface and the application programming interfaces.

6, according to the method for claim 5, also comprise step: to platform independence interface registration access processor, the visit information that this access processor is announced is added in the data structure by expansion interface.

7, according to the method for claim 6, also comprise step: use access processor to visit intended application, to call out the corresponding application interface by the platform independence interface.

8, according to the method for claim 7, also comprise step: use searching algorithm to discern the coupling access processor that uses by the platform independence interface with request content.

9, method according to Claim 8, selection is used to represent the language of platform independence interface in the group that wherein comprises from below: structured definition language and script.

10, according to the method for claim 9, wherein structured definition language is based on XML.

11,, be used to wherein represent that the language of script is ECMAscript according to the method for claim 9.

12, according to the method for claim 7, also comprise step: the assembling request content, so that it comprises the content of selecting from following group: local position and remote location.

13, according to the method for claim 12, wherein remote location is positioned at by network and is connected on another terminal of described terminal, and described another terminal has this to an application in using, and is used for this network interaction being carried out in other application of using.

14,, wherein be the client of defining mode service that can be by access to netwoks with described another terminal configuration according to the method for claim 13.

15, according to the method for claim 7, wherein data structure is to select from the group that comprises application scenario table and application programming interfaces descriptor table.

16, according to the method for claim 15, wherein the application scenario table comprises the application scenario of a plurality of intended application.

17, according to the method for claim 15, wherein the application programming interfaces descriptor table comprises the descriptor of selecting in the group that comprises from below: application programming interfaces descriptor and access processor descriptor.

18, according to the method for claim 15, wherein data structure comprises the visit information of selecting in the group that comprises from below: use URI, application version is used and is described and the right predetermined set of coupling application programming interfaces structure.

19, according to the method for claim 7, also comprise step: the interface that the platform independence interface of selecting in the group that comprises from below is provided: expansion interface, inquiry and registration interface, and executive's interface.

20, according to the method for claim 19, wherein the expansion interface configuration is used for being connected of the new described interface module of dynamic expansion and platform independence interface.

21, according to the terminal of claim 19, wherein configuration is used to announce the visit information relevant with interface module with registration interface in inquiry.

22, a kind ofly be provided at the terminal of the dynamic interaction between a pair of application by the platform independence interface of terminal, this comprises the requestor application of wishing that access destination is used to application, and this terminal comprises:

Register device is used to utilize described platform independence interface to register the visit information of intended application, and this visit information comprises the visit information of announcement, and the visit information of this announcement is available in data structure;

Receiving trap is used in the request of access of platform independence interface reception from requestor application, and this request of access comprises the corresponding request content of announcement visit information with intended application;

Obtain device, be used for obtaining interface module by using this request content that the data structure is retrieved, this interface module configuration is used to adopt the desired access stencil of intended application to be implemented in communication between platform independence interface and the intended application; With

Operative installations is used for using interface module by the platform independence interface, to satisfy the request of access of requestor application, so that carry out alternately with intended application.

23. according to the terminal of claim 22, wherein interface module comprises application programming interfaces, described application programming interfaces are arranged to adopt with the incompatible language of platform independence interface and communicate.

24, according to the terminal of claim 23, wherein said incompatible language is the employed language of this machine environment working time by terminal.

25, according to the terminal of claim 22, wherein interface module comprises application programming interfaces, and described application programming interfaces are arranged to the language with the platform independence interface compatibility and communicate.

26, according to the terminal of claim 23, wherein interface module also comprises access processor, and described access processor is arranged to and is provided at translating between platform independence interface and the application programming interfaces.

27, according to the terminal of claim 26, also comprise expansion interface, to platform independence interface registration access processor, the visit information that this access processor is announced is added in the data structure by described expansion interface.

28, according to the terminal of claim 27, also comprise the corresponding application interface, use access processor to visit intended application, to call out corresponding application programming interfaces by the platform independence interface.

29,, comprise that also the searching algorithm of using request content discerns the device of the coupling access processor that is used by the platform independence interface according to the terminal of claim 28.

30,, select to be used to represent the language of platform independence interface in the group that wherein comprises: structured definition language and script from below according to the terminal of claim 29.

31, according to the terminal of claim 30, wherein structured definition language is based on XML.

32,, be used to wherein represent that the language of script is ECMAscript according to the terminal of claim 30.

33, according to the terminal of claim 28, wherein assemble request content, so that it comprises the content of selecting from following group: local position and remote location.

34, according to the terminal of claim 33, wherein remote location is positioned at by network and is connected on another terminal of described terminal, and described another terminal has this to an application in using, and is used for this network interaction being carried out in other application of using.

35,, wherein be the client of defining mode service that can be by access to netwoks with described another terminal configuration according to the terminal of claim 34.

36, according to the terminal of claim 28, wherein data structure is to select from the group that comprises application scenario table and application programming interfaces descriptor table.

37, according to the terminal of claim 36, wherein the application scenario table comprises the application scenario of a plurality of intended application.

38, according to the terminal of claim 36, wherein the application programming interfaces descriptor table comprises the descriptor of selecting in the group that comprises from below: application programming interfaces descriptor and access processor descriptor.

39, according to the terminal of claim 36, wherein data structure comprises the visit information of selecting in the group that comprises from below: use URI, application version is used and is described and the right predetermined set of coupling application programming interfaces structure.

40, according to the terminal of claim 23, also comprise the interface of platform independence interface, the interface of described platform independence interface is to select in the group that comprises from below: expansion interface, inquiry and registration interface, and executive's interface.

41, according to the terminal of claim 40, wherein the expansion interface configuration is used for being connected of the new described interface module of dynamic expansion and platform independence interface.

42, according to the terminal of claim 40, wherein configuration is used to announce the visit information relevant with interface module with registration interface in inquiry.

Images