KR102637168B1 - Appartus for providing application services, method thereof, and computationally-implementable storage medium storing a program for providing application services - Google Patents

Abstract

The disclosed embodiment relates to an application service providing device, an application service providing method, and a storage medium storing a program executable on a computer that provides the application service. One embodiment includes receiving a service request for an application package from a client using a workspace; performing authentication of the requested application package based on authentication information included in a software bundle related to the workspace; and approving or rejecting a service request for the received application package according to the authentication result.

Description

Device for providing application services, method for providing application services, and computer-readable recording medium storing programs for providing application services

The following disclosure relates to an application service providing device, an application service providing method, and a storage medium for storing a computer-executable program that provides the application service.

Depending on the transaction between a company and a company or between a company and an individual, information related to the transaction or documents containing that information are exchanged.

However, the exchange of documents and the format or specifications of information that must be included in the documents may vary depending on the company, and since the document format, internal request contents, or writing methods are different depending on the various transaction types, various software has been developed. come.

Such software can help you enter and exchange information necessary for transactions in a standardized form between multiple companies, such as electronic document exchange. As this method of electronic document exchange becomes more common, a standardized method is prescribed, so that time and effort can be reduced by converting it into a standardized electronic document and exchanging, accumulating, and processing it on the computers of the parties involved in the transaction.

However, the software that creates these standardized electronic documents often had the inconvenience of having to be individually changed depending on the parties to the transaction, the transaction mode, and the format and content of the transaction.

For new companies in the market, it may be difficult to prepare standardized forms and formats required by existing trading parties. Because there are many complex trading patterns and requirements in the market, it may be difficult to activate trading due to problems such as difficulty understanding or following these standardized trading formats.

In addition, if the parties to a transaction use incompatible software or have separate software in an incompatible system, there were technical inconveniences such as having to develop software for the transaction or having to install software suitable for the system. .

And even if application services were provided with the same software image, there were difficulties in providing efficient services, as all versions and types of software packages had to be prepared and provided for each client.

The disclosed embodiment is intended to solve the above inconvenient problems, and includes an application service providing device, an application service providing method, and a computer providing the application service that can solve technical inconveniences for transactions and further activate transactions. A storage medium storing an executable program can be provided.

One embodiment disclosed includes receiving a service request for an application package from a client using a workspace; performing authentication of the requested application package based on authentication information included in a software bundle related to the workspace; and approving or rejecting a service request for the received application package according to the authentication result.

The authentication information may vary depending on the workspace in which the software bundle is installed.

The step of performing the authentication may use a non-repudiation token based on the RSA (Rivest-Shamir-Adleman) encryption algorithm.

The workspace may run the same software bundle except for the authentication information.

One embodiment disclosed from another perspective includes a storage medium for storing data; and a server including at least one processor, wherein the processor receives a service request for an application package from a client; perform authentication of the requested application package based on authentication information included in a software bundle related to the workspace; and operations for approving or rejecting a service request for the received application package according to a result of the authentication.

One embodiment disclosed from another perspective includes receiving a service request for an application package from a client using a workspace; perform authentication of the requested application package based on authentication information included in a software bundle related to the workspace; and approving or rejecting a service request for the received application package according to the authentication result. Provides a storage medium for storing a computer-executable program that includes computer instructions and provides an application service.

According to the disclosed embodiment, technical inconveniences for transactions can be resolved and transactions can be further activated.

According to the disclosed embodiment, market transactions can be technically activated using software even if a standardized form for existing transactions is not prepared or there are complex transaction requirements.

According to the disclosed embodiment, a convenient transaction system can be provided even when transaction parties use incompatible software or have separate software in incompatible systems.

According to the disclosed embodiment, an efficient application service can be provided without the need to prepare all versions and types of software packages for each client.

1 is a flowchart illustrating an example of a method for providing an application service according to an embodiment.
Figure 2 is a diagram illustrating an example of providing an application service to a client through a workspace among the disclosed embodiments.
Figure 3 is a diagram illustrating an example of distributing packages to each node in the example of the disclosed application service device.
Figure 4 is a conceptual diagram disclosing elements for each layer for application service provision according to an embodiment.
Figure 5 is a diagram illustrating a concept in which an application service providing device establishes a channel between an instance and a client or partner according to an embodiment.
FIG. 6 is a diagram illustrating a specific example in which an application service providing device establishes a channel between an instance and a client or partner according to an embodiment.
Figure 7 is a diagram illustrating an example of setting up a distributed channel and receiving a service according to an embodiment.
8 is a diagram illustrating an example of managing setting information of a package installed according to an embodiment.
9 is a diagram illustrating an example of managing and using a package according to a workspace of the disclosed embodiment.
Figure 10 is a diagram illustrating an example of mapping EDI information as a type of application service according to an embodiment
Figure 11 is a diagram illustrating an example of providing an application service using an integrated package according to an embodiment
Figure 12 is a diagram illustrating an example of a platform interface according to an example of providing the disclosed application service.
FIG. 13 is a diagram illustrating another example of a platform interface according to an example of providing the disclosed application service.
FIG. 14 is a diagram illustrating an example in which an application service providing device according to an embodiment provides a framework for integrating different systems.
Figure 15 is a diagram showing an example of coding a connector among the integration flow functions based on graphics when developing an integration flow based on an embodiment.
Figure 16 is a diagram showing an example of graphic-based coding of services among the integration flow functions when developing an integration flow based on an embodiment.
Figure 17 is a diagram showing an example of graphic-based coding of the processor among the integration flow functions when developing an integration flow based on an embodiment.
Figure 18 is a diagram showing an example of graphically coding the control flow among the integration flow functions when developing the integration flow based on the embodiment.
Figure 19 is a diagram showing an example of coding a modifier among the integration flow functions based on graphics when developing an integration flow based on an embodiment.
Figure 20 is a diagram illustrating an example of providing a unique workspace isolated depending on the client according to an embodiment.
21 is a flowchart illustrating an example of providing a package to a client from an isolated workspace according to an embodiment.

Below, embodiments that can solve the above problems and solve technical inconveniences for transactions are disclosed.

When the components of the embodiments are mentioned below, they can all be implemented with optimized hardware or software unless specifically limited to physical devices.

1 is a flowchart illustrating an example of a method for providing an application service according to an embodiment.

The application service provision method according to the disclosed embodiment allows multiple clients to obtain, download, or add or change desired functions through a platform.

The embodiment may receive a channel request for transmitting and receiving information from a client using a virtual isolated workspace (S100).

When a client connects to the platform, the system can provide a virtual, isolated workspace to the client.

A client may have a workspace that can receive separate services, but the hardware base of the system providing each workspace may be common.

The system administrator or client can remotely control and update the system so that the client can receive the above services, and the system can be equipped with communication functions according to protocols linked to various standards.

The client can request a channel through which the desired information can be transmitted and received from the platform, and the platform can allow the client to set up the channel.

Detailed examples of this are disclosed below.

The embodiment may provide a platform service that allows a client to convert, such as create, change, or save an application package in his or her workspace (S200).

A client may develop an application package or part of a package in a system such as the embodiment, trade related applications or software, and operate a trading-related business.

Hereinafter, an application package or package refers to a bundle of programs or files, including an adapter package that supports protocols or services, a resource package required to execute a program, and an integrated package in which several packages are reintegrated. Includes etc. In the examples below, in some cases, the application package may be referred to as a software package.

The system may provide several means or specialized computer languages to support mapping to the various data formats and structures desired by the client. Additionally, the application and related tools can be provided to allow the client to change the application package.

Detailed examples of this are disclosed below.

The embodiment may provide a service that controls scale-out of the service when the client uses an application package or when another client receives an application service in his or her workspace (S300). This step can be performed as needed for scale control related to service provision. Clients can receive application services or operate application services without interruption depending on the provided system.

Detailed examples of this are disclosed below.

Figure 2 is a diagram illustrating an example of providing an application service to a client through a workspace among the disclosed embodiments.

This drawing is a conceptual diagram to explain workspace and multi-tenancy among the embodiments that provide the disclosed application service.

Embodiments may provide software-as-a-service (hereinafter referred to as SaaS) to users.

Embodiments may provide applications or SaaS-type software services used to transmit and receive information such as transactions between parties.

In this drawing, the transaction parties are indicated as Client 1 (110), Client 2 (120), or Client 3 (130).

Clients 110, 120, and 130 may transmit and receive various information, including business transactions, with each partner. In this case, the clients 110, 120, and 130 can use the example application service provision method.

An application service providing device according to an embodiment includes an instance system 1000 that provides an application including SaaS-type software, and a manager system 2000 that provides application services through the instance system 1000. do.

The manager system 2000 may provide an instance system 1000 capable of scale-out to the clients 110, 120, and 130.

In the instance system 1000, the interface of the service provided by the manager system 2000 to the clients 110, 120, and 130 may be executed.

The manager system 2000 may include a manager server 2100 that connects and controls the instance system 1000 and a database 2200 that can store the transmitted and received information and the requirements of the clients 110, 120, and 130. there is. The functions of the manager system (2000) are described in detail below.

The instance system 1000 provided by the manager system 2000 may include at least one node.

In the example of this figure, node #0 (1100) may serve as a service coordinator that provides application services and performs scale-out under the control of the manager system 2000.

In this example, the coordinator 1100, which is node #0, includes worker nodes: the first node (Node #1), the second node (Node #2), the third node (Node #3), and the Nth node (Node #N), etc. to control the scale of the system.

For example, connections between nodes can use interface protocols such as the HTTP protocol (hereinafter referred to as HTTP/REST) of the RESTful Application Programming Interface (API), which uses HTTP to provide data between servers. can be transmitted and received.

For example, the coordinator 1100, which is node #0, has the first node (Node #1), the second node (Node #2), the third node (Node #3), and the N-th node (Node #N). ) can transmit and receive data with each node through HTTP/REST.

Likewise, the first node (Node #1) is connected to other nodes (Node #0, second node (Node #2), third node (Node #3), and N-th node (Node #N) based on HTTP/REST. ) can transmit and receive data.

The coordinator (1100) installs the software package on each node (in this example, the first node (Node #1) to the N-th node (Node #N)) in response to a software package installation request from the manager system (2000). You can install it.

Each node can include a framework that can create a workspace regardless of the type of system. This will be described later.

The coordinator 1100 may provide workspaces 1510, 1520, and 1530 running in the framework of each node to each client 110, 120, and 130, respectively.

Clients 110, 120, and 130 may have workspaces 1510, 1520, and 1530 that are isolated from each other, and may receive, change, or use applications or software packages through the isolated workspaces.

In this example, the first node (Node #1) may provide software package A and software package C provided by the framework within the first node (Node #1) to the client through the coordinator (1100). .

The second node (Node #2) may provide software package A and software package B provided by the framework within the second node (Node #2) to the client through the coordinator (1100).

The third node (Node #3) can provide software package B and software package C provided by the framework within the third node (Node #3) to the client through the coordinator (1100).

The manager system 2000 can stably provide each of the workspaces 1510, 1520, and 1530 isolated from each other to the clients 110, 120, and 130 through the instance system 1000.

For example, Client 1 (110) can independently use the workspace (1510).

Client 1 (110) can transmit and receive necessary data in its workspace through a channel set with the coordinator (1100). For example, Client 1 (110) can receive the necessary software packages A and C from the coordinator (1100) through an HTTP channel in workspace A (1510). A detailed example of setting up a channel between the workspace and the coordinator 1100 or between the coordinator 1100 and each node will be described later.

Client 2 (120) can receive the necessary software packages A and B from the coordinator (1100) in workspace B (1520) through, for example, an HTTP channel.

Similarly, client 3 (130) can receive the necessary software packages B and C from the coordinator (1100) through an HTTP channel in workspace C (1530).

The instance system 1000 can provide a virtualized system, so that the clients 110, 120, and 130 can select which node in the instance system 1000 wants a software package in their workspaces 1510, 1520, and 1530. There is no need to be aware that it provides .

Nodes (Node #1, Node #2, Node #3, Node #N) that store and provide software packages by the coordinator (1100) provide the software packages to the workspaces (1510, 1520, and 1530). You can store available software packages. That is, multiple nodes (Node #1, Node #2, Node #3, Node #N) can be virtualized to provide workspaces (1510, 1520, 1530) isolated from each other.

Each node (Node #1, Node #2, Node #3, Node #N) includes a framework, and each framework can be controlled to download and execute software packages from the software package storage (not shown). You can. This will be explained in detail below.

A software package required for workspace A (1510) used by client 1 (110) may be stored in at least one of the nodes (Node #1, Node #2, Node #3, and Node #N).

In this example, software package A is stored in the first node (Node #1) and the second node (Node #2), but due to the scale-out of the coordinator (1100), other nodes (Node #3, Node #3) #N) and can also be stored.

Software package B is stored in the second node (Node #2) and the third node (Node #3), but due to the scale-out of the coordinator (1100), other nodes (Node #1, Node #N) It may also be passed on and stored.

Similarly, software package C is stored in the third node (Node #3) and the first node (Node #1), but due to the scale-out of the coordinator (1100), other nodes (Node #2, Node # It can also be passed to N) and stored.

In this way, software packages can be distributed and installed on multiple nodes. The coordinator 1100 can store information on which node a software package is installed, perform routing for software package requests if necessary, and perform a task scheduling function for nodes it manages.

Accordingly, the clients 110, 120, and 130 can use their respective virtualized and isolated workspaces 1510 without the need to recognize on which node the desired software package is stored due to the scale-out of the coordinator 1100. , 1520, 1530).

The manager system 2000 can control the coordinator 1100 to provide application services so that clients 110, 120, and 130 can obtain desired software packages.

Nodes serve as worker nodes where adapter packages or software packages described below are installed and executed. In the instance system 1000, worker nodes can be scaled out and expanded automatically or manually according to the management of the manager system 2000, if necessary.

Figure 3 shows an example of distributing packages to each node in the example of the disclosed application service device.

According to embodiments, software developers can quickly develop and deploy applications using software images.

The framework on each node can run an application and use as many node resources as necessary to run the application. When a node is included in a cloud system, it can run applications based on cloud resources. If the node is an on-premises-based system, the application can be run based on on-premises resources. In this drawing, the case of a cloud is shown as an example.

The framework on the nodes included in the instance system can control the cloud/on-premise resources included in the node for virtualization processing of the application and can allow application packages to be ported to other nodes.

An application service provider can create a software package (service app) related to a service and store it in a storage device or application repository (Registry). Hereinafter, for ease of explanation, the application service provided by the application service provider is exemplified as an EDI (Electronic Data Interchange) service, and the software package is exemplified as a software image (EDI service app) of the EDI service.

For example, EDI refers to a method of entering information related to commercial transactions in an agreed-upon standard format and exchanging the information according to a standardized transmission and reception method. There can be many EDI services depending on various transaction forms, traded goods or services, and transaction entities.

An application service provider (ASP) can create a software package (EDI service app) related to this EDI service and register it in a database or store it in an application repository (Registry).

A software package refers to a bundle of software that includes components that enable a client to install and use the software. In this example, a software package (App package) is indicated as a package that includes an application and its executable binary parts or library parts.

Therefore, a software package can take the form of a file that is a software image that runs on a virtualized cloud resource.

Each client can download a software package (EDI service app) stored in the registry or registered in the database from each workspace (not shown), and change or execute it.

Software packages (EDI service app) stored in the registry or registered in the database can be downloaded or executed on nodes providing each workspace, even if the package is the same.

Each client can download the necessary software package (EDI service app) as a software image in its own isolated workspace (not shown) and use it for the desired EDI service.

Each client can download the software image and use it to obtain the desired EDI service, or provide the EDI service to the client's partner.

When a client provides a desired EDI service by downloading it as a software image in an isolated workspace, the software package (EDI service app) can be saved in the registry or registered in the database.

An application service provider (ASP) provides an instance system so that clients can use, change, or provide software packages related to services such as EDI services, and can manage data transmission and reception with the instance system. This is described in detail below.

Figure 4 is a conceptual diagram disclosing elements for each layer for providing application services according to an embodiment.

An application service providing device according to an embodiment may be controlled and managed by the manager system 2000.

The manager system 2000 can provide application services such as EDI services using an on-premise system or a cloud system. Detailed examples of services provided by the manager system 2000 are described below.

The computing system may include at least one of an on-premise system or a cloud system.

Computing systems may also include a virtualization layer, such as containers or virtual machines (VMs), that can virtualize computing resources.

This figure illustrates a case where a virtualization layer is included, and the virtualization layer is indicated by a dotted line.

For example, a computing system may provide containers as a virtualization layer. Containers can use the host's resources as needed to run applications on top of the host operating system (OS). Container images allow you to quickly develop and deploy applications.

The computing system may include a framework layer 1700 that provides a framework. The framework can enable various applications to run through application programming interfaces (APIs) (1610, 4100).

The workspace (1500, 3000) or the interface governance platform (4000) is located on the application programming interface (API) (1610) or governance API (4100), and various applications are located on the application programming interface (API) (1610, 4100). It can be run on

The client 100 may receive the application service provided by the manager system 2000, that is, a software package, by a system with layers as illustrated in this figure.

For example, the client 100 can use services such as an EDI application (EDI App.) through the isolated workspace 1500. In this example, the client 100 provides EDI and other application services (App.), message services (message), web services (web services), protocol adapter services, and data conversion services ( You can use applications or services such as transformation, monitoring service, and security service. Applications or services on the workspace 1500 are described in detail below.

Partner 200 is an actual transaction partner of the client 100, or another transaction subject related to the transaction, who uses the application service through the workspace 1500 or receives application services such as the EDI service provided by the client 100. You can.

When the client 100 conducts a transaction through an application related to the EDI service, the partner 200 can proceed with the transaction through the EDI service application provided by the client 100.

The manager system 2000 can provide an environment in which clients can develop applications necessary for their transactions.

The manager system 2000 can develop and test applications in the development workspace 3000 and provide application services developed through the workspace 1500. In addition, the manager system (2000) manages the computing environment that provides the development workspace (3000) to the client (100) or partner (200), and allows the client (100) or partner (200) to use the development workspace (3000). This allows you to develop the applications you need.

This development workspace (3000) includes a development tool application that can develop applications, a billing application that determines the use and billing system for the developed application (payment/billing), and an app store that can sell the developed application. (app. Store), which supports and controls these features and can include back-office applications.

For example, the client 100 or partner 200 can develop, change, and test an application through the development workspace 3000. The client 100 or partner 200 can develop its own application or software package in the development workspace 3000 as well as the application provided by the manager system 2000.

Additionally, the client 100 may provide applications developed through the development workspace 3000 to other clients or partners through the app store 3000 illustrated in the drawing.

The partner 200 and the manager system 2000 can be used to develop, test, utilize, and provide services like the client 100 through the system provided.

The manager system 2000 may provide inspection and control of the client system through the interface governance platform 4000 on the solution API 4100, and these services will be described separately in detail.

Below, detailed examples of how the client 100 receives or provides a service using a software package through the workspace 1500 will be described.

Figure 5 is a diagram illustrating a concept in which an application service providing device establishes a channel between an instance and a client or partner according to an embodiment.

As disclosed, an instance system may include at least one node. For example, an instance system may include a coordinator node and worker nodes that transmit and receive software packages with the coordinator node.

An instance system can not only expand its own worker nodes, but can also expand into two or more instance systems. Therefore, even as the number of clients increases, it is possible to provide continuously expanded system environments and services.

In order to provide an application service, the application service manager 2100 may collect information such as resources from clients or partners 300.

In this case, if the application service manager 2100 directly accesses the system of the client/partner 300 and collects resource information of the client/partner 300, it may become a security problem.

Accordingly, the embodiment may install the agent 350 on the client/partner 300 and allow the client/partner 300 to directly manage connection information.

The agent 350 can set connection information for resource management information or connection information within the client/partner 300. In this example, the agent 350 may collect resource management information or connection information of the client/partner 300, user information of the client/partner 300, and other file system information. Additionally, the agent 350 may access the database of the client/partner 300 to collect stored information. Agent 350 may store the collected information.

The agent 350 of the client/partner 300 may be connected to the agent adapter 1350 installed on the N-th node (Node #n) 1300, which is an arbitrary node of the instance system that can receive application services.

The application service manager 2100 may obtain information related to the client/partner 300 collected from the agent 350 of the client/partner 300 from the agent adapter 1350 installed on the N-th node 1300.

The N-th node 1300 may include a configuration storage unit (Config. Repository) 1330, which contains information set by the manager system 2100, for example, configuration information for the agent or transmission/reception information between the agent and the agent adapter. It can be saved. The agent adapter 1350 may store various information received from the agent 350 of the client/partner 300.

The application service manager 2100 may include a message box 2110, where the agent adapter 1350 of the N-th node 1300 receives stored information (outbox slot), or the agent adapter ( You can request information (inbox slot) at 1350).

The agent adapter 1350 transmits information (inbox slot) received from the message box 2110 of the application service manager 2100 to the agent 350 of the client/partner 300. And, the agent adapter 1350 delivers information (outbox slot) received from the agent 350 of the client/partner 300 to the message box 2110 of the application service manager 2100.

The message box 2110 is a storage space that can store transmitted and received data, files, or documents, and may be configured as a separate server. Therefore, the message box 2110 may be called a message server, but in the example of this drawing, it is indicated as a message box as a unit of logical division and monitoring.

The agent 350 registered with the client/partner 300 can send data to the agent adapter 1350. And the agent 350 can receive or poll data from the agent adapter 1350 at regular intervals.

The Config. Repository 1330 of the N-th node 1300 that provides services to the client/partner 300 contains channel setting information between the agent 350 and the agent adapter 1350 or the agent adapter 1350. ) can store setting information received from the agent 350.

The application service manager 2100 may provide or obtain information necessary for services provided to the client/partner 300 from the agent adapter 1350 installed on the node 1300.

Since the agent 350 collects only the necessary information of the client/partner 300, security problems occurring in the client/partner 300 can be minimized. Additionally, because the agent 350 does not retrieve unnecessary data and data is transmitted and received at regular intervals, channel overload may not occur between the N-th node 1300 and the client/partner 300.

Since the N-th node 1300 stores necessary information in the configuration storage unit (Config. Repository) 1330, the information collected by the agent 350 can be maintained up to date and the channel can be lightweight.

According to the embodiment, the latest state of information related to the client/partner 300 may be stored in the N-th node 1300, thereby enhancing security without burdening the client/partner 300.

Transmitting and receiving information necessary for the service of the agent adapter 1350 in the N-th node 1300 through a channel set as in the disclosed example will be described in detail below.

FIG. 6 is a diagram illustrating a specific example in which an application service providing device establishes a channel between an instance and a client or partner according to an embodiment.

According to the concept disclosed above, the application service manager 2100 can enable a client or partner 300 to provide, use, and change an application through the instance system 1000. The instance system 1000 may include a coordinator 1100 and an N-th node 1300, which is a random node.

The application service manager 2100 may distribute information for installing the agent 350 to the client/partner 300. For example, information for installing the agent 350 may include agent setting information, key information for agent setting, resource management information, user management setting information, etc.

For example, agent configuration information may include information such as time to synchronize channel information, timeout for HTTP requests, key value of session key related to the installation browser, and path required for the agent to send and receive related information. there is.

A channel is set to use a service provided by the application service manager 2100, and can be described as a component for connecting to a package, for example, an adapter package. Examples related to this are described in detail below.

The agent 350 may be installed on the client/partner 300, and the agent 350 may collect resource management information, connection information, user information, etc. of the client/partner 300. If necessary, the agent 350 can access the database or file system of the client/partner 300.

The agent 350 may request a software package from the coordinator 1100 of the instance system 1000. In this case, the agent 350 may request a channel service for receiving a software package from the agent adapter 1350 of the coordinator 1100. Here, the agent 350 can use an HTTP request for the channel service requested by the agent adapter 1350.

For example, when the agent 350 of the client/partner 300 forwards a request to a preset HTTP URI, the coordinator 1100 allows incoming HTTP traffic, that is, inbound HTTP connection, to a specific port, and this HTTP The service can be converted into a channel service delivered to the agent adapter 1350 of the N-th node 1300, which is a worker node.

Information for installing the agent 350 already includes path information for accessing the instance system 1000.

When the agent 350 is installed on the client/partner 300, the administrator of the client/partner 300 can set management information, user information, etc. of the client/partner 300 system managed by the agent 350, and It is also possible to set synchronization time with the agent adapter 1350 of the N node 1300, etc.

The application service manager 2100 sets setting information for the agent adapter 1350 installed in the instance system 1000 in relation to the registered agent 350 and information on whether synchronization with the registered agent 350 is active. You can.

The application service manager 2100 is configured to store outbox slot information in a message box for storing information transmitted by the registered agent 350 and information received by the registered agent 350. You can set the inbox slot information in the message box.

The application service manager 2100 stores the information transmitted by the agent 350 and the information received by the agent 350 according to the information set as above into the outbox slot and the inbox slot ( Save each file to an inbox slot. A slot in a message box is a logical division concept that stores data processing units, and the message box can store and output data processing units like a queue.

Meanwhile, the application service manager 2100 can also set authentication key information through which the registered agent 350 and agent adapter 1350 can perform authentication.

In this way, when the agent 350 is registered with the client/partner 300 and the agent adapter 1350 is set in the instance system 1000, the agent adapter 1350 can be connected to the resource set in the agent 350.

In addition, related information or data can be transmitted and received with the agent adapter 1350 according to the information set by the agent 350.

In this drawing, a channel through which the agent 350 transmits information (outbox) output according to a set cycle from the resources of the client/partner 300 is indicated as a send channel. And the channel through which the agent 350 receives information (inbox) transmitted from the agent adapter 1350 is indicated as a receive/polling channel.

The agent 350 can send and receive data requested from the agent adapter 1350 through a set send channel and a set receive/polling channel.

Figure 7 is a diagram illustrating an example of managing channels and receiving services in a distributed system according to an embodiment.

As illustrated, nodes within the instance system 1000 may transmit and receive data through a channel to provide services. A channel is a general term for a channel that calls data or packages to provide a service, or searches to find out on which node an already registered channel is running.

Here, an example is disclosed in which the coordinator 1100 of the instance system 1000 manages packages installed on nodes in a distributed environment through a channel connection.

The coordinator 1100 can store channel information that can connect each worker node and information about the packages stored in each worker node.

For example, the coordinator 1100 can register and store information about packages stored in the worker nodes 1110 and 1120. The coordinator 1100 registers and stores information about the adapter package A and the integration package stored by the worker node 1110 of the first node (Node #1), and stores the information about the adapter package A and the integration package stored by the worker node 1110 of the first node (Node #2). Information about adapter package B stored by the worker node 1120 can be registered and stored.

The coordinator 1100 may receive a service request related to the package from a client or partner. As described above, this example illustrates the case where a service request is received through an HTTP request containing URL information.

The coordinator 1100 can set up a service channel for worker nodes when registered and mapped to the coordinator 1100 based on URL information included in the HTTP request.

As in the example here, the coordinator 1100 sets up an HTTP service channel according to an HTTP request containing URL information of a client or partner. The coordinator 1100 can call adapter package A provided by the first worker node (worker node #1) 1110 through a set HTTP service channel.

Since the client or partner uses an isolated workspace provided by the coordinator 1100, the clients (or partners) may have different versions of packages in their respective workspaces and may use different versions of adapter packages.

Adapter package A requested by the client can be called through the HTTP service channel from the first worker node (worker node #1) 1110 according to information registered in the coordinator 1100.

The first worker node (worker node #1) 1110 can provide adapter package A registered according to the HTTP service channel.

If a client or partner develops an application package in that workspace, they may need an integration package that includes adapter package B.

According to the registered information, the coordinator 1100 stores the integrated package in the first worker node (worker node #1) 1110 and stores the adapter package B in the second worker node (worker node #2) 1110. I know that.

The coordinator 1100 can search for the integrated package including adapter package B in the first worker node (worker node #1) 1110 through the adapter function channel. And if adapter package B is not included in the integrated package stored in the first worker node (worker node #1) 1110, the first worker node (worker node #1) 1110 is connected to the second worker node (worker node #2) Adapter package B stored at (1120) can be called through a channel connection between worker nodes.

Then, the second worker node (worker node #2) 1120 can provide the called adapter package B. In this case, the coordinator 1100 registers the channel providing adapter package B to the adapter function channel and provides it with the integrated package. You can have it come with adapter package B.

In the embodiment disclosed in this way, various packages can be distributed and installed on multiple nodes. In order to communicate between packages or call a specific adapter package from outside the instance system, the coordinator 1100 can manage and store channels for searching, calling, or registering the package in worker nodes that can provide package services.

Coordinate 1100 The agent adapter 1350 of the instance system 1000 can set the transmission channel and reception channel from the agent 350 as illustrated. The agent adapter 1350 can set a specific agent and channel using channel-related information such as the agent's identifier and channel cycle.

In this way, the coordinator 1100 can manage various information so that the requested package-related services can be distributed and performed across worker nodes. The HTTP service channel is illustrated above, but the package can also be delivered through a file transfer channel such as FTP.

The coordinator 1100 may store adapter packages distributed across multiple worker nodes in shared memory (not shown) or storage.

Additionally, the coordinator 1100 can also store and manage data such as logs related to adapters used by multiple clients.

Figure 8 is a diagram illustrating an example of managing setting information of an installed package according to an embodiment.

In the example of this figure, the coordinator 1100, the m-th node (node #m) 3110, and the n-th node (node #n) 3210, which are distributed systems within the instance system 1000, each have configuration storage units within the node. May include (1115, 3115, 3215).

The application service manager 2100 of the manager system 2000 can store various setting information (rectangles) related to the package. The saved configuration information may include various configuration information required when the package is executed on each node.

The application service manager 2100 may store package setting information in the database 2200. The application service manager 2100 may obtain package configuration information from a specific node, in this example, the m-th node (node #m) 3110, or may store configuration information of an externally requested package in the database 2200.

The coordinator 1100 may store the configuration information of the package managed by the application service manager 2100 in its configuration storage unit 1115. The application service manager 2100 can manage and store package setting information through a control screen, etc.

The m-th node (node #m) 3110 and the n-th node (node #n) 3210, which are Wicker nodes in the instance system 1000, receive configuration information of related packages from the configuration storage unit 1115 of the coordinator 1100. Can be received and stored in each setting storage unit (3115, 3215).

In this example, the nth node (node #n) 3210, which is a work node worker node, can synchronize the configuration information of the package with the configuration information of the package stored in the configuration storage unit 1115 of the coordinator 1100. This synchronization may be performed periodically, or may be synchronized at different periods depending on settings.

When the nth node (node #n) 3210, which is a work node worker node, needs to execute a package, it can execute the package using the configuration information synchronized and stored in its configuration storage unit 3215.

The client/partner can change and save the package setting information of the mth node (node #m) 3110, which is the work node worker node, through the package setting screen of the coordinator 1100, etc.

If the package setting information of the mth node (node #m) 3110, which is a work node worker node, is changed, the changed setting information of the package may be transmitted to the application service manager 2100.

Again, the application service manager 2100 may store the changed setting information of the package transmitted from the mth node (node #m) 3110 in the database 2200.

FIG. 9 is a diagram illustrating an example of managing and using a package according to a workspace of the disclosed embodiment.

Clients can create, run, and change multiple packages in an isolated workspace.

For example, a client can run an adapter package in a workspace, and the adapter package can be executed using configuration information stored in the configuration repository. However, in some cases, the package may be executed by referring to resource files in addition to the configuration information in the configuration repository.

A resource file is a mapping program that is a type of resource package and can be installed in the workspace. Resource files can be accessed using a resource path when executing a package such as an adapter package, allowing the adapter package to be executed.

According to the disclosed embodiment, it is possible to develop or test and operate a package in a workspace.

Therefore, according to the embodiment, resource files can be provided by separating the workspace for operation and the workspace for development.

In the example of this figure, when developing an adapter package in the development workspace 1510, the adapter package can be used as a program that can not only read but also write resource files. In this case, the resource file, which is a mapping program, can be accessed by specifying a writable shared resource path.

On the other hand, when executing the adapter package in the operation workspace 1520, the resource file may be provided as a resource package that the adapter package can only read and cannot write to. In this case, the adapter package can be installed and accessed by referencing the resource package, and the resource files within the resource package cannot be changed.

Figure 10 is a diagram illustrating an example of mapping EDI information as a type of application service according to an embodiment.

The disclosed embodiments can not only provide various application services, but also provide a platform environment for developing various application services.

Below, the EDI service will be described as an example of such an application service. As those skilled in the art can understand from the disclosure, various application services can be developed or provided using the embodiment, so it is not necessarily limited to EDI services.

As a type of application service, EDI requires various types of transactions, transaction parties, and transaction forms for each industry. Therefore, efficient transactions are possible when utilizing examples that cover complex and various types of transaction aspects for each industry, making it very effective in revitalizing industrial transactions.

This diagram illustrates an application service that converts various information or documents required for EDI services between trading parties.

EDI has many different formats that follow specific rules and regulations depending on the industry, and EDI documents must be created and processed according to these formats in order for a transaction to be established. EDI services come in various forms for various industries, such as transportation, logistics, finance, and insurance, as well as e-commerce. EDI is standardized by ISO, an international standardization organization, and is regulated and managed by UN/EDIFACT (United Nations/Electronic Data Interchange for Administration, Commerce and Transport) or ANSI (American National Standards Institute) X.12.

Depending on the nature of the transaction carrying out the ordering and supply, different types of documents containing different data or information may be used and the systems used by the parties to the transaction may also be different.

For EDI services, documents must be mapped between two transaction parties.

The example in this figure conceptually discloses an advanced mapping engine, a program that converts documents containing data into a general-purpose system to provide EDI services.

For example, a transaction party can provide EDI documents and EDI schema required for the transaction. Such data can be converted into decoded data (unmarshal data) by decoding bytes or strings included in EDI data (i.e., EDI document) according to the input schema.

The mapping engine may include reference information for mapping schemas to each other based on the data to be converted and the schemas of the data to be converted. Here, the mapping standard information is called a mapping script.

The mapping standard information is for converting unmarshalled data into a document of another target format and may have a script format.

The mapping engine converts EDI data and EDI schema decoded data (unmarshal data) into a file of a specific format (here, a JSON file as an example) that can be used as an interface for a general document and a schema for the file of the specific format ( Here, it can be converted by mapping to JSON schema (example).

In more detail, as an EDI schema, the EDI format of the SEF (Standard Exchange Format) standard can be used, or an EDI format such as EXF (EDI Exchange Format) can be used.

The file in the changed format may be a flat file, JSON, XML, etc.

If marshalling or unmarshalling is performed for each file type on the file in the changed format, it can be converted into a schema file defined as an annotation. In other words, you can obtain marshaled or unmarshalled results with a schema that defines a type corresponding to the data to be converted and an annotation corresponding to a specific data type.

The embodiment may generate a schema through this mapping engine and provide the user with a graphical interface through which a mapping script, which is mapping standard information, can be written.

Figure 11 is a diagram illustrating an example of providing an application service using an integrated package according to an embodiment.

According to an embodiment, the client 310 may provide an application service such as the disclosed example to the desired partner 320. The embodiment not only provides a service from the client 310, but also allows the client 310 to directly provide a customized service to the desired partner 320 using the embodiment.

Here, the EDI service among application services is explained as an example. In order for the client 310 to transact with the partner 320, the embodiment may provide a coordinator 1100 and a worker node 1300 included in the instance system.

The application service manager 2100 may provide and manage an instance system so that the client 310 and the partner 320 can exchange information required for a transaction through the instance system.

As disclosed, an agent (not shown) is installed in the client 310, and EDI information, which is information required for a transaction, can be requested through the agent. In this case, the request for EDI information may be transmitted as HTTP traffic.

The coordinator 1100 of the instance system maps the HTTP request including EDI information delivered from the client 310 to a designated channel and delivers it to the corresponding worker node. In the above example, the coordinator 1100 initiated an example of inquiring and managing channel registration through an HTTP request including URL information. The coordinator 1100 changes the HTTP request into a channel service and delivers it to the agent adapter 1350 of the corresponding worker node 1300 that can receive the channel service.

The agent adapter 1350 transmits the requested EDI information to the message box 2110 of the application service manager 2100 through the channel service.

The message box 2110 of the application service manager 2100 may store the EDI information delivered from the agent adapter 1350 in the client inbox 2111.

The message box 2110 of the application service manager 2100 transmits the requested EDI information to the integration package 1380 of the worker node 1300.

Here, the integration package 1380 is a bundle of programs in which development items are integrated, and includes various development flows, Java or script programs. An integration package 1380 may allow combinations of these development items to address integrated requirements.

The integration package 1380 allows the client 310 and partner 320 to transact by exchanging information with the message box 2110, the worker node adapters 1350, 1370, and 1390, and the coordinator's channel service. It can implement various requirements.

The integration package 1380 can solve user requirements by creating and registering routing for necessary information exchange within the package when a specific channel is called according to the distributed channel service.

Elements and usage examples of the integration package 1380 are disclosed in detail below.

The integration package 1380 may transmit the EDI information stored in the client inbox 2111 of the message box 2110 to the mapping adapter 1370.

The mapping adapter 1370 unmarshalls the EDI information of the client 310 received from the integration package 1380 and outputs it as EDI conversion data mapped to information needed by the partner 320.

When the integration package 1380 receives the EDI conversion data output by the mapping adapter 1370, it transmits and stores it to the partner outbox 2113 of the message box 2110 and delivers it to the EDI adapter 1390. You can.

The EDI adapter 1390 converts the EDI conversion data output from the integration package 1380 or stored in the partner outbox 2113 into a standardized format, such as UN/EDIFACT or ANSXI X.12. It can be converted.

The EDI adapter 1390 may transmit and store standardized EDI conversion data to the partner out box 2113 of the message box 2110.

The coordinator 1100 receives standardized EDI conversion data stored in the partner outbox 2113 of the message box 2110 or converted by the EDI adapter 1390 through a channel service, and sends it to the partner 320 as HTTP traffic. It can be converted and transmitted.

As a result, the partner 320 can receive the EDI information delivered by the client 310 as standardized EDI converted data. Even when the partner 320 delivers its EDI information to the client 310, the data can be delivered according to a similar process.

Accordingly, the client 310 and the partner 320 can easily use application services such as EDI services according to the disclosed embodiment, even if they do not know the standardized format or do not accurately understand the documents and information requested by the transaction counterparty. Transactions can be easily carried out according to a standardized format.

The client 310 or partner 320 may develop or use several software packages in its workspace and link them to the integrated package 1380.

In the embodiment, the development of such packages and connection with existing packages can be provided through a very easy interface, and the developed packages can also be sold, shared, or provided separately.

FIG. 12 is a diagram illustrating an example of a platform interface according to an example of providing the disclosed application service.

This diagram illustrates the interface provided by the platform when a user accesses the platform according to an example of providing an application service.

When a client connects to a launching system, the platform may provide a user interface menu associated with a workspace dedicated to the user.

As illustrated in this figure, a client can use the instance system through an interface platform provided by the manager system or connect to the instance system using HTTP including a URL, etc.

In the example of this drawing, the interface platform provided by the manager system is a user-only workspace (151), a message box (152), a file transfer (153), and a message sent to a mobile terminal. (SMS) 154, and if the information exchange is related to EDI, an option may be provided for information 155 about the corresponding standard mapping.

The workspace 151 is a menu that allows the client to use his or her workspace, and the message box 152 stores messages related to the client.

File transfer 153 allows you to check the file transfer method or history transmitted and received through the instance system.

The user can check the package 161 used or developed by the user or the package 162 purchased by selecting the user interface menu.

FIG. 13 is a diagram illustrating another example of a platform interface according to an example of providing the disclosed application service.

This diagram illustrates a user interface menu that can be seen when accessing a platform according to an example of providing a client-initiated application service and selecting one's workspace.

The client identifies the workspace it created (171), the instance system related to the workspace (172), the creation date for each workspace (173), the description information of the workspace (174), whether the workspace is activated (175), You can check and use services (176) and packages (177) related to the workspace.

Below, when the application is an application that connects different systems, an embodiment that can provide an application that can interoperate with different systems is disclosed. Software or applications developed through the workspace of the embodiment can be shared and used by multiple clients. If the systems used by the client or partner are different, the application developed by the client (or partner) must be usable on the partner's (or client) system.

The instance system according to the embodiment may provide a framework that can integrate these different systems, and the embodiment is disclosed as follows.

FIG. 14 is a diagram illustrating an example in which an application service providing device according to an embodiment provides a framework for integrating different systems.

An application service providing device according to an embodiment may include a framework that provides applications executable on different systems. Therefore, this integrated framework can provide applications that allow users of different systems to connect with each other, making it efficient and ideal for providing the EDI services exemplified above.

This diagram illustrates an integrated system architecture as a framework that can integrate different systems. The integrated system architecture provided by the embodiment framework includes one or more route engines.

The route engine provides routes by connecting endpoints, which are different systems, and processors, which are tasks performed between endpoints.

A route can describe a working interface between systems, and in this example the route engine would configure routes 1, 2, … , an example of providing N was disclosed.

Processor refers to data processing that must be performed between transmission and reception systems, that is, endpoints. In this example, a router processor and a message filter processor are exemplified.

A component refers to an adapter of a transmission/reception system to be interconnected. In this example, the integrated system architecture provides an example of connecting different systems by providing a unified interface to the endpoint using components such as files, JMS, and HTTP. .

A person who retrieves or receives data from a component (or is called) is called a consumer, and a person who calls, transmits, or queries data from a component is called a producer.

A message is data exchanged for system communication and may include a body, header, and attachments.

An exchange is a container that contains messages exchanged between systems. It is an object that is created at the start of a route flow and whose life cycle is maintained only until the end of the flow.

Using this integrated system architecture, applications that can be used in different systems can be created and developed as an integration package. As an example of this, the integration package 1380 is illustrated in the above example.

An integration package developed based on an integrated system architecture can provide an integration flow that can solve integration requirements by linking with services or adapter packages provided by the platform according to the embodiment.

The integration package implements the necessary processes within the flow of the integrated system architecture and can provide scripts or Java programs capable of various data conversions.

A client (or partner) can create integrated packages necessary to provide its own services using the integrated system architecture illustrated above based on the platform according to the embodiment.

The platform according to the embodiment can also provide an environment in which a client (or partner) can very easily develop an integrated package that implements an integrated flow using graphic-based coding.

Below, an environment in which an integration flow can be developed as an integration package provided by the integrated system architecture of the platform according to the embodiment is exemplified.

A platform according to an embodiment of a device that provides an application service may provide a graphic-based development environment using a library.

A client (or partner) can develop a graphic-based integration flow using the example, and the integration flow can largely include five functions.

Here, the five functions included in the integration flow are called connector, service, processor, control flow, and modifier. These names are illustrative and each function is described in detail as follows.

Figure 15 shows an example of coding a connector among the integration flow functions based on graphics when developing an integration flow based on an embodiment.

The connector may include a From graphic element that defines the start of the route of the integrated system architecture illustrated above.

A connector may include a To graphic element that defines external operations when a flow developed in a development environment, such as calling a service or adapter or storing data, is implemented.

As illustrated in this figure, an integration flow can be developed using a connector that can express the input/output (From/To) of the route through graphic coding in the graphic-based development environment provided by the embodiment.

To explain the connector in more detail, the connector acts as a consumer and calls specific data (From Connector), and as a producer, it provides data processed through the flow to the outside of the integration flow. (To Connector) You can.

The consumer is when the integrated flow calls specific data (From Connector), and there is a direct that calls the route in the application package, and a timer that periodically calls the data by the task scheduler. There may be.

Also, this is another case where the integration flow calls specific data (From Connector), registering the route as a channel and starting the route when the channel is called, periodically checking for unprocessed messages, and if there are unprocessed messages. There may be a message box that starts a route, or an FTP that checks whether a document exists in the registered FTP service path and starts a route if the document exists.

These consumers include the route identifier (Route ID) within the integrated package, Auto Start, which indicates whether the route is started at the time of package installation, and Start Order, which indicates the start order of the route for package installation. Options may be included.

Producer refers to the external output operation (To connector) of the connector as a result of performing the integrated flow. Types of producers include direct, which means calling another direct route within the same application package, and message box, which means saving a document in a message box. Additionally, as a producer, there may be a channel, which means calling another channel in the workspace, or an FTP, which means sending a document to a registered FTP service.

Therefore, as shown in the example in this figure, an integration flow can be developed using a connector that includes route input/output (From connector/To connector) coding elements through graphic coding.

Figure 16 shows an example of graphic-based coding of services among the integration flow functions when developing an integration flow based on an embodiment.

Depending on the embodiment, an integration flow that can be developed graphically can be coded based on a visual interface using service blocks.

In the example of this figure, the service block may include a getNextControlNumber element, an isDuplicatedControlNumber element, a putUsingConrolNumber element, a remoteCache element, etc. provided graphically.

The getNextControlNumber element means issuing a new control number, and the isDuplicatedControlNumber element is an element that checks whether the control number is duplicated.

In this drawing, cases where control numbers overlap (True) and cases where control numbers do not overlap (False) can be defined together.

In developing an integrated flow, among the service blocks, the putUsingConrolNumber element stores the used control number in storage and uses it to check for duplicates, and the remoteCache element exemplifies accessing the workspace's cache service.

Therefore, the integration flow can be coded graphically using service blocks such as the example in this figure.

Figure 17 shows an example of graphic-based coding of the processor among the integration flow functions when developing an integration flow based on an embodiment.

Depending on the embodiment, an integration flow that can be developed graphically can be coded based on a visual interface using a processor block.

In the example in this figure, the processor block may include graphically provided log elements, process elements, xslt elements, groovy elements, and delay elements.

The log element allows information required when executing a flow to be recorded in the package log. The package log can be checked in the adapter that monitors the execution status of the package.

The process element allows custom processing to be performed by calling the method of the bean registered in the uploaded Java (Jar) package item.

The xslt element can perform XSLT conversion by selecting an XSLT package item.

The groovy element can allow you to call a script by selecting a Groovy package item.

The delay element can cause the flow's route to be briefly delayed.

Therefore, the integration flow can be coded graphically using a processor block such as the example in this figure.

Figure 18 shows an example of graphic-based coding of control flow among the integration flow functions when developing an integration flow based on an embodiment.

Depending on the embodiment, an integration flow that can be developed graphically can be coded based on a visual interface using a control flow block.

In the example of this figure, the control flow block may include graphically provided split elements, for elements, while elements, xslt elements, If or Switch-Case elements, and Try-Catch elements.

The split element allows information required when executing a flow to be recorded in the package log, and the package log can be checked in the adapter that monitors the execution status of the package. The split element is a function that can process one integrated document (Exchange) by splitting it into multiple Exchanges, and can support Delimiter, XPath, and Bean methods.

The for element is used when processing a message multiple times, and provides the ability to process it in a different way for each repetition.

The While element provides the ability to activate a while loop that loops until the Simple expression evaluates to false or null.

The If or Switch-Case element provides functionality that allows messages to be routed to the correct destination based on the content of the message exchange.

The Try-Catch element can support the same exception handling function as Java's Try-Catch.

Therefore, the integration flow can be coded graphically using the example control flow block.

Figure 19 shows an example of coding the modifier among the integration flow functions based on graphics when developing an integration flow based on an embodiment.

Depending on the embodiment, an integration flow that can be developed based on graphics can be coded based on a visual interface using a modifier block.

In the example of this figure, the modifier block may include graphically provided loadProperty elements, setProperty elements, setHeader elements, setBody elements, removerHeader elements, and removeProperty elements.

The loadProperty element provides the function to retrieve a configuration node from the configuration repository and store it in Exchange Property.

The setProperty element can provide the ability to assign a value to an Exchange Property.

The setHeader element can provide the ability to specify a value for the Exchange Message Header.

The setBody element can provide the ability to specify a value to the Exchange Message Body.

The removerHeader element can provide the ability to remove a value from an Exchange Message Header.

The removeProperty element can provide the ability to remove a value from an Exchange Property.

The integration flow can be coded graphically using the example modifier block.

Below, an example in which users such as clients can be distinguished and each workspace can be isolated according to the embodiment disclosed above is disclosed.

If the software packages provided to clients using the workspace are the same and the same software image is executed for each client, all versions and types of software packages must be prepared and provided for each client.

However, according to the embodiment disclosed below, even if the application service is provided using the same software package, resources can be used efficiently and services isolated for each workspace used by the client can be provided.

A detailed example is disclosed as follows.

Figure 20 is a diagram illustrating an example of providing a unique workspace isolated depending on the client according to an embodiment.

In the illustrated example, the instance system 1000 may include a coordinator (not shown) and one or more worker nodes. In this example, a plurality of worker nodes (Node #1, Node #2, Node #3, Node #N ) is exemplified.

A coordinator (not shown) according to an embodiment may allow access through user authentication when a user connects and provide each workspace according to the user.

In this example, it is assumed that Client 1 (110), Client 2 (120), and Client 3 (130) access the instance system 1000 according to the embodiment.

The manager system (not shown) can manage the coordinator and worker nodes (Node #1, Node #2, Node #3, Node #N) of the instance system 1000.

When clients 110, 120, and 130 each connect through a coordinator (not shown), the instance system 1000 can provide workspaces 1510, 1520, and 1530 that are isolated from each other according to users. there is.

In this example, Client 1 (110) can be assigned and use Workspace A (1510), Client 2 (120) can be assigned and use Workspace B (1520), and Client 3 can be assigned Workspace C (1530).

When client 1 (110) is assigned workspace A (1510) on the instance system (1000), worker node 1 (Node #1) is a package that is a workspace bundle unique to workspace A (1510). E can be provided.

Here, a workspace bundle is a software package and represents a group of expandable software programs including detailed metadata.

At this time, worker node 1 (Node #1) provides software as a workspace bundle that depends on workspace A (1510) or is unique to workspace A (1510) at the request of client 1 (110). Package E can be provided.

Here, the software package depends on workspace A (1510), which means that software package E provided by the framework of the worker node (Node #1) includes authentication information related to workspace A (1510). means that

That is, the framework of worker node 1 (Node #1) uses package E, a software bundle containing authentication information related to workspace A (1510), as a unique workspace bundle, and workspace A ( 1510).

Similarly, the framework of worker node 2 (Node #2) provides authentication information related to workspace B (1520) as a unique bundle of workspace B (1520) at the request of client 2 (120). Package E, which is a software bundle, is provided to workspace B (1520).

Likewise, the framework of worker node 3 (Node #3) sends package E, a unique software bundle containing authentication information related to workspace C (1530), to workspace C at the request of client 3 (130). Provided in (1530).

Here, each worker node (Node #1, Node #2, and Node #3) provides the same software package E, but the software includes unique authentication information for each workspace (1510, 1520, and 1530). Package E is provided.

Therefore, since an image combining the same software package E and different unique authentication information is provided for each workspace (1510, 1520, and 1530), the clients (110, 120, and 130) are isolated in their respective workspaces. This effect may occur.

As such, in this example, the framework of worker node 1 (Node #1) provides package E containing the identification information of workspace A and a separate package F to workspace A (1510), and worker node 2 (Node #1) provides a separate package F to workspace A (1510). The framework of #2) provides package E, which includes identification information of workspace B, and a separate package G to workspace B (1520). Likewise, the framework of worker node 3 (Node #3) provides package E containing identification information of workspace C and a separate package H to workspace C (1530).

The identification information of each workspace can be used as information to authenticate each workspace. As an example of authentication information, a non-repudiation token based on the RSA (Rivest-Shamir-Adleman) encryption algorithm can be used. .

Therefore, when each client receives an application service through each workspace, the instance system verifies the application service provided for each workspace based on the authentication information of each workspace, and each client authenticates its authority to the application service. can do.

Therefore, when an application service according to a software bundle is provided through each workspace, a unique software bundle is installed in each workspace, and the services and execution areas provided accordingly can be isolated.

When a software package is requested from workspaces, worker nodes (Node #1 to Node #N) can approve or deny the download or execution of the requested application based on authentication information unique to each workspace. there is.

Meanwhile, a Java framework such as OSGi can be used as an example of the framework of worker nodes (Node #1 to Node #N). OSGi is a type of Java framework that can provide a software bundle containing Java components and metadata in the execution environment. In this case, worker nodes (Node #1 to Node #N) can provide the OSGi framework.

Figure 21 is a flowchart illustrating an example of providing a package to a client from an isolated workspace according to an embodiment.

A request for an application package is received from a client (or partner) using the workspace (S110).

The manager system can manage the instance system and provide services for application packages.

The instance system can provide workspace to each client (or partner) based on coordinators and worker nodes.

The workspace of each client (or partner) can be isolated, and the client (or partner) can request service for the application package to the instance system through the isolated workspace.

Authentication of the requested application package is performed based on authentication information included in the software bundle related to the workspace (S120).

When a worker node that provides a workspace within an instance system installs a software bundle in that workspace, it can install a software bundle containing authentication information unique to that workspace.

Here, the authentication information can provide authentication to use other application package services. For example, as authentication information, a non-repudiation token based on the RSA (Rivest-Shamir-Adleman) encryption algorithm may be used.

Therefore, even if the same software bundle is installed in the workspaces provided by the worker node, each workspace may contain different authentication information. Using this, a software bundle can have a dependency on the workspace in which it is installed.

Additionally, the workspace authentication information can be used as an authentication key to authenticate the application package of the requested service.

Workspaces can be isolated from each other by providing workspaces where identical software bundles except for authentication information can be implemented. That is, even if the same software runs in a workspace, the workspaces can be isolated from each other because they contain different authentication information.

According to the authentication result, the service request for the received application package is approved or rejected (S130).

When a worker node provides an application package requested from a workspace, the authentication information of the software bundle installed in the workspace can be used as authentication information for the workspace. An example of a framework that can provide such a workspace is the OSGi framework.

Therefore, the worker node can provide the requested application package to the workspace only when the workspace is authenticated, based on the authentication information of the software bundle installed in each workspace.

If the authentication information of the software bundle installed in the workspace does not match, the worker node refuses to provide the application package service requested for the workspace.

The application service providing device according to the embodiment disclosed above may include a manager system and an instance system.

The instance system is at least one server including a coordinator and a worker node, and the server may include a storage medium for storing data and a processor.

At this time, the processor of the server may receive a service request for an application package from a client and perform authentication of the requested application package based on authentication information included in a software bundle related to the workspace. Additionally, the processor of the instance system may perform operations to approve or deny a service request for the received application package according to the authentication result.

If the above embodiment is performed as an instance system-based program, the program can receive a service request for an application package from a client using the workspace. And the computer-executable program performs authentication of the requested application package based on authentication information included in the software bundle related to the workspace, and approves or rejects the service request for the received application package according to the authentication results. can do.

Even if the software package provided to the client (partner) using the workspace is the same, if a different software image is executed for each client (partner), all versions and types of software packages must be prepared and provided for one client (partner).

However, by using a framework that provides a workspace in which a software bundle containing unique authentication information for each client is executed, as in the disclosed embodiment, the workspaces can be isolated from each other and application services can be provided using the same software package. Computing resources can be operated efficiently.

110, 120, 130, 310: Client
200, 320: Partner
300: Client or Partner
350: Agent
1000: Instance system
1100: Coordinator
1110, 1120, 1300, 3110, 3210: nodes
1330, 1115, 3115, 3215: Setting storage unit
1350: Agent adapter
1370: Mapping Adapter
1380: integrated package
1390: EDI adapter
1500, 1510, 1520, 1530: Workspace
1610:API
1700: Framework layer
1800: Virtualization layer
1900: Resource Layer
2000: Manager System
2100: Application Service Manager
2110: Message box
3000: Development workspace
4000: Interface Governance Platform
4100: Governance API

Claims (9)

Receiving, by a processor of a virtualized computing system in a platform providing a workspace, a service request for an application package from a client using the workspace;
performing, by the processor, authentication of the requested application package based on authentication information included in a software bundle related to the workspace; and
Comprising, by the processor, providing a service for the received application package according to the authentication result,
Here, when the application package is executed, the workspace is isolated from other workspaces of the virtualized computing system by the authentication information that varies depending on the workspace. According to paragraph 1,
The method of providing the application service is,
It further includes the step of providing, by the processor, a development tool for an integrated flow that is software to the client,
Here, the development tool of the integrated flow is a method of providing an application service that includes input/output coding elements of the route of the software bundle. According to paragraph 1,
The steps for performing the authentication are:
A method of providing application services using a non-repudiation token based on the RSA (Rivest-Shamir-Adleman) encryption algorithm. According to paragraph 1,
The workspace is,
A method of providing an application service in which the same software bundle can be executed except for the authentication information. A storage medium that stores data; and
A virtualized computing system including a processor that provides a workspace for executing the data,
The processor,
Receiving a service request for an application package from a client using the workspace;
perform authentication of the requested application package based on authentication information included in a software bundle related to the workspace; and
Providing services for the received application package according to the authentication results,
Here, when the application package is executed, the workspace is isolated from other workspaces of the virtualized computing system by the authentication information that varies depending on the workspace. According to clause 5,
The processor,
Provide development tools for integrated flow, which is software, to the client,
Here, the development tool of the integrated flow is an application service providing device that includes input/output coding elements of the route of the software bundle. According to clause 5,
When the processor performs the authentication,
An application service providing device that uses a non-repudiation token based on the RSA (Rivest-Shamir-Adleman) encryption algorithm. According to clause 5,
The application service providing device is,
An application service providing device including a framework that provides a workspace in which the same software bundle except the authentication information is executed. Receiving a service request for an application package from a client using a workspace of a virtualized computing system within the platform;
perform authentication of the requested application package based on authentication information included in a software bundle related to the workspace; and
Providing services for the received application package according to the authentication result,
Here, when the application package is executed, the workspace is isolated from other workspaces in the virtualized computing system by the authentication information that varies depending on the workspace, and a computer stores a program for executing an application service provision method on the computer. A readable recording medium.

Images