Patent Description:
Moving web applications components to a cloud-computing system can be expensive and tedious often requiring a large number of separate API ("Application Programming Interface") calls to ensure that all components are migrated appropriately to the new environment. Also, because the a web application can include components and meta data stored on multiple different devices including web servers and a local computer, the appearance and functionality of the web application can vary depending on the location from which the web application is access. Accordingly, a web application may appear to have a different look-and-feel to a user after migration to the cloud-computing environment.

In some implementations, the systems and methods described below provide a mechanism for importing all web application components to a cloud-computing system destination in a single API call. In some such implementations, an agent computer system analyzes the source content (i.e., the web application running in its current environment) and generates a manifest that summarizes all of the components of the web application and other data that affects the appearance and function of the web application. The manifest and all of the identified components of the web application are then included in a migration container (e.g., a temporary container) that is uploaded to a cloud system storage. When the cloud-computing system receives an API call requesting migration, the cloud-computing system accesses the migration container, reads the manifest, and then proceeds to asynchronously reconstruct the web application in the cloud-computing environment based on the manifest. After migration is complete and the web application has been reconstructed in the cloud-computing environment, the cloud-computing system transmits a response to the API call.

One or more embodiments are described and illustrated in the following description and accompanying drawings. These embodiments are not limited to the specific details provided herein and may be modified in various ways as long as they do not depart from the scope of the invention as it is depicted by the appended claims. Also, the functionality described herein as being performed by one component may be performed by multiple components in a distributed manner. Likewise, functionality performed by multiple components may be consolidated and performed by a single component. Similarly, a component described as performing particular functionality may also perform additional functionality not described herein. For example, a device or structure that is "configured" in a certain way is configured in at least that way, but may also be configured in ways that are not listed, as long as they do not depart from the scope of the invention as it is depicted by the appended claims.

Furthermore, some embodiments described herein may include one or more electronic processors configured to perform the described functionality by executing instructions stored in non-transitory, computer-readable medium. Similarly, embodiments described herein may be implemented as non-transitory, computer-readable medium storing instructions executable by one or more electronic processors to perform the described functionality. As used in the present application, "non-transitory computer-readable medium" comprises all computer-readable media but does not consist of a transitory, propagating signal. Accordingly, non-transitory computer-readable medium may include, for example, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a RAM (Random Access Memory), register memory, a processor cache, or any combination thereof.

In addition, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. For example, the use of "including," "containing," "comprising," "having," and variations thereof herein is meant to encompass the items listed thereafter and equivalents thereof as well as additional items. The terms "connected" and "coupled" are used broadly and encompass both direct and indirect connecting and coupling. Further, "connected" and "coupled" are not restricted to physical or mechanical connections or couplings and can include electrical connections or couplings, whether direct or indirect. In addition, electronic communications and notifications may be performed using wired connections, wireless connections, or a combination thereof and may be transmitted directly or through one or more intermediary devices over various types of networks, communication channels, and connections. Moreover, relational terms such as first and second, top and bottom, and the like may be used herein solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.

<FIG> illustrates an example of a web application operating environment. A web application (or "Web App") is a client-server computer program that the client typically runs in a web browser. In the example of <FIG>, the client <NUM> includes a user device such as, for example, a person computer, a tablet computer, or a smart phone. The web application software is launched on the client <NUM> and connects to a web server <NUM>, for example, through the Internet. The web application software operating on the client <NUM> also provides the user interface for the web application (for example, a web page displayed in the web browser of the client device). The web server <NUM> stores additional code and data that interacts with the web application code executed by the client <NUM> to provide the functionality of the web application.

The web application in the example of <FIG> also includes multiple different Web Parts <NUM>. A web part <NUM> is a reusable component that contains or generates web-based content such as XML, HTML, and scripting code. It has a standard property schema and displays that content in a cohesive unit on a webpage (i.e., the user interface of the web application displayed on the client <NUM>). At least some of the web parts <NUM> interact with the web application code on the client <NUM> to cause content to be displayed on the user interface. For example, one web part <NUM> may include software for a "search box" that is displayed on the web page user interface of the web application and another web part <NUM> may include software for a "display pane" configured to show content (e.g., text, video, images, etc.) on the web page user interface of the web application. In some implementations, the web application is configured to cause the web parts <NUM> to interact with other web parts <NUM>. For example, the web application software may be configured to cause a "search box" web part <NUM> to interact with a "display pane" web part <NUM> such that the content shown in the "display pane" web part <NUM> is adjusted or changed based on search text entered by a user through the "search box" web part <NUM>.

Although the example of <FIG> shows only a single client <NUM> and a single web server <NUM>, in some implementations, the web application can be distributed across many clients and many web servers. For example, some of the individual web parts <NUM> of the web application may be stored or executed on different web servers. Furthermore, in some implementations, many different clients may be configured to run the web application and to interact with the same web server(s) <NUM>. Also, because at least a part of the web application software is executed locally by the client <NUM>, the appearance and functionality (i.e., "look-and-feel') of the web application can be influenced by local alterations and customizations to the web application software including, for example, local meta data.

In contrast, a cloud-computing environment is one in which software applications are executed by "virtual machines" based on on-demand availability of computer system resources (e.g., data storage and computing power). When a software application in a cloud computing environment is accessed by a user on a client computer system (e.g., client <NUM>), the application software is generally not stored or executed locally on the client <NUM>. Instead, the application software is executed by cloud computing resources (i.e., a cloud computing service) and the local client <NUM> operates only as a user interface for displaying data and receiving user inputs.

Moving a software application from a web application operating environment to a cloud-computing environment is complicated, for example, by the existence of multiple different components stored and executed on multiple different computing devices. Furthermore, because the web application software is executed locally on the client <NUM> and its appearance and functionality can be adjusted/customized by local modifications (e.g., metadata), it is difficult to ensure that a web application will have the same look-and-feel after migration to a cloud-computing environment.

<FIG> illustrates a three-step method for migrating a web application from a source environment (e.g., the web application operating environment of <FIG>) to a cloud-computing service environment (e.g., a "cloud service"). First, a migration container is generated (step <NUM>). As described in further detail below, the migration container includes all of the web parts for the web application and a manifest defining the appearance and functionality of the web application and defining how the web part interact with each other and with the user interface. The migration container is then transferred to a cloud storage (step <NUM>) and the cloud service accesses the migration container to reconstruct the web application in the cloud-computing environment (step <NUM>).

In some implementations, the method of <FIG> is greatly simplified from the user perspective and user direction is not required to facilitate the individual steps of the migration process. In fact, in some implementations, the user and the client device are not even aware of the specific steps being performed during the migration process. Instead, as illustrated in <FIG>, a user points the migration software to an existing webpage (e.g., a web application operating on a server or on a local desktop) (step <NUM>) and inputs a "migrate" commend (e.g., by pressing a "migrate" button on the user interface or by typing a command into a command-line interface) (step <NUM>). In some implementations, no further user interaction is required to facilitate the migration process and the user simply receives a notification through the client or another user device when the migration process is complete (step <NUM>).

<FIG> illustrates various different system components that may be involved in the migration of the web application in the method of <FIG> including a source computer system <NUM>, an agent computer system <NUM>, a cloud service computer system <NUM>, and a user device <NUM>. The source computer system <NUM> includes a source electronic processor <NUM> and a source memory <NUM>. The source memory <NUM> stores data and/or instructions that are executed by the source electronic processor <NUM> to provide the functionality of the source computer system <NUM>. The source computer system <NUM> also includes a source transceiver <NUM> for wired or wireless communication with other computer systems. Similarly, the agent computer system <NUM> includes an agent electronic processor <NUM>, an agent memory <NUM>, and an agent transceiver <NUM>; the service computer system <NUM> also includes a service electronic processor <NUM>, a service memory <NUM>, and a service transceiver; and the user device <NUM> includes a user device electronic processor <NUM>, a user device memory <NUM>, and a user device transceiver <NUM>.

In some implementations, the user device <NUM> includes the client computer system that executes the web application software and provides a user interface for the web application in the web application operating environment of <FIG>. In some implementations, the arrangement of <FIG> may include multiple different user devices <NUM> each configured to provide a user interface for and execution of the web application software. In some environments, a first user device <NUM> may include the client for the web application operating environment and a second user device <NUM> may include a different computing device through which a user initiates the web application migration process.

In some implementations, the source computer system <NUM> includes a web server storing one or more web parts of the web application. In other implementations, the web parts of the web application are stored on multiple different source computers. Similarly, as discussed above, a web application in the operating environment such as illustrated in the example of <FIG> includes software stored and executed on a client device. Accordingly, unless specified otherwise, the phrase "source computer system" as used herein refers to all of the computer devices that store or execute software code or that store content/data for a web application in its current operating environment prior to migration to the cloud service environment.

The agent computer system <NUM> refers to the computer device component or components that perform tasks relating to the migration operation including in some implementations, for example, generating the migration container and/or initiating an API call as discussed in further detail below. The service computer system <NUM> refers to the computer device component or components that performs the reconstruction of the web application in the cloud computing service environment. Accordingly, the system architecture illustrated in <FIG> is just one example of a system that might be configure to perform the migration operation of <FIG>. Other implementations may include more, fewer, or different components that contribute to or facilitate the migration process as described herein.

<FIG> illustrates an example of a method for generating a migration container for migrating a web application from a source environment to a cloud environment (e.g., step <NUM> in <FIG>). As discussed in further detail below, the method of <FIG> may be performed by migration software executed by the cloud-computing service system, by an agent system, by the local client system, or by the web server (e.g., source system). First, an identification of an existing web page is received (step <NUM>). This may be provided, for example, by a user via the user interface on a client device and may be, for example, in the form of a URL. The automated software system analyzes the identified web page to identify all web parts that are included or interface with the web application associated with the identified web page (step <NUM>). The automated software also analyzes the web page appearance & functionality as defined by the software executed by the local client computer and any additional software stored/executed by one or more web servers (step <NUM>). The automated software also analyzes an local metadata stored on the local client that affects the appearance and/or operation of the web application.

After analyzing the existing webpage for the web application in its current operating environment, the automated software generates a Migration Manifest (step <NUM>). The migration manifest includes a list of all of the "web parts" and any other components (e.g., software or data/content) for the web applications. The migration manifest also defines how to reconstruct the webpage to match the appearance and functionality of the web application in its current operating environment. The migration manifest is generated based on the analysis of the existing web page and any local metadata on the client computing system that affects the appearance or operation of the web application. In some implementations, the migration manifest is automatically generated as an XML document.

The automated software creates a migration container (step <NUM>) that includes copies of all web parts for the web application (step <NUM>) and a copy of the migration manifest (step <NUM>). <FIG> illustrates a block diagram representation of the contents of a migration container <NUM> including the migration manifest <NUM> for the web application and copies of all of the web parts <NUM> and/or other software/data components for the web application.

In some implementations, the user device <NUM> communicates with an agent computer system <NUM> to initiate the creation of the migration container and the method illustrated in <FIG> is performed by the agent computer system <NUM>. In other implementations, the user device <NUM> itself is configured to generate the migration container and, in still other implementations, the cloud-computing service computer system <NUM> is configured to generate the migration container in response to a received request (e.g., from the user device <NUM>).

In some implementations, the agent computer system <NUM> both generates the migration container and initiates a migration command to the cloud-computing service computer system <NUM>. <FIG> illustrates an example of one such method performed by the agent computer system <NUM>. As discussed above in reference to <FIG>, a user input identifies an existing webpage of a web application (step <NUM>) and initiates the migration process (step <NUM>) via a user interface. In the method of <FIG>, the agent computer system <NUM> receives that user input (step <NUM>) and generates the migration container in response (step <NUM>) (for example, according to the method illustrated in <FIG>). In some implementations, the agent computer system <NUM> then uploads the migration container to a storage location accessible by the cloud-computing service computer system <NUM> (step <NUM>) such as, for example, a cloud storage system or the service memory <NUM>. The agent computer system <NUM> then transmits an API call to the cloud-computing service (step <NUM>). The agent computer system <NUM> then waits for a response to the API call from the cloud-computing service (step <NUM>). Once a response to the API is received from the cloud-computing service (step <NUM>), the migration process is complete (step <NUM>). In some implementations, the agent computer system <NUM> outputs a visual confirmation notice to the user interface indicating that the migration to the cloud-computing environment is successfully completed. Alternatively or additionally, in some implementations, the agent computer system <NUM> transmits a message confirming completion of the migration through another mechanism including, for example, email or text message.

In the example of <FIG>, the agent computer system <NUM> performs the generation of the migration container and transmits the API call to the cloud-computing service computer system <NUM>. However, in other implementations, these individual steps might be performed by other computer systems. For example, in some implementations, a local user device where the web application is currently executed can be configured to serve as the "agent" - in other words, the local user device or client may be configured to generate the migration container and transmit the API call to the cloud-computing service computer system <NUM>. In other implementations, the "agent" functionality (e.g., as illustrated in the example of <FIG>) may be divided among multiple different computer systems. For example, the user device or client might be configured to first transmit a request to the cloud-computing service computer system <NUM> requesting generation of a migration container for the web application. In some such implementations, the cloud-computing service computer system <NUM> might be configured to automatically initiate the migration process (e.g., as discussed below in reference to <FIG>) in response to completing the generation of the migration container. In other such implementations, the cloud-computing service computer system <NUM> may be configured to notify the user device or client that the migration container has been generated and then await further instructions (e.g., an API call from the user device/client) before initiating the rest of the migration process.

<FIG> illustrates a method performed by the cloud-computing service computer system <NUM> for completing the migration of the web application to the cloud-computing environment in response to receiving the API call from the agent (i.e., step <NUM> in <FIG>). In response to receiving the migration API call from the agent (step <NUM>), the cloud-computing service computer system <NUM> determines whether service resources are available (step <NUM>). In this way, the cloud-computing service computer system <NUM> may delay completion of the migration or may perform the migration process asynchronously in order to ensure that computing resources required for the migration process are utilized during periods of relatively low usage. If sufficient service resources are not available at the time that the API call is received from the agent (step <NUM>), the cloud-computing service computer system <NUM> waits for a period of lower resource usage (step <NUM>) before beginning the migration process.

Once the cloud-computing service computer system <NUM> determines that sufficient service resources are available (step <NUM>), it accesses the migration container for the web application (step <NUM>), for example, from a cloud storage or from another location where the migration container had been stored by the agent. The cloud-computing service computer system <NUM> accesses the manifest from the migration container (step <NUM>) and begins to reconstruct the web page (i.e., the appearance and functionality of the web page) based on the information in the manifest (step <NUM>) including importing the web parts from the migration container into the reconstructed web application in the cloud-computing environment as dictated by the manifest (step <NUM>) and establishing interactions and connections between the web parts as dictated by the manifest. As described above, in some implementations, the migration manifest is an XML document and the cloud-computing service computer system <NUM> is configured to read and convert the XML of the manifest into a plurality of different elements that together recreate the web page for the web application as it appeared in the original operating environment. Also, because the migration manifest was generated based, in part, on metadata stored on one or more client devices, that metadata is preserved and reflected in the web application after migration to the cloud-computing environment. Accordingly, the appearance and functionality of the web application in the cloud-computing environment more closely matches the appearance and functionality of the web application on a particular client device in the original operating environment.

In some implementations, the migration process performed by the cloud-computing service computer system <NUM> (i.e., the reconstruction of the web application in the cloud-computing environment) may be automatically halted when resource usage in the cloud-computing service rises above a threshold level. In these cases, the cloud-computing service computer system <NUM> is configured to resume the migration process at either a specified time or in response to detecting that usage of the cloud-computing service resources has again dropped below the threshold.

After the migration process is completed by the cloud-computing service computer system <NUM> and the web application has been recreated in the cloud-computing environment (step <NUM>), the cloud-computing service computer system <NUM> transmits a response to the API call received from the agent (step <NUM>). The API response is transmitted to the agent and confirms that the migration of the web application to the cloud-computing environment has been completed.

In some implementations, the migration container used to facilitate the migration process is a temporary container. Accordingly, in some implementations, the cloud-computing service computer system <NUM> may be configured to automatically delete the migration container in response to completion of the migration process (step <NUM>). In other implementations, the cloud-computing service computer system <NUM> may instead be configured to retain the migration container in cloud storage for a defined period of time (step <NUM>) and deletes the migration container (step <NUM>) in response to the expiration of the retention period (step <NUM>). In still other implementations, the cloud-computing service computer system <NUM> is configured instead to retain the migration container in memory indefinitely (step <NUM>). In yet other implementations, the cloud-computing service computer system <NUM> may be configured to automatically delete or retain the migration container based on terms selected for or by the particular user requesting the migration.

In some implementations, as described in certain examples above, the entire web application, including all of the web parts, is migrated to the cloud-computing environment in only one API call. Accordingly, the need for frequent and repeated communication between the service and the agent (or between the service and other web servers) is eliminated. This simplifies the process and greatly reduces the burden on communication resources. Furthermore, by using a migration container, the migration process is "source-agnostic. " For example, because the migration manifest and all of the associated web parts for the web application are included in the migration container, the cloud-computing service computer system <NUM> may be configured to perform the same process for migration regardless of the original source operating environment. The migration manifest serves as the "template for creation" that is used by the cloud-computing service computer system <NUM> to reconstruct the web application in the cloud-computing environment.

Claim 1:
A method for migrating a web application from a source environment to a cloud service, the method comprising:
accessing (<NUM>), by a cloud service system, a temporary container containing a manifest and a plurality of web parts for the web application, wherein each web part of the plurality of web parts is a software component that generates web-based content for the web application during operation of the web application, wherein the manifest includes a list of contents of the temporary container and defines an appearance and functionality of the web application operating in the source environment;
reconstructing (<NUM>), by the cloud service system, the web application on the cloud service by automatically generating a user interface environment for the web application on the cloud service based on the manifest, and importing each web part of the plurality of web parts to the cloud service by configuring each web part and the user interface environment to interact as defined by the manifest, wherein the user interface environment on the cloud service replicates the appearance and functionality of the web application operating in the source environment;
receiving (<NUM>), by the cloud service system, a single API call requesting migration of the web application to the cloud service, wherein reconstructing the web application on the cloud service includes reconstructing the web application on the cloud service in response to receiving the single API call;
generating, by the cloud service system, a response to the single API call after reconstructing the web application on the cloud service, wherein the response to the single API call confirms that the migration of the web application to the cloud service is complete; and
identifying, by the cloud service system, one or more periods of relatively low usage of the cloud service after receiving the single API call, wherein reconstructing the web application on the cloud service includes reconstructing the web application on the cloud service asynchronously only during the one or more identified periods of relatively low usage of the cloud service,
wherein the periods of relatively low usage corresponds to periods when sufficient services resources required for the migration of the web application are available.