US20210103483A1 - Adaptive application version integration support - Google Patents
Adaptive application version integration support Download PDFInfo
- Publication number
- US20210103483A1 US20210103483A1 US16/592,314 US201916592314A US2021103483A1 US 20210103483 A1 US20210103483 A1 US 20210103483A1 US 201916592314 A US201916592314 A US 201916592314A US 2021103483 A1 US2021103483 A1 US 2021103483A1
- Authority
- US
- United States
- Prior art keywords
- version
- api
- application
- network
- processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000003044 adaptive effect Effects 0.000 title description 12
- 230000010354 integration Effects 0.000 title description 12
- 238000012545 processing Methods 0.000 claims abstract description 68
- 230000009466 transformation Effects 0.000 claims abstract description 48
- 238000000844 transformation Methods 0.000 claims abstract description 30
- 238000000034 method Methods 0.000 claims description 57
- 230000008569 process Effects 0.000 claims description 29
- 230000004044 response Effects 0.000 claims description 26
- 230000001174 ascending effect Effects 0.000 claims description 16
- 238000013507 mapping Methods 0.000 claims description 8
- 238000004891 communication Methods 0.000 description 12
- 230000003993 interaction Effects 0.000 description 12
- 230000008520 organization Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 10
- 230000008859 change Effects 0.000 description 5
- 230000003247 decreasing effect Effects 0.000 description 5
- 238000004519 manufacturing process Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000001131 transforming effect Effects 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 230000000977 initiatory effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 239000010979 ruby Substances 0.000 description 1
- 229910001750 ruby Inorganic materials 0.000 description 1
- 238000013515 script Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/36—Software reuse
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/542—Intercept
Definitions
- API Application Programming Interface
- FIG. 1 is a diagram of a system for adaptive application version integration support, according to an example embodiment.
- FIG. 2 is a diagram of a sample adapter, according to an example embodiment.
- FIG. 3 is a diagram of a method for adaptive application version integration support, according to an example embodiment.
- FIG. 4 is a diagram of another method for adaptive application version integration support, according to an example embodiment.
- FIG. 5 is a diagram of another system for adaptive application version integration support, according to an example embodiment.
- a method for adaptive application version integration support is presented.
- An Application Programming Interface (API) call is intercepted; the API call is initiated by a first application and directed to a second application.
- a first version number associated with the first application is identified and a second version number associated with the second application is identified.
- One or more transformations are processed on the API call based on the first version number and the second version number.
- a second API call is produced based on processing the one or more transformations.
- the second API call is provided to the second application for processing on behalf of the first application.
- FIG. 1 is a diagram of a system 100 for adaptive application version integration support, according to an example embodiment. It is to be noted that the components are shown schematically in greatly simplified form, with only those components relevant to understanding of the embodiments being illustrated.
- the terms “user,” “consumer,” “user,” and “customer” may be used interchangeably and synonymously.
- the terms refer to an individual operating a user-device and interacting with a user-facing interface of a mobile application (app) or interacting with a web-based user interface to access features/functions of a network-based service (which itself may be accessible through a web or browser-based API).
- the system 100 permits multiple different mobile application API versions to be supported simultaneously over network connections by a single network service. This is achieved through adapters that transform interface selections/API calls made from the mobile application API versions into API input expected by the network service before the network service receives the input for processing. Similarly, outputs produced by the network service are transformed by the adapters into API outputs which can be processed by each of the mobile application API versions. In this way, changes made to the source code of the API of the network service are decoupled from the source code of the mobile application API versions and coupled through the version API adapters.
- version refers to the API used by an application with respect to one or more server-based services.
- versions are discussed as being Integer numbers that are sequential, this does not have to be the case as a “version” can be any unique identifier for which there is a mapping that identifies whether the API used in that mobile app matches an API used by the server-based services that provides services to the mobile app.
- the version can be any string that includes a mapping that allows versions of APIs used by the mobile app to be matched to adapters (as discussed herein and below) for purposes of properly interfacing with the production-based released and available network-based services that support the mobile apps.
- versions are referenced as sequential-based Integers that increase by a factor of 1.
- the factor of increase and the unique string associated with the version can be any scheme and is not explicitly limited to the examples presented herein and below.
- whatever scheme is used there is an ordering between versions such ordering can be sequential and numeric or based on a mapping, such as through a mapping table.
- the user-facing version number of the mobile app may be completely different from and disconnected from the mobile app API version with respect to the adapters and the network-based services for the API.
- a user mobile app may have a user-facing version of 1.2 whereas the adapter version is 4, etc.
- the system 100 supports up to X simultaneous mobile app versions, which can be supported (serviced) by a single current-release of a network service or set of network services.
- An organization associated with the network service(s) can set X to any desired prior supported releases of the network service(s).
- System 100 includes a plurality of processing devices and device types 110 - 150 .
- the system 100 includes user-operated devices 110 - 140 and one or more servers 150 .
- Server 150 includes executable instructions that execute on one or more hardware processors 151 of server 150 from a non-transitory computer-readable storage medium 152 as: a version manager 153 , adapters ( 154 - 156 ) and a network-based application (“app”) service(s) production API version 147 (latest supported release of the production services—herein after just “app service 147 ”).
- Each user-operated device 110 - 140 includes its own processor and non-transitory computer-readable storage media.
- the media includes executable instructions, which when executed by the corresponding processors cause to perform processing for the mobile app API versions 111 - 141 .
- servers 150 there may be multiple servers 150 , such that the different elements 153 - 157 may execute on a same server 150 or multiple different servers 150 networked together. Furthermore, multiple servers 150 may be logically cooperating within cloud computing environment and accessible as a single server 150 .
- each element 153 - 157 may simultaneously process within different independent processing environments as duplicated instances of elements 153 - 157 , each processing environment servicing a different set of the user-operated devices 110 - 140 for network interaction.
- a same server 150 may execute different processing environments, such as when the different processing environments are Virtual Machines (VMs) and/or containers. Additionally, at least some of the processing environments may execute on different servers 150 from one another.
- VMs Virtual Machines
- the processing environments may execute on different servers 150 from one another.
- a given mobile app API version 1 111 is initiated on user-operated device #1 110 , this establishes a network connection between user-operated device #1 110 and server 150 .
- the mobile app API version #1 111 reports its version number when connecting to the server 150 and/or reports its version number with each interface call that is initiated from mobile app API version #1 111 .
- the reported API version number by the mobile app API version (hereinafter just “app API version”) is just a serial number or a unique identifier that the mobile app uses to reports its current working API version. Again, there is no correlation between the user-published mobile app version and the reported API version.
- a typical conventional processing workflow between a mobile app and a network service would entail direct interaction between the mobile app and the network service.
- Such typical workflow is altered by the teachings herein, such that interactions or API calls made between app API versions ( 111 , 121 , 131 , and 141 ) and the app service 147 are indirect when a given app API version ( 111 , 121 , 131 , and 141 ) does not correspond to the production version associated with the app service 147 (detectable based on the API version number reported by the mobile apps and the last released version number for the adapters).
- Direct interaction can occur between mobile app API version when the app API version is one version higher than the most-recent released adapter version or stated another way when the current supported and released API version used by the app service 157 matches the reported mobile app API version reported by the mobile app.
- the version manager 153 identifies a variety of metadata with each interaction between any given app version API and the app service 157 .
- metadata includes a mobile app identifier, a mobile app API version number, a last recorded or known adapter version number, a sender identifier (who is initiating the interaction), and a receiver identifier (who is receiving the interaction for response processing).
- the API version number in use by the app service 157 is N and there is no adapter N
- the version manager 153 performs no adapter-based processing and allows any mobile app API version N 141 to directly interact with app service 153
- the APIs calls between app API version N 141 and app service 157 are both compatible and support for session interaction.
- API version supported by app service 157 is 1
- there is no adapter which is an indication to version manager 153 that direct interaction between app API version 1 111 and app service 157 can be direct and proceed for a session without any API adapter.
- a second API version is released, which is now reflected in app service 157 , this results in adapter 1 154 being released (API version is 2) as well as a new mobile app API version 2 121 .
- Version manager 153 detects a call between the initial and first released app API version 1 111 and app service 157 during a session, the current API version is 2 and the initial and first released app API version 1 111 reports version 1 plus there is now adapter 1 154 ; accordingly, version manager 153 applies adapter 1 154 to transform calls made between initial and first released app API version 1 111 and app service 157 .
- version manager 153 allows direct communication with no API call transformations between app API version #2 121 and app service 157 (which is currently using API version 2).
- the version manager 153 determines: whether adapters are needed at all for any given communication between an app API version and app service 157 , how many adapters need to be applied serially for any given communication, and an order (serially ascending or serially descending) based on who is the sender of any given communication.
- the last known adapter version available from the server 150 , the API version associated with a given app API version, the sender, and the receiver are processed by the version manager 153 to determine any adapters that are needed, the number of needed adapters, and the order to apply needed adapters.
- the order (ascending or descending) for processing multiple adapters needed is determined by the version manager 153 based on who is the sender in any given communication. If the sender is the app service 157 , the order is decreasing or descending. If the sender is an app API version, the order is increasing or ascending.
- the starting adapter to apply is determined based on the API version associated with the sender and the API version of the receiver.
- the sender is app API version 2 121
- last recorded adapter is adapter 3, which is adapter N ⁇ 1 156 when N is 4.
- Version manager 153 intercepts an API call made by app API version 2 121 directed to app service 157 , identifies app API version 2 121 as the sender and determines that the order to apply the adapters is ascending.
- the last known of available adapter is adapter 3 (in this example adapter N ⁇ 1 156 ).
- the starting adapter is the adapter that matches app API version 2 121 , which is adapter 2 155 and the number of adapters to apply is just 2 because the last known adapter is adapter 3 (N ⁇ 1 156 ).
- the original API call sent from app API version 2 121 is processed by adapter 2 155 to produce a transformed or modify API call as a first output; the first output is provided as input to adapter 3 (N ⁇ 1 156 ) resulting in second output for the original API call.
- App service 157 generates first response data and sends to app API version 2 121 .
- Version manager 153 intercepts, identifies the sender as app service 157 and the recipient as app API version 2 121 .
- the adapter order processing is determined to be descending and since the sender is the app service 157 , the starting adapter is always the last available adapter, which is adapter 3 (N ⁇ 1 156 ).
- the first response data is processed by adapter 3 (N ⁇ 1 156 ) to produce transformed second response data, the second response data is provided as input to adapter 2 155 to produced third response data.
- the third response data is provided as response data recognized and capable of being processed by app API version 2 121 (for a version 2 of the API).
- the version manager 153 supplies the sender's API call as input to a starting adapter (determined as discussed above), if multiple adapters are needed, the version manager 153 provides output produced by the starting adapter as input to the next adapter. The continues until the ending adapter produces a final modification on the original API call. The final modification is provided as a request or a response to the receiver and the final modification corresponds to an API version supported by the receiver.
- the version manager 153 knows that no adapter is needed when there is no adapter matching an API version number of the app API version.
- the API version number of the app API version maps to a starting version number for any needed adapter (when the app API version is the sender in a communication with the app service 153 ). In this way, when the API version of the app API version is 1 greater than the last-released adapter (app API version N 141 ), then that app API version N 141 requires no adapter-based processing and is assumed to match the version number of the app service 157 (this is illustrated in FIG. 1 because the last adapter is adapter N ⁇ 1 156 ), such that the app service 157 is also at version N in this example matching app API version N 141 . In this way, the API version that is current supported by app service 157 has no adapter matching that API version, such that the most-recently released app API version that works with the supported API version is always 1 greater than the last known adapter.
- a communication session is established.
- Each session is managed separately/independently from other connections associated with other app API versions ( 121 , 131 , and 141 ).
- Each session is assigned a corresponding known version number associated with the corresponding connected app API version ( 111 , 121 , 131 , or 141 ).
- the version number is maintained as metadata associated with the corresponding session.
- the version manager 153 intercepts API calls made from a given app API version 1 111 during a corresponding session to the app service 157 . Similarly, the version manager 153 intercepts API calls made from the app service 157 during the corresponding session to the given app API version 1 111 .
- Each API call includes metadata or an identifier that uniquely identifies that API call (command), a sender identifier, a receiver identifier, and a session identifier. At least one of the sender identifier or the receiver identifier will be associated with the app service 157 , and the remaining identifier associated with the given app API version 1 111 for the corresponding session.
- Each API call may also include an associated packet payload having data or information needed or used by that API call (the data or information can include links, processing parameters/options, image data, graphical data, video data, audio data, text data, or various combinations of these types of data or information).
- the version manager 153 obtains the app API version number along with the sender identifier, the receiver identifier, the API call identifier, and any packet payload.
- the API version number informs the version manager 153 , which adapter ( 154 - 156 ) needs to be processed for that API call before delivering to the receiver, and the API version number informs version manager 153 how many adapters have to be processed/transformed before delivering the API call and any packet payload to the corresponding receiver during the corresponding session.
- Each adapter ( 154 - 156 ) includes marked-up transformations/instructions that are specific to a given API version and transforming API calls and any expected packet payload to a next version (ascending and descending). These transformations are instructions that are processed by version manager 153 to ensure any given API call and any expected packet payload are recognized and expected by the receiver, such that the receiver is able to properly process the given sender-provided API call and any given sender-provided packet payload.
- a given transformation/instruction statement within a given adapter 1 154 may include a matching API call identifier (label) based on the sender and a replacement API call identifier (label) recognized by the receiver that corresponds or maps to the sender's API call identifier.
- a given transformation/instruction statement may also include a series of sub-transformation/instruction statements and/or calls to transformation routines.
- Version manager 153 may subtract the current version number N associated with the app service 157 (current released and supported version of app service 157 available on server 150 ) from a given version number of a given session (associated with app API version 1 111 , 2 121 , or 3 131 ). The result of the subtraction identifies how many adapters ( 154 - 156 ) have to be processed on the given API call before the resulting transformations can be delivered to the receiver as input or response data for the receiver to process. Version manager 153 determines the order in which the determined number of adapters ( 154 - 156 ) are to be sequentially processed based on the sender identifier.
- the order is increasing or ascending.
- the sender identifier is associated with app service 157 , the order is decreasing or descending.
- the starting adapter ( 154 , 155 , or 156 ) is always adapter N ⁇ 1 156 when the sender is the app service 157 (order is descending).
- the starting adapter ( 154 , 155 , or 156 ) when the sender is one of the app API versions ( 111 , 121 , or 131 ) is the adapter ( 154 , 155 , or 156 ) that corresponds to the version of the sending app API version ( 111 , 121 , or 131 ).
- adapter 1 154 is the starting adapter
- adapter 2 155 is the starting adapter
- the API version number of a sending app API version determines the starting adapter ( 154 , 155 , and 156 ) that is first processed by the version manager 153 for a given API call and any given packet payload.
- the version manager 153 determines how many additional adapters ( 155 and/or 156 ) need to be processed before the transformed API call and any packet payload are provided to app service 157 for processing. The order is determined as ascending because the sender was a mobile app version ( 111 , 121 , or 131 ).
- the sender is the app service 157
- the order is descending
- the first adapter processed by the version manager 153 is always adapter N ⁇ 1 156 (assuming the receiver is not app API version N 141 in which case as explained above no adapter is processed by version manager 153 ).
- the last adapter processed in a descending order from N ⁇ 1 is the adapter that corresponds to the receiving app API version ( 111 , 121 , or 131 ).
- FIG. 1 depicts 3 mobile app versions ( 111 , 121 , 131 , and 141 ), which is done for illustration, as there can be just two mobile app versions ( 111 and 141 (where N is 2)) or there can be up to a configurable number (X) app API versions ( 111 , 121 , 131 and continuing for a configurable number of additional iterations to 141 ).
- adapter N ⁇ 1 146 implies that N is at least 5 or more (given the diagram depicted in FIG. 1 ). Again, this does not have to be the case as there can be just one adapter 156 corresponding to app version 1 111 , such that N is 2 and adapter N 156 is adapter 1 154 .
- version manager 153 does not invoke and does not process any adapter 154 - 156 when the app API version N 141 is engaged in a network session with the app service 157 (since the API version numbers match, there is no adapter N on server 150 , and there is no disparity in the API calls between the two during the session).
- Each adapter 154 - 156 includes transformations/instructions for making API calls from one version compatible a next version to process (both ascending and descending based on the sender). So, adapter 1 154 produces (when processed by the version manager 153 ) transformations that transform input being sent by app API version 1 111 during a session to expected corresponding input that can be processed by an API version 2 of the app service 157 . Moreover, adapter 1 154 produces (when processed by version manager 153 ) transformations that transform output being sent by an API version 2 of the app service 157 into expected corresponding output expected by app API version 1 111 .
- the version manager 153 sequentially processes transformation outputs from one adapter ( 154 , 155 , or 156 ) and provides those outputs as input to a next adapter ( 154 , 155 , or 156 ) until the version number of the last adapter processed matches a version number associated with the receiver.
- the sequential order is determined based on who the sender is for any given API call being processed.
- the sender is app API version ( 111 , 121 , or 131 ) the order of applying any needed adapters ( 154 , 155 , and/or 156 ) is ascending, when the sender is the app service 157 the order of applying the needed adapters ( 156 , 155 , and/or 154 ) is descending.
- a user operating device #1 110 selects from a user-facing interface of app API version 1 111 option X during a network session with app service 157 .
- Version manager 153 is activated on server 150 upon initiation of the session.
- the session version number is set to 1 based on mobile app version 1 111 .
- the current support API version for app service 157 is detectable as 3 based on the last adapter on the server being adapter 2 155 by adding 1, since the current API version support is 1 more than the last available adapter on the server 150 .
- Option X is intercepted as an API call.
- Version manager 153 subtracts API version 1 from API version 4 (version of app service 157 ) resulting in 2, which indicates the number of adapters that need processed before the API call can be delivered to the app service 157 for processing during the session.
- the version number of app API version 1 111 is the number 1, which maps to adapter 1 154 .
- the sender identifier is app API version 1 111 , so the order is ascending.
- Version manager 143 obtains the transformation instructions from adapter 1 154 and processes them to obtain output A.
- Version manager 153 obtains the transformation instructions for adapter 2 155 and applies them on output A to obtain output B.
- Output B is provided as input B to app service 157 in place of option X.
- App service 157 produces a response Y to input B.
- Version manager 153 intercepts Y and obtains reverse transformations instructions from adapter 2 155 to obtain output D. Version manager 153 obtains reverse transformation instructions from adapter 1 154 to obtain output E. Output E is provided as response data to app API version 1 111 based on initial user selection of option X.
- FIG. 2 shows example syntax and semantics associated with an example adapter ( 154 , 155 , or 156 ), according to an example embodiment. It is to be noted that other syntax and semantics may be used that are different from that which is shown for illustration in the FIG. 2 .
- an API endpoint is renamed when issued from one app API version ( 111 , 121 , or 131 ) to make that API call compatible with a next API version (sender is “app”).
- the redirection is actually a path location to the API endpoint on server 150 , such that results from processing the sample adapter is a call to a different path location on server 140 (location2) to a replacement API endpoint.
- the adapter shown in FIG. 2 also replaces a response string sent as a response from the app service 157 to a given app API version ( 111 , 121 , or 131 ) from “success” to “1.”
- the given app API version ( 111 , 121 , or 131 ) knows how to handle and process a “1” response string as an indication of success but is unable to handle and process a “success” response string.
- Version N of the app service 157 produces the “success” response string
- the version manager 153 processes the corresponding adapter N ⁇ 1 156 resulting in a “1” response string being provided back to the given app API version ( 111 , 121 , and 131 ).
- the adapters 154 , 155 , and 156 provide a mechanism by which compatibility issues between existing app API versions ( 111 , 121 , and 131 ) can be isolated in small easy to manage files, such as the file shown in the FIG. 2 .
- Each file includes instructions that are interpreted by the version manager 153 at runtime to move an API call to a next version of the API call (current version+1 forward) or move the API call to a previous version of the API call (current version ⁇ 1 backward).
- Output from one adapter for processing a given API call can be provided as input to a next adapter to move the original API call to a compatible format that spans more than 1 API version.
- the adapters can be chained together in this manner for up to a configurable number (X) of previous versions associated with the app service 157 .
- the version manager 153 can prompt the app API version to force an update to a newer version of the app API version.
- This number X is configurable and can be increased or decreased based on the needs of the organization providing the app service 157 .
- the adapters 154 - 156 are files representing programming instructions that are capable of being opened, read, and interrupted in real-time by the version manager 153 .
- the files are Ruby files.
- the adapters 154 - 156 are executable scripts passed the API call, sender identifier, receiver identifier, and any packet payload as parameters by the version manager 153 .
- the adapters 154 - 156 are eXtensible Markup Language (XML) files.
- the adapters 154 - 156 are customized markup language files having a proprietary syntax and statements.
- the user-operated devices 110 , 120 , 130 , and 140 can include: phones, tablets, wearable processing devices, and/or intelligent appliances that are part of the Internet-of-Things (IoTs).
- IoTs Internet-of-Things
- the app service 157 is an insurance service provided by an insurance company to subscribers and potential subscribers.
- app API version ( 111 , 121 , 131 , and 141 ) as described above can be web-based or browser-based user interfaces/applications that interact with the app service 157 in the manners discussed hereinabove and below.
- app service 157 may be web-based or browser-based.
- FIG. 3 is a diagram of a method 300 for adaptive application version integration support, according to an example embodiment.
- the software module(s) that implements the method 300 is referred to as a “version manager.”
- the version manager is implemented as executable instructions programmed and residing within memory and/or a non-transitory computer-readable (processor-readable) storage medium and executed by one or more processors of a device.
- the processor(s) of the device that executes the version manager are specifically configured and programmed to process the version manager.
- the version manager may have access to one or more network connections during its processing.
- the network connections can be wired, wireless, or a combination of wired and wireless.
- the device that executes the version manager is the server 150 .
- the server 150 is a cloud-based processing environment comprising a collection of physical servers cooperating as a single logical server.
- the server 150 is a Local-Area Network (LAN)-based server or a Wide-Area Network (WAN)-based server.
- LAN Local-Area Network
- WAN Wide-Area Network
- the version manager is all or some combination of the version manager 153 , the adapters 154 - 156 , and/or the network-based app service version N 157 .
- the version manager intercepts an API call sent from a first application to a second application.
- the first and second application are connected for a communication session with one another over a network connection.
- the version manager is interposed between the first and second application.
- the version manager is initiated upon establishment of the session between the first and second applications and is transparently part of the session.
- the version manager identifies a first version number associated with the first application and a second version number associated with the second application. That is both applications include an identifier and/or metadata that permits the release or API version number for software associated with the applications to be identified by the version manager. This can be done in a variety of manners as discussed above. For example, unique identifiers for the applications can be used to look up the API version numbers, or each communication includes metadata that identifies the release or API version number.
- the version manager processes one or more transformations based on the first version number and the second version number.
- first version number is equal to the second version number
- the processing is bypassed and the first and second application communicate directly with one another during the session.
- the transformations (when the version numbers are not equal to one another) change or modify API calls issued from one of the applications (sending application) into other API calls that are recognized and processed, during the session, by the other application (receiving application).
- the version manager determines an order for the transformations based on the first application and the first version number.
- the version manager determines the order as being an increasing or ascending order when the first version number is less than the second version number. This is an indication that the first application is a app API version ( 111 , 121 , 131 , or 141 ) that is sending an API call during the session to a second application that is an app service 157 , where the version of the first application is not currently up-to-date with the version of the second application (first version number of the first application is less than the second version number of the second application).
- the version manager determines the order as being a decreasing of descending order when the first version number is greater than the second version number. This is an indication that the first application is an app service 157 that is sending an API call during the session to a second application that is an app API version ( 111 , 121 , 131 or 141 ), where the version of the second application is not currently up-to-date with the version of the first application (first version number of the first application is greater than the second version number of the second application).
- the version manager determines a total number of the transformations that are needed as an absolute value of the difference between the second version number and the first version number.
- the version manager produces a second API call based on output produced from processing the transformations at 330 .
- the version manager passes output produced for the API call by a starting transformation as input to a next transformation for the total number of transformations in the order; this produces the second API call as a final output from a last processed transformation. That is, the transformations are chained together and processed sequentially for the total number of needed transformations in the order (ascending or descending) for making the final output on the API call match a receiving application.
- the version manager produces the second API call in a higher version number format than the first version number associated with the first application when the first version number is lower than the second version number.
- the first application is an app API version ( 111 , 121 , 131 , 141 ) having a version number that is less than the receiving second application (which is the app service 157 ).
- the first application is the sending application during the session and the second application is the receiving application.
- the version manager produces the second API call in a lower version number format than the first version number associated with the first application when the first version number is higher than the second version number associated with the second application.
- the first application is the app service 157 that is making an API call to a second application that is an app API version ( 111 , 121 , 131 , or 141 ). Again, the first application is the second application during the session and the second application is the receiving application.
- the version manager provides the transformed second API call to the second application for processing on behalf of the first application.
- the second API call is recognized and processed by the second application during the session.
- the processing 310 - 350 may be iterated during the session between the first application and the second application for all API calls made between the first and second applications. This makes incompatible application versions (seamlessly compatible).
- the version manager intercepts a response sent from the second application to the first application.
- the second application produces the response based on processing the second API call.
- the version manager then processes the transformations (this time in a different order from what was done at 330 ) based on the first version number and the second version number.
- the version manager produces a second response based on the final output of the transformations, and the version manager provides the second response to the first application for processing on behalf of the second application.
- each adapter provides forward and backward (reverse) transformations on an API call in a first version X to a second version X+1 (forward) and/or a third version X ⁇ 1 (reverse).
- a transformation can: replace an API call with a new API call or a new set of API calls (second API call); change a format of the API call to a new format (represented by the second API call); ignore an API call with now action; change codes between the API call with the second API call; and/or change text, links, images, graphics, audio, video between the API call and the second API call.
- the difference between the first version number and the second version number can be up to a configurable number X. So, the first application and the second application can differ from one another by up to X released versions.
- FIG. 4 is a diagram of another method 400 for adaptive application version integration support, according to an example embodiment.
- the software module(s) that implements the method 400 is referred to as a “version compatibility manager.”
- the version compatibility manager is implemented as executable instructions programmed and residing within memory and/or a non-transitory computer-readable (processor-readable) storage medium and executed by one or more processors of a device.
- the processors that execute the version compatibility manager are specifically configured and programmed to process the version compatibility manager.
- the version compatibility manager may have access to one or more network connections during its processing.
- the network connections can be wired, wireless, or a combination of wired and wireless.
- the device that execute the version compatibility manager is the server 150 .
- the server 150 is a cloud processing environment, a LAN server, or a WAN server.
- the version compatibility manager is all of, or some combination of: version manager 153 , adapters 154 - 156 , and/or the method 300 .
- the version compatibility manager presents another and, in some ways, enhanced processing perspective of the method 300 .
- the version compatibility manager intercepts API calls made between a mobile application (app—such as app API versions 111 , 121 , or 131 ) and a network-based service (service—such as app service 157 ) during a network communication session between the and the service.
- apps such as app API versions 111 , 121 , or 131
- service such as app service 157
- the version compatibility manager may be initiated when a successful session is established between the app and the service (such as upon detection of a successful login by app to the service).
- the version compatibility manager allows the session to continue with no compatibility processing, since in this scenario the app and the service are known to be compatible with one another, such that direct communication between the app and the service occurs during the session.
- the version compatibility manager is engaged and performs the processing 410 - 430 as discussed herein.
- the version compatibility manager processes adapters (such as adapters ( 154 , 155 , and/or 156 ) that transform the API calls between an application version supported by the app and a service version supported by the service.
- adapters such as adapters ( 154 , 155 , and/or 156 ) that transform the API calls between an application version supported by the app and a service version supported by the service.
- the version compatibility manager processes the adapters in an ascending (increasing) order for app-initiated API calls made by the app to the service during the session.
- the sender of any given API call is the app.
- the version compatibility manager processes the adapters in a descending (decreasing) order for service-initiated API calls made by the service to the app during the session.
- the sender of any given API call is the service.
- the version compatibility manager identifies a starting adapter from the adapters based on whether the APP is a sender of a given API call or whether the service is the sender of the given API call.
- the starting adapter is the service version number minus 1.
- the starting adapter matches the app version number.
- the version compatibility manager identifies an ending adapter from the adapters based on whether the app is a receiver of a given API call or whether the service is the receiver of the given API call.
- the ending adapter is the service version number minus 1.
- the ending adapter matches the app version number.
- the version compatibility manager obtains the adapters as files.
- Each file including instructions for mapping or transforming API calls back and forth between a first version (V+1) and a second version (V ⁇ 1) associated with the service.
- the version compatibility manager dynamically loads the files and processes the instructions (interprets the software instructions defined in the files and processes them).
- the version compatibility manager sequentially processes each API call through the adapters beginning at a starting adapter with output produced by each processed adapter for the processed API call passed as input to a next adapter.
- the adapters are chained together.
- the version compatibility manager provides transformed API calls to the app and the service based on the processing of 420 during the session.
- the service version number is up to 10 versions higher than the app version number.
- the version compatibility manager simultaneously supports multiple different mobile apps, where the mobile apps comprise a plurality of different version numbers, some of which are the same as the service version number and some of which are different from the service version number and the mobile app version number.
- FIG. 5 is a diagram of another system 500 for adaptive application version integration support, according to an example embodiment.
- the system 500 includes a variety of hardware components and software components.
- the software components of the system 500 are programmed and reside within memory and/or a non-transitory computer-readable medium and execute on one or more processors of the system 500 .
- the system 500 communicates over one or more networks, which can be wired, wireless, or a combination of wired and wireless.
- system 500 implements, inter alia, the processing described above with the FIGS. 1-4 .
- the system 500 includes: a cloud processing environment 510 comprising processors 511 and non-transitory computer-readable storage media 512 .
- the media 512 comprising executable instructions representing a version manager 513 and a network-based service 514 .
- the system 500 interacts with a plurality of mobile applications 521 , each mobile application (app) executing as executable instructions from non-transitory computer-readable storage media by a processor of a mobile device 520 .
- the mobile app 521 associated with a release or version number that does not match a release or version number associated with the network-based service 514 .
- the version manager 513 is all or some combination of: version manager 153 , adapters 154 - 156 , the method 200 , and/or the method 300 .
- the network-based service 514 is the app service 157 .
- the mobile apps are app API versions 111 , 121 , 131 , and 141 .
- the network-based service 514 when executed by at least one of the processors 511 from the non-transitory computer-readable storage media 512 cause the at least one processor 511 to: 1) interact with a mobile app 521 that executes on the mobile device 520 using API calls associated with a released version of the network-based service 514 ; and 2) provided one or more services to the mobile app 521 through the API calls.
- the version manager 513 when executed by at least one of the processors 511 from the non-transitory computer-readable storage media 512 cause the at least one processor 511 to: 1) intercept mobile-app API calls associated with a different version of the network-based service 514 before the network-based service 514 obtains the mobile-application API calls; 2) intercept network-based service API calls provided by the network-based service 514 before the mobile application 521 obtains the network-based service API calls; 3) process adapters that make the mobile-application API calls compliant with the released version of the network-based service 514 and supply compliant mobile-application API calls to the network-based service 514 for processing and providing the one or more services; and 4) process the adapters that make the network-based service API calls compliant with the different version of the network-based service 514 and supply compliant network-based service API calls to the mobile application 521 .
- the adapters are the adapters 154 , 155 , and/or 156 .
- the adapters are in a syntax and semantics as what was illustrated in the FIG. 2 .
- each adapter is a file that comprises instructions for mapping the network-based service API calls and the mobile-application API calls between two versions associated with the network-based service 514 .
- each adapter includes instructions for transforming API calls from a mobile-app API version to V+1 (forward transformation) and V ⁇ 1 (reverse or backward transformation).
- the adapters are chained together and processed by the version manager 513 . For example, if the mobile app API version number is 1 and the network-based service API version number is 4.
- the version manager 513 processes adapters 1 to get to version 2, adapter 2 to get to version 3, and adapter 3 to get to version 4 when the sender is the mobile application 521 .
- the version manager 513 processes adapter 3 to get to version 3, adapter 2 to get to version 2, and adapter 1 to get to version 1.
- the version manager 513 when executed by the at least one processor 511 from the non-transitory computer-readable storage medium 512 further causes the at least one processor to 511 : dynamically interpret and process each file's instructions when processing each adapter.
- modules are illustrated as separate modules, but may be implemented as homogenous code, as individual components, some, but not all of these modules may be combined, or the functions may be implemented in software structured in any other convenient manner.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
Description
- Software engineers have traditionally been limited in the types of updates that can be made to the interface (Application Programming Interface (API)) between a mobile application and a server service that interacts with the mobile application. Solutions that increase the flexibility in making API updates also increase code complexities associated with the API and become increasingly more time consuming to support.
- Often times, a software engineer must consider all previous versions of the API that are in existence in order to properly develop updates for each of the versions, which may be necessary when changes are being made to the server service. If many versions of the API exists, the software development becomes virtually impossible to practically achieve in any reasonable time frame. As a result, much-needed changes to fix known problems and/or to add functionality to the server service (and/or API) are either delayed or scrapped and not released at all.
- As an organization grows its user base, performance issues and logic problems associated with the organization's network services become more apparent. The growing user base may also begin demanding enhancements to support additional functionality. As the software engineers work to develop and release new versions of the network services to satisfy user concerns/needs, other changes/enhancements detected are queued up for future releases of the network services. Because changes to the network services will often require changes to the API, the organization must continually force the user base to update their mobile applications, and very quickly the API code becomes untoward and difficult or far too complex to change with each additional release. As a result, enhancements and/or bug/performance fixes to the network services are scrapped or substantially delayed by the organization. The organization may then begin to experience a reduction in users as the users move to a competitor or scrap using the associated network services altogether.
-
FIG. 1 is a diagram of a system for adaptive application version integration support, according to an example embodiment. -
FIG. 2 is a diagram of a sample adapter, according to an example embodiment. -
FIG. 3 is a diagram of a method for adaptive application version integration support, according to an example embodiment. -
FIG. 4 is a diagram of another method for adaptive application version integration support, according to an example embodiment. -
FIG. 5 is a diagram of another system for adaptive application version integration support, according to an example embodiment. - In various embodiments, methods and a system for adaptive application version integration support are provided.
- According to one aspect, a method for adaptive application version integration support is presented. An Application Programming Interface (API) call is intercepted; the API call is initiated by a first application and directed to a second application. A first version number associated with the first application is identified and a second version number associated with the second application is identified. One or more transformations are processed on the API call based on the first version number and the second version number. A second API call is produced based on processing the one or more transformations. The second API call is provided to the second application for processing on behalf of the first application.
-
FIG. 1 is a diagram of asystem 100 for adaptive application version integration support, according to an example embodiment. It is to be noted that the components are shown schematically in greatly simplified form, with only those components relevant to understanding of the embodiments being illustrated. - Furthermore, the various components (that are identified in the
FIG. 1 ) are illustrated and the arrangement of the components is presented for purposes of illustration only. It is to be noted that other arrangements with more or with less components are possible without departing from the teachings of adaptive application version integration support, presented herein and below. - As used herein and below, the terms “user,” “consumer,” “user,” and “customer” may be used interchangeably and synonymously. The terms refer to an individual operating a user-device and interacting with a user-facing interface of a mobile application (app) or interacting with a web-based user interface to access features/functions of a network-based service (which itself may be accessible through a web or browser-based API).
- As will be discussed in detail below, the
system 100 permits multiple different mobile application API versions to be supported simultaneously over network connections by a single network service. This is achieved through adapters that transform interface selections/API calls made from the mobile application API versions into API input expected by the network service before the network service receives the input for processing. Similarly, outputs produced by the network service are transformed by the adapters into API outputs which can be processed by each of the mobile application API versions. In this way, changes made to the source code of the API of the network service are decoupled from the source code of the mobile application API versions and coupled through the version API adapters. This allows an organization to isolate API (interface) code changes needed by the mobile app API versions when updates are made to the network service within manageable adapter files, each adapter file corresponding to a specific known mobile app API version being used by customers of the organization when accessing the organization's network service(s). - It is to be noted that use of the word “version” refers to the API used by an application with respect to one or more server-based services. Moreover, although versions are discussed as being Integer numbers that are sequential, this does not have to be the case as a “version” can be any unique identifier for which there is a mapping that identifies whether the API used in that mobile app matches an API used by the server-based services that provides services to the mobile app. In this way, the version can be any string that includes a mapping that allows versions of APIs used by the mobile app to be matched to adapters (as discussed herein and below) for purposes of properly interfacing with the production-based released and available network-based services that support the mobile apps. For purposes of discussion and comprehension herein, versions are referenced as sequential-based Integers that increase by a factor of 1. Again, the factor of increase and the unique string associated with the version can be any scheme and is not explicitly limited to the examples presented herein and below. However, whatever scheme is used there is an ordering between versions, such ordering can be sequential and numeric or based on a mapping, such as through a mapping table.
- Moreover, the user-facing version number of the mobile app may be completely different from and disconnected from the mobile app API version with respect to the adapters and the network-based services for the API. For example, a user mobile app may have a user-facing version of 1.2 whereas the adapter version is 4, etc.
- In an embodiment, the
system 100 supports up to X simultaneous mobile app versions, which can be supported (serviced) by a single current-release of a network service or set of network services. An organization associated with the network service(s) can set X to any desired prior supported releases of the network service(s). -
System 100 includes a plurality of processing devices and device types 110-150. Thesystem 100 includes user-operated devices 110-140 and one ormore servers 150.Server 150 includes executable instructions that execute on one ormore hardware processors 151 ofserver 150 from a non-transitory computer-readable storage medium 152 as: aversion manager 153, adapters (154-156) and a network-based application (“app”) service(s) production API version 147 (latest supported release of the production services—herein after just “app service 147”). - Each user-operated device 110-140 includes its own processor and non-transitory computer-readable storage media. The media includes executable instructions, which when executed by the corresponding processors cause to perform processing for the mobile app API versions 111-141.
- It is to be noted that there may be
multiple servers 150, such that the different elements 153-157 may execute on asame server 150 or multipledifferent servers 150 networked together. Furthermore,multiple servers 150 may be logically cooperating within cloud computing environment and accessible as asingle server 150. - Additionally, each element 153-157 may simultaneously process within different independent processing environments as duplicated instances of elements 153-157, each processing environment servicing a different set of the user-operated devices 110-140 for network interaction. A
same server 150 may execute different processing environments, such as when the different processing environments are Virtual Machines (VMs) and/or containers. Additionally, at least some of the processing environments may execute ondifferent servers 150 from one another. - During operation of the
system 100, a given mobileapp API version 1 111 is initiated on user-operateddevice # 1 110, this establishes a network connection between user-operateddevice # 1 110 andserver 150. The mobile appAPI version # 1 111 reports its version number when connecting to theserver 150 and/or reports its version number with each interface call that is initiated from mobile appAPI version # 1 111. - The reported API version number by the mobile app API version (hereinafter just “app API version”) is just a serial number or a unique identifier that the mobile app uses to reports its current working API version. Again, there is no correlation between the user-published mobile app version and the reported API version.
- A typical conventional processing workflow between a mobile app and a network service would entail direct interaction between the mobile app and the network service. Such typical workflow is altered by the teachings herein, such that interactions or API calls made between app API versions (111, 121, 131, and 141) and the app service 147 are indirect when a given app API version (111, 121, 131, and 141) does not correspond to the production version associated with the app service 147 (detectable based on the API version number reported by the mobile apps and the last released version number for the adapters). Direct interaction can occur between mobile app API version when the app API version is one version higher than the most-recent released adapter version or stated another way when the current supported and released API version used by the
app service 157 matches the reported mobile app API version reported by the mobile app. - The
version manager 153 identifies a variety of metadata with each interaction between any given app version API and theapp service 157. Such metadata includes a mobile app identifier, a mobile app API version number, a last recorded or known adapter version number, a sender identifier (who is initiating the interaction), and a receiver identifier (who is receiving the interaction for response processing). When the API version number in use by theapp service 157 is N and there is no adapter N, theversion manager 153 performs no adapter-based processing and allows any mobile app API version N 141 to directly interact withapp service 153, the APIs calls between app API version N 141 andapp service 157 are both compatible and support for session interaction. - So, assuming the
current app service 157 supports API version N, there would be no adapter N and mobile app API version #N 141 would have direction interaction withapp service 157. If the app API version lacks a corresponding matching identifier associated with any available adapter, then this is an indication to the version manager 153 (based on the lack of any matching adapter identifier for the API version in the adapters) that direct communication, without applying any adapters, can occur. In a similar manner, if thecurrent app service 157 is on API version indicated by a presence of adapter (not shown inFIG. 1 ), then mobile app API version #N 141 would indirectly communicate withapp service 157 through adapter N usingversion manager 153. - Initially, a very first
app API version 1 111 is released (API version supported byapp service 157 is 1), there is no adapter, which is an indication toversion manager 153 that direct interaction betweenapp API version 1 111 andapp service 157 can be direct and proceed for a session without any API adapter. Now, assume that a second API version is released, which is now reflected inapp service 157, this results inadapter 1 154 being released (API version is 2) as well as a new mobileapp API version 2 121.Version manager 153 detects a call between the initial and first releasedapp API version 1 111 andapp service 157 during a session, the current API version is 2 and the initial and first releasedapp API version 1 111reports version 1 plus there is nowadapter 1 154; accordingly,version manager 153 appliesadapter 1 154 to transform calls made between initial and first releasedapp API version 1 111 andapp service 157. This makes theAPI version 1 being used and processed by the initial and first releasedapp API version 1 111 compatible with and supported by app service 157 (which is using API version 2). In this scenario, because the current API version is 2 (V=2),version manager 153 allows direct communication with no API call transformations between appAPI version # 2 121 and app service 157 (which is currently using API version 2). - The
version manager 153 determines: whether adapters are needed at all for any given communication between an app API version andapp service 157, how many adapters need to be applied serially for any given communication, and an order (serially ascending or serially descending) based on who is the sender of any given communication. - The last known adapter version available from the
server 150, the API version associated with a given app API version, the sender, and the receiver are processed by theversion manager 153 to determine any adapters that are needed, the number of needed adapters, and the order to apply needed adapters. - The order (ascending or descending) for processing multiple adapters needed is determined by the
version manager 153 based on who is the sender in any given communication. If the sender is theapp service 157, the order is decreasing or descending. If the sender is an app API version, the order is increasing or ascending. The starting adapter to apply is determined based on the API version associated with the sender and the API version of the receiver. - For example, assume the current API version supported by
app service 157 is N=4, the sender isapp API version 2 121, and last recorded adapter isadapter 3, which is adapter N−1 156 when N is 4.Version manager 153 intercepts an API call made byapp API version 2 121 directed toapp service 157, identifiesapp API version 2 121 as the sender and determines that the order to apply the adapters is ascending. The last known of available adapter is adapter 3 (in this example adapter N−1 156). The starting adapter is the adapter that matchesapp API version 2 121, which isadapter 2 155 and the number of adapters to apply is just 2 because the last known adapter is adapter 3 (N−1 156). The original API call sent fromapp API version 2 121 is processed byadapter 2 155 to produce a transformed or modify API call as a first output; the first output is provided as input to adapter 3 (N−1 156) resulting in second output for the original API call. The second output is provided toapp service 157 and recognized as a valid API call for API version 4 (N=4 in the example).App service 157 generates first response data and sends toapp API version 2 121.Version manager 153 intercepts, identifies the sender asapp service 157 and the recipient asapp API version 2 121. The adapter order processing is determined to be descending and since the sender is theapp service 157, the starting adapter is always the last available adapter, which is adapter 3 (N−1 156). The first response data is processed by adapter 3 (N−1 156) to produce transformed second response data, the second response data is provided as input toadapter 2 155 to produced third response data. The third response data is provided as response data recognized and capable of being processed byapp API version 2 121 (for aversion 2 of the API). - These examples can continue, such that as any new API version is released (version N) and reflected in the app service 157 a new corresponding adapter N−1 156 is added on
server 150 for the last released app API version N−1.Version manager 153 will then use adapter N−1 156 for any interaction betweenapp service 157 and app API version N−1. However, App API version N 141 will have direct interactions withapp service 157 since its version number N matches the supported API version of the app service 157 (detectable byversion manager 153 because there is no adapter N on server 150). - The
version manager 153 supplies the sender's API call as input to a starting adapter (determined as discussed above), if multiple adapters are needed, theversion manager 153 provides output produced by the starting adapter as input to the next adapter. The continues until the ending adapter produces a final modification on the original API call. The final modification is provided as a request or a response to the receiver and the final modification corresponds to an API version supported by the receiver. - The
version manager 153 knows that no adapter is needed when there is no adapter matching an API version number of the app API version. - The API version number of the app API version maps to a starting version number for any needed adapter (when the app API version is the sender in a communication with the app service 153). In this way, when the API version of the app API version is 1 greater than the last-released adapter (app API version N 141), then that app API version N 141 requires no adapter-based processing and is assumed to match the version number of the app service 157 (this is illustrated in
FIG. 1 because the last adapter is adapter N−1 156), such that theapp service 157 is also at version N in this example matching app API version N 141. In this way, the API version that is current supported byapp service 157 has no adapter matching that API version, such that the most-recently released app API version that works with the supported API version is always 1 greater than the last known adapter. - During a connection between a given
app API version 1 111 and theapp service 157, a communication session is established. Each session is managed separately/independently from other connections associated with other app API versions (121, 131, and 141). Each session is assigned a corresponding known version number associated with the corresponding connected app API version (111, 121, 131, or 141). In an embodiment, the version number is maintained as metadata associated with the corresponding session. - The
version manager 153 intercepts API calls made from a givenapp API version 1 111 during a corresponding session to theapp service 157. Similarly, theversion manager 153 intercepts API calls made from theapp service 157 during the corresponding session to the givenapp API version 1 111. - Each API call includes metadata or an identifier that uniquely identifies that API call (command), a sender identifier, a receiver identifier, and a session identifier. At least one of the sender identifier or the receiver identifier will be associated with the
app service 157, and the remaining identifier associated with the givenapp API version 1 111 for the corresponding session. Each API call may also include an associated packet payload having data or information needed or used by that API call (the data or information can include links, processing parameters/options, image data, graphical data, video data, audio data, text data, or various combinations of these types of data or information). - During any API call of any session, the
version manager 153 obtains the app API version number along with the sender identifier, the receiver identifier, the API call identifier, and any packet payload. The API version number informs theversion manager 153, which adapter (154-156) needs to be processed for that API call before delivering to the receiver, and the API version number informsversion manager 153 how many adapters have to be processed/transformed before delivering the API call and any packet payload to the corresponding receiver during the corresponding session. - Each adapter (154-156) includes marked-up transformations/instructions that are specific to a given API version and transforming API calls and any expected packet payload to a next version (ascending and descending). These transformations are instructions that are processed by
version manager 153 to ensure any given API call and any expected packet payload are recognized and expected by the receiver, such that the receiver is able to properly process the given sender-provided API call and any given sender-provided packet payload. - A given transformation/instruction statement within a given
adapter 1 154 may include a matching API call identifier (label) based on the sender and a replacement API call identifier (label) recognized by the receiver that corresponds or maps to the sender's API call identifier. A given transformation/instruction statement may also include a series of sub-transformation/instruction statements and/or calls to transformation routines. -
Version manager 153 may subtract the current version number N associated with the app service 157 (current released and supported version ofapp service 157 available on server 150) from a given version number of a given session (associated withapp API version 1 111, 2 121, or 3 131). The result of the subtraction identifies how many adapters (154-156) have to be processed on the given API call before the resulting transformations can be delivered to the receiver as input or response data for the receiver to process.Version manager 153 determines the order in which the determined number of adapters (154-156) are to be sequentially processed based on the sender identifier. When the sender identifier is associated with one of the app API versions (111, 121, or 131), the order is increasing or ascending. When the sender identifier is associated withapp service 157, the order is decreasing or descending. The starting adapter (154, 155, or 156) is always adapter N−1 156 when the sender is the app service 157 (order is descending). The starting adapter (154, 155, or 156) when the sender is one of the app API versions (111, 121, or 131) is the adapter (154, 155, or 156) that corresponds to the version of the sending app API version (111, 121, or 131). For example, whenapp API version 1 111 is the sender,adapter 1 154 is the starting adapter; whenapp API version 2 121 is the sender,adapter 2 155 is the starting adapter, etc. (Again, there is no need for any adapter processing when the API version number associated with the app API version has no corresponding adapter—an indication that the app API version is up to date with what is supported by theapp service 157.) Notice there is no adapter processed at all when app API version N 141 is the sender, since the version number N matches the version of theapp service 157 and can be determined by theversion manager 153 based on no presence or a lack of presence of any adapter N onserver 150. - So, the API version number of a sending app API version (111, 121, and 131) determines the starting adapter (154, 155, and 156) that is first processed by the
version manager 153 for a given API call and any given packet payload. In this scenario, based on the difference between the API version number of that sending app API version (111, 121, or 131) and the version number N (version number of theapp service 157 and detected because there is no adapter N onserver 150 and adding 1 to the last available adapter N−1 156), theversion manager 153 determines how many additional adapters (155 and/or 156) need to be processed before the transformed API call and any packet payload are provided toapp service 157 for processing. The order is determined as ascending because the sender was a mobile app version (111, 121, or 131). - When the sender is the
app service 157, the order is descending, the first adapter processed by theversion manager 153 is always adapter N−1 156 (assuming the receiver is not app API version N 141 in which case as explained above no adapter is processed by version manager 153). The last adapter processed in a descending order from N−1 is the adapter that corresponds to the receiving app API version (111, 121, or 131). - It is to be noted that
FIG. 1 depicts 3 mobile app versions (111, 121, 131, and 141), which is done for illustration, as there can be just two mobile app versions (111 and 141 (where N is 2)) or there can be up to a configurable number (X) app API versions (111, 121, 131 and continuing for a configurable number of additional iterations to 141). Furthermore, adapter N−1 146 implies that N is at least 5 or more (given the diagram depicted inFIG. 1 ). Again, this does not have to be the case as there can be just oneadapter 156 corresponding toapp version 1 111, such that N is 2 andadapter N 156 isadapter 1 154. Furthermore, it is again noted thatversion manager 153 does not invoke and does not process any adapter 154-156 when the app API version N 141 is engaged in a network session with the app service 157 (since the API version numbers match, there is no adapter N onserver 150, and there is no disparity in the API calls between the two during the session). - Each adapter 154-156 includes transformations/instructions for making API calls from one version compatible a next version to process (both ascending and descending based on the sender). So,
adapter 1 154 produces (when processed by the version manager 153) transformations that transform input being sent byapp API version 1 111 during a session to expected corresponding input that can be processed by anAPI version 2 of theapp service 157. Moreover,adapter 1 154 produces (when processed by version manager 153) transformations that transform output being sent by anAPI version 2 of theapp service 157 into expected corresponding output expected byapp API version 1 111. When there is more than 1 difference in API versions between the app API version (111, 121, or 131) and the version of theapp service 157, theversion manager 153 sequentially processes transformation outputs from one adapter (154, 155, or 156) and provides those outputs as input to a next adapter (154, 155, or 156) until the version number of the last adapter processed matches a version number associated with the receiver. Again, the sequential order (ascending or descending) is determined based on who the sender is for any given API call being processed. When the sender is app API version (111, 121, or 131) the order of applying any needed adapters (154, 155, and/or 156) is ascending, when the sender is theapp service 157 the order of applying the needed adapters (156, 155, and/or 154) is descending. - As an example, consider the following scenario where N is 3 (version=3) of
app service 157 is released and supported onserver 150 by a given organization), such that the last adapter on theserver 150 isadapter 2 155. A useroperating device # 1 110 selects from a user-facing interface ofapp API version 1 111 option X during a network session withapp service 157.Version manager 153 is activated onserver 150 upon initiation of the session. The session version number is set to 1 based onmobile app version 1 111. The current support API version forapp service 157 is detectable as 3 based on the last adapter on theserver being adapter 2 155 by adding 1, since the current API version support is 1 more than the last available adapter on theserver 150. Option X is intercepted as an API call.Version manager 153 subtractsAPI version 1 from API version 4 (version of app service 157) resulting in 2, which indicates the number of adapters that need processed before the API call can be delivered to theapp service 157 for processing during the session. The version number ofapp API version 1 111 is thenumber 1, which maps toadapter 1 154. The sender identifier isapp API version 1 111, so the order is ascending. Version manager 143 obtains the transformation instructions fromadapter 1 154 and processes them to obtain outputA. Version manager 153 obtains the transformation instructions foradapter 2 155 and applies them on output A to obtain output B. Output B is provided as input B toapp service 157 in place of option X.App service 157 produces a response Y to inputB. Version manager 153 intercepts Y and obtains reverse transformations instructions fromadapter 2 155 to obtain outputD. Version manager 153 obtains reverse transformation instructions fromadapter 1 154 to obtain output E. Output E is provided as response data toapp API version 1 111 based on initial user selection of option X. - The
FIG. 2 shows example syntax and semantics associated with an example adapter (154, 155, or 156), according to an example embodiment. It is to be noted that other syntax and semantics may be used that are different from that which is shown for illustration in theFIG. 2 . - As illustrated in
FIG. 2 under the “when” statement for a resource associated with an API endpoint and, during a transformation from one version to a next version, an API endpoint is renamed when issued from one app API version (111, 121, or 131) to make that API call compatible with a next API version (sender is “app”). The redirection is actually a path location to the API endpoint onserver 150, such that results from processing the sample adapter is a call to a different path location on server 140 (location2) to a replacement API endpoint. This permits an older app API version (111, 121, or 131) to make a proper call to the currently supported and needed API endpoint (resource1) and allows the older API endpoint to be removed from server 150 (from location1) without updating the app API version (111, 121, or 131). - The adapter shown in
FIG. 2 also replaces a response string sent as a response from theapp service 157 to a given app API version (111, 121, or 131) from “success” to “1.” The given app API version (111, 121, or 131) knows how to handle and process a “1” response string as an indication of success but is unable to handle and process a “success” response string. Version N of theapp service 157 produces the “success” response string, theversion manager 153 processes the corresponding adapter N−1 156 resulting in a “1” response string being provided back to the given app API version (111, 121, and 131). - The
adapters FIG. 2 . Each file includes instructions that are interpreted by theversion manager 153 at runtime to move an API call to a next version of the API call (current version+1 forward) or move the API call to a previous version of the API call (current version−1 backward). - Output from one adapter for processing a given API call can be provided as input to a next adapter to move the original API call to a compatible format that spans more than 1 API version. The adapters can be chained together in this manner for up to a configurable number (X) of previous versions associated with the
app service 157. - If the
version manager 153 detects an app API version number that is greater than a configurable number (X) of previous versions, theversion manager 153 can prompt the app API version to force an update to a newer version of the app API version. This number X is configurable and can be increased or decreased based on the needs of the organization providing theapp service 157. - In an embodiment, the adapters 154-156 are files representing programming instructions that are capable of being opened, read, and interrupted in real-time by the
version manager 153. In an embodiment, the files are Ruby files. - In an embodiment, the adapters 154-156 are executable scripts passed the API call, sender identifier, receiver identifier, and any packet payload as parameters by the
version manager 153. - In an embodiment, the adapters 154-156 are eXtensible Markup Language (XML) files.
- In an embodiment, the adapters 154-156 are customized markup language files having a proprietary syntax and statements.
- In an embodiment the user-operated
devices - In an embodiment, the
app service 157 is an insurance service provided by an insurance company to subscribers and potential subscribers. - It is to be noted that the app API version (111, 121, 131, and 141) as described above can be web-based or browser-based user interfaces/applications that interact with the
app service 157 in the manners discussed hereinabove and below. Similarly, theapp service 157 may be web-based or browser-based. - The above-referenced embodiments and other embodiments are now discussed with reference to the
FIGS. 3-5 . -
FIG. 3 is a diagram of amethod 300 for adaptive application version integration support, according to an example embodiment. The software module(s) that implements themethod 300 is referred to as a “version manager.” The version manager is implemented as executable instructions programmed and residing within memory and/or a non-transitory computer-readable (processor-readable) storage medium and executed by one or more processors of a device. The processor(s) of the device that executes the version manager are specifically configured and programmed to process the version manager. The version manager may have access to one or more network connections during its processing. The network connections can be wired, wireless, or a combination of wired and wireless. - In an embodiment, the device that executes the version manager is the
server 150. In an embodiment, theserver 150 is a cloud-based processing environment comprising a collection of physical servers cooperating as a single logical server. In an embodiment, theserver 150 is a Local-Area Network (LAN)-based server or a Wide-Area Network (WAN)-based server. - In an embodiment, the version manager is all or some combination of the
version manager 153, the adapters 154-156, and/or the network-based appservice version N 157. - At 310, the version manager intercepts an API call sent from a first application to a second application. The first and second application are connected for a communication session with one another over a network connection. The version manager is interposed between the first and second application. In an embodiment, the version manager is initiated upon establishment of the session between the first and second applications and is transparently part of the session.
- At 320, the version manager identifies a first version number associated with the first application and a second version number associated with the second application. That is both applications include an identifier and/or metadata that permits the release or API version number for software associated with the applications to be identified by the version manager. This can be done in a variety of manners as discussed above. For example, unique identifiers for the applications can be used to look up the API version numbers, or each communication includes metadata that identifies the release or API version number.
- At 330, the version manager processes one or more transformations based on the first version number and the second version number. First it is to be noted that if the first version number is equal to the second version number, then the processing is bypassed and the first and second application communicate directly with one another during the session. The transformations (when the version numbers are not equal to one another) change or modify API calls issued from one of the applications (sending application) into other API calls that are recognized and processed, during the session, by the other application (receiving application).
- In an embodiment, at 331, the version manager determines an order for the transformations based on the first application and the first version number.
- In an embodiment of 331 and at 332, the version manager determines the order as being an increasing or ascending order when the first version number is less than the second version number. This is an indication that the first application is a app API version (111, 121, 131, or 141) that is sending an API call during the session to a second application that is an
app service 157, where the version of the first application is not currently up-to-date with the version of the second application (first version number of the first application is less than the second version number of the second application). - In an embodiment of 331 and at 333, the version manager determines the order as being a decreasing of descending order when the first version number is greater than the second version number. This is an indication that the first application is an
app service 157 that is sending an API call during the session to a second application that is an app API version (111, 121, 131 or 141), where the version of the second application is not currently up-to-date with the version of the first application (first version number of the first application is greater than the second version number of the second application). - In an embodiment of 331 and at 334, the version manager determines a total number of the transformations that are needed as an absolute value of the difference between the second version number and the first version number.
- At 340, the version manager produces a second API call based on output produced from processing the transformations at 330.
- In an embodiment of 334 and 340, at 341, the version manager passes output produced for the API call by a starting transformation as input to a next transformation for the total number of transformations in the order; this produces the second API call as a final output from a last processed transformation. That is, the transformations are chained together and processed sequentially for the total number of needed transformations in the order (ascending or descending) for making the final output on the API call match a receiving application.
- In an embodiment, at 342, the version manager produces the second API call in a higher version number format than the first version number associated with the first application when the first version number is lower than the second version number. Here, the first application is an app API version (111, 121, 131, 141) having a version number that is less than the receiving second application (which is the app service 157). The first application is the sending application during the session and the second application is the receiving application.
- In an embodiment, at 343, the version manager produces the second API call in a lower version number format than the first version number associated with the first application when the first version number is higher than the second version number associated with the second application. Here, the first application is the
app service 157 that is making an API call to a second application that is an app API version (111, 121, 131, or 141). Again, the first application is the second application during the session and the second application is the receiving application. - At 350, the version manager provides the transformed second API call to the second application for processing on behalf of the first application. The second API call is recognized and processed by the second application during the session.
- The processing 310-350 may be iterated during the session between the first application and the second application for all API calls made between the first and second applications. This makes incompatible application versions (seamlessly compatible).
- For example, and in an embodiment at 360, the version manager intercepts a response sent from the second application to the first application. The second application produces the response based on processing the second API call. The version manager then processes the transformations (this time in a different order from what was done at 330) based on the first version number and the second version number. The version manager produces a second response based on the final output of the transformations, and the version manager provides the second response to the first application for processing on behalf of the second application.
- In an embodiment, the transformations are adapters (154, 155, and/or 156). In an embodiment, each adapter provides forward and backward (reverse) transformations on an API call in a first version X to a second version X+1 (forward) and/or a third version X−1 (reverse).
- In an embodiment, a transformation can: replace an API call with a new API call or a new set of API calls (second API call); change a format of the API call to a new format (represented by the second API call); ignore an API call with now action; change codes between the API call with the second API call; and/or change text, links, images, graphics, audio, video between the API call and the second API call.
- In an embodiment, the difference between the first version number and the second version number can be up to a configurable number X. So, the first application and the second application can differ from one another by up to X released versions.
-
FIG. 4 is a diagram of anothermethod 400 for adaptive application version integration support, according to an example embodiment. The software module(s) that implements themethod 400 is referred to as a “version compatibility manager.” The version compatibility manager is implemented as executable instructions programmed and residing within memory and/or a non-transitory computer-readable (processor-readable) storage medium and executed by one or more processors of a device. The processors that execute the version compatibility manager are specifically configured and programmed to process the version compatibility manager. The version compatibility manager may have access to one or more network connections during its processing. The network connections can be wired, wireless, or a combination of wired and wireless. - In an embodiment, the device that execute the version compatibility manager is the
server 150. In an embodiment, theserver 150 is a cloud processing environment, a LAN server, or a WAN server. - In an embodiment, the version compatibility manager is all of, or some combination of:
version manager 153, adapters 154-156, and/or themethod 300. - The version compatibility manager presents another and, in some ways, enhanced processing perspective of the
method 300. - At 410, the version compatibility manager intercepts API calls made between a mobile application (app—such as
app API versions - At 420, the version compatibility manager processes adapters (such as adapters (154, 155, and/or 156) that transform the API calls between an application version supported by the app and a service version supported by the service.
- In an embodiment, at 421, the version compatibility manager processes the adapters in an ascending (increasing) order for app-initiated API calls made by the app to the service during the session. Here, the sender of any given API call is the app.
- In an embodiment, at 422, the version compatibility manager processes the adapters in a descending (decreasing) order for service-initiated API calls made by the service to the app during the session. Here, the sender of any given API call is the service.
- In an embodiment, at 423, the version compatibility manager identifies a starting adapter from the adapters based on whether the APP is a sender of a given API call or whether the service is the sender of the given API call. When the service is the sender, the starting adapter is the service
version number minus 1. When the app is the sender, the starting adapter matches the app version number. - In an embodiment, at 424, the version compatibility manager identifies an ending adapter from the adapters based on whether the app is a receiver of a given API call or whether the service is the receiver of the given API call. When the receiver is the service, the ending adapter is the service
version number minus 1. When the receiver is the app, the ending adapter matches the app version number. - In an embodiment, at 425, the version compatibility manager obtains the adapters as files. Each file including instructions for mapping or transforming API calls back and forth between a first version (V+1) and a second version (V−1) associated with the service.
- In an embodiment of 425 and at 426, the version compatibility manager dynamically loads the files and processes the instructions (interprets the software instructions defined in the files and processes them).
- In an embodiment, at 427, the version compatibility manager sequentially processes each API call through the adapters beginning at a starting adapter with output produced by each processed adapter for the processed API call passed as input to a next adapter. The adapters are chained together.
- At 430, the version compatibility manager provides transformed API calls to the app and the service based on the processing of 420 during the session.
- One now appreciates how incompatible versions of a mobile app can be supported for a single released network service. Each transformation between two versions (V+1 (forward) and V−1 (backward)) encapsulated within a single adapter.
- In an embodiment, the service version number is up to 10 versions higher than the app version number.
- In an embodiment, the version compatibility manager simultaneously supports multiple different mobile apps, where the mobile apps comprise a plurality of different version numbers, some of which are the same as the service version number and some of which are different from the service version number and the mobile app version number.
-
FIG. 5 is a diagram of anothersystem 500 for adaptive application version integration support, according to an example embodiment. Thesystem 500 includes a variety of hardware components and software components. The software components of thesystem 500 are programmed and reside within memory and/or a non-transitory computer-readable medium and execute on one or more processors of thesystem 500. Thesystem 500 communicates over one or more networks, which can be wired, wireless, or a combination of wired and wireless. - In an embodiment, the
system 500 implements, inter alia, the processing described above with theFIGS. 1-4 . - The
system 500 includes: acloud processing environment 510 comprisingprocessors 511 and non-transitory computer-readable storage media 512. Themedia 512 comprising executable instructions representing aversion manager 513 and a network-based service 514. Thesystem 500 interacts with a plurality ofmobile applications 521, each mobile application (app) executing as executable instructions from non-transitory computer-readable storage media by a processor of amobile device 520. Themobile app 521 associated with a release or version number that does not match a release or version number associated with the network-based service 514. - In an embodiment, the
version manager 513 is all or some combination of:version manager 153, adapters 154-156, the method 200, and/or themethod 300. - In an embodiment, the network-based service 514 is the
app service 157. - In an embodiment the mobile apps are
app API versions - The network-based service 514 when executed by at least one of the
processors 511 from the non-transitory computer-readable storage media 512 cause the at least oneprocessor 511 to: 1) interact with amobile app 521 that executes on themobile device 520 using API calls associated with a released version of the network-based service 514; and 2) provided one or more services to themobile app 521 through the API calls. - The
version manager 513 when executed by at least one of theprocessors 511 from the non-transitory computer-readable storage media 512 cause the at least oneprocessor 511 to: 1) intercept mobile-app API calls associated with a different version of the network-based service 514 before the network-based service 514 obtains the mobile-application API calls; 2) intercept network-based service API calls provided by the network-based service 514 before themobile application 521 obtains the network-based service API calls; 3) process adapters that make the mobile-application API calls compliant with the released version of the network-based service 514 and supply compliant mobile-application API calls to the network-based service 514 for processing and providing the one or more services; and 4) process the adapters that make the network-based service API calls compliant with the different version of the network-based service 514 and supply compliant network-based service API calls to themobile application 521. - In an embodiment, the adapters are the
adapters - In an embodiment, the adapters are in a syntax and semantics as what was illustrated in the
FIG. 2 . - In an embodiment, each adapter is a file that comprises instructions for mapping the network-based service API calls and the mobile-application API calls between two versions associated with the network-based service 514. In an embodiment, each adapter includes instructions for transforming API calls from a mobile-app API version to V+1 (forward transformation) and V−1 (reverse or backward transformation). The adapters are chained together and processed by the
version manager 513. For example, if the mobile app API version number is 1 and the network-based service API version number is 4. Theversion manager 513processes adapters 1 to get toversion 2,adapter 2 to get toversion 3, andadapter 3 to get to version 4 when the sender is themobile application 521. When the sender is the network-based service 514, theversion manager 513processes adapter 3 to get toversion 3,adapter 2 to get toversion 2, andadapter 1 to get toversion 1. - In an embodiment, the
version manager 513, when executed by the at least oneprocessor 511 from the non-transitory computer-readable storage medium 512 further causes the at least one processor to 511: dynamically interpret and process each file's instructions when processing each adapter. - It should be appreciated that where software is described in a particular form (such as a component or module) this is merely to aid understanding and is not intended to limit how software that implements those functions may be architected or structured. For example, modules are illustrated as separate modules, but may be implemented as homogenous code, as individual components, some, but not all of these modules may be combined, or the functions may be implemented in software structured in any other convenient manner.
- Furthermore, although the software modules are illustrated as executing on one piece of hardware, the software may be distributed over multiple processors or in any other convenient manner.
- The above description is illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of embodiments should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
- In the foregoing description of the embodiments, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting that the claimed embodiments have more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Description of the Embodiments, with each claim standing on its own as a separate exemplary embodiment.
Claims (20)
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/592,314 US10970136B1 (en) | 2019-10-03 | 2019-10-03 | Adaptive application version integration support |
US17/178,079 US11416314B2 (en) | 2019-10-03 | 2021-02-17 | Adaptive application version integration support |
US17/810,980 US11720420B2 (en) | 2019-10-03 | 2022-07-06 | Adaptive application version integration support |
US18/336,513 US20230350734A1 (en) | 2019-10-03 | 2023-06-16 | Adaptive application version integration support |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/592,314 US10970136B1 (en) | 2019-10-03 | 2019-10-03 | Adaptive application version integration support |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/178,079 Continuation US11416314B2 (en) | 2019-10-03 | 2021-02-17 | Adaptive application version integration support |
Publications (2)
Publication Number | Publication Date |
---|---|
US10970136B1 US10970136B1 (en) | 2021-04-06 |
US20210103483A1 true US20210103483A1 (en) | 2021-04-08 |
Family
ID=75274089
Family Applications (4)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/592,314 Active US10970136B1 (en) | 2019-10-03 | 2019-10-03 | Adaptive application version integration support |
US17/178,079 Active US11416314B2 (en) | 2019-10-03 | 2021-02-17 | Adaptive application version integration support |
US17/810,980 Active US11720420B2 (en) | 2019-10-03 | 2022-07-06 | Adaptive application version integration support |
US18/336,513 Pending US20230350734A1 (en) | 2019-10-03 | 2023-06-16 | Adaptive application version integration support |
Family Applications After (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/178,079 Active US11416314B2 (en) | 2019-10-03 | 2021-02-17 | Adaptive application version integration support |
US17/810,980 Active US11720420B2 (en) | 2019-10-03 | 2022-07-06 | Adaptive application version integration support |
US18/336,513 Pending US20230350734A1 (en) | 2019-10-03 | 2023-06-16 | Adaptive application version integration support |
Country Status (1)
Country | Link |
---|---|
US (4) | US10970136B1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11416314B2 (en) | 2019-10-03 | 2022-08-16 | Caret Holdings, Inc. | Adaptive application version integration support |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11637737B2 (en) * | 2020-10-23 | 2023-04-25 | Dell Products L.P. | Network data management framework |
US20230168871A1 (en) * | 2021-12-01 | 2023-06-01 | Salesforce.Com, Inc. | Systems, methods, and devices for automatic application programming interface model generation based on network traffic |
CN115309554A (en) * | 2022-06-29 | 2022-11-08 | 统信软件技术有限公司 | Debugging method, debugging system and computing device for application running based on compatible layer |
Family Cites Families (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6952802B2 (en) * | 2000-04-14 | 2005-10-04 | Sun Microsystems, Inc. | User controllable document converter and methods thereof |
US8661420B2 (en) * | 2004-08-03 | 2014-02-25 | Oracle International Corporation | System and method for runtime interface versioning |
US7774404B2 (en) * | 2008-06-13 | 2010-08-10 | Sap Ag | Managing software component versions within a service oriented architecture |
US8484666B2 (en) * | 2010-09-13 | 2013-07-09 | Microsoft Corporation | Optimizations for implementing multi-stack stack hosts |
US8881181B1 (en) * | 2012-05-04 | 2014-11-04 | Kabam, Inc. | Establishing a social application layer |
US9063748B1 (en) * | 2013-03-19 | 2015-06-23 | Amdocs Software Systems Limited | System, method, and computer program for allowing a plurality of application programming interface (API) versions to interact with a single version of implementation code |
US9262237B2 (en) * | 2013-12-17 | 2016-02-16 | International Business Machines Corporation | Automating software availability management based on API versioning |
US10216548B1 (en) * | 2013-12-19 | 2019-02-26 | VCE IP Holding Company LLC | Dynamic and adaptive programmatic interface selection (DAPIS) |
US10334413B2 (en) * | 2016-12-24 | 2019-06-25 | Cisco Technology, Inc. | Managing mobile devices on different operator networks |
US20180232262A1 (en) * | 2017-02-15 | 2018-08-16 | Ca, Inc. | Mapping heterogeneous application-program interfaces to a database |
US10747587B2 (en) * | 2017-10-30 | 2020-08-18 | Microsoft Technology Licensing, Llc | Dynamic rule-based transformation of API calls |
US11615208B2 (en) * | 2018-07-06 | 2023-03-28 | Capital One Services, Llc | Systems and methods for synthetic data generation |
WO2020255389A1 (en) * | 2019-06-21 | 2020-12-24 | 日本電信電話株式会社 | Api conversion device, api conversion method, and program |
US10769000B1 (en) * | 2019-08-27 | 2020-09-08 | Cloudflare, Inc. | Method and apparatus for transparently enabling compatibility between multiple versions of an application programming interface (API) |
US10970136B1 (en) | 2019-10-03 | 2021-04-06 | Caret Holdings, Inc. | Adaptive application version integration support |
-
2019
- 2019-10-03 US US16/592,314 patent/US10970136B1/en active Active
-
2021
- 2021-02-17 US US17/178,079 patent/US11416314B2/en active Active
-
2022
- 2022-07-06 US US17/810,980 patent/US11720420B2/en active Active
-
2023
- 2023-06-16 US US18/336,513 patent/US20230350734A1/en active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11416314B2 (en) | 2019-10-03 | 2022-08-16 | Caret Holdings, Inc. | Adaptive application version integration support |
US11720420B2 (en) | 2019-10-03 | 2023-08-08 | Caret Holdings, Inc. | Adaptive application version integration support |
Also Published As
Publication number | Publication date |
---|---|
US20210173723A1 (en) | 2021-06-10 |
US20220334893A1 (en) | 2022-10-20 |
US20230350734A1 (en) | 2023-11-02 |
US10970136B1 (en) | 2021-04-06 |
US11416314B2 (en) | 2022-08-16 |
US11720420B2 (en) | 2023-08-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10970136B1 (en) | Adaptive application version integration support | |
US9721246B2 (en) | Synchronization patterns for mobile applications | |
US7805735B2 (en) | System and method of representing data entities of standard device applications as built-in components | |
US11531573B2 (en) | Asynchronous C#-JS data binding bridge | |
US8850390B2 (en) | Status management for phased implementation of configuration changes | |
US8032588B2 (en) | System and method for hosting one or more versions of a service using a service proxy | |
US20060271911A1 (en) | Generating executable objects implementing methods for an information model | |
WO2009043037A4 (en) | Network operating system | |
EP4130986A1 (en) | Modifying program modules in running applications | |
US10747588B2 (en) | Method for updating instance-based message maps using metadata | |
US20150082322A1 (en) | Data Upgrade Framework for Distributed Systems | |
CN110659030B (en) | Unity project compiling method, system, computer equipment and storage medium | |
US7464081B2 (en) | Web based dynamic data translation service and method | |
CN102169447A (en) | Method and corresponding system for registering and deregistering self-defined Shell | |
CN113448689A (en) | Dubbo protocol conversion device and method in operation period | |
US11245567B2 (en) | Electronic message adaptation | |
CN115603797A (en) | Satellite ground automatic test platform, test system and test method | |
US8261296B2 (en) | Invocation channel | |
US12021712B2 (en) | Cloud configuration interface | |
US11972253B2 (en) | Multi-cloud machine-learning model building | |
CN112051990A (en) | Network management northbound interface model adaptation method and system | |
CN118014505A (en) | Multi-cloud arrangement system and multi-cloud arrangement method | |
US20130166999A1 (en) | Method and system for modifying the look and behavior of a web application | |
KR20230133600A (en) | method for managing multi cloud and electronic device |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ROOT, INC., OHIO Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DEVINE, JAMES W.;MANGES, DANIEL C.;PANETTA, MICHAEL A.;REEL/FRAME:050619/0915 Effective date: 20191002 |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
AS | Assignment |
Owner name: CARET HOLDINGS, INC., OHIO Free format text: CHANGE OF NAME;ASSIGNOR:ROOT, INC.;REEL/FRAME:054133/0581 Effective date: 20200916 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: ACQUIOM AGENCY SERVICES, LLC, AS ADMINISTRATIVE AGENT, MINNESOTA Free format text: SECURITY INTEREST;ASSIGNOR:CARET HOLDINGS, INC.;REEL/FRAME:058792/0792 Effective date: 20220124 |
|
AS | Assignment |
Owner name: ACQUIOM AGENCY SERVICES, LLC, AS ADMINISTRATIVE AGENT, MINNESOTA Free format text: SECURITY INTEREST;ASSIGNORS:ROOT INC.;CARET HOLDINGS, INC.;REEL/FRAME:061715/0333 Effective date: 20221108 |
|
AS | Assignment |
Owner name: ACQUIOM AGENCY SERVICES LLC, AS THE ADMINISTRATIVE AGENT, COLORADO Free format text: SECURITY INTEREST;ASSIGNORS:ROOT, INC.;CARET HOLDINGS, INC.;REEL/FRAME:065478/0131 Effective date: 20231101 |
|
AS | Assignment |
Owner name: ACQUIOM AGENCY SERVICES, LLC, AS THE ADMINISTRATIVE AGENT, COLORADO Free format text: SECURITY INTEREST;ASSIGNORS:ROOT, INC.;CARET HOLDINGS, INC.;REEL/FRAME:066538/0718 Effective date: 20240222 |
|
AS | Assignment |
Owner name: ACQUIOM AGENCY SERVICES, LLC, AS THE ADMINISTRATIVE AGENT, COLORADO Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE THE CORRECT APPLICATION NUMBER IS 17/929,552 PREVIOUSLY RECORDED AT REEL: 66538 FRAME: 718. ASSIGNOR(S) HEREBY CONFIRMS THE SECURITY INTEREST;ASSIGNORS:ROOT, INC.;CARET HOLDINGS, INC.;REEL/FRAME:066947/0212 Effective date: 20240222 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |