System and method for message broker migration in application environment migration - Patents.com

Abstract

The method for message broker migration includes evaluating (412) a source message broker, scanning the broker (412) to identify connections between components (412a, 412b, ..., 412n), ascertaining an amount of change for migrating the broker (412) to a target message broker (430), predicting evaluation statistics (302) that provide at least one functional readiness (304) and timeline (306) for completing migration of the broker (412), and further generating a transformed message broker structure (550a, ..., 550n) by partitioning the broker (412) according to the target message broker (430) while maintaining the connections. Thereby, updating the fine-grained message broker components (552a, ... , 552n) of the target message broker (430) according to the predicted evaluation statistics (302) and the transformed message broker structure (550a, ... , 550n), and migrating the broker (412) to the target message broker (430) by replatforming the updated fine-grained message broker components (552a, ... , 552n).

Description

[Technical Field]

[0001] FIELD OF THE INVENTION The present disclosure relates generally to the field of computers, and more particularly, to a system and method for message broker migration in application environment migration that allows users to automatically migrate message brokers from an on-premise environment to a cloud environment without tedious and time-consuming user intervention while maintaining structural integrity and quality standards.

[0002] As times change, so does technology, from the invention of the wheel, we now stand in an era where our commute can be ordered through a mobile device. Thus, technology has made a giant leap from an era where computers were as big as ballrooms to the current era where they are as small as a thumbnail. Little by little, we have carved out technologies that help mankind through multiple applications. In this ever-changing and ever-changing field of technology, the application environment keeps improving, and with these advanced requirements, applications need to be kept updated.

[0003] Communication and data exchange between software systems is inevitable. Middleware enables communication and data exchange between distributed systems. Middleware technologies are classified into various categories, and message brokers are one of them. Messaging is a method of exchanging messages from point A to point B or multiple points. It is a way of decoupling software systems. A message sender (producer) sends a message to a message receiver (consumer), and the message receiver can receive a message from the message sender; the producer and consumer do not need to be available at the time to communicate. A message broker sends messages from one application to another, using a queue as an intermediate stage. The message remains in the queue until it is retrieved by the consumer. The advantage of this system is that it promotes an asynchronous method of communication, and the receiving system does not need to be available at the time the message is sent. Messaging models are generally classified into a point-to-point model, where a message is sent to a single consumer, and a publish-subscribe model, where a message is sent to many subscribers.

[0004] Traditionally, message brokers from on-premise application environments have been migrated to cloud environments by completely recreating the message broker for the newer environment, which is time-consuming and does not provide much benefit to the existing message broker ecosystem. As environments update more rapidly, newer versions are released by the time the message brokers are migrated to the newer environment, leaving insufficient time to manually update all of the message brokers. Additionally, migrating message brokers to different environments presented its own challenges, including, but not limited to, ensuring that connectivity is not lost during the conversion and ensuring a compatible migration between the older and newer environments.

[0005] Cloud adoption has become mainstream as enterprises leverage the cloud as a critical part of their IT strategies. This is evident in the year-over-year growth of major cloud providers such as AWS, Azure, and GCP over the past few years. In the initial phase, these enterprises successfully adopted the cloud by developing new applications on the cloud using cloud-native design principles and hosting message brokers on cloud solutions. Having realized this success, enterprises are now exploring how to migrate the rest of those critical applications to the cloud to maximize the benefits of the cloud. However, the challenge is that migrating existing applications to the cloud presents another set of issues, such as determining the right cloud migration approach, balancing risks, the cost and timeline for completing a cloud migration, the complexity of existing applications, especially older message brokers or applications without SMEs, maximizing total cost of ownership (TCO) savings, and increasing productivity, execution speed, and performance improvements for future releases.

[0006] Since migration of message brokers in application environments requires complex parameters and efforts, there is a need to develop a system and method for message broker migration in application environment migration that migrates message brokers from on-premise to cloud environment without or with minimal manual assistance while addressing various issues related to message brokers, their connections and their components along with crunching in time for regular updates. Summary of the Invention

[0007] This Summary is provided to introduce concepts related to systems and methods for message broker migration in application environment migration, which concepts are further described below in the Detailed Description. This Summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining or limiting the scope of the claimed subject matter.

[0008] In one embodiment, a method for message broker migration in an application environment migration is disclosed. The method includes: evaluating, by a processor 122 of an application server 102, a source message broker 412 of a source application environment; and scanning, by the processor 122, the source message broker 412 to identify connections between components 412a, 412b, ..., 412n of the source application environment. The method includes scanning, by the processor 122, a message broker for migrating the source message broker 412 to a target message broker 430. Quantitative change and predicting, by the processor 122, evaluation statistics 302, wherein the evaluation statistics 302 indicate at least one step for completing the migration of the source message broker 412. Feature Readiness 304 and a timeline 306. The method includes generating, by a processor 122, transformed message broker structures 550a, ..., 550n, where the transformed message broker structures 550a, ..., 550n are generated by partitioning the source message broker 412 according to the target message broker 430 while maintaining connectivity; and computing, by the processor 122, the connectivity of the target message broker 430 according to the predicted evaluation statistics 302 and the transformed message broker structures 550a, ..., 550n. subdividedand updating the message broker components 552a, ..., 552n. The method further includes migrating, by the processor 122, the source message broker 412 to the target message broker 430, wherein the migrating includes updating the updated message broker components 552a, ..., 552n. subdivided and replatforming the message broker components 552a, . . . , 552n.

[0009] In yet another embodiment, a method for migrating a source message broker 412 to a target message broker 430 is provided. Quantitative change is calculated based on the size and complexity of the source message broker 412 .

[0010] In yet another embodiment, the transformed message broker structures 550a, . . . , 550n are generated utilizing a continuous integration and deployment framework 150 and an automated testing framework 150.

[0011] In yet another embodiment, the reputation statistics 302 are stored in the Preventing the migration from completing Provide at least one disincentive.

[0012] In yet another embodiment, a transformed message broker structure 550a, . . . , 550n is generated according to the target message broker 430 while maintaining the connections between the components 412a, 412b, .

[0013] In yet another embodiment, the transformed message broker structure (550a, . . . , 550n) is identified by the AI ​​engine (152).

[0014] In yet another embodiment, the source message broker 412 of the application environment may be configured to process the source to target message brokers. Reconstructing the environment to, migration to the target message broker 430, which includes the steps of refactoring from the source to the target message broker, rehosting from the source to the target message broker, and replatforming from the source to the target message broker.

[0015] In yet another embodiment, the target message broker 430 is a cloud-based message broker ecosystem.

[0016] In yet another embodiment, the method includes migrating, by the processor 122, queues and topics from the source application environment according to the target application environment.

[0017] In another embodiment, the method includes implementing, by the processor 122, a message broker service and a service endpoint according to the target application environment.

[0018] In another embodiment, the method includes accessing, by the processor 122, application code 202 including business logic, links, a rules engine, libraries of available environments, standard tools, and coding languages.

[0019] In one embodiment, a system for message broker migration in application environment migration is disclosed. The system includes a processor 122 and a memory 126 coupled to the processor 122, the processor 122 executing a plurality of modules 128 stored in the memory 126. The plurality of modules 128 evaluates a source message broker 412 of a source application environment, scans the source message broker 412 to identify connections between components 412a, 412b, ..., 412n of the source application environment, and performs a migration of the source message broker 412 to a target message broker 430. Quantitative changean evaluation module 130 for verifying at least one of the following for completing the migration of the source message broker 412; Feature Readiness 304 and a timeline 306. The plurality of modules 128 further includes a refactoring module 132 for generating transformed message broker structures 550a, ..., 550n, where the transformed message broker structures 550a, ..., 550n are generated by splitting the source message broker 412 according to the target message broker 430 while maintaining connectivity. The plurality of modules 128 further includes a refactoring module 132 for splitting the source message broker 412 according to the target message broker 430 while maintaining connectivity. subdivided a replatforming module 134 for updating message broker components 552a, ..., 552n and migrating the source message broker 412 to the target message broker 430, whereby the updated subdivided It further includes a replatforming module 134, in which the message broker components 552a, . . . , 552n are replatformed.

[0020] In yet another embodiment, the system includes a method for migrating a source message broker 412 to a target message broker 430 that is calculated based on the size and complexity of the source message broker 412. Quantitative change It has.

[0021] In yet another embodiment, the system includes a transformed message broker structure 550a, . . . , 550n that is generated using a continuous integration and deployment framework 150 and an automated testing framework 150.

[0022] In yet another embodiment, the system includes a source message broker 412 Preventing the migration from completing It has an evaluation statistic 302 that provides at least one inhibitor.

[0023] In yet another embodiment, the system has a transformed message broker structure 550a, ..., 550n that is generated according to the target message broker 430 while maintaining connectivity between the components 412a, 412b, ..., 412n of the source message broker 412.

[0024] In yet another embodiment, the system includes a transformed message broker structure (550a, . . . , 550n) identified by the AI ​​engine (152).

[0025] In yet another embodiment, the system comprises a source to target message broker. Reconstructing the environment to , having a source message broker 412 of an application environment that is migrated to a target message broker 430 including the steps of refactoring from the source to the target message broker, rehosting from the source to the target message broker, and replatforming from the source to the target message broker.

[0026] In yet another embodiment, the system includes a target message broker 430 that is a cloud-based message broker ecosystem.

[0027] In yet another embodiment, the system comprises a refactoring module 132 that further includes migrating, by the processor 122, queues and topics from the source application environment according to the target application environment.

[0028] In another embodiment, the system includes a replatforming module 134 that further includes implementing, by the processor 122, a message broker service and service endpoints according to the target application environment.

[0029] In another embodiment, the system includes multiple modules 128 that further execute by the processor 122 access to application code 202, including business logic, links, rule engines, libraries of available environments, standard tools, and coding languages.

[0030] It is a primary objective of the subject matter to provide a system and method for message broker migration in application environment migration that can be used to migrate an application from one platform to another, and more specifically, that can be used to migrate a message broker from an older environment to a newer environment. The system and method for message broker migration in application environment migration can be customized based on the message broker being migrated and the environment, including the older environment in which the message broker was developed and the newer environment to which the message broker is to be migrated.

[0031] Another object of the subject matter is to provide a message broker migration during an application environment migration that accommodates multiple message brokers while maintaining their connectivity. Additionally, systems and methods for message broker migration during an application environment migration may enable selected target message brokers to be migrated from a wide range of environments to another wide range or ecosystem environment.

[0032] Another object of the subject matter is to provide a system and method for message broker migration in an application environment migration that migrates the message broker in an automated manner, without requiring manual input or in a hybrid manner that includes automated and manual steps.

[0033] Another object of the subject matter is to provide a message broker migration in an application environment migration that reduces the time and effort spent by a development team to migrate a message broker from an older environment to a newer environment by eliminating repeatable patterns of work done by the development team, thereby also reducing costs.

[0034] Another object of the subject matter is to provide a message broker migration in an application environment migration that provides greater control over inter-service communication, improves performance and scalability, improves reliability and efficiency, and ensures that data is transmitted securely.

[0035] Another objective of the subject matter is to provide message broker migration in application environment migration that can be used to migrate source / legacy message brokers including but not limited to IBM MQ, Microsoft MQ, TIBCO EMS / Rendezvous, WebLogic / WebSphere Message Queue, Sonic Message Queue, JBoss MQ, etc. to target cloud-based popular message brokers including but not limited to Amazon Web Services (AWS) Amazon AMQ, Azure Service Bus, Event Hub, MuleSoft Anypoint Platform, RabbitMQ, Apache ActiveMQ, Kafka, etc.

[0036] Another object of the subject matter is to provide a message broker migration in an application environment migration that migrates a message broker from an older environment to a newer environment by reducing implementation costs, reducing total cost of ownership to increase profitability, improving execution speed, improving application performance, and increasing application productivity.

[0037] It is another object of the subject matter to provide a number of advantages depending on the particular aspect, embodiment, implementation and / or configuration.

[0038] It is another objective of the subject matter to provide a platform that can provide reliable execution, scalability, and value-added services while controlling the effort and cost of operations.

[0039] Efficiently managing a large number of instances simultaneously, working with various regulatory requirements, and enabling resources to collaborate and work together closely, efficiently, and collectively with a user-friendly interface are other objectives of the subject matter.

[0040] These and other aspects, embodiments, processes, and features of the subject matter will become more fully apparent when the following detailed description is read in conjunction with the accompanying experimental details. However, both the foregoing summary of the subject matter and the following detailed description thereof represent one potential aspect or embodiment and are not intended to limit other alternative aspects or embodiments of the present disclosure or the subject matter. [Brief explanation of the drawings]

[0041] A clearer understanding of the principal features of the subject matter summarized above can be obtained by reference to the accompanying drawings illustrating the subject methods and systems, however, such drawings depict preferred embodiments of the subject matter and therefore should not be considered limiting in scope with respect to other embodiments that the subject matter may contemplate. [Figure 1] 1 shows a schematic modular diagram illustrating a method for message broker migration in application environment migration according to an embodiment of the present subject matter; [Figure 2] 1 shows a flowchart illustrating the operation of an exemplary message broker migration system in an application environment migration system, according to an embodiment of the present subject matter. [Figure 3]1 illustrates an exemplary assessment report automatically generated by an exemplary message broker migration in an application environment migration system, according to an embodiment of the present subject matter. [Figure 4] 1 illustrates an exemplary diagram of an exemplary message broker migration in an application environment migration method, according to an embodiment of the present subject matter. [Figure 5] 1 illustrates an exemplary diagram of an exemplary message broker migration in an application environment migration method, according to an embodiment of the present subject matter. [Figure 6] 1 illustrates an exemplary flowchart of a method for message broker migration in application environment migration, according to an embodiment of the present subject matter. [Figure 7] 1 illustrates another exemplary flowchart of a method for message broker migration in application environment migration, according to an embodiment of the present subject matter. DETAILED DESCRIPTION OF THE INVENTION

[0042] (Detailed Description of the Invention) The following is a detailed description of embodiments of the present disclosure that are illustrated in the accompanying drawings. The embodiments are in sufficient detail to clearly communicate the disclosure. However, the amount of detail provided is not intended to limit the embodiments, but rather to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure. Although aspects of the described systems and methods for message broker migration in application environment migration may be implemented in any number of different computing systems, environments, and / or configurations, the embodiments are described in the context of the following example system(s).

[0043] The present disclosure provides message broker cloud replatforming from a source on-premises message broker in a source application environment to a target message broker in a target application environment. Cloud replatforming of message brokers involves migrating existing on-premises message brokers to the cloud and leveraging the scalability and flexibility of the cloud to efficiently function the source message broker in the source application environment. The source message brokers in the source application environment are also restructured to reduce the total cost of ownership (TCO) of these message brokers, including adopting more open-source and cloud-friendly software to reduce virtual machine, application server, and database licensing costs. Actual TCO savings vary by message broker and are determined after an evaluation of the source message broker. This disclosure lists several key steps to be performed on a message broker, which vary depending on the message broker, and an existing message broker may be modified to work effectively on a Cloud Platform or PaaS, but all blockers related to source and on-premise design patterns are changed, all underlying links, dependencies, connections, libraries are updated to make the source message broker compatible with containers or PaaS, application servers (Weblogic, WebSphere, JBoss, etc.), and databases may be replaced with open source cloud-friendly software, monolith applications may be decoupled into smaller macro services for efficiency and speed, and the source message broker may be transformed and replatformed on the target cloud-based message broker.

[0044] This disclosure provides a mechanism for cloud replatforming through simple containerization, removing all code blockers that hinder containerization and deploying the source application in a container such as Docker to run it on the cloud. Furthermore, the source application release process, including test case and CI / CD automation, may also be automated. Furthermore, the source application and / or source database may be replatformed to a lightweight open-source server such as Tomcat for Java applications and a legacy DB2 database to reduce licensing costs and compute costs in the cloud, thereby lowering the TCO of these applications. However, to ensure stability and performance, the monolith application may need to be split into smaller services, a refactored database structure, a converted message broker, or the batch and scheduler refactoring may make all these applications stateless, deploying each to a separate Tomcat server in a separate container. Therefore, the source application may be migrated to the target application platform by decomposing the monolith application and exposing it through an API using a macroservice concept, making it a cloud-ready application. In addition to breaking down the monolith application into macro services, CI / CD is also implemented to ensure fast and automated deployment. It performs message broker replatforming, including converting on-premise commercial message brokers such as (but not limited to) IBM MQ to Amazon AMQ or Azure Service Bus, Azure Event Hub, and AWS SNS. The component-wise structure and step-by-step methodology are shown below:

[0045] FIG. 1 shows a schematic modular diagram 100 illustrating a method for message broker migration in application environment migration, according to an embodiment of the present subject matter.

[0046] In one embodiment, message broker migration in application environment migration system 120 implements a method for message broker migration in application environment migration system on server 102, where system 120 includes processor(s) 122, interface(s) 124, framework(s) 150, AI engine 152, and memory 126 coupled to processor(s) 122. Processor(s) 122 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any device that manipulates signals based on message broker migration instructions. Among other functions, processor(s) 122 are configured to fetch and execute computer-readable instructions stored in memory 126. Framework 150 includes, but is not limited to, a continuous integration and continuous deployment framework, an automated testing framework, etc. The AI ​​engine 152 includes, but is not limited to, a database (DB) replatforming engine, an application replatforming engine, a message broker replatforming engine, an open source AI engine, and the like.

[0047] Although the present disclosure is described with respect to a scenario in which the system is implemented as an application on a server, the system and method may be implemented in a variety of computing systems, including, but not limited to, mainframe computers, workstations, personal computers, desktop computers, minicomputers, servers, multiprocessor systems, laptops, tablets, SCADA systems, smartphones, mobile computing devices, etc.

[0048] The interface(s) 124 may include various software and hardware interfaces, such as, for example, a web interface, a graphical user interface, etc., that allow the system 120 to interact with a user. Additionally, the interface(s) 124 may allow the system 120 to communicate with other computing devices, such as web servers and external data servers (not shown). The interface(s) 124 may facilitate multiple communications within a wide variety of network and protocol types, including, for example, wired networks such as LANs, cable, and wireless networks such as WLANs, cellular, or satellite. The interface(s) 124 may include one or more ports for connecting multiple devices to each other or to another server.

[0049] The network used to communicate between all elements in the application server and cloud environment can be a wireless network, a wired network, or a combination thereof. The network can be implemented as one of several different types of networks, such as an intranet, a local area network (LAN), a wide area network (WAN), or the Internet. The network can also be a dedicated network or a shared network. A shared network refers to a collection of different types of networks that communicate with each other using various protocols, such as Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), and Wireless Application Protocol (WAP). The network can also include various network devices, including routers, bridges, servers, and computing devices. The network can also have access to storage devices, such as those located on client-site computers, host-site servers or computers, clouds, or a combination thereof. Storage can include one or many local and remote computer storage media, including one or many memory storage devices, databases, and the like.

[0050] The memory 126 may include any computer-readable medium known in the art, including, for example, volatile memory (e.g., RAM) and / or non-volatile memory (e.g., EPROM, flash memory, etc.). In one embodiment, the memory 126 includes module(s) 128 and system data 140.

[0051] Modules 128 further include evaluation module 130, refactoring module 132, replatforming module 134, and other modules 136, including, but not limited to, a blocker evaluation module, a script generator module, etc. Script generator modules further include, but are not limited to, a test case generator, a build script generator, a Docker script generator, a pipeline script generator, a deployment script generator, etc. It will be understood that such modules may be represented as a single module or a combination of different modules. Furthermore, memory 126 further includes system data 140, which serves as a repository for storing data fetched, processed, received, and generated by one or more of modules 128, among other things. System data 140 includes, for example, operational data, workflow data, and other data in storage 144. System data 140 optionally has storage 144, represented as 144a, 144b, ..., 144n. In one embodiment, system data 140 has access to other databases via the web or a cloud network. Storage 144 includes multiple databases, including, but not limited to, evaluation module data, refactoring module data, replatforming module data, libraries, link identifiers, database adapters, database dictionaries, database parsers, technology dictionaries, file adapters, application parsers, pattern recognizers, open source libraries, technology stacks, etc. It will be appreciated that such databases may be represented as a single database or a combination of different databases. In one embodiment, data may be stored in memory 126 in the form of data structures. Furthermore, such data may be organized using a data model, such as a relational data model or a hierarchical data model.

[0052] The server 102 is further connected to a cloud environment 110 having multiple computing systems, including a target application environment server 104, a target application environment server 106, and databases, including, but not limited to, a database 108. The computing systems and databases must communicate with each other under cloud computing rules and with the server 102 under the web or other available communication medium / protocol. The computing system 104 is generally a distributed processing system including multiple computing devices connected by and communicating over a network. Software applications can be executed "in the cloud" by configuring them to run across one or more computing devices in a particular cloud computing system. Each computing device in a cloud computing system may run a separate copy of the software application, or in some cases, the operation of the software application may be divided among different computing devices and executed in parallel. A cloud computing system may include multiple cloud computing instances, which represent resources available for running applications. Each instance may be a physical computing device with specific capabilities (such as storage size, processing speed, network bandwidth, etc.) or a virtual computing device with specific capabilities. A particular cloud computing system may offer different instance types with different sets of capabilities for running software applications.

[0053] In one embodiment, a user, including but not limited to a migration specialist, database administrator, application developer, quality analyst, or testing specialist, may initially use a user access device to access system 120 via interface 124 using server 102. The operation of system 120 and associated methods and associated modules, sub-modules, and methods may be explained in more detail using Figures 2, 3, 4, 5, 6, and 7, which are described below.

[0054] In one embodiment, system 120 receives user instruction data via interface 124 on server 102. Module 128 of system 120 processes the instructions using processor 122 while using system data 140, other modules 136, framework 150, and support components. Assessment module 130 for message broker migration in application environment migration is utilized prior to initiating the migration of a message broker from one environment to another. While assessing risk, cost, timeline, and the impact of the change on other dependent applications migrating to the target message broker of the target application environment, assessment module 130 performs an assessment of a source message broker 412 of the source application environment and scans source message broker 412 to identify connections between components 412a, 412b, ..., 412n of the source application environment that the source message broker of the source application environment must experience. Quantitative change The evaluation module 130 understands the underlying connections and dependencies developed by various developers with different styles. Furthermore, the predictive evaluation report 302 generated by the evaluation module 130 using the AI ​​engine 152 provides a detailed understanding of the required timeline, percentage of components / structures that need to be changed, and multiple Readiness ParametersThe assessment report 302 provides detailed information, including but not limited to, warnings with multiple inhibitors or code blockers and reasons, highlighted areas where the message broker component needs to be modified, the number of services the monolith can be split into, the types of services the monolith can be split into, and the readiness of the message broker for continuous integration and continuous deployment. The assessment report 302 generated by the assessment module 130 provides an accurate estimate and timeline for completing the source message broker migration of the source application environment. In one embodiment, the RPA bot is configured to generate the assessment report 302 using the Proactive Message Broker Migration Prediction for Application Environment Migration (PAEMF) algorithm. In one embodiment, the RPA bot is a software bot or a combination of software and hardware bots. In one embodiment, the software bot is a computer program that enables a processor to perform robotic process automation by utilizing AI. In another embodiment, the bot is a combination of hardware and software, where the hardware includes dedicated memory, processors, controllers, and other associated chipsets to perform functions that enable robotic process automation, particularly for message broker migration in application environment migration.

[0055] The refactoring module 132 for message broker migration in application environment migration supports automated replatforming from a source message broker migration in application environment migration to a target message broker migration in application environment migration by generating a transformed message broker 550 having a structure 550a, 550b, ..., 550n, where the transformed message broker structure 550a, ..., 550n is generated by splitting the source message broker 412 according to the target message broker 430 while maintaining connectivity. The refactoring module 132 utilizes a continuous integration and deployment framework 150, an automated testing framework 150, and middleware replatforming and environment-friendly design patterns to generate the transformed message broker structure 550a, ..., 550n.

[0056] The replatforming module 134 for message broker migration in application environment migration supports automated replatforming for source message broker migration in application environment migration to a target application environment to convert a message broker from one environment to another based on the size of the message broker and its complexity. The replatforming module 134 performs replatforming on components 552a, 552b, 552c, ..., 552n of the target message broker 430 according to the predicted evaluation statistics 302 and the converted message broker structure 550a, ..., 550n. subdivided Update the message broker 552 and migrate the source message broker 412 to the target message broker 430, where the migration subdividedThe message broker components 552a, ..., 552n are replatformed. The replatforming module 134 also performs activities including, but not limited to, integrating patterns from the source application environment with design patterns from the target application environment, fine-tuning code, resolving deployment issues, implementing security to ensure the migrated application is fully functional, etc. The replatforming module 134 supports multiple forms of environment migration, including, but not limited to, rehosting environment migration, message broker replatforming, message broker refactoring, and native message broker development.

[0057] In the blocker assessment module of other modules 136, any application, such as a monolith web application with on-premise design patterns, can be input to the system and method for message broker migration in application environment migration, and the blocker assessment module of the system and method for message broker migration in application environment migration can discover patterns in the on-premise design patterns of the monolith web application. Further, this information can be forwarded to the automated replatforming module of the system and method for message broker migration in application environment migration, as shown in FIG. 1.

[0058] The reference architecture of system 120 further includes supporting components such as a test generator that generates unit, functional, and performance test cases for generated APIs; a build script generator that generates scripts to successfully build and run an application; a Docker script generator that generates scripts to containerize an application and its dependencies; a pipeline script generator that generates scripts to create a CI / CD pipeline for development, test, and production environments; a deployment script generator that generates scripts to deploy an application to a target environment; a database adapter that establishes connections to multiple database servers, such as IBM DB2, Oracle, Microsoft SQL Server, Sybase ASE, and PostgreSQL; a database dictionary that contains a vast number of database-related keywords and built-in functions used by the above multiple database servers; a database parser that uses the database dictionary to parse database objects and find patterns that are incompatible with the target database; and an AI engine that identifies existing and potential macros / microservices in legacy applications. Message Broker Replatforming Engine - The Message Broker Replatforming Engine replatforms source message broker objects such as queues and tablets into target message broker compatible objects. File Adapter - The file adapter provides access to the application source files. The files are scanned, reports are generated, and finally replatformed as the target application.Technology Dictionary - The technology dictionary contains a vast number of patterns related to the technologies used within the monolith application. Application Parser - The application parser uses a pattern recognizer to analyze the application source code and find the entire inventory of technologies used by the application. This inventory is used for evaluation and replatforming. Pattern Recognizer - The pattern recognizer recognizes patterns based on the technology dictionary and finds the technologies used in the application. AppliPlatform Engine - The AppliPlatform Engine replatforms the source application analyzed by the application parser. This engine generates an application ready to be deployed to the cloud. The technology stack includes but is not limited to JAVA 1.8; Maven; JUnit, NUnit, XUnit JMeter; Docker Jenkins; AWS CLI, Azure CLI, etc.

[0059] FIG. 2 shows a flowchart 200 illustrating the operation of an exemplary message broker migration system in an application environment migration system, according to an embodiment of the present subject matter.

[0060] This disclosure presents two key activities: source application environment assessment and source message broker conversion to the desired target platform, which are illustrated in flowchart 200 below.

[0061] In one embodiment, a monolith web application 202, such as a JAVA or .NET application, is a source application of a source application environment. The monolith web application 202 is linked to various support components 204, including but not limited to databases, batch, integration, apps, schedulers, on-premise ecosystem components, etc. The functionality of a source message broker 412 of a source ecosystem component linked to the source application environment is described in further detail below.

[0062] In a first step, cloud blocker assessment 206 assesses the source application and generates an assessment report 212 containing code defects, source code insights, and on-premise design patterns 214. Cloud blocker assessment 206 also assesses the source application, message brokers, scans message broker connections, and generates an assessment report 212 containing message brokers, message broker connections, links, and dependencies. On-premise design patterns 214 include, but are not limited to, EJB, RMI, STRUTS / SPRING, SOAP / XML, JSP / ASP, ESB, etc. The assessment of the source application includes a technology stack and code analysis of the current application. The assessment provides automated insights into the time, effort, and risk associated with replatforming the source application, source database, source message broker, and other supporting components, including, but not limited to, batch and schedulers. The assessment includes an analysis of the source message broker components, performing an automated assessment of the source message broker 412, including links, connections, and other dependencies, and identifying the relationship between the message broker and the cloud blocker. Readiness ParametersThe cloud blocker assessment 206 identifies impediments or blockers (packages / frameworks / APIs / libraries, etc.) that could cause a containerized cloud migration to fail, thereby providing a detailed assessment report 212. It performs this code assessment on the entire source application ecosystem, including applications, databases, batch programs and schedulers, integration and message brokers, and build and deploy modules. The cloud blocker assessment 206 evaluates the risk, cost, timeline, and impact on other dependent components and applications that the source application environment must go through. Quantitative change The report primarily provides the percentage of code that needs to be changed, code readiness, blockers and warnings with reasons, exact locations where the code needs to be changed, number of services into which the monolith can be decomposed, DevOps and CI / CD readiness, and a timeline for such execution.

[0063] The next step is to perform automated message broker conversion / replatforming 208 for replatforming of application and supporting components from source environment to target environment while preserving source message broker connectivity in the target application environment to generate cloud ready application and supporting components 210 like IBM MQ message broker consisting of JAVA or .NET application, Oracle database or DB2 database, continuous integration and deployment framework 216, automated testing framework 218, middleware replatform 220, and cloud friendly design patterns 222 after converting / refactoring the source message broker of the source application environment. The substeps of automated replatforming 208 are to update message broker connections, interdependencies, links, and other supporting components, decouple the front-end and back-end, and convert all message broker components from source message brokers such as IBM MQ, Microsoft MQ, TIBCO EMS / Rendezvous, WebLogic / WebSphere Message Queue, and Sonic Message Queue to cloud-friendly message brokers such as Amazon Web Services (AWS) Amazon MQ, Azure Service Bus, Event Hub, MuleSoft Anypoint Platform, RabbitMQ, Apache ActiveMQ, and Kafka. All components, connections, queues, and tables are converted to work with the target message broker and achieve the same desired results as the source message broker. Once the message broker component conversion is complete, it converts the source message broker based on the design of the target application environment. subdividedBreaking it down into components, fine-tuning code rules, taking steps to resolve deployment issues, and implementing security are completed by the consultant to make the target application, database, and message broker fully functional. In one example, Table A and Table B can be used as examples to explain an exemplary code conversion. [Table A] [Table B]

[0064] Furthermore, message broker cloud replatforming involves several iterative steps, such as message broker component analysis, refactoring, library updates, compilation of build scripts, deployment scripts, containerization scripts, etc. The result can significantly improve time to market, subsequently reducing overall costs and achieving high-quality replatforming.

[0065] FIG. 3 illustrates an exemplary assessment report 302 automatically generated by an exemplary message broker migration in an application environment migration system, according to an embodiment of the present subject matter.

[0066] In one embodiment, the assessment module 130 generates an assessment report 302 in an exemplary view 300 after assessing the source application environment, including code defects, source code insights, database links, connections, message broker dependencies, batch and scheduler apps, on-premise design patterns 214, etc. The assessment report 302 provides automated insight into the time, effort, and risk involved in replatforming the source application environment.

[0067] The assessment includes the analysis of the source message broker, i.e., message broker and message broker components, where it performs an automated assessment and scan of the source message broker, including connections and other dependencies, and Readiness Parameters It identifies inhibitors or blockers (packages / frameworks / APIs / libraries, etc.) that cause cloud migration failures, thereby providing a detailed assessment report 302. It evaluates which on-premises message brokers are used, what messages they pass within the application's components, and also evaluates the compatibility and risks associated with replatforming to a cloud-based message broker or target. Report generation is an automated process that involves some user configuration based on the source application and target application environment.

[0068] An assessment report 302 must be passed by the source message broker to assess the risk, cost, timeline, and impact on other dependent components and message brokers. Quantitative change A deep understanding of Readiness Parameters 304 and visual composition 306 . Quantitative changeis the sum of all changes required for the message broker migration. The assessment report 302 has various sections, and some example diagrams for an application snapshot include parameters such as containerization readiness 304a, replatforming readiness 304b, DevOps readiness 304c, macro / micro API readiness 304n, batch app readiness 304n, scheduler replatforming readiness 304n, DB replatforming readiness 304n, and cloud message broker service readiness 304n, among others. Each parameter indicates a readiness state, such as a percentage (%), indicating how much is ready and / or how many not-ready / blocking / impeding conditions exist for the respective parameter. For example, Containerization Readiness 304a shows container readiness rate with readiness state and required refactoring / blocker rate, Replatform Readiness 304b shows Tomcat readiness rate with readiness state and required refactoring / blocker rate, DevOps Readiness 304c shows CD readiness rate with readiness state and CI readiness / blocker rate, Macro / Micro API Readiness 304n shows Macro API existing pointer with readiness state and Micro API existing / blocker state, Batch App Readiness 304n shows replatforming readiness rate with Batch App readiness state and required refactoring blocker / blocker rate, Scheduler Replatform Readiness 304n shows replatforming readiness rate with AWS Batch readiness state and Azure Logic App readiness / blocker rate, DB Replatform Readiness 304n shows replatforming readiness rate with PostgresSQL readiness state and required refactoring blocker / blocker rate, and Cloud Message Broker Service Readiness 304n shows replatforming readiness rate for target Amazon It shows the MQ readiness status and replatforming readiness rate with required refactoring blocker / impediment rate.Another section of the report 302 includes visual configurations 306 such as Database Objects Spread [#Objects] 306a, Database Objects Spread [#LoC] 306b, Platform Configuration by Number 306n, and Platform Configuration by LoC 306n. In one example, Database Objects Spread [#Objects] 306a indicates the spread or count number or percentage of triggers, sequences, packages, procedures, views, materialized views, functions, and tables; Database Objects Spread [#LoC] 306b indicates the spread or count number or percentage of triggers, sequences, packages, procedures, views, materialized views, functions, and tables; Platform Configuration by Number 306n indicates the spread or count number or percentage of JMS, XML Config, Web Services, Maven Build, Configuration, HTML, Servlets, Stylesheets, ReactJS, JSP, JUnit, POJO; Platform Configuration by LoC 306n indicates the spread or count number or percentage of JMS, XML Config, Web Services, Maven Build, Configuration, HTML, Servlets, Stylesheets, ReactJS, JSP, JUnit, POJO, etc.

[0069] Additionally, various sections of the Assessment Report 302 provide the following information sections, Application Snapshot consisting of Frameworks / Libraries / Packages Used, Application Containerization Readiness, Application Server Replatforming Readiness to Tomcat or Kestrel Application Server, Database Server Replatforming Readiness to PostgreSQL etc, Containerization Readiness (to Docker / Kubernetes), Message Broker Readiness to Amazon MQ Cloud Message Broker, CI / CD Readiness (Unit / Functional / Performance Test Cases, Build and Continuous Integration, Available Automation), Macro and Micro API Candidates, API Readiness (Existing and Potential APIs in the Application).

[0070] Our methodology provides end-to-end conversion capabilities by assessing your source application environments, then converting them to the cloud using cloud-friendly design patterns, and finally managing the entire journey by providing your stakeholders and decision makers with transparent visibility for rapid decision-making. Convert all application dependencies holistically to the cloud, from databases to batch programs, schedulers to message brokers. In the application analysis section of the assessment report 302, the methodology analyzes the entire source application and identifies blockers in the source code, including design patterns that inhibit cloud migration. All dependencies are also analyzed, providing a holistic view for design and planning purposes. It discovers and analyzes the inventory of application components, technology stack and its dependencies, identifies the application's business, data services and its API readiness, identifies blockers & DevOps readiness for containerization and cloud replatforming, and identifies initiatives for changes such as JAVA vX.X to JAVA v1.8; EJB (Session Bean / Entity Bean / MDB) to Spring Boot Service with Spring Framework (POJO); .NET vX.X to .NET Core v2.2, IBM MQ to Amazon MQ (just an example).

[0071] In the database analysis section of assessment report 302, the methodology analyzes databases to analyze and discover database inventory, data object details and database size, identify database replatforming preparation and blockers, identify application blockers and dependencies for database replatforming, and identify efforts for change such as from Oracle / SQL Server / DB2 / Sybase to Postgres / MySQL. In the batch & scheduler analysis section of assessment report 302, the methodology analyzes batch & schedulers to analyze and discover batch program inventory and batch schedulers, batch scheduler replatforming preparation, identify blockers and dependencies, identify application batch services for batch replatforming, and identify efforts for change such as from Autosys / ControlM to AWS Batch (AWS Cloud) / Azure Logic App (Azure Cloud) / Quartz (Private Cloud). In the message broker analysis section of the assessment report 302, the methodology analyzes message brokers, analyzes and discovers message broker inventory and messaging objects, identifies message broker replatforming readiness, blockers and dependencies, identifies application blockers and dependencies for message broker replatforming, efforts for change such as from TIBCO EMS / Rendezvous or WebLogic / WebSphere or Message Queue or Sonic Message Queue to Active MQ.

[0072] FIG. 4 illustrates an example diagram 400 of an example message broker migration in an application environment migration method, according to an embodiment of the present subject matter.

[0073] In one embodiment, an application deployment view 400 with pre- and post-replatforming is depicted using a method and system for source message broker migration in application environment migration to a target application environment according to an embodiment of the present subject matter. A monolith application typically resides in a source application environment residing or accessible by server 102 and is transformed or migrated to a modernized, replatformed application residing in a target application environment residing or accessible by cloud environment 110. First, a code evaluation 206 is performed from the source application migration to the target application migration. The application evaluation determines the amount of code changes required to remove and modify code inhibitors for containerization. The migration is performed in the following steps, where application web servers with applications accessible by server 102 are optionally converted to web front instances 422a, 422b, ..., 422n. The application server (IIS cluster) 202 is further refactored into an API management layer 426 with various App macro service instances 426a, 426b, 426c, ... 426n. The macro service instances are based on the size and complexity of the source application. In one embodiment, the refactoring module 132 performs the factoring and repackaging 208 of the macro services into the target application environment.

[0074] The source application database 204 also maps the PaaS / CaaS cluster 424a to the replatformed version of the target database 424. subdividedThe web front instances 422a, 422b, ..., 422n and macro service instances 426a, 426b, 426c, ..., 426n are further linked to components of the cloud computing environment 110, including but not limited to a service mesh, AKS cluster, App services, ACI, etc. In one embodiment, the source Oracle database is migrated to a PostgresSQl database in conjunction with the container / orchestration platform of the cloud environment 110.

[0075] The virtual machine instances 408a, 408b, ..., 408n of the source application are migrated to a container cluster in the cloud environment 110. In this manner, the on-premise data center 410 of the source application environment 410 with its on-premise ecosystem 412 is replatformed 210 / migrated to the private / public cloud 428 of the cloud environment 110. In one embodiment, components 412a, 412b, 412c, 412d, 412e..., 412n of on-premises ecosystem 412, including but not limited to EBS, caching, local files, rule engines, message brokers, authentication protocols, security platforms, etc., are replatformed 210 / migrated to independent or standard service / target components 430a, 430b, 430c, 430d, 430e, 430f, 430g,..., 430h private / public cloud 428, including but not limited to Azure queues, event hubs, service bus, AppInsights, Redis cache, storage, Vnet, Azure AD, etc.

[0076] In one embodiment, a method modifies existing on-premise applications to run efficiently on the cloud using containers or PaaS, updating or modifying all blockers related to source code and design patterns and all underlying libraries to make them compatible with containers or PaaS, replatforming application servers and databases to reduce TCO, and monolith applications can be decoupled into services to improve efficiency and speed.

[0077] In one example, Table C can be used as an example to explain the replatforming migration. [Table C]

[0078] In one embodiment, the current state is a monolith web application with session EJB calls and a commercial application server with JSP-based UI with some data services, session persistence and stateful services are the current state, and the migrated future state is a decoupled web application with JSF WebFront and RESTful Spring Boot macro services (independently scaling) on ​​a container via an API gateway.

[0079] FIG. 5 illustrates an example diagram 500 of an example message broker migration in an application environment migration method, according to an embodiment of the present subject matter.

[0080] Cloud-native applications are developed using a microservices architecture to take advantage of the inherent benefits of cloud computing, including flexibility, scalability, and rapid deployment. Each service is a modular or small component that represents a business domain with its own database. This concept is called domain-driven design, which is commonly adopted in cloud application development. For microservices to work together, they need a way to communicate with each other. A message broker is one of the mechanisms they use to create this shared communication backbone. Message brokers are often used to manage communication between these components in cloud environments.

[0081] A message broker queue provides delivery services to message brokers, such as source message broker 412 and target message broker 430. Message delivery relies on a number of supporting components that handle connection services, message routing and delivery, persistence, security, and logging. A message server may use one or more broker instances. Message delivery in a message broker queue begins with the generation of a message from a client to a destination, and then the transmission of the message from the destination to one or more consuming clients, performed by a broker (or a cluster of broker instances working together). To perform message delivery, a broker must set up communication channels with clients, perform authentication and authorization, route messages appropriately, ensure reliable delivery, and provide data for monitoring system performance. To perform this complex set of functions, a broker uses several different internal components, each of which plays a specific role in the delivery process. The message broker component performs the primary message routing and delivery service, while others provide important support services.

[0082] In one embodiment, an application deployment view 500 with pre- and post-replatforming is depicted using a method and system for source message broker migration in application environment migration to a target application environment according to an embodiment of the present subject matter. A monolith application typically resides in a source application environment residing or accessible by a server 102 and is transformed or migrated to a modernized replatformed application residing in a target application environment residing or accessible by a cloud environment 110.

[0083] In one embodiment, a method for message broker migration in an application environment migration is disclosed. The method includes: evaluating, by a processor 122 of an application server 102, a source message broker 412 of a source application environment; and scanning, by the processor 122, the source message broker 412 to identify connections between components 412a, 412b, ..., 412n of the source application environment. The method includes scanning, by the processor 122, a message broker for migrating the source message broker 412 to a target message broker 430. Quantitative change and predicting, by the processor 122, evaluation statistics 302, wherein the evaluation statistics 302 indicate at least one step for completing the migration of the source message broker 412. Feature Readiness 304 and a timeline 306. The method includes generating, by a processor 122, transformed message broker structures 550a, ..., 550n, where the transformed message broker structures 550a, ..., 550n are generated by partitioning the source message broker 412 according to the target message broker 430 while maintaining connectivity; and computing, by the processor 122, the connectivity of the target message broker 430 according to the predicted evaluation statistics 302 and the transformed message broker structures 550a, ..., 550n. subdividedand updating the message broker components 552a, ..., 552n. The method further includes migrating, by the processor 122, the source message broker 412 to the target message broker 430, wherein the migrating includes updating the updated message broker components 552a, ..., 552n. subdivided and replatforming the message broker components 552a, . . . , 552n.

[0084] First, for cloud replatforming, a method accesses an on-premises ecosystem 412 having message brokers or a source message broker 412 having components such as queues and tables, and components 412a, 412b, ..., 412n of the on-premises ecosystem 412, including but not limited to EBS, cache, local files, rules engine, message broker, authentication protocol, security platform, etc., are replatformed to a target message broker 430 having target components 430a, 430b, 430c, 430d, ..., 430n, including but not limited to Azure queues, event hubs, service bus, AppInsights, Redis Cache, storage, Vnet, Azure AD, AWS SNS, Amazon MQ, Azure Service Bus, Azure Event Hubs, etc. The method takes a complete inventory of the message broker and message broker components, such as queues, tables, connections, size and complexity of the source message broker 412, compatibility, and risks associated with replatforming to a cloud-friendly target message broker 430 such as Amazon MQ, and replatforms the monolith. subdivided, 412n of the source message broker 412 to the target message broker 430. Quantitative change Functionality for verifying and completing the migration of message broker components 412a, 412b, ..., 412n of source message broker 412 Readiness Parameters The evaluation report 302 provides assessment statistics 302 that provide insights into the cloud message broker service provisioning, including the expected impact on the deployment, and forecasts the impact on the deployment ...

[0085] In the next message broker conversion step to perform message broker replatforming 504, the method mainly performs two functions. First, it generates converted message broker structures 550a, 550b, ..., 550n by splitting the source message broker 412 according to the target message broker 430 while preserving connectivity. The converted cloud message broker 550 includes creating queue message communication 550a and topic message communication 550b. The method converts all message broker components from a source message broker, such as IBM MQ, Microsoft MQ, TIBCO EMS / Rendezvous, WebLogic / WebSphere Message Queue, Sonic Message Queue, etc., to a target cloud-based popular message broker, including, but not limited to, Amazon Web Services (AWS) Amazon MQ, Azure Service Bus, Event Hub, MuleSoft Anypoint Platform, RabbitMQ, Apache ActiveMQ, Kafka, etc. All components are converted to work with the target message broker and achieve the same desired results as the source message broker. Once the message broker components are converted, the message broker is configured based on the application design. subdivided The method is divided into components. The method takes care to avoid data corruption and distributed transaction issues in the target application environment and helps it function properly. Second, the target message broker 430 is updated according to the predicted evaluation statistics 302 and the transformed message broker structure 550a, ..., 550n. subdividedReplatforming by updating message broker components 552a, 552b, 552c, ..., 552n, in which the target message broker component includes creating a message broker service in cloud 552a, creating the necessary queues and topics 552b, and configuring service endpoints in application 552c. Further, in one example, the updated subdivided The source message broker 412 is migrated to the target message broker 430 by replatforming the message broker components 552a, ..., 552n to a cloud ecosystem 430 including a target message broker 430 having AWS SNS 430a, Amazon MQ 430b, Azure Service Bus 430c, and Azure Event Hubs 430d.

[0086] In another example, an exemplary message broker migration methodology automates the analysis and generates a report that provides details about which on-premises message brokers are used and how they pass messages within application components. It then modifies the application code to use the customer's cloud message broker of choice. Creating message broker services and queues and topics is done manually in cloud environments. The exemplary message broker migration methodology first scans the application's source code and source message broker structure to determine which on-premises message brokers are used within application components, how they pass messages, and the compatibility and risks associated with replatforming to a cloud-based message broker. Once this assessment is complete, the exemplary message broker migration methodology generates an interactive HTML report with drill-down capabilities in a format that is easy for technical and business users to consume. This assessment report can be used by architects and application SMEs to design the new replatformed application. Once the design preparation is complete, the process can proceed to the next step which is message broker replatforming in the message broker replatforming step, an exemplary message broker migration method and SME performs the following steps, namely, convert all application component code to the customer's selected cloud message broker, SME can manually perform message broker service, queue and topic creation activities in the cloud environment, SME can manually create message broker services, queue and topic creation activities are manually performed in the cloud environment, SME can manually configure code components to use cloud-based queues and topics, and once these steps are complete, a report is generated showing components that were automatically converted and components that could not be converted.Any components that could not be converted by amaze will be converted manually by our consultants, providing the ability to understand the current message broker and messaging model used in the system, along with the message exchanges between different application components, and converting the source code to use a cloud-based messaging system.

[0087] FIG. 6 illustrates an exemplary flowchart 600 of a method for message broker migration in application environment migration, according to an embodiment of the present subject matter.

[0088] In one embodiment, a method 600 for message broker migration in application environment migration is illustrated. The method may be described in the general context of computer-executable instructions. Generally, computer-executable instructions may include routines, programs, objects, components, data structures, procedures, modules, functions, etc. that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices linked through a communications network. In a distributed computing environment, computer-executable instructions may be located in both local and remote computer storage media, including memory storage devices. The order in which the method is described is not intended to be construed as limiting; any number of the described method blocks may be combined in any order to implement the method or alternative methods. Furthermore, individual blocks may be omitted from the method without departing from the spirit and scope of the disclosure described herein. Furthermore, the method may be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method may be implemented in the system described above.

[0089] In step / block 602, a source message broker of the source application environment is evaluated by the processor 122 of the application server 102. In one embodiment, the source message broker may be evaluated by the evaluation module 130.

[0090] The source message broker is scanned to identify connections between components of the source application environment in step / block 604. In one embodiment, the source message broker may be scanned by the assessment module 130.

[0091] In step / block 606, a method for migrating a source message broker to a target message broker is performed. Quantitative change In one embodiment, Quantitative change may be verified by the evaluation module 130.

[0092] At step / block 608, at least one message broker is created to complete the migration of the source message broker. Feature Readiness In one embodiment, the evaluation statistics may be predicted by the evaluation module 130.

[0093] Thus, the method 600 assists message broker migration in application environment migration by providing predicted evaluation statistics and a timeline for migration from a source application environment to a target application environment.

[0094] FIG. 7 illustrates another exemplary flowchart 700 of a method for message broker migration in application environment migration, according to an embodiment of the present subject matter.

[0095] In one embodiment, a method 700 for message broker migration in application environment migration is illustrated. The method may be described in the general context of computer-executable instructions. Generally, computer-executable instructions may include routines, programs, objects, components, data structures, procedures, modules, functions, etc. that perform particular functions or implement particular abstract data types. The method may also be practiced in a distributed computing environment where functions are performed by remote processing devices linked through a communications network. In a distributed computing environment, computer-executable instructions may be located in both local and remote computer storage media, including memory storage devices. The order in which the method is described is not intended to be construed as limiting; any number of the described method blocks may be combined in any order to implement the method or alternative methods. Furthermore, individual blocks may be omitted from the method without departing from the spirit and scope of the disclosure described herein. Furthermore, the method may be implemented in any suitable hardware, software, firmware, or combination thereof. However, for ease of explanation, in the embodiments described below, the method may be implemented in the system described above.

[0096] In step / block 702, a source message broker of the source application environment is evaluated by the processor 122 of the application server 102. In one embodiment, the source message broker may be evaluated by the evaluation module 130.

[0097] The source message broker is scanned to identify connections between components of the source application environment in step / block 704. In one embodiment, the source message broker may be scanned by the assessment module 130.

[0098] In step / block 706, a method for migrating a source message broker to a target message broker is performed. Quantitative changeIn one embodiment, Quantitative change may be verified by the evaluation module 130.

[0099] At step / block 708, at least one message broker is created to complete the migration of the source message broker. Feature Readiness In one embodiment, the evaluation statistics may be predicted by the evaluation module 130.

[0100] In step / block 710, a transformed message broker structure is generated by splitting the source message broker according to the target message broker while maintaining connectivity. In one embodiment, the transformed message broker structure may be generated by refactoring module 132.

[0101] In step / block 712, the target message broker is evaluated according to the predicted evaluation statistics and the transformed message broker structure. subdivided Update the message broker component. In one embodiment, the target message broker subdivided The message broker component may be updated by the replatforming module 134.

[0102] In step / block 714, the updated subdivided Migrating a source message broker to a target message broker by replatforming the message broker component: In one embodiment, a source message broker may be migrated to a target message broker by the replatforming module 134.

[0103] Thus, the method 700 assists in message broker migration in application environment migration by providing predictive assessment, refactoring code, and replatforming message brokers for migration from a source application environment to a target application environment.

[0104] This solution is used to replatform complex message brokers to the cloud and deploy them to a production environment. Several examples are presented using the source message broker migration method and system for application environment migration to a target application environment according to embodiments of the present subject matter. The following describes the preparation, planning, and execution steps, along with the results of the study. As an example, in the cloud replatforming of a Java batch application for a leading secondary mortgage company, the source application environment belongs to a leading secondary mortgage company, a multi-billion dollar company operating in the United States and a publicly traded company that provides mortgage-backed securities. The primary business challenge is a complex Java batch application developed 10 years ago with Autosys and EJBs on WebLogic MQ, using an IBM MQ message broker, along with the use of an Oracle database, message-driven bean EJBs (MDBs), Pojo Services, JDBC, and more. This application is business-critical and handles important long-running processes. Cloud replatforming presented challenges due to the unavailability of key SMEs who developed the application. Using this solution approach, the Oracle database was replatformed to Postgres using method steps, the Autosys scheduler was replatformed to Quartz, and the backend EJBs (MDBs) were replatformed to independent Spring JMS with Spring Boot / Batch Service Apps with REST endpoints. The message broker was replatformed to Amazon MQ. Each service app was then deployed on a separate container on an AWS ECS VPC, providing infinite scalability, high availability, high fault tolerance, and improved performance. Autosys' centralized JOB dependencies were refactored into self-managed dependencies using app-specific Quartz schedulers, reducing operational complexity.Among the key benefits, TCO was reduced by over 50%, mainly due to the elimination of WebLogic & Autosys and also due to containerization, development productivity was improved due to macro services and CI / CD automation, and using automation the total cost of implementation was reduced by over 50%, with the implementation being completed in 6 weeks (compared to the same 9 months if done manually).

[0105] In another example, our solution was used to cloud replatform a .NET web application for one of our leading consulting firms. The source application environment is a content management company and one of the largest professional services and auditing organizations, with employees in over 700 offices in 150 countries around the world. The primary business challenge was a complex .NET web application developed over several years using ASP.NET, C#, and Telerik ORM, alongside the use of Microsoft MQ and a SQL Server database. This application is business-critical, handling key B2C functions for the leading professional services provider. The task was further complicated by the unavailability of a key SME who developed the application. Using the current solution approach, the source application will be split into a web front-end and a service back-end. The back-end legacy .NET service using Telerik ORM will be replatformed into independent .NET Core service apps with Entity Framework and REST endpoints. The web front-end and each service app will be deployed in separate containers on the Azure cloud with Kestrel & NGINX, providing infinite scalability, high availability, high fault tolerance, and improved performance. The web front and macro services were made stateless with Redis cache. The message broker was replatformed to RabbitMQ. The services' REST API endpoints are secured by oAuth2. Automated testing + CI / CD was enabled for the web front and all macro services. Among the top benefits, the replatforming resulted in a TCO reduction of over 45% mainly due to the deprecation of IIS & Telerik ORM, a total cost of implementation reduction of over 45%, and increased development productivity due to the macro services and CI / CD automation, which was completed in 6 weeks compared to 7 months if done manually.

[0106] Although implementations of the system and method for message broker migration during application environment migration are described in language specific to structural features and / or methods, it is to be understood that the appended claims are not necessarily limited to the particular features or methods described. Rather, the specific features and methods are disclosed as example implementations for message broker migration during application environment migration.

Claims

1. evaluating, by a processor (122) of the application server (102), information related to message broker components associated with a source message broker (412) of the source application environment for use in predicting evaluation statistics (302); scanning the structure of a source message broker (412) by said processor (122) to identify connections and dependencies between components (412a, 412b, . . . , 412n) of said source application environment; identifying, by the processor (122), quantitative changes for migrating the source message broker (412) to the target message broker (430) based on the source message broker's structure, identified connections, and / or dependencies; predicting, using an AI engine (152), evaluation statistics (302) based on the quantitative changes identified by the processor (122), the evaluation statistics (302) providing at least one of a functional readiness (304) and a timeline (306) for the migration of each message broker component from the source message broker to the target message broker to complete the migration of the source message broker (412); generating, by said processor (122), a transformed message broker structure (550a, ..., 550n), said transformed message broker structure (550a, ..., 550n) being generated by partitioning said source message broker (412) according to said target message broker (430) while maintaining said connections; updating, by the processor (122), the disaggregated message broker components (552a, . . . , 552n) of the target message broker (430) according to the predicted evaluation statistics (302) and the transformed message broker structure (550a, . . . , 550n); migrate, by the processor (122), the source message broker (412) to the target message broker (430), wherein the migration includes replatforming the updated fragmented message broker components (552a, . . . , 552n).

2. 2. The method of claim 1, wherein the quantitative change for migrating the source message broker (412) to the target message broker (430) is calculated based on the size and complexity of the source message broker (412).

3. 10. The method of claim 1, wherein the transformed message broker structure (550a, . . . , 550n) is generated utilizing a continuous integration and deployment framework (150) and an automated testing framework (150).

4. The method of claim 1 , wherein the evaluation statistics (302) provide at least one inhibitor that prevents the source message broker (412) from completing the migration.

5. 2. The method of claim 1, wherein the transformed message broker structure (550a, . . . , 550n) is generated according to the target message broker (430) while maintaining connectivity between the components (412a, 412b, . . . , 412n) of the source message broker (412).

6. The method of claim 1 , wherein the transformed message broker structure (550a, . . . , 550n) is identified by an AI engine (152).

7. The method of claim 1 , further comprising migrating, by the processor (122), queues and topics from the source application environment according to a target application environment.

8. The method of claim 1 , further comprising implementing, by the processor (122) a message broker service and a service endpoint according to a target application environment.

9. 2. The method of claim 1, further comprising accessing, by the processor, application code including business logic, links, a rules engine, libraries of available environments, standard tools, and coding languages.

10. 2. The method of claim 1, wherein the source message broker (412) of an application environment is migrated to the target message broker (430) including the steps of rebuilding the environment from the source to the target message broker, refactoring from the source to the target message broker, rehosting from the source to the target message broker, and replatforming from the source to the target message broker.

11. The method of claim 1 , wherein the target message broker (430) is a cloud-based message broker ecosystem.

12. a processor (122), a memory (126) coupled to the processor (122), and an AI engine (152); The processor (122) executes a plurality of modules (128) stored in the memory (126); The plurality of modules (128) evaluate information related to message broker components associated with a source message broker (412) of the source application environment for use in predicting the evaluation statistics (302); an assessment module (130) that scans the structure of the source message broker (412) to identify connections and dependencies between components (412a, 412b, ..., 412n) of the source application environment, and identifies quantitative changes for migrating the source message broker (412) to a target message broker (430) based on the structure of the source message broker and the identified connections and / or dependencies; and, based on the identified quantitative changes, predicts, using the AI ​​engine (152), assessment statistics (302) that provide at least one of a functional readiness (304) and a timeline (306) for migrating each message broker component from the source message broker to the target message broker to complete the migration of the source message broker (412); a refactoring module (132) for generating a transformed message broker structure (550a, . . . , 550n), the transformed message broker structure (550a, . . . , 550n) being generated by splitting the source message broker (412) according to the target message broker (430) while maintaining the connections; a replatforming module (134) for updating the disaggregated message broker components (552a, ..., 552n) of the target message broker (430) according to the predicted evaluation statistics (302) and the converted message broker structure (550a, ..., 550n) and migrating the source message broker (412) to the target message broker (430), wherein the migration replatforms the updated disaggregated message broker components (552a, ..., 552n).

13. 13. The system of claim 12, wherein the quantitative change for migrating the source message broker (412) to the target message broker (430) is calculated based on the size and complexity of the source message broker (412).

14. 13. The system of claim 12, wherein the transformed message broker structure (550a, . . . , 550n) is generated utilizing a continuous integration and deployment framework (150) and an automated testing framework (150).

15. The system of claim 12 , wherein the evaluation statistics (302) provide at least one inhibitor that prevents the source message broker (412) from completing the migration.

16. 13. The system of claim 12, wherein the transformed message broker structure (550a,...,550n) is generated according to the target message broker (430) while maintaining connectivity between the components (412a, 412b,...,412n) of the source message broker (412).

17. The system of claim 12, wherein the transformed message broker structure (550a, . . . , 550n) is identified by an AI engine (152).

18. The system of claim 12 , wherein the refactoring module (132) further comprises migrating, by the processor (122), queues and topics from the source application environment according to a target application environment.

19. The system of claim 12 , wherein the replatforming module (134) further comprises implementing, by the processor (122), a message broker service and a service endpoint according to a target application environment.

20. 13. The system of claim 12, wherein the plurality of modules (128) are further configured to access, by the processor (122), application code (202) including business logic, links, rules engines, libraries of available environments, standard tools, and coding languages.

21. 13. The system of claim 12, wherein the source message broker (412) of an application environment is migrated to the target message broker (430) including the steps of rebuilding the environment from the source to the target message broker, refactoring from the source to the target message broker, rehosting from the source to the target message broker, and replatforming from the source to the target message broker.

22. The system of claim 12 , wherein the target message broker (430) is a cloud-based message broker ecosystem.

Images