KR101061326B1 - Application Server Development System - Google Patents

Abstract

An embodiment relates to an application server development system.

The application server development system according to the embodiment includes a repository based real time application server development system using a diagram in application server development.

Application Server, Modeling, Test

Description

Application Server Development System {DEVELOPING SYSTEM FOR APPLICATION SERVER}

The embodiment relates to a repository based real time application server development using a diagram and its operating system.

Conventionally, the demand for productivity and quality improvement is increasing when developing an application system. For this purpose, the use of various tools supporting each process of design document creation, source coding, compilation, and distribution is required.

However, according to the prior art, there are many factors that lower productivity and quality at the time of initial development as well as continuous change management.

For example, the prior art requires manual synchronization operations due to the different form of each tool product and lack of integrated connectivity.

In addition, according to the prior art, additional work is required due to an inconsistency in the interdependency relationship at the time of compilation and an inconsistency in the environment at the time of distribution.

In addition, according to the prior art, additional work such as bug elimination work is required due to the lack of design and development pre-validation during testing.

In addition, according to the prior art, it is very difficult to grasp the business model at the time of reuse, and thus it is only a level of utilization of paste after copying at the source code level.

The embodiment is intended to solve the above problems, such that it is possible to create, change, and execute in a single form (diagram), thereby maximizing both productivity and quality improvement by eliminating complete integration and additional work. The goal is to maximize reusability through business model refinement and GAP reflection speed.

The application server development system according to the embodiment includes a repository-based application server development system using a diagram in application server development.

According to the embodiment, the design specification can be created, changed, and executed without source coding, thereby providing a productivity and quality improvement by unifying multiple tasks (design creation, source coding, build, and distribution) with a consistent view. And improve reusability by acquiring and utilizing formal business models.

In other words, the embodiment expresses design specifications as diagrams without source coding, compiling, and distributing work, which can maximize productivity and maximize the reusability of business models through the completion and operation of application server development (change management, execution). have.

The embodiment is a method of developing an application server. Instead of documenting, re-coding, compiling, and distributing design specifications, the design specifications are represented by diagrams to provide integrated management based on repository (change management, call relationship management). It can lead to quality improvement (design verification, elimination of document and source mismatch problems), and productivity improvement (resource elimination) and quality improvement (reduction of coding errors) through repository-based execution engines.

In addition, the embodiment does not have to analyze and partially utilize difficult source code with mismatched design documents when using existing cases, but repositories' refining flexibility that includes pre-modeled business models (using diagram rather than source code). Increased understanding) and immediate execution (run through an engine independent of the operating environment) can maximize reuse value.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings.

According to the embodiment, the design specification can be created, modified, and executed without source coding, thereby providing productivity and quality by unifying multiple tasks (design creation, source coding, build, and distribution) with a consistent view. And improve reusability by acquiring and utilizing formal business models.

Repository-based real-time application server development using the diagram according to the embodiment and its operating system 100 may include a modeling UI (110) and the server (120).

The modeling UI 110 may include four layers (Business Service, Business Rule, Data Access, Service Access) for management modeling and business modeling for defining a server environment, and provides a modeling function for each layer and provides a remote location. You can create, modify, and test functions by communicating with your server (modeling engine).

The server 120 may include a modeling engine 121, an execution engine 122, and a repository 123.

The modeling engine 121 is composed of a server environment manager and four model managers for each layer. The modeling engine 121 stores and manages information received from the modeling UI in a repository, and performs a function of requesting a server (execution engine) for real-time reflection and testing. do.

The execution engine 122 is composed of four layer executers, and loads repository information for each layer to perform business logic, DB queries, and legacy interworking.

In addition, the execution engine 122 is divided into a test and a service, the test is used for real-time verification in the modeling UI using the test DB, the service is used when requesting from the business UI, Legacy system, etc. using the operation DB It serves to provide services.

The repository 123 serves as a business model repository that integrates and stores all the business logic depicted in the diagram.

The embodiment may operate as shown in FIG. 2.

According to the embodiment, the design specification can be created, modified, and executed without source coding, thereby providing productivity and quality by unifying multiple tasks (design creation, source coding, build, and distribution) with a consistent view. And improve reusability by acquiring and utilizing formal business models.

In other words, the embodiment maximizes productivity and maximizes reusability of business models through the completion and operation of application server development (change management, execution) by simply expressing design specifications as diagrams without source coding, compilation, and distribution. can do.

The embodiment is a method of developing an application server. Instead of documenting, re-coding, compiling, and distributing design specifications, the design specifications are represented by diagrams to provide integrated management based on repository (change management, call relationship management). It can lead to quality improvement (design verification, elimination of document and source mismatch problems), and productivity improvement (resource elimination) and quality improvement (reduction of coding errors) through repository-based execution engines.

In addition, the embodiment does not have to analyze and partially utilize difficult source code with mismatched design documents when using existing cases, but repositories' refining flexibility that includes pre-modeled business models (using diagram rather than source code). Increased understanding) and immediate execution (run through an engine independent of the operating environment) can maximize reuse value.

(Example)

Hereinafter, a method of building a business solution server, opening a service, and responding to change management using an application server development system according to an embodiment will be described using eLibrary. eLibrary is an example business solution basically included in the application server development system according to the embodiment, and the business solution is not limited thereto.

Hereinafter, the requirements will be described in order of definition step, modeling plan step, modeling and test step, method exposure step, and change management step.

On the other hand, the embodiment will be described for the application server development system for library, etc., but the embodiment is not limited to such library.

First of all, the requirements stage can define requirements, and the requirements can be library library, book loan and return, status inquiry, etc. In case of library library, book receipt, book search, book inquiry, There may be specific requirements, such as book revision and book disposal.

Next, a modeling planning step is described according to the above requirements.

In an embodiment, a use case diagram may be set for a modeling plan, and a sequence diagram may be set accordingly.

For example, as shown in FIG. 3, a sequence diagram for “book receipt” among “book management” requirements may be set, and a sequence diagram for other requirements such as book search and book modification may be set.

Next, the modeling and testing steps are described.

The modeling and testing phase is where you complete your service while modeling and testing your business logic. The modeling and testing phases in the embodiment are modeling and test environment construction phases, data access modeling and testing phases, data access method execution phases, business rule modeling phases, business rules. It may include, but is not limited to, an active business rule method. It will be described sequentially below.

First, the modeling and test environment construction steps are explained.

Modeling and test environment construction can be done by the administrator. Therefore, in order to build environment, ".admin." You can log in as a user, for example. ".admin." The initial password of the user may be ".admin."

After that, proceed with the DB (Database) server registration. In this step, you register a database server to access from the Data Access layer. In this case, in order to minimize the effect of the database server change, the embodiment may grant an alias when registering the database server. Accordingly, the Data Access layer refers to Alias assigned to each database server. Even if the database server related information is changed, the data access layer does not need to be changed, and only the database server related information needs to be changed.

For example, you can enter ".eLibraryDB." As the alias for the database used by eLibrary. ".Name." On the database registration screen You can type in the text box.

In the embodiment, the database used by the eLibrary may support Oracle and MS SQL Server 2000 or higher, but is not limited thereto. For example, the embodiment may employ Microsoft SQL Express 2005, but the server type may be selected as a Structured Query Language (SQL) Server, but is not limited thereto. The embodiment can be implemented in a Java version and a .NET version. For a Java environment, for example, JDK 1.4 or later and WAS (WebLogic / WebSphere / JEUS) are possible.

In the embodiment, the database used by the eLibrary may not be separately separated from the database to be used in the building phase and the service to be used in the service. Each item and value may be paired and connected to the database connection string. If you need more connection information, the administrator can add it yourself.

The application server development system according to the embodiment may manage the database server information (Test Server Information) to be accessed at the business solution server building stage and the database server information (Service Server Information) to be accessed when in actual service. That is, database-related work that occurs when building a business solution server may be performed in the database server defined in Test Server Information, and database-related work that occurs after the service starts may be performed in the database server defined in Service Server Information.

Next, the registration step of the modeler will be described. This step registers modelers to participate in modeling and testing, and can be given an ID and a password. For example, in the embodiment, eLibrary is added by default to ".sample." Your account is available so you don't need to register a separate ID. The initial password of the account may be ".sample."

In this embodiment, the Component and Method of the eLibrary are ".sample." An account can take ownership. Thus ".sample." You can change the method only by logging in with an account. If you log in with a different account, you may only be able to refer to it.

Next, data access layer modeling and testing steps will be described. The Data Access layer is a collection of components and methods that connect to and perform operations on the database server. The method of the data access layer can be called by the methods of the business rule layer or can be directly exposed to the outside.

First, the components of the Data Access layer can be classified into two categories, one table / view management Component (see Table 1) and Ad-hoc / Stored Procedure Component (see Table 2), depending on whether one table / view is used. .

As shown in Table 1, the one table / view management Component is pre-assigned the table / view to be used for creation. Therefore, most of the methods belonging to this component include simple SQL statements that work only with the table / view specified by the component. And since the patterns of SQL statements are almost the same, modelers can easily and quickly create SQL statements with a click of a mouse, according to the guidance provided by the manager of the application server development system.

As shown in Table 2, Ad-hoc / Stored Procedure Component does not specify the table / view to be used when creating. Therefore, methods belonging to this component include complex SQL statements using several objects in the database. And since the pattern of the SQL statements is not fixed, the modeler must write all the SQL statements directly.

Next, a data access method will be described. The Data Access Method performs the tasks specified by the modeler in the actual database.

Data Access Method can be called by Business Rule Method, or it can be exposed and serviced externally. Data Access Method includes Data Access Method (Wizard method, Script method) (see Table 3) belonging to One table / view management Component, Data Access Method (Normal SQL statement and Optional Condition SQL) belonging to Ad-hoc / Stored Procedure Component. Ad-hoc SQL statements, stored procedure calls (see Table 4), and so on.

Data Access Methods belonging to One table / view management Component are shown in Table 3.

Data access methods belonging to the Ad-hoc / Stored Procedure Component are shown in Table 4.

Next, after modeling the Data Access Method, the test is performed. Only after a successful test can you share with other modelers. Tests can be found in the ".Test." Tree context menu. ".Test." In the menu or in the Data Access Method window. It can be done with a button.

Next, the Activate step will be described. Activate is a command that allows other modelers to call a modeled and tested Data Access Method. In other words, Activate can be thought of as a command that a modeler declares that a method has been modeled and tested. The Data Access Method that has been successfully activated can be used by all modelers. If the activation is successful, the icon of the method can be changed to "A".

Next, business rule layer modeling and testing steps are explained.

The business rule layer is a set of components and methods that execute the business logic modeled by the modeler. The method of the business rule layer may be called by the methods of other business rule layers, or may be directly exposed to the outside. You can also call Data Access Methods internally.

First, the Business Rule Component will be described.

Unlike the Data Access Component, the Business Rule Component has no type, and the information required for creation can be simple. In general, eLibrary may configure a Business Rule Component as shown in Table 5, but is not limited thereto.

Next, the business rule method will be described. Business Rule Method can execute the business logic modeled by the modeler.

In an embodiment, the business rule method configuration of the eLibrary may be as shown in Table 6, but is not limited thereto.

4A to 4N are examples of modeling a business rule method using an application server development system according to an embodiment, but are not limited thereto.

First, ID and Input / Output parameters are defined as shown in FIG. 4A.

Next, necessary variables may be defined internally as shown in FIG. 4B.

Next, as shown in FIG. 4C, a step for calling a method that has already been created may be added.

Next, a method to be called is selected as shown in FIG. 4D.

Next, the input / output data of the method to be called are allocated as shown in FIG. 4E.

Next, pressing OK as shown in Figure 4f can be added to the call step as shown below.

Next, as shown in FIG. 4G, another method call step may be added in the same manner as in the above procedure, and then a loop step may be added.

Next, as shown in FIG. 4H, a repetition condition, an index initial value, and an increment value may be defined.

Next, as shown in FIG. 4I, if the user presses OK, a loop step may be added as shown below.

Next, a Substitution step may be added to change or assign a value as shown in FIG. 4J.

Next, the target variable cell can be selected as shown in FIG. 4K.

Next, other variables or calculated values may be assigned as shown in FIG. 4 |

Next, pressing OK as shown in Figure 4m may be added to the Substitution step as shown below.

Next, Figure 4n is completed by adding more call steps.

Hereinafter, the test steps for the business rule method will be described.

5A to 5C are exemplary views of testing a business rule method using an application server development system according to an embodiment.

After modeling the business rule method, test should be performed. Only after a successful test can you share with other modelers. As illustrated in FIG. 5A, a test may be performed by using a "Test" menu of a tree context menu or a "Test" button of a Business Rule Method window.

When testing the business rule method, you can perform the test step by step. If you use the "Request by step" button in the test window as shown in Figure 5b, a flow diagram appears, you can proceed or stop step by step using the "Start", "Go next step", "Stop" button. After performing one step, the result can be confirmed using the Output tab as shown in FIG. 5C.

Next, the Activate step of the business rule method will be described.

Like the Data Access Method, the Business Rule Method must be activated so that it can be shared with the modeler and the service can be started externally. Activate changes the status from "C" to "A".

Next, the method exposure step will be described.

6A to 6B are diagrams illustrating method exposure in an application server development system according to an embodiment.

Business Rule Method, Data Access Method, and Service Access Method can all be exposed to the outside. In other words, if it receives a request from the outside, it can provide a service. In order to expose the method to the outside, it must be activated, and a "Start Service" command must be given as shown in FIG. 6A.

If you select a method to expose to the outside and give the command "Start Service", the icon of the method changes from "A" to "S" and the method is added under the "Business Service" node.

In the embodiment, all methods that are currently exposed to the outside world exist under the "Business Service" node of the tree. In the eLibrary of the embodiment, the method as shown in FIG. 6B may be exposed to the outside and serviced.

Next, the change management step will be described.

First, the dependency checking step will be described.

Activated methods can be called by other business rule methods. The call relationship between these methods can be checked in the Dependency tab of each method window. Caller is a list of methods to call itself, Callee may be a list of methods to call itself.

Next, the activated method change will be described.

7A to 7C are diagrams illustrating an example of changing an activated method in an application server development system according to an exemplary embodiment.

Activated methods are called by methods written by other modelers, so changing them may affect other methods. Therefore, be careful about changes. If you change the activated method and click the "Apply" button, it changes to the "Modifying" state. After modification and testing, it is reflected in the actual method through the "Reactivate" command. The method before modification continues until it is "Reactivate".

There are two cases of change, and the effect on other methods is different. If only the internal logic is changed, it is unnecessary to change the method that calls the modified method. On the other hand, when changing the In / Out Parameter, it is necessary to change the method that calls the modified method.

First, the internal logic change will be described.

If a change occurs only internally without changing the in / out parameter, whether it is a data access method or a business rule method, other methods that call the changed method need not be changed directly. In other words, you only need to "Reactivate" after modifying the method you want to change.

Next, the change of the In / Out Parameter will be described.

If the In / Out Parameter is changed, all the methods calling the changed method should be changed. In other words, you need to double check all the In / Out parameters that you mapped when you called.

Figure 7a is an exemplary view of the change effect check in the embodiment.

If a method's In / Out parameter changes, all affected methods will be marked with a "?". FIG. 7A shows that the In / Out parameter of the "Generate Book Master Number" method called in the "Receipt of Book" method of eLibrary is changed to indicate that the "Receive Book" method needs to be changed. Mark is displayed. The modeler says "?" After opening the method with the mark, you can modify the required part and "Reactivate" again.

7B is an exemplary view of a change order when a parameter is added.

If a parameter is added, all the methods in the call chain can be modified and reactivated first in order to reflect the change without interruption of service. If the call has a call relationship as shown in FIG. 7B and a parameter of Method D needs to be added, Method A, Method B / Method C, and Method D may be modified and then reactivated.

Next, FIG. 7C is an exemplary diagram of a change order when a parameter is deleted in the embodiment.

If the parameter is deleted, all the methods in the call chain can be modified to reflect the changes without interruption of service, and the lowest method can be reactivated in order. If it has a call relationship as shown in FIG. 7C and a parameter of Method D needs to be deleted, Method D, Method B / Method C, and Method A may be modified and then reactivated.

The embodiment has the following additional features.

First, the embodiment may be implemented in a Java version and a .NET version, but is not limited thereto. The embodiment may support Java environment (JDK 1.4 or higher / WAS (WebLogic / WebSphere / JEUS)). In other words, the technical area of the embodiment has been expanded to support the Java environment (JDK 1.4 or higher / WAS (WebLogic / WebSphere / JEUS)) as well as the .NET environment (.NET 2.0 or higher / COM +), and to customize other WAS. It is possible through.

Second, the embodiment may provide a history management and rollback function for the service definition stored in the repository by the configuration management function.

In other words, the embodiment is stored in the repository on the server through the modeling UI without the download / upload, unlike the configuration management method of the check-in / out-based download / upload method by the configuration management function integrated with the change tool. You can change the existing service definition, change history management through it, and select and roll back the previous version.

Third, the embodiment may provide a function of selectively moving service definition contents in a repository between BizActors located remotely by a model remote merging function.

That is, the embodiment can synchronize the real-time execution state and the selective movement of the service definition content in the repository between the BizActors in the remote in real time, unlike the existing deployment method by the model remote merge function.

Fourth, the embodiment can provide a detailed execution performance logging and reporting function for each service defined by the execution performance analysis function.

In other words, the embodiment executes and logs differently from the existing execution programs such as components by the execution performance analysis function provided by the execution engine itself. It can provide logging and reporting functions.

Fifth, the embodiment may provide a calling system and a structured query language (SQL) reporting function between all services by using a change impact analysis function.

That is, the embodiment manages the dependencies and parameters between services by real-time change impact analysis function through integrated management, and immediately informs the service to be affected when the parameter is changed, and when the change is made, it displays the affected service and even the detailed step location. It can guide to supplement changes, and can also provide calling system and reporting of Structured Query Language (SQL) between all services.

The present invention is not limited to the described embodiments and drawings, and various other embodiments are possible within the scope of the claims.

1 is a block diagram of an application server development system according to an embodiment according to the embodiment.

2 is an example of utilization of the application server development system according to the embodiment.

3 is an exemplary diagram of a sequence diagram of a modeling plan in an application server development system according to an embodiment.

4A to 4N are exemplary views of modeling a business rule method using an application server development system according to an embodiment.

5a to 5c is an exemplary diagram for testing a business rule method using the application server development system according to the embodiment.

6a to 6b are views illustrating a method exposure in an application server development system according to an embodiment.

7A to 7C are views illustrating a method of changing an activated method in an application server development system according to an embodiment.

Claims (15)

Based on a repository using a diagram, A modeling UI for modeling business logic; And A server for testing and executing the modeled business logic; The server comprises a modeling engine for storing and managing the information received from the modeling UI in the repository; And an execution engine for testing and executing the business logic. The repository is included in the server, and serves as a business model repository that integrates and stores diagram-based business logic. The business logic is a single, unified business execution model that is ready to run on the execution engine at design time. The integrated single business execution model is a formal business model, The formal business model is an application server development system, characterized in that the business execution model of the two types of diagram information stored and the form for execution integrated. delete The method according to claim 1, The modeling UI The management screen for defining a server environment and a plurality of layers for the business logic modeling, Applied server development system that provides the modeling function for each layer, and performs the business logic to create, change, and test through communication with the server. delete The method according to claim 1, The modeling engine includes a server environment manager and a plurality of layer managers (Layer), the application server development system performing a function of requesting the execution engine for real-time reflection and testing. The method according to claim 1, The execution engine Application server development system that includes executor for each layer and loads repository information for each layer to test and execute business logic, DB query and Legacy integration. The method according to claim 1, The execution engine is an application server development system including a test execution engine and a service execution engine. 8. The method of claim 7, The test execution engine is used for real-time verification in the modeling UI using a test DB, The execution engine for the service is an application server development system that serves to provide a service upon request in a business UI, legacy system using the operation DB. delete delete The method according to claim 1, The application server development system Application server development system, characterized in that can be implemented in the .NET (.NET) version or Java (Java) version. The method according to claim 1, The application server development system An application server development system comprising a history management and rollback function for the formal business model stored in the repository through the modeling UI without downloading and uploading by an integrated configuration management function. The method according to claim 1, The application server development system An application server development system characterized by providing a selective movement of the business logic content in each repository between a plurality of application server development systems by a model remote merge function. The method according to claim 1, The application server development system An application server development system characterized by providing a detailed execution performance logging and reporting function for each business logic service defined by the execution performance analysis function. The method according to claim 1, The application server development system Application server development system, characterized in that by providing a change impact analysis function, provides a call system and SQL (Structured Query Language) reporting function between business logic services.

Images