Shared components and methods between applications for web application development

Abstract

A system and method for creating and integrating shared components into a host platform. The system and method involves creating and integrating shared components into a host platform, wherein a microservice application on the host platform comprises a shared component and a microservice application, and communicates requests corresponding to the shared component (SC) application to a UX development platform, communicates the SC as a microservice shared component to a microservice application development platform, the microservice application development platform generates a microservice shared component package based on the shared component, and integrates the microservice shared component package, and the application is integrated using the microservice shared component on a request basis.

Description

Technical Field

[0001] (Cross - reference to Related Applications) This application claims the benefit of U.S. Patent Application No. 18 / 177,723, filed on March 2, 2023, which is a Continued - in - Part (CIP) of U.S. Patent Application No. 17 / 824,563, filed on May 25, 2022, the disclosure of which is incorporated herein by reference.

[0002] (Technical Field) The present invention relates to methods and standards for application packaging and integration, and more particularly, to application resource integration and deployment within a cloud.

[0003] (Background) Computer systems have several issues regarding the development and installation of updates and patches for hosted web applications. Software - as - a - Service (SaaS) web applications are integrated into a system by a vendor using special delivery and installation packages. However, when a vendor needs to integrate / deploy its applications within a cloud, the vendor has to repeat all integration operations multiple times for each host or hosting platform. Hosts and hosting platforms have applications that control the host or hosting platform. These applications are very difficult and costly to integrate with external (third - party) applications or web services.

[0004] Currently, the integration of applications into hosts and hosting platforms is performed by a controller. In the case of a cloud system, the cloud (or cloud server) is a combination of a host provider's software and hardware that provides the functionality of external applications in its client accounts.

[0005] In the field of cloud computing platforms, inefficiencies exist in the creation and deployment of client applications, alongside the operation of the platform itself. For example, cloud computing platforms may encounter problems with effective application development and / or host deployment. Software as a Service (SaaS) web applications are typically developed in close association with the platform host. Every process related to a new application in development is tightly tied to the deployment of the platform host stack. Such methods, combined with the need to solve application problems at a core level, have resulted in inconvenience and wasted time.

[0006] The main drawback of conventional technologies is that, when creating and deploying new applications, the platform host is required to communicate with packages that have unclear test environments within the package during application deployment. Furthermore, conventional technologies require excessive deployment time and a continuous internet connection during application creation. Therefore, there is a need in this technology for efficient and inexpensive methods for integrating applications themselves, updating applications, and patching to cloud platform hosts. [Overview of the Initiative]

[0007] The embodiments described herein provide shared component development. Specifically, the embodiments disclose a system and method for creating and integrating a shared component application into a host platform. The system and method may include communicating a requirements package corresponding to a microservice frontend application to a UX development platform, the UX development platform generating a mockup package based on the requirements package, communicating the mockup package to the microservice frontend development platform, the microservice application development platform generating a microservice frontend application package based on the mockup package, and integrating the microservice frontend application package, the vendor application being integrated using the microservice frontend application based on the requirements package.

[0008] Traditionally, front-end developers may encounter several challenges when developing microservices separately from the overall platform microservices for use on a platform host as part of a multi-microservices environment. Developing microservices via a platform host incurs additional development costs, including deployment and sandbox adjustments (i.e., to the stack and platform host). Even minor changes to microservice code may require redeploying all the code to the stack, resulting in a loss of transfer. Front-end developers are typically given requirements for UI (user interface) elements (buttons, fonts, colors, etc.) and must implement them from scratch each time. Developers need to consider many aspects in addition to describing how the microservices should appear in relation to the core of the business task itself—i.e., the application itself—and how the microservices should appear and function within a common interface (the platform host) to conform to a single experience.

[0009] In some embodiments, the SCD method and system may include a local microservice development mode that operates independently of the platform host, as described in detail in U.S. Patent Application No. 17 / 824,563, which is incorporated herein by reference in its entirety. In some embodiments, the SCD method and system may additionally include processes for mockups and tokenization, i.e., tokens maintained in a unified library of widgets that are supported independently of a particular application and available to front-end developers. In some embodiments, the SCD method and system may further include interactions between microservices and the outside world. For example, the SCD method and system may enable communication between shared components under development and other microservices, the host itself, a Representation State Transfer (REST) ​​request system, unit testing, application debugging, simulation of pre-host deployment communications, and the like.

[0010] In some embodiments, the SCD method and system may further include the use of a specific cloud framework as an integrated part of the process, providing front-end developers with everything they need and incorporating the results as an application. The framework pre-isolates the new microservices (web applications) into specific program layers. According to the embodiments described herein, task resolution is effectively achieved by well-organizing communication between different parts of the “blocks” involved in the entire web application creation process. Thus, faster application preparation, improved testing and debugging, and reduced application development costs can be obtained.

[0011] Such methods reduce the time front-end developers spend on new microservices and make them accessible to less skilled developers. SCD systems and methods require developers to simply combine software layers, perform a debugging process, and further deploy executable microservices to the stack and platform host. The vertical details of specific REST stores provide efficient connectivity between the front-end and back-end of the developed microservices, as described below, allowing developers to use the same code in modes such as local development (through data transfer level emulation), unit testing, and production (runtime).

[0012] According to embodiments of the present invention, a system and method for shared component development (SCD) to improve the application development process are provided. The SCD solution effectively addresses the aforementioned technical challenges and provides an independent application creation process at the platform host core level, and efficient application deployment to the platform host with minimal downtime.

[0013] A system and method for creating, sharing, and integrating vendor applications are provided. The system and method for application development and deployment may include: communicating framework packages corresponding to application frameworks by a host platform, wherein the framework packages include software abstractions for providing general-purpose functionality in the development of vendor applications; receiving application packages corresponding to vendor applications by the host platform, wherein the application packages include multiple metadata files, control method descriptions, and content files; and integrating the application packages to generate an integration of vendor applications based on the application framework.

[0014] According to some embodiments, the SCD system and method differ from prior art by creating and integrating shared component applications into a host platform. According to some embodiments, the system and method create and integrate shared components into a host platform, the host platform's microservices application comprising shared components and microservices applications, communicating requests to a UX development platform for shared component (SC) applications, communicating the SCs as microservice shared components to a microservices application development platform, the microservices application development platform generating a microservices shared component package based on the shared components, and integrating the microservices shared component package, the application being integrated using the microservices shared components on a request.

[0015] According to some embodiments, the shared component lifecycle methodology has its own process for sharing one platform application (e.g., a component) and using it in another. Embodiments of a system for shared component development (SCD) can include shared components (SC) from an application that wishes to use a component from another application. In some embodiments, the SC can include a first device and a second device. The first device may be a server, such as a host computer. The second device may be a computing device on which the application is developed. The SCD can initiate a step of performing a component download process. The first device can receive a request from the second device to download the application to the second device. This allows the first device to send a given application to the second device and have it deployed in a limited mode. In a non-limited example, the second device can deploy the application received from the first device in a limited mode, for example, limited to the main container activation of the application's home screen. The second device can retrieve a specified component from the application and register it in the global scope of the platform's rendering engine. For example, a specified component may be registered in a script such as VueJS.

[0016] In some embodiments, the SCD can initiate communication with the application indicating the completion of the download process and register the package in the global scope. If there is an error in one of the stages of the component loading process, the application receives a flag indicating the error. Subsequently, the SCD can allow components from another application (e.g., the first device) to be deployed into the application along with integrated logic and infrastructure, even if the application itself does not necessarily implement them. The SCD enables direct sharing at runtime, specifically through business component applications, allowing the business functionality layer of one application to be incorporated into another application without the other application determining internal ownership and logic. The SCD enables communication with the black box through input (input parameters)-output (component events) interfaces. These interfaces are compatible with component owners. The application owner can reuse components in their own application or task.

[0017] Furthermore, the same components can be used within the application itself. Components are not intended to be shared directly, but rather are created for other applications that will display them. Components that are expected to be shared can be added to a separate container. No separate flow is required to create specific components. This feature extends the host's functionality by optimizing the use of overlapping functional layers across different applications. Also, there is no need to know the internal implementation of a component, what components it consists of, what logic it has, or what network resources it accesses. For the application user, it is a black box with a public interface in the form of configuration input properties and outputs of various business events. In addition, the SC lifecycle has events that determine its current state (loading, loaded, error). This process of sharing one platform application and using it in another is unique.

[0018] Figure 1 shows an exemplary operating environment of a shared component development (SCD) system according to several embodiments. Figure 2 shows SCD systems according to several embodiments. Figure 3 illustrates methodologies for developing and delivering microservice frontends in an SCD system, according to several embodiments. Figure 4 illustrates an example of a computing device according to one embodiment. Figure 5 illustrates the integration of applications in SCD according to several embodiments.

[0019] For the purpose of facilitating an understanding of the principles of this disclosure, embodiments illustrated in the drawings are described herein using specific terminology. However, it should be understood that this is not intended to limit the scope of this disclosure in any way.

[0020] This embodiment may be implemented in hardware, firmware, software, or any combination thereof. Alternatively, this embodiment may be implemented as instructions stored in a machine-readable medium, which can be read and executed by one or more processors. The machine-readable medium may include any mechanism for storing or transmitting information in a format readable by a machine (e.g., a computing device). For example, the machine-readable medium may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and others. Furthermore, firmware, software, routines, and instructions may be described herein as performing specific actions. However, such descriptions are merely for convenience, and it should be understood that such actions are actually the results obtained by a computing device, processor, controller, or other device executing the firmware, software, routines, instructions, etc.

[0021] It should be understood that the actions shown in the illustrative methods are not exhaustive, and other actions may be performed before, after, or between any of the illustrated actions. In some embodiments of this disclosure, the actions may be performed in a different order and / or in a variable manner. [Brief explanation of the drawing]

[0022] [Figure 1] This illustrates an example of a system operating environment for independent application design and deployment to a platform host, based on several embodiments. [Figure 2] This describes a system for independent application design and deployment to a platform host, based on several embodiments. [Figure 3] This describes a set of methods for deployment to a platform host in an IADD system, based on several embodiments. [Figure 4]Depict the integration of applications rendered by a platform host in an IADD system according to some embodiments. [Figure 5] Depict the integration of applications rendered by a platform host in an IADD system according to some embodiments. [Figure 6] Depict a methodology for the handshake between a platform host and an application rendered by the platform host in an IADD system according to some embodiments. [Figure 7] Show the operating environment of an example of a system for shared component development (SCD) according to some embodiments. [Figure 8] Show an SCD system according to some embodiments. [Figure 9] Show a methodology for the development and delivery of a microservice front end in an SCD system according to some embodiments. [Figure 10] Show an example of a computing device according to some embodiments. [Figure 11] Show the object classes of applications within SCD according to some embodiments. **DETAILED DESCRIPTION OF THE INVENTION**

[0023] For the purpose of facilitating an understanding of the principles of the present disclosure, reference is made here to the embodiments illustrated in the drawings and they are described using specific language. However, it should be understood that no limitation of the scope of the present disclosure is thereby intended.

[0024] This embodiment may be implemented in hardware, firmware, software, or any combination thereof. Alternatively, this embodiment may be implemented as instructions stored in a machine-readable medium, which can be read and executed by one or more processors. The machine-readable medium may include any mechanism for storing or transmitting information in a format readable by a machine (e.g., a computing device). For example, the machine-readable medium may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and others. Furthermore, firmware, software, routines, and instructions may be described herein as performing specific actions. However, such descriptions are merely for convenience, and it should be understood that such actions are actually the results obtained by a computing device, processor, controller, or other device executing the firmware, software, routines, instructions, etc.

[0025] It should be understood that the actions shown in the illustrative methods are not exhaustive, and other actions may be performed before, after, or between any of the illustrated actions. In some embodiments of this disclosure, the actions may be performed in a different order and / or in a variable manner.

[0026] (Application creation) The embodiments described herein are directed toward SCD methods and systems that can include a local microservices development mode that operates independently of a platform host, as detailed in U.S. Patent Application No. 17 / 824,563, which is incorporated herein by reference in its entirety. The IADD system and method are provided to address the above technical challenges. The IADD system and method provide a specific layer for local vendor applications that are independent of a platform host. This enables application development even in non-persistent internet connectivity modes.

[0027] Figure 1 illustrates an IADD system according to several embodiments. As shown in Figure 1, the IADD system 100 provides an ecosystem for various projects that can be separated based on, for example, functionality, responsiveness, and team. The IADD system 100 includes a development platform 110, a bundle 120, and a platform host (hosting cloud) 130.

[0028] As depicted, application creation on the development platform 110 is separate from the platform host 130 itself. According to an exemplary embodiment, one or more frameworks relate the application on the development platform 110 to the (production) application on the platform host (130). That is, the frameworks interconnect the respective applications. The frameworks provide basic templates necessary for application and testing on the development platform 110. The frameworks further provide specific means necessary for integrating and deploying the application on the platform host (hosting cloud) 130.

[0029] In an exemplary embodiment, the development platform 110 includes an application 102 and a framework 104. The application 102 may contain code written by a developer. The framework 104 (e.g., VUE) may provide a software abstraction to provide general-purpose functionality that can be selectively adapted and implemented by the application 102, thereby providing purpose-specific software, such as for building user interfaces. The framework 104 may provide this abstraction built on top of a standard programming language (e.g., HTML, CSS, JavaScript, etc.) and provides a declarative and component-based programming model that enables the efficient development of purpose-specific software, such as user interfaces, whether simple or complex.

[0030] If IADD100 is configured to deploy application 102, the development platform 110 can generate an application bundle 120 that implements application 102 and framework 104 as standalone components, all within a single container. According to an exemplary embodiment, a developer (e.g., a cloud application vendor) can bundle application 102 and framework 104 according to APS. The format of the bundle depends on the receiving side, e.g., platform host 130. If the receiving side is a standard Windows desktop, the software can be packaged using a standard installer, and the file has the extension *.exe or *.msi. The installer includes unpacking rules, including user dialogs, registry writes, and update confirmations. In the case of APS, the bundle may have the extension app.zip and include metadata, scripts, and the software code itself.

[0031] An exemplary development application 102 is transferred to the platform host 130 via the application bundle 120. Application 132 is generated internally on the platform host 130. The platform host 130 includes application 132, a framework 134, an adapter 136, and an Application Packaging Standard (APS) module 138.

[0032] Adapter 136 connects frameworks 104 / 134 to the platform host at runtime and renders the interpreting application 132 and framework 134 as web applications that provide an interface to the client via the APS module 138.

[0033] The APS module 138, also referred to as the controller or application packaging controller, is a runtime module configured to distribute application 132 to client 140. As shown in Figure 1, a single application can be delivered to one or more clients. APS is a specification that defines the lifecycle of application 132 in the cloud. The application lifecycle includes packaging, delivery to the cloud, integration (and unpackaging / deployment) within the cloud, distribution to clients, licensing, functionality, updates, and deletion. APS can include an application programming interface (API) for accessing APS functionality from program code or via http / https requests. APS provides efficient integration of SaaS web applications, such as application 132, into the cloud. According to an exemplary embodiment, in order for the application to function according to APS, the APS module 138 (i.e., the controller) is integrated into the software hosting platform of the hosting cloud (platform host 140).

[0034] The APS module 138 functions as a connector for controlling application 132. The APS module 138 receives application control requests and distributes these requests to the appropriate scripts in the application APS package 120. The application 132's response to client 140 (outside the cloud 100) is also processed by the controller module 110 and provided to client 140. To integrate the application, the APS module 138 can apply a framework 134 to verify the format and structure of the application package (e.g., bundle 120), the metadata of the metadata file, and the functionality of at least one application programming interface (API) of the vendor application.

[0035] Figure 2 illustrates the communication between the application and the platform host. As shown in Figure 2, the system 200 comprises a local development application 210 and a platform host 230. The local development application 210 comprises an adaptive layout framework 220 (skeleton) and a preset module 222, which can include a rapid development system preset. A preset can include, for example, one or more plugins with several optional configurations. For example, a preset can contain plugins / options bundled together with other configuration options, so that selecting a preset would mean selecting all of those options.

[0036] For example, a default preset may include plugins (e.g., Babel, Typescript, Vuex, ESLint, Unit-Jest, etc.) as options / features. When a developer selects a default preset, a local development application 210 is created, allowing utility modules to be installed during project creation. In addition, or alternatively, the developer can also manually select desired options and plugins. Presets allow for faster project creation. The preset module 222 works in conjunction with the adaptive layout framework 220 (skeleton).

[0037] As described above, the environment is prepared with the framework as an auxiliary layer. The framework provides everything needed for a new application decoupled from the production stack, and this can also be used for testing. As will be explained in more detail below, the application can be compiled into a bundle file that communicates dynamically to the platform host, allowing for optimized communication and implementation to the platform host. The bundle file can be prepared as a set of asynchronous web components that can be communicated in parts when opening a new page representation of the application.

[0038] According to several embodiments, the platform host 230 may comprise a user experience (UX) framework module 240, a UX user interface (UX-UI) kit module 250, and a UX-UI theme module 260. The UX framework module 240 comprises runtime components for local development and testing that operate at runtime. For example, the platform host 230 may be an embodiment of the platform host 130. In some embodiments, the platform host 230 may include a UX-UI kit module 250, which uses a set of components (UI blocks) and provides means for creating a ready-to-use form via mockups, as a private portion integrated into the UX framework module 240. The UX-UI theme module 260 provides a repository containing design tokens, global styles, and override styles, i.e., elements that represent design decisions and values.

[0039] Unlike traditional deployment processes, a Hot Module Replacement (HMR) process can be implemented, allowing the development of application 210 using the environment of a framework (e.g., corresponding to UX framework 240). Therefore, developers can evaluate changes to application 210 without deploying the application to platform host 230.

[0040] The platform host 230 may receive a first indicator from the IADD system 200. According to some embodiments, the platform host 230 may be triggered to request the status of the local development application 210 in response to prompts from the IADD system 200, requests from the local development platform, scheduled events, etc.

[0041] In response to receiving the first indicator, the platform host 210 performs an action to receive the development application 210. In some embodiments, the platform host may request and wait for the transmission of the development application 210. In some embodiments, the transmission is performed asynchronously.

[0042] After receiving a transmission containing the development application 210, the platform host 230 can then perform the process of integrating the application. In some embodiments, the platform host 230 integrates the application while minimizing downtime by continuing the current version of the application's runtime (which may be the APS runtime). For example, in some embodiments, the platform host 230 can integrate the application by synchronously applying web components. In some embodiments, the platform host 230 can provide a supplementary layer (e.g., a framework 240) to the development platform. The framework 240 includes a basic abstraction of the operating environment and can enable the development platform to be configured as needed to develop applications in a decoupled stack format. The framework 240 provides foundational support for the application architecture used for application development and testing.

[0043] The compiled bundle file can be provided to be dynamically downloaded to the platform host. This optimizes the download of the file to the platform host. The bundle file can be prepared as one or more asynchronous web components that can be downloaded incrementally as a new page (i.e., the application's path or representation) is rendered by the APS adapter.

[0044] At the same time, the final bundle file does not contain the primary vendor library code. This code is downloaded directly to the host from framework 240. In this way, application deployment can be performed while minimizing the size of the bundle file, in which case the bundle file contains only specific business layer code. The IADD system and methodology enables the organization of web components to optimize platform host deployment. Web components provide a new, isolated layer of application, independent of the platform host.

[0045] Therefore, the IADD system and method are configured so that new applications can coexist alongside older applications without affecting each other. In other words, new and old applications coexist with the optimal platform host load.

[0046] By providing supplementary functionality to frameworks for local application development (e.g., Adaptive Layout Framework 220), a convenient debugging process becomes possible, which may include the use of specific real-time means such as utility tools (e.g., VUE DEVTOOLS) to assist developers in developing applications.

[0047] Due to the independent application creation mode, which eliminates the need to send code to the stack for review every time, faster application creation is achieved, thereby enabling the achievement of set business objectives more quickly than before. This process organization brings convenience to the process and reduces time. Additional benefits include more reliable application and patch deployment. The framework provides the same environment for runtime, testing, and local development. At the framework level, each possible runtime use case is considered, enabling development by focusing on specific business layers. In this way, a smoother transition from the old workflow to the new workflow is achieved, allowing for phased development with minimal unnecessary downtime.

[0048] (Integration) Figure 3 shows an IADD methodology 300 for deploying a new workload integrated at APS runtime. By utilizing specific descriptive parameters, a new application can be deployed using a framework that provides means for APS integration. According to the embodiment, the IADD methodology 300 enables new and old applications to run concurrently.

[0049] As shown in Figure 3, in operation 310, the platform host 230 can receive application metadata corresponding to an application, such as an APS application. In operation 320, the platform host 230 determines whether the framework is loaded. Based on this determination, the platform host (e.g., the UX framework module 240) can retrieve and start the framework as a supplementary layer that can include a basic abstraction of the operating environment. Thus, the platform host 320 is configured at runtime to maintain supplementary support, including support for the application architecture under development. These supplementary features facilitate the debugging process and minimize downtime for production applications such as the APS runtime.

[0050] Figure 4 illustrates an IADD system 400 with a container as a controller representing an application that utilizes a set of web components. As shown in Figure 4, in order to render application 410 to a client (for example, client 140), application 410 is represented as a set of web components such as route 420.

[0051] System 400 comprises one or more containers that function as controllers 415 for application 410. Controller 415 acts as a higher layer over one or more web components, i.e., routes 420, configured to organize the flow and behavior of other web components. Route 420 is a web component that can be provided with the organization implemented by controller 415. Route array 420 comprises one or more routes and provides a library for page navigation (routes) of the application, for example, the web application. Each route 420 is another view that the web application 410 can render (e.g., the current route 422) or hide as requested by user navigation, for example. Application 410 may include a specific representation with an internal physical structure. Thus, application 410 itself represents web components, i.e., routes 420, configured to control other web components.

[0052] Figure 5 illustrates the browser application deployment process 500. As shown in Figure 5, the browser application deployment process 500 may include an action 501 that initializes a localization scheme 505 and configures the web components.

[0053] In operation 502, the web components configured by the localization scheme 501 are integrated into the container 515 by the controller 510. For example, the initial (i.e., home) route can be integrated into the container 515.

[0054] Operation 503 may include an operation to split the bundle into application bundle chunks 520. Operation 503 may include an integration of each chunk 520 that has or can have a specific webroot component.

[0055] In action 504, once each web component has been added to the browser, the initial application lifecycle can proceed. Action 504 may include rendering the application configured for a client (for example, client 140).

[0056] (Platform-host handshake) Figure 6 illustrates a process 600 for performing a new deployment of an application (which could be an embodiment of application 102 deployed as, for example, application 132, application 210, 410, etc.). Process 600 includes a handshake between the application provided by the local development platform (e.g., platform 110) and the platform host (e.g., platform host 130), allowing the application deployment to run at runtime. As shown in Figure 6, after the application has been developed, it can be deployed to the platform host.

[0057] In operation 605, the platform host 601 can perform operations corresponding to the creation of a web component, such as sending the connected web component to an application (for example, a container such as the main container).

[0058] In operation 610, the connected web component is mounted in container 602. Operation 610 may include initiating a handshake between container 602 and platform host 601.

[0059] In operation 615, data including a first indicator, such as a flag, may be communicated between the container 602 and the platform host 601 to indicate that the application is ready for deployment.

[0060] In operation 620, the platform host 601 waits for communication of the first indicator. Upon receiving the first indicator, the platform host 601 can be configured to start a deployment process, which may be an embodiment such as the deployment process 500.

[0061] In operation 625, upon receiving the first indicator, the platform host 601 may be configured to integrate the corresponding application parameters as described above.

[0062] In operation 630, after configuring the application parameters, the platform host 601 may communicate data including a second indicator that the application is being deployed.

[0063] In operation 635, the application waits for communication of a second indicator. Upon receiving the second indicator, container 602 sets the application's parameters (for example, the “public” parameter) in operation 640 and allows the runtime process to render the application. Operation 640 may include, for example, setting parameters to allow the APS runtime to render to client 140 by platform host 130.

[0064] (Event System) According to an exemplary embodiment, an event-based system interaction methodology is provided to enable coordination between a vendor application development platform and a platform host. The event-based system interaction methodology comprises one or more processes for creating a specific event-controllable system, which may be, for example, an embodiment of system 100. The event-based system interaction methodology enables coordination to be achieved without robust communication between the vendor application development platform and the platform host, and allows vendor applications to be modified independently. This event-based methodology offers advantages over conventional processes that require a robust dependency between the development platform and the platform host, while enabling the local development and host runtime environments to be managed as predictable behavior.

[0065] According to some embodiments, the interaction between the host platform and the vendor application development platform additionally enables the coordination of one or more platform frameworks between the platform host and the development platform. According to exemplary embodiments, these interactions may include (A) a vendor application development platform that sends events with one or more frameworks to the platform host, and (B) a vendor application development platform that subscribes to platform host events. In some embodiments, (1) private events with one or more frameworks may be, for example, internal use events sent from the application to the host platform; (2) private events may be, for example, internal use events sent from the platform host to the application; (3) public events with one or more frameworks may be, for example, public use by the UX1 framework developer sent from the application to the platform host; and (4) public events may include abstractions sent from the platform host to the vendor application development platform to provide general-purpose functionality that can be selectively adapted and implemented by, for example, application 102.

[0066] This event-based methodology can be configured to perform basic system communication. Such communication may include information used for, for example, routing, notifications, and sending analytical data (such as Google Analytics data), and the event-based methodology can be configured to share components associated with application functionality.

[0067] The resulting solution is flexible and can be extended without limitation to any number of new features (system communication). Bidirectional system interaction between the platform host and the application is performed using a proprietary framework system, which may include providing one or more web components configured to organize the interaction at the native browser level. According to some embodiments, the IADD event system allows the application and platform host under development to be modified independently without requiring a strong bundle or dependencies.

[0068] (Shared component integration) In some embodiments, the SCD method and system may additionally include processes for mockups and tokenization, i.e., tokens maintained in a unified library of widgets that are supported independently of a specific application and available to front-end developers. In some embodiments, the SCD method and system may further include interactions between microservices and the outside world. For example, the SCD method and system may enable communication between shared components under development and other microservices, the host itself, a Representation State Transfer (REST) ​​request system, unit testing, application debugging, simulation of pre-host deployment communications, and the like.

[0069] To address the aforementioned technical issues, a Shared Component Development (SCD) system and methodology is provided. The SCD system and methodology provides a specific layer to the vendor microservice application frontend, thereby providing frontend developers with all the necessary resources, and the application is returned as an integrated part of the process. SCD facilitates task resolution and effectively organizes and enables communication between different components of the web application creation process block. The SCD system and methodology enables timely application preparation and improved testing and debugging. Thus, better end-user application operability is achieved while reducing application development costs. Frontend developers are enabled to specifically combine software layers, perform the debugging process and deployment, while minimizing the time and effort spent on developing new microservices. The SCD system and methodology includes specific REST store vertical details to provide a more effective connection between the frontend and backend of microservices, enabling developers to use a single code compilation for modes such as local development (at an emulated data transfer level), unit testing, and runtime (i.e., production).

[0070] Figure 7 illustrates an SCD system according to several embodiments. As shown in Figure 7, the SCD system 700 provides an ecosystem for multiple projects that can be separated, for example, based on functionality, responsibility, and team. The SCD system 700 comprises a first device 710 and a second device 720.

[0071] The first device 710 may include a first REST store vertical, a shared component (SC) 714, and an additional component 716. The second device 720 may include a second REST store vertical and SC 714, as described above.

[0072] As described above, each application will have a system component (SC714) that enables the use of the application's tiled components. To achieve this, the SCD700 allows two main parameters to be communicated between the first device 710 and the second device 720: the application ID and the name of the component intended for use / sharing. During implementation, additional supported parameters can be communicated to configure the SC, and the application can subscribe to component events.

[0073] As shown in Figure 8, SC714 has its own lifecycle. SCD800 can initiate a step that performs the component download process. The first device 710 can receive a request from the second device 820 to download an application to the second device. The first device 710 can send SC714 to the second device 820 to be deployed in a restricted mode. In a non-restrictive example, the second device 710 can deploy the SC714 received from the first device 710 in a restricted mode, for example, limited to launching the main container of the application's home screen. The second device 820 can obtain SC814 from the application on the first device 810 and register it in the global scope of the platform's rendering engine, which is implemented based on modules 812 (812.1~812.n) obtained from the root service 812. SC814 can implement one or more components 816.1-816.n obtained from the component root store 818 (roots 818.1-818.n) (for example, within the main container). If SC814 is needed but does not exist, developers can request to share it further by simply specifying a component storage or folder, as shown below.

[0074] The specified component can be registered with a script such as VueJS. SC814 enables the use of tiled components in an application. In some embodiments, SCD can cause the application to send a communication indicating the completion of a download process that registers the package in the global scope. If there is an error in one of the stages of the component loading process, the application receives a flag regarding it. Subsequently, SCD800 can allow components from another application (e.g., the first device 810) to be deployed into the application along with integrated logic and infrastructure, even if the application itself does not necessarily implement them. SCD enables direct sharing at runtime 802, specifically through a business component application, allowing the business functionality layer of one application to be incorporated into another application without the other application determining internal ownership and logic. SCD800 enables communication with a black box through an input (input parameters)-output (component events) interface. These interfaces are compatible with component owners. The application owner can reuse this component in their own application or task.

[0075] Furthermore, the same components can be used within the application itself. Components are inherently assumed to be created not for direct sharing, but for other applications in which they appear. Components intended to be shared can be further added to separate containers. A separate flow is not required to create specific components. This feature extends the host's functionality by optimizing the use of overlapping functional layers across different applications. And, without needing to know the internal implementation of a component, what components it consists of, what logic it has, or what network resources it accesses, it is a black box to the application's user, with an exposed interface in the form of input properties for configuration and outputs of various business events, plus SC lifecycle events, which determine its current state (loading, loading complete, error). This process of sharing one platform application for use in another application is unique.

[0076] The root store 818 acts as a higher layer for one or more web components configured to organize the flow and behavior of other web components, i.e., routes 818.1 to 818.3n. A route 818 is a web component that can be provided with an organization implemented by a controller (e.g., controller 415). A route array 818 has one or more routes and provides a library for page navigation (routes) in an application, such as a web application. Each route 818 is another view that the web application (e.g., 602) on the first device 810 can render (e.g., the current route 812) or hide as requested by user navigation. An application 814 can contain a specific representation with an internal physical structure. Thus, application 814 itself represents a web component, i.e., a route 818, configured to control other web components.

[0077] The root store 818 is configured to act as a top layer for one or more web components, for example, by connecting to the REST store layer 630 via an API and organizing the flow and behavior of other web components. The REST layer 712 can be configured to connect to the microservice backend application and the Application Packaging Standard (APS) bus. The REST layer 712 can be configured to make data requests to the microservice backend application and the Application Packaging Standard (APS) bus and to retrieve data.

[0078] This environment includes a support framework (FW) layer. The FW provides everything needed for a new application in a decoupled stack format. In addition, the same single FW can be used for creating unit tests.

[0079] The integration of a new application may further involve the creation of a compiled bundle file that is dynamically downloaded to the platform host. Furthermore, the file download to the platform host is optimized. The aforementioned file is prepared as a set of asynchronous web components that can be downloaded in parts when a new page representation of the application is opened. Simultaneously, the final bundle file does not contain primary vendor library code; this code is downloaded directly from the FW to the host. In some embodiments, the final bundle file contains specific business layer code that provides only the minimum bundle file size. Such process organization provides optimal and efficient platform host deployment.

[0080] Figure 9 shows the SCD system 900, including the lifecycle of SC814 / 914 (indicated as SC call 914), in relation to the main container 920. As shown in Figure 9, in one embodiment, the main container 900 may include hooks configured to start or stop processes in response to events, for example. The main container 900 may further include addListener events for handling processes associated with the vue application 910, including the shared component call 914.

[0081] SC call 914 can call a shared component from the UX1 framework 904, which may be an embodiment of SC814. An example of SC call 914 is shown in Figure 11 (for example, SC script 1100). Root store 912 may be an embodiment of root store 812, and component roots 918.1~918.n may be an embodiment of the component roots 818.1~818.n described above. For example, SC914 can implement one or more components 816.1~816.n obtained from component root store 818 (roots 818.1~818.n) (for example, within main container 920). If SC814 is needed but does not exist, the developer can specify a component storage or folder and request that it be shared further, as shown below.

[0082] As shown in Figure 9, a specified component can be registered with a script, for example, VueJS. SC914 invokes the use of SC814 in any application's tiled components. In some embodiments, SCD can cause the application to send a communication indicating the completion of the download process that registers the package in the global scope. If there is an error in one of the stages of the component loading process, application 910 receives a flag regarding it. As mentioned above, SCD900 can allow components from other applications to be deployed into the application along with integrated logic and infrastructure, even if the application itself does not necessarily implement them. SCD900 enables direct sharing within runtime 902, specifically by being available through business component applications, allowing the business functionality layer of one application to be incorporated into another application without another application determining internal ownership and logic.

[0083] SC914 may contain a specific representation with an internal physical structure. Therefore, application 914 itself represents a web component, namely root 918, configured to control other web components.

[0084] Various embodiments can be implemented using one or more computer systems, such as the computer system 1000 shown in Figure 10. One or more computer systems 1000 can be used, for example, to implement any of the embodiments described herein, as well as combinations and subcombinations thereof. For example, computer system 1000 can be used to implement system 100 for the development and deployment of a shared component application, including the framework 700 in Figure 7, and / or for other implementations of the disclosed embodiments.

[0085] The computer system 1000 may include one or more processors (also called a central processing unit or CPU), for example, processor 1004. Processor 1004 may be connected to a communication infrastructure, i.e., bus 1006.

[0086] Furthermore, the computer system 1000 may include user input / output devices 1008 such as a monitor, keyboard, and pointing device, which can communicate with the communication infrastructure 1006 through the user input / output interface 1002.

[0087] One or more of the processors 1004 may be graphics processing units (GPUs). In some embodiments, the GPU may be a processor that is a special electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.

[0088] Furthermore, the computer system 1000 may include main or primary memory 1008, such as random access memory (RAM). The main memory 1008 may include one or more levels of cache. The main memory 1008 may have control logic (i.e., computer software) and / or data stored internally.

[0089] Furthermore, the computer system 1000 may include one or more secondary storage devices or memories 1010. The secondary memory 1010 may include, for example, a hard disk drive 1012 and / or a removable storage device or drive 1014. The removable storage drive 1014 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, a tape backup device, and / or other storage device / drive.

[0090] The removable storage drive 1014 can interact with the removable storage unit 1018. The removable storage unit 1018 may include a computer-accessible or computer-readable storage device having computer software (control logic) and / or data stored thereon. The removable storage unit 1018 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and / or other computer data storage device. The removable storage drive 1014 can read from and / or write to the removable storage unit 1018.

[0091] The secondary memory 1010 may include other means, devices, components, mediators, or other approaches to enable computer programs and / or other instructions and / or data to be accessed by the computer system 1000. Such means, devices, components, mediators, or other approaches may include, for example, a removable storage unit 1022 and an interface 1020. Examples of the removable storage unit 1022 and interface 1020 may include a program cartridge and cartridge interface (such as those found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and / or other removable storage units and associated interfaces.

[0092] The computer system 1000 may further include a communication or network interface 1024. The communication interface 1024 may enable the computer system 1000 to communicate with and interact with a combination of external devices, external networks, external entities, etc. (referenced individually and collectively in reference number 1028). For example, the communication interface 1024 may enable the computer system 1000 to communicate with an external or remote device 1028 via a communication path 1026, which may be wired and / or wireless (or a combination thereof) and may include a combination of LAN, WAN, Internet, etc. Control logic and / or data may be transmitted to and from the computer system 1000 via the communication path 1026.

[0093] Furthermore, the computer system 1000 may be, to give some non-limiting examples, a personal digital assistant (PDA), a desktop workstation, a laptop or notebook computer, a netbook, a tablet, a smartphone, a smartwatch or other wearable, an appliance, part of the Internet of Things, and / or an embedded system, or any combination thereof.

[0094] Computer system 1000 may be a client or server that accesses or hosts any application and / or data through any delivery norm, and may include, but is not limited to, remote or distributed cloud computing solutions, local or on-premises software ("on-premises" cloud-based solutions), "as a service" models (e.g., Content as a Service (CaaS), Digital Content as a Service (DCaaS), Software as a Service (SaaS), Managed Software as a Service (MSaaS), Platform as a Service (PaaS), Desktop as a Service (DaaS), Framework as a Service (FaaS), Backend as a Service (BaaS), Mobile Backend as a Service (MBaaS), Infrastructure as a Service (IaaS), etc.), and / or hybrid models that include any combination of the aforementioned examples or other services or delivery norms.

[0095] Any applicable data structures, file formats, and schemas in computer system 1000 may be derived from standards including, but not limited to, JavaScript Object Notation (JSON), Extended Markup Language (XML), Yet Another Markup Language (YAML), Extended Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations, either alone or in combination. Alternatively, proprietary data structures, formats, or schemas may be used, either exclusively or in combination with known or open standards.

[0096] In some embodiments, a tangible non-transient device or product comprising a tangible non-transient computer-usable or readable medium having stored control logic (software) may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, a computer system 1000, main memory 1008, secondary memory 1010, and removable storage units 1018 and 1022, as well as a tangible product embodying the aforementioned combination. When such control logic is executed by one or more data processing devices (such as computer system 1000), such data processing devices can be made to operate as described herein.

[0097] It should be understood that the actions shown in the illustrative methods are not exhaustive, and other actions may be performed before, after, or between any of the illustrated actions. In some embodiments of this disclosure, the actions may be performed in a different order and / or in a variable manner.

[0098] It should be understood that the detailed description, rather than the abstract, is intended to be used to interpret the claims. The abstract may describe one or more embodiments of the invention intended by the inventors, but not all of which are exemplary, and is therefore not intended to limit the invention and the appended claims in any way.

[0099] The present invention has been described above with the help of function building blocks that illustrate the implementation of specific functions and their relationships. The boundaries of these function building blocks are arbitrarily defined herein for the sake of explanation. Alternative boundaries can be defined, as long as the specific functions and their relationships are properly performed.

[0100] The prior description relating to specific embodiments fully illustrates the general nature of this disclosure and, by applying the knowledge of those skilled in the art, such specific embodiments can be readily modified and / or applied to various uses without departing from the general concept of the invention and without performing any unnecessary experimentation. Such applications and modifications are therefore intended to be within the meaning and scope of the equivalent embodiments disclosed, based on the teachings and guidance presented herein. The expressions and terms herein are for illustrative purposes only and should therefore be understood to those skilled in the art to be interpreted in light of the teachings and guidance.

[0101] The breadth and scope of the present invention should not be limited by any of the exemplary embodiments described above, but should be defined solely by the following claims and their equivalents.

Claims

1. A method for creating a shared component and integrating it into a host platform, wherein the microservice application on the host platform comprises the shared component and the microservice application, and the method Communicating requests to the UX development platform for shared component (SC) applications, As a shared microservice component, the SC communicates with the microservice application development platform, The aforementioned microservices application development platform generates a microservices shared component package based on shared components, A method for integrating the microservice shared component package, wherein an application is integrated using the microservice shared component based on the requirements.

2. The method according to claim 1, further comprising generating the microservice shared component, communicating errors associated with the request in order to deploy the SC.

3. The method according to claim 1, further comprising generating the microservice shared component to share the SC with the runtime of a microservice application.

4. The method according to claim 1, further comprising generating the microservice shared component to generate the business function layer of one application implemented in another application.

5. The method according to claim 1, further comprising generating the microservice shared component to deploy the SC in a limited mode of the microservice application.

6. The method according to claim 1, further comprising generating the microservice shared component by deploying the SC within the main container activation of the home screen of the microservice application.

7. The method according to claim 1, further comprising generating the microservice shared component by registering the SC within the global scope of the rendering engine of the microservice application platform.

8. A system for creating and integrating shared components into a host platform, wherein the microservices application of the host platform comprises the shared components and the microservices application, and the system Communicating requests to the UX development platform for shared component (SC) applications, As a shared microservice component, the SC communicates with the microservice application development platform, The aforementioned microservices application development platform generates a microservices shared component package based on shared components, A system comprising a processing system having one or more processors that execute computer-readable instructions causing an application to integrate the microservice shared component package based on the request, and to integrate the microservice shared component.

9. The system according to claim 8, further comprising generating the microservice shared component to notify errors associated with the request in order to deploy the SC.

10. The system according to claim 8, further comprising generating the microservice shared component and sharing the SC with the runtime of a microservice application.

11. The system according to claim 8, further comprising generating the microservice shared component to generate the business function layer of one application implemented in another application.

12. The system according to claim 8, further comprising generating the microservice shared component to deploy the SC in a limited mode of the microservice application.

13. The system according to claim 8, further comprising generating the microservice shared component by deploying the SC within the main container activation of the home screen of the microservice application.

14. The system according to claim 8, further comprising generating the microservice shared component by registering the SC within the global scope of the rendering engine of the microservice application platform.

15. A computer program for creating a shared component and integrating it into a host platform, wherein the host platform's microservice application comprises the shared component and the microservice application, and the computer program comprises computer-readable program code that, when obtained from a non-temporary computer-readable medium, can be executed by at least one processor, and the program code is to the processor, Communicating requests to the UX development platform for shared component (SC) applications, As a shared microservice component, the SC communicates with the microservice application development platform, The aforementioned microservices application development platform generates a microservices shared component package based on shared components, A computer program comprising instructions configured to cause an application to integrate the microservice shared component package, which is integrated using the microservice shared component based on the request.

16. The computer program according to claim 16, further comprising generating the microservice shared component and sharing the SC with the runtime of a microservice application.

17. The computer program according to claim 16, further comprising generating the microservice shared component to generate the business function layer of one application implemented in another application.

18. The computer program according to claim 16, further comprising generating the microservice shared component to deploy the SC in a limited mode of the microservice application.

19. The computer program according to claim 16, further comprising generating the microservice shared component by deploying the SC within the main container activation of the home screen of the microservice application.

20. The computer program according to claim 16, further comprising generating the microservice shared component by registering the SC within the global scope of the rendering engine of a microservice application platform.

Images