Method and system for adapting programs for interoperability and adapters therefor

Abstract

To provide a method and system that enable achieving a generalized program for programming interoperability, and an adaptor with which a different program achieves the interoperability.SOLUTION: A method and system employ an automatic or substantially automatic transform adapter in order to use a given exchange standard for two-way communication with a program. In order for the adapter to employ the exchange standard, a discovery manager may learn the program's data communications structure and / or format, and may learn data meaning information from the program. An adapter creator may derive a transform which converts the program's data communications structure and data meaning into the exchange standard. The transform may be used by the adapter to enable two-way communication with any adapter and / or program similarly employing the given exchange standard to achieve interoperability.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention generally relates to methods and systems for adapting software programs for interoperability. The present invention further relates to adapters that enable different programs to achieve interoperability.

Background Art

[0002] It is not admitted that the background art disclosed in this section constitutes prior art legally.

[0003] Currently, programs such as database programs, for example, use various different data models, interface languages, naming rules, data semantics, schemas, and data representations. Thus, the basic problem is the sharing of heterogeneous information among various resources. The diversity of data from different programs can create a significant barrier, where interoperability between such diverse programs may be highly desirable but has heretofore been impossible to achieve.

[0004] Many attempts have been made towards heterogeneous databases, but there continue to be significant requirements for the design, engineering, and manufacture of applications that can easily access and import data in an efficient and effective manner. Efforts to develop global query languages have not provided a satisfactory solution for many users who would like to view the world of external data as an extension of their existing systems and their specialized representations. These users may not want to learn different global representations, and more importantly, their expensive design tools may only be capable of handling one of their specialized representations.

[0005] Database gateways, the Common Object Request Broker (COBRA), and the Open Database Connectivity (ODBC) interface attempt to address heterogeneity, but their efforts are only at a relatively superficial level. Therefore, there are fundamental drawbacks from the start in achieving universal program interoperability.

[0006] In all these cases, in order to call some of the functions designed in the interface between programs so that they can interoperate in some way, the programmer still has to write application code, resulting in additional unwanted costs and time delays. Data conversion and reformating may be required, either on the source side of the application programming interface (API), the target side of the API, or often both. All of this is left to the programmer, who has to implement this interoperability functionality on a case-by-case basis, which is very costly for the desired implementation. Unfortunately, there is little or no existing software that can build these conversion means, and each effort usually starts from scratch. Multiple vendors offer import conversion means from some common formats, but generally these do not provide sufficient interoperability.

[0007] Furthermore, when the targeted use of data anticipates non-relational data (e.g., links, nesting, or other formats), additional data conversion may be required. This usually involves significant and very costly programming effort, as well as additional time-consuming requirements. Even in a relational data mode, there are usually several different ways to design relational tables. That is, there are usually more than two ways to normalize data. If an application requires data different from what the API provides, data conversion is usually necessary. Thus, an organization often has to write expensive and time-consuming specialized conversion means for its specific requirements.

[0008] In large enterprises in recent years, other interoperability drawbacks often occur. It is inevitable that different parts of an organization may use different systems to generate, store, and retrieve their important data. This diversity of data sources can be caused by many factors, including lack of coordination within the company, differences in the adoption rate of new technologies, mergers and acquisitions, and geographical separation of collaborative groups. However, without combining information from these various systems, a company may not be able to recognize the value of all the data contained therein. Thus, program interoperability has become more complex in large enterprises in recent years.

[0009] For example, in industries such as finance or healthcare, mergers are quite common occurrences. The companies resulting from mergers inherit the data stores of the original single or multiple institutions. Many of those data stores can often be from different manufacturers. Both the acquirer and the target may have had one or more document management systems for storing text documents. Each of them may have had applications for calculating important information, such as the risk of providing financing to a given customer or a source of information regarding a customer's purchasing patterns.

[0010] The newly merged company will need to access customer information from both sets of data stores, analyze that new portfolio using existing and new applications, or generally use a combination of resources from both organizations through a common interface. Additionally, the company will need the ability to identify common customers and integrate their accounts, even if the customer data is stored in different databases in different formats. These are all aspects of program interoperability, and all can pose significantly overly costly challenges in the implementation process. Additionally, this implementation typically requires extra long delays to achieve the desired interoperability.

[0011] Another attempt at interoperability is to establish a data warehouse, which is typically constructed by loading data from one or more data sources into a newly defined schema within the warehouse database. In this loading process, the data is often cleaned and transformed. Changes in the underlying source can bring about changes in the loading process, and parts of the applications working on data analysis need to be protected. New data sources can introduce changes to the schema, and it becomes necessary to define a new loading process for the new data. However, any functionality of a new data source that is not part of the standard parts of the warehouse database management system usually needs to be re-implemented within the warehouse database system or as part of an application, often incurring additional costs and wasted time for installation.

[0012] Solutions based solely on warehousing may be impractical or cost-ineffective for various other reasons. For example, it is not always feasible to move data from its original location to the data warehouse, and as mentioned above, warehousing has its own maintenance and implementation costs.

[0013] Using a database federation system is yet another attempt to achieve universal interoperability. The term "database federation" refers to an architecture in which a database management system provides uniform access to several heterogeneous data sources. However, the time and expense of designing and implementing such systems are usually an undesirable extra. Even when realized, such systems are typically limited to relational databases only and not, for example, to other formats such as hierarchical or other forms. Thus, such a limited architecture is completely unsuitable for universal interoperability. Scaling up by adding previously unknown input data sources can be at best an external challenge, if not completely impractical for some applications.

[0014] Generally, extra expense and time are required to create an interface to achieve some measure of program interoperability, such as when a large group of heterogeneous data sources are used. Such manual work by programmers is usually an undesirable extra, if not difficult.

[0015] It would be highly desirable to have a system and method that enables the interoperability of any number of different programs in an automatic or substantially automatic, highly efficient and effective manner. Such systems and methods should provide protection against human error. Additionally, it would be highly desirable to have a program adapter to assist in promoting universal interoperability between different programs. By operating in an automatic or substantially automatic manner, this adapter would eliminate or greatly reduce the need for programmers to develop interfaces for programs that were previously unknown. This adapter should be able to enable interoperability even between programs with previously unknown data arrangements and meanings, and this implementation may be completed substantially without human intervention. Thus, previously unknown programs can be easily accessed by other programs for interoperability purposes, allowing the system to be globally extended in an essentially unrestricted manner and with a fast and efficient approach.

[0016] Adapters have been used to assist in achieving access to databases by other programs. For example, the following U.S. patents (Patent Document 1, Patent Document 2, Patent Document 3, Patent Document 4, Patent Document 5, and Patent Document 6) may be referenced.

[0017] Additionally, Non-Patent Document 1 and Non-Patent Document 2 are non-patent publications.

[0018] For example, Patent Document 6 discloses a database adapter, which claims to reduce "the time and cost associated with adapting an application program to operate with a second database different from a first database designed to be accessed by the application." However, first, such an adapter needs to be manually customized for each of the two different database programs. In particular, when there can be a large number of different possible heterogeneous programs that should interoperate in an efficient and effective manner, of course, implementing such customization takes excessive cost and an unacceptably long time. Second, the disclosed adapter is designed to instantiate both databases, which may be undesirable for most applications.

[0019] Patent Document 4 of Tamboli and Patent Document 1 of Szyperski disclose an adapter and techniques for data mapping of information to assist interoperability. The Tamboli patent discloses an adapter used for data integration. Identification attributes are displayed by the user workstation. Those attributes are "actually stored in the catalog." (Column 12, lines 43-49.) The user can then enable "execution of a transfer to transfer specific identified data from a source native repository to a destination native repository." "In such an embodiment, the user interface can write catalog keys from the identification attributes to the transfer cart for all the native records transferred by the user when so instructed... In a typical embodiment, the user interface then writes the catalog keys to the transfer cart (242), writing one key for each transfer record." (Column 13, lines 1-26.) To enable this operation, the programmer writes "code for the adapter function or member method, which is written in the language of the database management system for the native repository or calls an application programming interface ('API') supported by the native repository or its database management system." (Column 23, lines 8-12.) When there is an error in the mapping, "to the extent that the mapping needs to be corrected, programming is not required and only text editing is needed. To the extent that the adapter needs to be corrected, only a small amount of programming is involved and in the current example, it is sufficient to add one excluded data element.... Due to human error or human selection, as a practical matter, data elements are excluded without defining a complete join, and the fact that 'correction is needed'." (Column 25, lines 29-40.)

[0020] Therefore, it is clear that the mapping requires correction due to human error when manually entering information at the workstation. Such human errors and manual corrections would be costly and highly undesirable. The tambour technology that requires "in a typical embodiment, the user interface then writes the catalog key to the transfer cart (242), writing one key for each transfer register" is subject to human error for all records within the system. Thus, serious accuracy problems can be easily and predictably brought about.

[0021] In the Sipersky patent, an attempt is made to "correlate different nominal types together based on a minimal set of common shapes or structures." "In one implementation, the developer identifies several different nominal types (source types) of interest and identifies a minimal set of the shapes of the common type accessed by the application program. Then, using that minimal set of the shapes of the common type, an intermediate type (target type) can be created, and each of the other different source types can be mapped to that intermediate type. For example, one or more proxies can be created that map the shapes of one or more source types to the corresponding shapes of the created target type. Thereafter, the application program created by the developer can access, operate on, or otherwise use the mapped data of each different source type through a single target type." (Abstract, lines 2 - 15.)

[0022] However, for the purpose of data mapping, the developer needs to identify the different nominal types (source types) of interest and identify a minimal set of the shapes of the common type accessed by the application program. Such programming can be overly costly and time - consuming. In addition, it is clear that the developer needs to already know those types before he or she can identify several different nominal types and further identify a minimal set of the shapes of the common type. Thus, Sipersky requires prior knowledge of a specific program before mapping can be done.

[0023] To better understand certain embodiments and to see how they may actually be carried out, reference will now be made, by way of example, to the accompanying drawings to describe non-limiting preferred embodiments of the present invention.

Prior Art Documents

Patent Documents

[0024]

Patent Document 1

Patent Document 2

Patent Document 3

Patent Document 4

Patent Document 5

Patent Document 6

Non-Patent Documents

[0025]

Non-Patent Document 1

Non-Patent Document 2

Brief Description of Drawings

[0026]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Mode for Carrying Out the Invention

[0027] Reference will now be made in detail to the specific embodiments of the present invention as illustrated in the accompanying drawings, in which some, but not all, embodiments of the invention are shown. In fact, these embodiments of the present invention may take many different forms and, thus, should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided as illustrative examples only so that this disclosure will satisfy applicable legal requirements. Throughout, like numbers refer to like elements.

[0028] It will be readily understood that the components of the embodiments generally described and illustrated in the drawings herein may be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the specific embodiments of the apparatus system, components, and methods of the present invention represented in the drawings is not intended to limit the scope of the claimed invention, but is merely representative of one or more embodiments of the present invention.

[0029] According to an embodiment, the system facilitates interoperability between first and second different programs. The programs may have previously unknown data meanings and data arrangements. The system includes first and second bidirectional exchange standard adapters, each of the bidirectional exchange standard adapters including first and second data function conversions. The conversion may be a conversion function of data structure and data format between the first and second programs and a common exchange standard. In addition, each of the first and second adapters includes a communication transfer that reads and writes data to and from the respective first and second programs. A communication link may connect the first and second adapters to transmit exchange standard information bidirectionally.

[0030] Data function conversions according to various embodiments may be created without human intervention and enable program interoperability. The data structure and data format, as well as the read / write data for each program, are learned by the discovery manager. Thus, data conversion and read / write data for each adapter enable the adapter creator to create the adapter, and all of these may be done without human intervention.

[0031] It should be understood that the term "data function conversion" as used herein may be variously referred to herein as "ES data conversion", "conversion", or "ES program data conversion", among others.

[0032] Another embodiment relates to a method of creating a bidirectional exchange standard adapter. This method includes receiving program data meaning and corresponding data locations from a given program. Next, it is determined whether the received program meaning is equivalent to the desired meaning of the exchange standard. A further determination may be made as to whether data from the received data locations of the given program is consistent with the corresponding data of the exchange standard.

[0033] Thus, when data meanings may be available, the data for those meanings may be verified by analyzing the related data. If no meanings are available, the data itself may be analyzed to determine whether any of the data contained in the unknown program could be the one of interest, and this may all be completed in a fast and efficient manner without human intervention.

[0034] When equivalence and / or consistency is determined, then a two-way function conversion may be created. The function conversion may be a function of the data structure and data format for data conversion between a given program and the corresponding exchange standard. The function conversion is provided for a given bidirectional exchange standard adapter to facilitate interoperability between the given program and a different program having another bidirectional exchange standard adapter.

[0035] The method of creation may include a discovery manager that facilitates the search for data meaning with respect to data stored in a given program. The search may include receiving an application programming interface (API) via the discovery manager.

[0036] The method of creation may include a discovery manager that facilitates the search for data meaning with respect to data stored in a given program in the form of metadata.

[0037] The method of creation using the discovery manager may include determining a desired interchange standard meaning based on the received program data meaning and determining whether the interchange standard meaning is equivalent to the corresponding program data meaning.

[0038] The method of creation using the discovery manager may include determining whether a program data profile exists and whether an exchange data profile exists. If they exist, then it may be determined whether there is consistency between the program data profile and the interchange standard data profile via the discovery manager.

[0039] The method of creation may include determining whether the discovery manager determines that either data meaning equivalence and / or data profile consistency exists, and then an adapter may be created by an adapter creator, except when (1) the program data meaning is not equivalent to the interchange standard data meaning, or (2) the program data profile is not consistent with the interchange standard data profile.

[0040] The method of creation may include creating rules that define read and write commands and function data conversion.

[0041] Yet another embodiment relates to a bidirectional exchange standard adapter that enables a given program to interoperate with a different program having a different bidirectional exchange standard adapter. The adapter may include one or more hyperobjects that include one or more rules defining two-way function data conversion. The function conversion may be a data conversion function for data structures and data formats for a given program and a given exchange standard. The one or more hyperobjects may also define rules for data reading and data writing for a given program. As a result, communication with another bidirectional exchange standard adapter is facilitated, providing interoperability between a given program and different programs.

[0042] The bidirectional exchange standard adapter may further include a communication link for communication between the adapter and another bidirectional exchange standard adapter for transmitting two-way exchange standard information.

[0043] In one embodiment, the hyperobject rules of the adapter enable fast and efficient implementation in a well-known and accepted hyperobject framework. Additionally, the rules may be modified dynamically or otherwise changed.

[0044] Referring now to the drawings, and more particularly to FIG. 1, there is shown a bidirectional exchange standard adapter 10 that enables a given program, such as program 12 of program group 13, to interoperate with a different unknown program, such as program 14. Program group 13 may be various different programs, such as databases, applications, and other types and kinds of programs. In addition, the data meaning may not have been known heretofore among the various programs 13. According to various embodiments, by each of the programs 13 including an exchange standard adapter similar to adapter 10, the programs 13 may still be able to interoperate with each other and share data with each other, even when the structure and arrangement of the data of each of the programs 13 are different and may have been unknown heretofore.

[0045] To create adapter 10 for program 12, a discovery manager 15 may be used to discover the meaning of specific desired data used or stored in program 12. For this purpose, specific received program information indicated by 16 is provided to discovery manager 15 to notify it of how to find the data meaning and corresponding data location, which may be provided to server 17 of discovery manager 15.

[0046] According to various embodiments, when it may not be possible to obtain such data meaning and data location, the data itself, such as program data (P-DATA), may be automatically or semi-automatically analyzed to learn the data meaning and data location.

[0047] According to an embodiment, a given exchange standard (ES), generally denoted by 18, is received by the discovery manager 15. The exchange standard data ES-DATA may include data representing desired given information, including but not limited to desired data meaning, data structure and format, data profile, and others.

[0048] When the discovery manager 15 learns that a given desired data meaning corresponding to a given exchange standard ES and their positions have been discovered and / or the program data P-DATA is consistent with the exchange standard data ES-DATA, the adapter creator 19 having the server 21 may then create data function conversions for the data structure and data format as well as read-write program commands.

[0049] Once created, conversions such as ES program data conversion, for example, may be assembled into the adapter 10 as shown at 20. In addition, communication transfer read / write data may also be defined by the discovery manager 15, and this communication transfer read / write data may be used by the adapter creator 19 to access the program 12 to provide read and write commands for a given program 12 and may be assembled into the adapter 10 as shown at 22.

[0050] Referring now to FIG. 2, when the adapter 10 is complete, a given program 12 may be connected via its adapter 10, through the ES data communication link 26, to a different bi-directional exchange standard adapter, such as adapter 27, for example. By coupling this adapter 27 via link 25 to a different program, such as program 14 for example, interoperability between programs 12 and 14 may be facilitated. Adapter 27 is assumed to be created by discovery manager 15 and adapter creator 19, or may be created by a similar proprietary discovery manager (not shown) and adapter creator (not shown) of its own. Adapter 27 includes ES program data conversion 29, which performs bi-directional conversion between program information within program 14 and the exchange standard ES, in a manner similar to the conversion 20 of adapter 10 for use with program 12. Similarly, adapter 27 may include communication transfer read / write data 28, which has a function similar to the communication transfer data 22 of adapter 10 and provides read and write commands to program 14.

[0051] As an example, assume that a given program 12 includes Italian language information and a different program 14 includes Chinese language information. Further assume that the exchange standard ES is in English. Program 12 may request information by sending a message, such as an Italian language query for example, to program 14 via link 11, adapter 10, ES data communication link 26, adapter 27, and link 25. When doing so, the Italian language program request from program 12 is sent using read / write command 22, converted to English via ES data conversion at 20, and transmitted by link 26 and adapter 27 to provide an English language request. Next, adapter 27 converts the English language request to Chinese using data conversion 29 for provision to program 14. The Chinese language request is transmitted to program 14 via link 25 by using read / write data 28 for program 14.

[0052] Next, program 14 may respond to adapter 27 in Chinese via link 25 using read / write commands compliant with that data 28. Adapter 27 converts Chinese information into English by data conversion 29 and provides an English response to adapter 10 via ES data communication link 26. Next, adapter 10 converts the English data response into Italian via data conversion 20 and supplies Italian information to program 12 via link 11 using read / write data 22. As a result, two-way communication is performed between programs 12 and 14, and interoperability may be provided even though these two programs are different and communicate in different languages or may have other differences.

[0053] Referring now to FIGS. 1 and 3, a method or process for creating a bidirectional exchange adapter 10 according to various embodiments will now be described in more detail. Program 12 is a database program and is assumed to use data meanings that were previously unknown. However, other programs, such as group 13 of the programs in FIG. 1 for example, may be different programs, such as an application, and may have different unknown data arrangements. Group 13 of programs may have other different adapters, such as adapter 27 created in a manner similar to adapter 10 for example.

[0054] In box 31, program information and exchange standard ES are received by discovery manager 15. For example, certain desired healthcare information, such as specific patient information, may be desirable. The program information may be assumed to notify discovery manager 15 of the data meaning (P-DM) contained in program 12 and how to find its location. The program information received by discovery manager 15 may be in the form of, for example, an application programming interface (API), metadata, or data meaning and data location, or may be information received manually for program 12.

[0055] In determination box 32, the discovery manager 15 determines whether any program data meanings (P-DM) can be obtained from program 12. If available, in determination box 34, it is determined whether the available program data meanings (P-DM) of program 12 are equivalent to the corresponding exchange standard data meanings (ES-DM). For example, the program data meanings (P-DM) of program 12 may include "temperature" or "temp" for the body temperature recorded for a given patient. Assuming that at least one of the exchange standard data meanings is "body temperature", then equivalence is determined by the discovery manager 15. Determining equivalence means that program 12 includes program data meanings (P-DM) equivalent to the exchange standard data meanings (ES-DM) such as "body temperature" in this example. This operation may be achieved by processing a comparison or matching function.

[0056] In this example, since it is assumed that the exchange standard data meanings (ES-DM) are not equivalent to the corresponding program data meanings (P-DM) or that the program data meanings are not available, in determination box 38, the discovery manager 15 determines whether the program data (P-DATA) and the exchange standard data (ES-DATA) are available.

[0057] As shown in box 41, since P-DATA and ES-DATA are available, discovery manager 15 may determine whether data program P-DATA is consistent with exchange standard data ES-DATA. The data may be similar to the corresponding ES-DATA, but not necessarily the same. Consistency may be defined in various ways including, but not limited to, similarity, fitness, possibility, or others. When P-DATA is outside the data range described in the exchange standard, the program data may not be consistent. For example, by comparing program data with exchange standard data in the range of physiologically possible body temperatures, the program data "1000" may be determined not to be the "body temperature" of a human patient. Other techniques for checking consistency are described below.

[0058] Assume that P-DATA and ES-DATA are available. Then in decision box 41, program data P-DATA may be determined by discovery manager 15 to be consistent with the corresponding exchange standard data ES-DATA. When they are consistent, then adapter creator 19 may create a transformation for adapter 10.

[0059] As shown in boxes 34 and 36, when program data meaning P-DM is not equivalent to exchange standard data meaning ES-DM, then in stop box 36, discovery manager 15 may determine that no further discovery of this data meaning by discovery manager 15 will be made, other data meanings may be processed, or the entire process may end.

[0060] When discovery manager 15 determines in box 41 that there is no consistency between program data P-DATA and exchange standard data ES-DATA, then as shown in stop box 45, discovery manager 15 may determine that no further discovery of this data meaning by discovery manager 15 will be made, other data meanings may be processed, or the entire process may end.

[0061] The discovery manager 15 may determine in box 34 that the program data meaning P-DM is equivalent to the exchange standard data meaning ES-DM and, in box 38, that the program data P-DATA and the exchange standard data ES-DATA are not available. Then, by an AND function 43 such as an AND gate, or by other techniques such as a software function, the adapter creator 19 may then provide a function conversion for the adapter 10, as shown in box 47. Additionally, as shown in box 41, when the discovery manager 15 determines that the data P-DATA and the data ES-DATA are consistent, an ES data conversion may then be created by the adapter creator 19, except when the program data in the stop box 45 is not consistent with the exchange standard data profile.

[0062] According to various embodiments, by analyzing program data, it is possible to determine whether the program data of the program 12 can be the desired one, even if no arbitrary data meaning is available. Thus, an unknown program such as the program 12 according to an embodiment may be analyzed by its data alone to determine whether the data is the desired one required by the exchange standard ES.

[0063] As shown in Box 47, the adapter creator 19 develops a function data conversion T that is a function of both the exchange standard data structure / format (ES-DSF) and the program data structure / format (P-DSF). This data structure may be related to data units for some applications. For example, if the exchange standard data meaning ES-DM is "body temperature", the ES-DSF may use degrees Celsius as the unit of measure for the exchange standard data, and the P-DSF may be expressed in degrees Fahrenheit. Then the adapter creator 19 may use a conventional conversion formula as at least a part of the conversion T to convert between degrees Celsius and degrees Fahrenheit. A general data conversion may be any mathematical function and / or logical operation.

[0064] The data format (ES-DSF) for the exchange standard may be a binary format, while the program data format (P-DSF) may be represented in ASCII format. For example, the adapter creator 19 may use a conversion formula as a part of the conversion T to convert between binary and ASCII formats.

[0065] As shown in Box 49, the adapter creator 19 also provides data read and data write commands for communication with the program 12.

[0066] Thereafter, as shown in Box 52, the adapter 10 receives the ES data conversion T from the adapter creator 19 at 20 and receives read and write data at 22.

[0067] Referring now to FIG. 4, adapter 10 is described in more detail. Adapter 10 according to a preferred embodiment may include a read group 53 of hyperobjects such as hyperobjects 54 and 56, for example. The read group 53 of hyperobjects receives information from the bidirectional link 11 coupled to program 12 and forms part of the read / write data 22. The read group 53 transmits information to a program data group 58 of hyperobjects such as hyperobject 61 and hyperobject 63, for example. The program data group 58 forms part of the ES data conversion 20 and subsequently transmits the converted data to the bidirectional link 26 and another adapter such as adapter 27, for example. Thus, information may be transmitted from program 12 through the bidirectional link 11 and hyperobject groups 53 and 58 to the bidirectional link 26 coupled to adapter 27.

[0068] In the opposite direction, a program data group 66 of hyperobjects such as hyperobject 68 and hyperobject 71, for example, forms part of the ES data conversion 20 and transmits information from the bidirectional link 26 from adapter 27. Information from the program data group 66 may be transmitted to a write group 55 of hyperobjects such as hyperobject 57 and hyperobject 59, for example, and the write group 55 forms part of the read / write data 22. The read / write data 22 transmits information to the bidirectional link 11 coupled to program 12. Thus, information may be transmitted from adapter 27 through link 26 and hyperobject groups 55 and 66 to the bidirectional link 11 coupled to program 12.

[0069] The group of hyperobjects may be executed under the control of server 65 and may be programmed according to read / write command rules generated according to, for example, an API or similar information of a program such as program 12 for managing communication between adapter 10 and program 12. The rules or algorithms may include complex functional formulas or equations for implementing the rules in a simple expression manner, such as those described in relation to transformation T. Implementations for writing information such as, for example, Structured Query Language (SQL) and others that are more complex as rules are relatively easy. Since the hyperobject framework is well-known, the rules may be dynamically changed relatively quickly and easily for the dynamic updates required in a particular application. Hyperobjects do not contain data. See, for example, U.S. Patent No. 8,386,442, which is hereby incorporated by reference in its entirety.

[0070] Accordingly, program interoperability may be achieved by the use of adapters according to various embodiments, even if those programs may be different and the data arrangements therein have been unknown heretofore. Further, by using an exchange standard, dynamic updates may be achieved simply by updating the exchange standard. By using discovery managers and adapter creators according to various embodiments, adapters may be created and dynamically updated without requiring expensive and time-consuming programming. Such techniques used according to various embodiments enable the handling of large data standards and requirements in modern industries and facilitate flexibility and scaling requirements.

[0071] Here, consider techniques according to various embodiments for determining whether program data P-DATA alone can include desired data specified in the exchange standard data ES-DATA. According to a particular embodiment, a particular data profile may be recognized by the discovery manager 15. Data profiles according to various embodiments may describe unique characteristics of the program data P-DATA, such as, for example, data value ranges for the data itself, data hierarchical structures, statistical distributions of the data, and others. The data profile of the exchange standard ES is preferably a high-quality sample.

[0072] The high-quality sample data curve from the exchange standard ES may be compared with the input data curve from program 12. Various methods may be used to determine the consistency of the two data curves. For example, a cross-correlation method based on the "Two-Sample Kolmogorov-Smirnov Test" algorithm may be used to calculate the consistency of the two data curves.

[0073] FIG. 5 shows an example for illustrative purposes only of a non-limiting description of an exchange standard data profile that can be derived from underlying data. The data diagram 40 shown in FIG. 5 is a one-dimensional histogram forming the data profile. With particular reference to box 41 in FIG. 3, assume that program 12 is a database program for healthcare and that the exchange standard ES is designed to access desired data regarding patients who have undergone a hemoglobin test. The data profile of FIG. 40 in FIG. 5 shows the number of samples tested versus the hemoglobin values for various patient records for defining the fingerprint of the data profile.

[0074] On the X-axis of FIG. 40, test values of hemoglobin test results for various patients are shown. On the Y-axis, the number of hemoglobin samples corresponding to each value identified on the X-axis is listed. The total number of values for the test samples was 715,511. The result is a characteristic curve 40 showing the data distribution pattern. Thus, this pattern is a data profile for the results of hemoglobin clinical tests and may be used as an interchange standard data profile. It should be understood that many different types and kinds of data profiles may exist and be used according to various embodiments. Examples of data profiles may include, without limitation, electrocardiograms (ECGs), images, histograms, and many others. Referring now to FIG. 6, according to a preferred embodiment for step 41 of the method of FIG. 3, a conventional convolutional neural network (CNN) 42 may be used. The CNN may be trained to capture an invariant representation (intrinsic shape) of the data curve. The trained CNN may also be used to calculate a consistency score between two data curves. In the present example of the histogram curve 40 shown in FIG. 6, the CNN is first trained to capture the intrinsic shape of the data curve 40 and, in addition, is trained to calculate a desired consistency score between two curves based on the curve 40 as an interchange standard. Then, both P-DATA and interchange standard ES-DATA from program 12 are fed into the CNN for processing purposes. The result of the consistency determination may be either "yes" or "no" as shown.

[0075] In view of the foregoing drawings and the detailed description of the specific embodiments, it will be apparent to those skilled in the art that the disclosed embodiments and other embodiments relate to novel techniques for achieving program interoperability within and between different programs, despite the fact that a program may have data that has been unknown heretofore. An adapter may be created to assist in achieving the desired interoperability, at least in part, by learning whether the program contains the desired data.

[0076] The method and system according to the embodiments enable a generalized program for programming interoperability. This method and system use an automatic or substantially automatic conversion adapter for using a given exchange standard for two-way communication with a program. Since the adapter uses the exchange standard, the discovery manager may learn the program's data communication structure and / or format, and may also learn the data semantic information from the program. The adapter creator may derive a conversion that converts the program's data communication structure and data semantics into the exchange standard. This conversion may be used by the adapter to achieve interoperability by enabling two-way communication with any adapter and / or program that similarly uses that given exchange standard.

[0077] Although the present invention has been described with reference to the above examples, it will be understood that numerous modifications and variations are expected within the true spirit and scope of the embodiments disclosed herein. Many modifications and other embodiments will occur to those skilled in the art in relation to the present invention, which will have the benefit of the teachings provided in the foregoing description and the accompanying drawings. Accordingly, it is to be understood that the present invention is not limited in any way to the specific embodiments or modifications thereof disclosed herein, and that such modifications and other embodiments are intended and expected to be included within the scope of the appended claims. Specific terms are used herein, but they are used only in a general descriptive sense and not for purposes of limitation.

Claims

1. 1. A method for enabling different programs to automatically or substantially automatically interoperate, comprising: providing a discovery manager; receiving, by the discovery manager, a first program data semantics and corresponding data location for a first program; searching, by the discovery manager, the first program data semantics for data stored in the first program to determine whether the first program data semantics are substantially equivalent to predetermined data semantics of an exchange standard; determining whether data from the received data location of the first program substantially matches corresponding data of the interchange standard; generating a two-way functional data transformation if substantial equivalence or substantial consistency is determined; providing said two-way function data conversion to a first bidirectional exchange standard adapter to enable interoperability between said first program and a second program having a second bidirectional exchange standard adapter; A method comprising:

2. 2. The method of claim 1, wherein the step of receiving, by the discovery manager, a first program data semantics and corresponding data locations for a first program comprises receiving an application programming interface.

3. 2. The method of claim 1, wherein the step of receiving, by the discovery manager, first program data semantics and corresponding data locations for a first program includes receiving metadata from the first program.

4. 2. The method of claim 1, wherein the step of searching, by the discovery manager, the first program data meaning for data stored in the first program to determine whether the first program data meaning is substantially equivalent to a predetermined data meaning of an exchange standard comprises comparing the received first program data meaning with the predetermined data meaning of the exchange standard to determine whether the predetermined data meaning of the exchange standard is substantially equivalent to a corresponding first program data meaning.

5. 2. The method of claim 1, wherein the step of determining whether data from the received data location of the first program substantially matches corresponding data of the exchange standard is performed by determining, via the discovery manager, whether a program data profile exists and whether an exchange standard data profile exists.

6. The method of claim 5 , wherein the discovery manager comprises a convolutional neural network.

7. The method of claim 1 , further comprising generating a communication transport transformation that includes rules for reading and / or writing data.

8. 8. The method of claim 7, wherein the data transformation and the communication transport transformation are assembled by an adapter creator for the bidirectional exchange standard adapter.

9. 2. The method of claim 1, wherein the step of determining whether data from the received data location of the first program substantially matches corresponding data of the interchange standard includes a first program data semantic being equal to an interchange standard data semantic.

10. 2. The method of claim 1, wherein the step of determining whether data from the received data location of the first program substantially matches corresponding data of the exchange standard includes determining whether the first program data falls outside a data range described in the exchange standard.

11. 11. The method of claim 10, wherein the first program data includes one or more of the following unique characteristics: a data value range, a data hierarchical structure, and a statistical distribution of data.

12. 2. The method of claim 1, wherein the step of generating a two-way functional data transformation when substantial equivalence or substantial consistency is determined includes developing a functional data transformation that is a function of both the exchange standard data structures / formats and the program data structures / formats.

13. 1. A method for enabling different programs to automatically or substantially automatically interoperate, comprising: providing a discovery manager; receiving program data semantics and corresponding data locations for a first program; determining whether the program data semantics are substantially equivalent to predetermined data semantics of an interchange standard; determining whether data from the received data location of the first program substantially matches corresponding data of the interchange standard by determining whether program data semantics are equal to interchange standard data semantics; generating a two-way functional data transformation if substantial equivalence or substantial consistency is determined; providing said two-way function data conversion to a first bidirectional exchange standard adapter to enable interoperability between said first program and a second program having a second bidirectional exchange standard adapter; A method comprising:

14. 14. The method of claim 13, wherein the step of receiving, by the discovery manager, first program data semantics and corresponding data locations for a first program includes receiving an application programming interface.

15. 14. The method of claim 13, wherein the step of receiving, by the discovery manager, first program data semantics and corresponding data locations for a first program includes receiving metadata from the first program.

16. 14. The method of claim 13, wherein the step of searching, by the discovery manager, the first program data meaning for data stored in the first program to determine whether the first program data meaning is substantially equivalent to a predetermined data meaning of an exchange standard includes comparing the received first program data meaning with the predetermined data meaning of the exchange standard to determine whether the predetermined data meaning of the exchange standard is substantially equivalent to a corresponding first program data meaning.

17. 14. The method of claim 13, wherein the step of determining whether data from the received data location of the first program substantially matches corresponding data of the exchange standard is performed by determining, via the discovery manager, whether a program data profile exists and whether an exchange standard data profile exists.

18. The method of claim 17 , wherein the discovery manager comprises a convolutional neural network.

19. The method of claim 13 , further comprising generating a communication transport transformation that includes rules for reading and / or writing data.

20. 20. The method of claim 19, wherein the data transformation and the communication transport transformation are assembled by an adapter creator for the exchange standard adapter.

21. 14. The method of claim 13, wherein the step of determining whether data from the received data location of the first program substantially matches corresponding data of the exchange standard includes determining whether first program data falls outside a data range described in the exchange standard.

22. 22. The method of claim 21, wherein the first program data includes one or more of the following unique characteristics: a data value range, a data hierarchical structure, and a statistical distribution of data.

23. 14. The method of claim 13, wherein the step of generating a two-way functional data transformation if substantial equivalence or substantial consistency is determined includes developing a functional data transformation that is a function of both the exchange standard data structures / formats and the program data structures / formats.

24. 1. A system for automatically or substantially automatically facilitating interoperability between first and second distinct programs, comprising: a first bidirectional exchange standard adapter including one or more first hyperobjects each having a first rule, the first rule defining a first data function transformation and a first communication transport transformation, the first data function transformation being a first transformation function for data structures and data formats between a first program and an exchange standard, the first bidirectional exchange standard adapter further including a first communication transport transformation standard for reading data from and writing data to the first program; a second bidirectional exchange standard adapter including one or more second hyperobjects each having second rules, the second rules defining a second data function transformation and a second communication transport transformation, the second data function transformation being a transformation function for data structures and data formats between a second program and the exchange standard, the second bidirectional exchange standard adapter including a second communication transport transformation standard for reading data from and writing data to the second program; a common communications link coupled between the first bidirectional exchange standard adapter and the second bidirectional exchange standard adapter for bidirectionally communicating exchange standard information therebetween; Including, the system.

25. 25. The system of claim 24, wherein the first program includes information in a first language and the second program includes information in a second language different from the first language.

26. 26. The system of claim 25, wherein the second program responds to the first adapter in the second language.

27. 26. The system of claim 25, wherein the exchange standard information communicated over the common communications link includes information in a third language different from the first language and the second language.

28. A bidirectional exchange standard adapter for enabling a given program to interoperate with a different program having another bidirectional exchange standard adapter, one or more hyperobjects containing one or more rules that define a two-way functional transformation; Including, the functional transformation being a data transformation function for a data structure and data format for a given program and exchange standard; the one or more hyperobjects defining rules for reading and writing data for the given program; thereby facilitating intercommunication with the other bidirectional exchange standard adapter, thereby providing interoperability between the given program and the different program. Two-way interchangeable standard adapter.

29. 30. The bidirectional exchange standard adapter of claim 28, wherein said rules include said function transformation, said data reading, and said data writing.

30. 30. The bidirectional exchange standard adapter of claim 28, further comprising a communications link for communication between the adapter and another bidirectional exchange standard adapter for communicating two-way exchange standard information.

31. 30. The bidirectional exchange standard adapter of claim 28, wherein the bidirectional exchange standard adapter includes a reading group of hyperobjects configured to receive information from a first bidirectional link coupled to the given program.

32. 32. The bidirectional exchange standard adapter of claim 31, wherein the read group of a hyperobject conveys information for a first program data group of a hyperobject.

33. 33. The bidirectional exchange standard adapter of claim 32, wherein the program data group forms part of an ES data conversion and conveys the converted data to the bidirectional link and to the other bidirectional exchange standard adapter.

34. 34. The bidirectional exchange standard adapter of claim 33, wherein a second program data group of hyperobjects forms part of said ES data transformation and conveys information from said bidirectional link from said other bidirectional exchange standard adapter.

35. 35. The bidirectional exchange standard adapter of claim 34, wherein information from the second program data group of a hyperobject is communicated to a write group of a hyperobject.

36. 36. The bidirectional exchange standard adapter of claim 35, wherein the write group of hyperobjects and the read group of hyperobjects form read / write data configured to convey the information over the first bidirectional link.

37. 37. The bidirectional exchange standard adapter of claim 36, wherein said group of hyperobjects is executed under the control of a server.

Images