Patent Application
20200387372
Many enterprise software applications must work with a variety of other applications, such as various browsers, operating systems and/or external services. In addition, most enterprise software applications are maintained and updated by a large, often geographically distributed team of developers rather than a single person or small group. This creates challenges for large-scale applications that are developed with a monolithic architecture, as changes to one element of the application can affect other elements in such an architecture. In addition, changes to applications developed with a monolithic architecture often can only be implemented in an update to the entire application.
To address these challenges, enterprise and other server-side applications may employ a micro services architecture, in which the application is made of a collection of loosely coupled, collaborating code sets. Each code set, as well as the service provided when the code set is running, may be referred to as a microservice. Each microservice involves a particular function, and it only needs to define operations that pertain to that function. Microservices can be stored and/or executed across multiple hosts, and therefore can help decentralize processing and memory requirements.
However, even the development of micro services requires some time and resources, both human and computational. Microservices also require that the developer know various characteristics of the application programming interfaces (APIs) with which the microservice will interact. These issues can delay the development and deployment of micro services in large enterprises.
This document describes a system that can help reduce processing time and resources required to generate or update microservices.
In various embodiments, a microservice file generation system includes a processor, a user interface, and a computer-readable medium containing programming instructions that are configured to cause the processor to create a project structure for a microservice. The system will receive a project definition for a microservice, receive definitions for domain objects for the micro service, receive dependencies between one or more of the domain objects and one or more internal or external services, and use the domain objects and the dependencies to define a project structure. The project structure includes a repository comprising various containers. Each of the containers has a label and is configured to contain code corresponding to one or more of the domain objects, one or more of the dependencies, and/or one or more additional containers. For one or more of the containers, the system will access a data store containing code elements. The system will identify a code element having one or more attributes that correspond to the label of the container. The system will extract the identified code element and populate the container by copying the code element to the container, and the system will present the project structure to a user via the user interface. The user interface is configured to, upon selection of one of the containers by the user, enable the user to edit the code element in any container that is populated with a code element, and enter code into any container that is not already populated with a code element.
Optionally, after the user has entered and/or edited one or more of the code elements, the system may access a test case file that corresponds to one or more attributes of the project, insert one or more of the entered and/or edited code elements into the test case file, and run a simulation of the test case file to test operation of the microservice. If at least one of the containers is a test container, then after running the simulation the system may save results of the simulation to the test container.
Optionally, after the user has entered and/or edited one or more of the code elements, the system may save the code elements of each of the containers to a project file.
Optionally, if one or more of the containers corresponds to a specified application program interface (API), the system may, for any container that corresponds to a specified API: access a data store of code; identify, in the data store, code that corresponds to one or more of the objects and one or more of the dependencies; and transfer the identified code from the data store to the container that corresponds to the specified API. Before transferring the identified code, the system may place the identified code in a temporary container and receive, via the user interface, edits to the identified code. If so, then when transferring the identified code from the data store to the container that corresponds to the specified API, the system may do so for the identified code with the received edits. As another option, the system may access a data store containing API documentation for various APIs, identify API documentation in the data store that corresponds to the specified API, and present the identified API documentation to the user.
Optionally, when defining the project structure, the system may create at least one of the containers as an empty container that is configured to receive user input via the user interface.
Optionally, when defining the project structure, the system may identify a project configuration file that defines the project structure names for each container in the project structure.
Optionally, one or more of the containers may include a database folder that holds domain entity and database repository classes. In addition, one or more of the containers may include an integration folder that contains classes for integration with other services.
As used in this document, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise. Unless defined otherwise, all technical and scientific terms used herein have the same meanings as commonly understood by one of ordinary skill in the art. As used in this document, the term “comprising” (or “comprises”) means “including (or includes), but not limited to.” When used in this document, the term “exemplary” is intended to mean “by way of example” and is not intended to indicate that a particular exemplary item is preferred or required.
In this document, when terms such “first” and “second” are used to modify a noun, such use is simply intended to distinguish one item from another, and is not intended to require a sequential order unless specifically stated. The term “approximately,” when used in connection with a numeric value, is intended to include values that are close to, but not exactly, the number. For example, in some embodiments, the term “approximately” may include values that are within +/−10 percent of the value.
Each end-user-facing application (such as website application 101 and/or mobile application 102) will be associated with one or more application programming interfaces (APIs) 109. Each API 109 is a software intermediary that defines functions of its associated application. Each API 109 relays requests from one or more connected services to the API's associated application, and it returns the application's responses to the connected service(s). In this example, the connected services are microservices of a server-side application for managing the online storefront, including a chat microservice 103 that is connected to a technical or other customer service support service 105 via a support API 104, as well as an inventory microservice 113 that is connected to an inventory database 115. The connected services also may include microservices of a different server-side application, such as an employee access portal microservice 123 that is connected to a human resource service 125 via an employer intranet API 124.
A discussion of some background terminology will be helpful before we describe the invention. First, “domain objects” are entities and value objects that encapsulate behavior required by a domain. In the context of a retail storefront website, an example domain may include a shopping cart, a garment or shoe sizing tool, or a product comparison tool. Domain objects and sub-objects of the shopping cart domain may include features such as calculation, payment and authorization. “Domain services” encapsulate behaviors of a single domain object, and are where the business logic for a domain resides (example: create/read/update/delete information for cart domain services. In contrast to domain services, “application services” handle the flow of use cases, including any additional concerns needed on top of the domain (example: a transfer/calculate order process would be part of application services).
In a traditional (prior art) manual microservice generation process, developers will identify domain objects and domain sub-objects, then begin technical design of aspects such as the application programming interface (API), database, front-end and data model. When this is complete, coding and building starts, which can take several weeks. Testing and updating comes afterward, adding more time and risk of human error in the process. By way of example, referring to
In various embodiments of the approach that the applicant has developed, a microservice file generation application is available as a set of instructions that, when executed, will cause a computing device to output a user interface via which a developer can more quickly and easily create and/or update microservices for various server-side applications. This application can increase speed, reduce coding errors, and ensure interoperability of domains and sub-domains in the code and build portion of the application generation process. The system will do this by: (1) defining the domain objects and operations; (2) defining dependencies between each domain object and internal and/or external systems; (3) defining a database/entity structure for the project; (4) starting and performing behavior-driven development; and (5) onboarding the microservice(s) to an existing platform or an under-development platform.
The microservice file generation application will generate and output on a computer system a user interface via which developers may specify features of various microservices. The system will start by receiving a project definition (step 301) from a user. In some embodiments, the user may use the microservice file generation application to generate a new microservice application file. In this case, the user may select a “define new project” or similar function in the user interface. In other embodiments, the system may enable the developer to select and edit an existing microservice application file. The application may do this by providing a user-selectable function for generating new files, or by defining the project as an existing microservice, in which case the system will access and retrieve existing files that are available in a connected library of microservice application files. The files associated with any particular microservice will typically be stored together in a data store that contains a directory for the microservice, and they may include configuration (config) files, a project object model (POM), source code for execution of the microservice's functions, and other fields.
The system will then open the defined project (step 302) as one or more build files, which may be a new file for a new microservice or an existing file (or files) for an existing microservice. The system may use a toolkit such as Maven (available at maven.apache.org) to open and enable a user to access and edit the microservice's files (step 303).
The system will provide a user interface via which a user may select and edit the microservice's operational file (i.e., the file with rules for generating requests for a connected API and receiving and processing responses from the API), configuration files containing parameters and settings that the operational file, object files containing constants and/or other information such as source and sink identifiers. Optionally, the system may open one or more templates, and/or apply certain structures, to build any of these files and/or edit a known file.
Optionally, the system may include a user interface via which the user may access documentation for the API (step 304) to which the microservice will be linked. This may be a unique user interface, or a known interface such as the Swagger UI 401, as shown in
Returning to
The system may define the domain objects (step 501) and operations by a combination of manual input via a user interface, retrieval from a database or lookup table, or otherwise. For example,
The system may define the dependencies (step 502) between each domain object by a combination of manual input via a user interface, retrieval from a database or lookup table, or otherwise. For example,
The system will then use the objects and dependencies to automatically create a project structure (step 503) that code developers can use to expedite a code generation process. For example,
Each container in a repository will have sub-containers and/or one or more files corresponding to its container label. The system may populate any or all of the containers in the repository with certain default information. For example, an API folder (container) 802 may include code for security, manifest, swagger and basic create-read-update-delete (CRUD) services. A database folder 803 may hold domain entity and database repository classes. An integration folder 804 may contain classes used for connecting with other services. The integration folder 804 also may contain a sample client program to test the integration. A testing folder 805 may be used to hold artifacts from prior integration tests and/or new tests, when performed. Other folders such as a messaging folder may be generated if the system determines that the objects and dependencies would support a messaging function.
Some of the containers may be empty and available for user input. The system may populate any or all of the other containers by accessing a data store of code, identifying code in the data store that has a label corresponding to the label of the container, and extracting the identified code to place a copy of the code in the container. A code may correspond to the label if it matches the label, if it has a semantic similarity to the label, if it corresponds to both the container's label and the container's parent container's label, or based on any suitable a set of rules that the system employs.
Optionally, the system may process and modify the code before copying it to a container. For example, before being deployed to a container, the system may place a code set for a container in a temporary output folder. The code in the output folder may have one or more fields that will be completed and/or revised to include certain attributes of the project, such as a project label and/or one or more dependencies. When a developer has reviewed, revised (if needed) and accepted the code in the output folder, the code may then be transferred (moved or copied) to the appropriate container.
Returning to
In some embodiments, the system may automatically test (step 306) a new or updated microservice application file set to ensure that it works with the associated API. The system will do this by running test case files, an example of which 901 is shown in
When editing and/or testing of the microservice's files has completed, the system will save the new and/or updated files to the data store in the microservice's directory (step 308), such as in a testing container 805 as shown in
An optional display interface 1030 may permit information from the bus 1000 to be displayed on a display device 1035 in visual, graphic or alphanumeric format. An audio interface and audio output (such as a speaker) also may be provided. Communication with external devices may occur using various communication devices 1040 such as a wireless antenna, an RFID tag and/or short-range or near-field communication transceiver, each of which may optionally communicatively connect with other components of the device via one or more communication system. The communication device 1040 may be configured to be communicatively connected to a communications network, such as the Internet, a local area network or a cellular telephone data network.
The hardware may also include a user interface sensor 1045 that allows for receipt of data from input devices 1050 such as a keyboard, a mouse, a joystick, a touchscreen, a touch pad, a remote control, a pointing device and/or microphone. Digital image frames also may be received from a camera 1020 that can capture video and/or still images.
The system also may include a data store 1060 that includes a computer-readable, non-transitory memory for storing information. Such information may include, for example, API documentation and/or the default code sets that the system may use to populate containers of a project structure.
In the description above, the terms “electronic device” or a “computing device” refers to a device or system that includes a processor and memory, and other components such as those shown in
The terms “processor” and “processing device” refer to a hardware component of an electronic device that is configured to execute programming instructions. Except where specifically stated otherwise, the singular terms “processor” and “processing device” are intended to include both single-processing device embodiments and embodiments in which multiple processing devices together or collectively perform a process.
The terms “memory,” “memory device,” “data store,” “data storage facility” and the like each refer to a non-transitory device on which computer-readable data, programming instructions or both are stored. Except where specifically stated otherwise, the terms “memory,” “memory device,” “data store,” “data storage facility” and the like are intended to include single device embodiments, embodiments in which multiple memory devices together or collectively store a set of data or instructions, as well as individual sectors within such devices.
In this document, the term “connected” when used to describe a relationship between two services or applications, means that the services or application are communicatively connected via one or more wired or wireless communication paths.
The features and functions described above, as well as alternatives, may be combined into many other different systems or applications. Various alternatives, modifications, variations or improvements may be made by those skilled in the art, each of which is also intended to be encompassed by the disclosed embodiments.
