JP3944229B2 - Framework system - Google Patents

Description

  The present invention relates to a framework system that executes one or more selected business logics in response to a message from a client.

  This type of framework system is typically composed of one or more servers communicatively connected to one or more clients. Conventionally, this kind of framework system has been provided with two basic functions, a messaging service and a framework service. The messaging service is a service that processes message communication between a client and a server and between a server and a server. A framework service usually has multiple business logics (business process processes) and executes one or more selected business logics in a synchronous or asynchronous manner in response to a message from a client. Execute the transaction.

  However, in the above conventional example, the business logic processing schedule in the framework service is fixedly programmed. Therefore, it is difficult to flexibly define a complicated business logic flow according to various messages.

  In some cases, a plurality of business logics are sequentially executed in response to a message from a client. For example, in response to a purchase registration request from a client, purchase registration, inventory update, accounts payable, etc. are performed. In such a case, in the conventional system, business logic related to the front desk such as purchase registration is executed in synchronization with the message, but business logic related to the back office such as inventory update and accounts payable accounting is performed at night. It is executed by batch processing. For this reason, the results of back office processing cannot be referred to until the next day. However, in order to catch new trading opportunities as soon as possible, it is desirable that the back office business logic be executed as early as possible and the results can be referenced early.

  In a system including a plurality of framework servers, a series of business logics are executed in cooperation with each other while sending and receiving messages between the framework servers. The status of each server (for example, the type of business logic it owns, whether it is operating normally, whether it is busy, etc.) is usually different from other servers, and over time Change. This complicates the scheduling that determines which server is requested to execute the business logic.

  An object of the present invention is to provide a framework system in which a business logic flow can be easily defined and changed without programming.

  Another object of the present invention is to enable P to P communication and P to M communication in a framework system.

  Another object of the present invention is to provide a framework system that can execute a series of business logic in a manner as close to real time as possible even if it is not completely real time.

  Still another object of the present invention is to enable a series of business logic to be appropriately scheduled according to the status of the servers in a system including a plurality of framework servers.

  In accordance with one aspect of the present invention, a framework system communicatively connected to a client is associated with a plurality of business logic and selected one or more business logics in response to a request message from the client. And a framework service that outputs a reply message to the client; a messaging service that intervenes between the client and the framework service and relays the message between the client and the framework service; A flow definition file associated with the work service. The request message includes a subject ID for the subject of the message. The flow definition file includes a plurality of definition sentences respectively corresponding to a plurality of different subject IDs, and each definition sentence describes an execution schedule for one or more predetermined business logics. When the framework service receives the message of the request from the messaging service, the framework service refers to the definition sentence corresponding to the subject ID of the received message in the definition file, and executes it according to the execution schedule described in the referenced definition sentence. Select one or more business logics to power.

  In a preferred embodiment, the framework system further comprises a flow definition update component that updates the flow definition file while the framework service is running.

  In a preferred embodiment, the flow definition file also includes a definition describing a linked execution schedule for linked execution of a plurality of business logics including one preceding business logic and at least one subsequent business logic. A sentence can be included (of course, it is not necessary to include a definition sentence that defines a linkage execution schedule). The linkage execution schedule includes a linkage mode regarding selection of a synchronous method and an asynchronous method with respect to the execution of the subsequent business logic. When the framework service executes multiple business logics according to the linkage execution schedule, it executes subsequent business logic synchronously or asynchronously with the execution of the preceding business logic according to the linkage mode in the linkage execution schedule. To do.

  In a preferred embodiment, the linkage execution schedule includes information regarding the preceding business logic and information regarding the second request message for the subsequent business logic. And when executing a plurality of business logic according to the linkage execution schedule, the framework system generates a message of the second request using the execution result of the preceding business logic after executing the preceding business logic, Send the second request message to the messaging service. After that, when receiving the message of the second request from the messaging service, the framework system executes the subsequent business logic according to the execution schedule of the definition sentence corresponding to the message of the second request.

  In a preferred embodiment, the messaging service also comprises a non-volatile message queue for guaranteeing the message of the second request. The message queue stores the second request message without deleting it even after the second request message is sent to the framework service. Then, the messaging service can retransmit the message of the second request stored in the non-volatile message queue to the framework system as necessary.

  A framework system communicatively connected to a client according to another aspect of the invention processes a request message from the client and outputs a reply message to the client; the client and the framework And a messaging service that relays messages between the client and the framework service. The messaging service relays not only P to P communication messages such as the request and reply messages but also P to M communication messages between the client and the framework service.

  In a preferred embodiment, the messaging service has a ring buffer for temporarily waiting for messages for P to M communication.

  In the preferred embodiment, each of the messages for P to P communication also includes a guarantee mode regarding whether or not message guarantee is necessary. The messaging service temporarily waits for a P to P communication message that requires message guarantee and a first message queue for temporarily waiting for P to P communication message that does not require message guarantee. Non-volatile second message queue.

  In accordance with yet another aspect of the present invention, a framework system communicatively connected to a client includes a plurality of meshed mesh services including at least one messaging service connected to the client; And a plurality of framework services respectively connected to the messaging services. Each of the plurality of framework services waits for a request message having a predetermined subject ID, and when receiving a request message having the predetermined subject ID, It can process and output a reply message to the client. The plurality of messaging services relay messages between the client and the plurality of framework services, and relay messages between the plurality of framework systems.

  In a preferred embodiment, each messaging service monitors the operation of one or more other messaging services, and if it does not detect normal operation for some other messaging service, Instead of relaying a message to a messaging service that does not exist, relay the message to another normally running messaging service.

  In a preferred embodiment, each messaging service also monitors the status of a framework service connected to each messaging service and relays a message of a request from a client to the framework service according to the monitored status. Select whether to relay to any other messaging service.

  In the preferred embodiment, each messaging service also has its own management table, which includes the subject ID of the message that the framework system connected to each messaging service awaits, and the connection to each messaging service. The subject ID of the message that is waited for by each of the other one or more other messaging services registered is registered. When each message service receives a message, it looks up its own management table to find a framework service or other messaging service that waits for a subject ID that matches the subject ID of the received message. Relay received messages to a framework service or other messaging service.

  In a preferred embodiment, each messaging service further informs one or more other messaging services of the subject ID of the message that the messaging service awaits based on the contents of its own management table. Each of the other messaging services that have received the notification registers the notified content in its own management table if the notified content has not yet been registered in its own management table.

  In accordance with yet another aspect of the present invention, a framework system communicatively connected to a client processes a request message from the client and outputs a reply message to the client; A messaging service interposed between the framework service and relaying messages between the client and the framework service. Request messages from clients have a given priority. The messaging service includes a message queue for temporarily waiting for the message of the request and a queue management component for managing input / output of the message queue. The queue management component has a priority mode for controlling the output order of a plurality of messages from the message queue according to the priority of each message when a plurality of messages are accumulated in the message queue; and a plurality of messages in the message queue. A sequence guarantee mode for prohibiting the retrieval of other messages accumulated in the message queue until the processing of the message previously retrieved from the message queue is completed in the framework service.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings. FIG. 1 shows the overall configuration of this embodiment.

  This system includes a presentation layer 1, a business logic layer 2, and a data service layer 3.

  The presentation layer 1 includes a Web (World Wide Web) client 11, a Web (World Wide Web) server 12, or a VB (Visual Basic) client 13.

  The business logic layer 2 is provided with an RtFA server 14 that is a server computer system to which a framework architecture (hereinafter referred to as “RtFA: Real Time Framework Architecture”) according to the principle of the present invention is applied. The RtFA server 14 includes a server computer system (hereinafter simply referred to as “messaging service”) 15 that performs a messaging service, and a server computer system (hereinafter simply referred to as “framework service”) 16 that performs a framework service. ing. Typically, messaging service 15 and framework service 16 are each implemented using a separate computer machine or a set of separate computer machines. However, this is not necessarily the case, and it is possible that both the messaging service 15 and the framework service 16 are implemented using the same computer machine or set of computer machines.

  The messaging service 15 controls message exchange between the clients 11 and 13 and the RtFA server 14. That is, the messaging service 15 receives a request message for a certain process from the clients 11 and 13 and passes the request message to the framework service 16 that can perform the requested process. The messaging service 15 also receives a reply message indicating the result of the executed process from the framework service 16 and, in some cases, an additional request message for a subsequent additional process. . Then, the messaging service 15 sends the reply message to the clients 11 and 13 and passes the additional request message to the framework service 16 again.

  Each of all messages handled by the messaging service 15 includes a subject ID that is an identification code indicating the subject of the message (for example, purchase registration request, inventory update request, accounts payable registration request, etc.). As will be described later, this subject ID is used by the messaging service 15 or the framework service 16 for the purpose of selecting the destination of the message, and is therefore also called a “destination subject ID”.

The framework service 16 has a plurality of business logics (for example, purchase processing business logic, inventory processing business logic, accounts payable processing business logic, message conversion business logic, etc.) for processing various types of messages, respectively. Yes. When receiving a message from the messaging service 15, the framework service 16 selects business logic for processing the message from the subject ID of the message, and calls the selected business logic. The called business logic performs processing according to the content of the message and updates data in the data service layer 9. The computer program for the messaging service 15 and the framework service 16 is described by, for example, JAVA language (trademark).
The data service layer 3 includes a database server (DB server) 17.

  A communication connection by HTTP or socket can be established between the web client 11 and the web server 12. A direct communication connection by a socket can be established between the web client 11 and the RtFA server 14. A direct communication connection by a socket can be established between the VB client 13 and the RtFA server 14. Further, a direct communication connection by a socket can be established between the web server 12 and the RtFA server 14. Further, a communication connection by JDBC can be established between the RtFA server 14 and the DB server 17.

  FIG. 2 shows a message structure handled by the RtFA server 14.

  As shown in FIG. 2, the message 10 includes a plurality of server control items and business data. The server control item is various data for controlling the RtFA server 14 and includes, for example, a message type, a guarantee mode, a priority order, a subject ID (destination subject ID), transmission source information, and the like.

  The “message type” distinguishes whether the message is a P to P (Point to Point) communication message or a P to M (Point to Many) communication message. Here, P to P communication refers to communication in which a message is sent from one computer system to another computer system, that is, one-to-one communication. An example of P to P communication is a case in which a purchase registration request message from a certain client is sent to a certain framework service that executes a purchase process. On the other hand, P to M communication refers to communication in which a message is sent from one or a plurality of computer systems to another plurality of computer systems, that is, one-to-multiple or multiple-to-multiple communication. An example of P to M communication is a case in which a message indicating an inventory update result from a certain framework service is transmitted to a plurality of client terminals responsible for front desk work.

  “Guaranteed mode” distinguishes whether or not a message guarantee (ie, guarantee that the message is transmitted and processed reliably) (“G”) or not (“N”). When the message having the guarantee mode “N” is received, the messaging service 15 puts the message into a message queue using volatile semiconductor memory (hereinafter referred to as “memory queue”). On the other hand, when the message having the guarantee mode “G” is received, the messaging service 15 puts the message into a message queue (hereinafter referred to as “DB (database) queue”) using a non-volatile disk storage. Even after sending the message, save the message in the DB queue. Therefore, for a message whose guarantee mode is “G”, even if a problem such as transmission failure or system failure occurs, the same message can be transmitted again later.

  “Priority” indicates a priority level of processing of the message. For example, there are three types of priorities: high (“H”), normal (“N”), and low (“L”). As will be described later, when a plurality of messages are waiting in the message queue, the messaging service 15 can control the order of retrieving the messages from the message queue according to the priority of each of the messages. .

  The “subject ID (destination subject ID)” is an identification code indicating the subject type of the message, as described above. As described below, when the messaging service 15 receives a message, the messaging service 15 selects a computer system (eg, client, framework system, other messaging service, etc.) to which the message is to be addressed based on the subject ID of the message. To do. In addition, when the framework service 16 receives a message, the framework service 16 selects business logic to be called to process the message based on the subject ID of the message.

  “Sender information” represents the subject, IP address, computer name, etc. of the sender of the message.

  FIG. 3 is a configuration diagram of the RtFA server 14.

  In FIG. 1 already referred to, only one RtFA server 14 is shown. However, in practice, a plurality of RtFA servers 14 can be provided as shown in FIG. In the example shown in FIG. 3, two RtFA servers 14 are provided, but more RtFA servers 14 can be provided.

  As shown in FIG. 3, each RtFA server 14 is provided with one messaging service 15 and one or a plurality of framework services 16, and the messaging services 15 and the framework services 16 are connected to communicate with each other. Yes. The messaging service 15 is also communicably connected to one or more clients 11 and 13. The messaging service 15 processes a plurality of threads 171 that communicate with the clients 11 and 13 and the framework service 16 in parallel.

  Since there are a plurality of RtFA servers 14, there are a plurality of sets of messaging services 15 and framework services 16. The messaging services 15 of the plurality of RtFA servers 14 are connected so that they can communicate with each other. The messaging service 15 of each RtFA server-14 also includes a thread 171 that handles communication with the messaging service 15 of the other RtFA server 14. The plurality of communication threads 171 included in each messaging service 15 has a keep alive function, and by this function, the clients 11 and 13 connected to the messaging service 15, other messaging services 15, and the framework service 16 Checking each other's normal operation.

  Each messaging service 15 is associated with a management table 18 illustrated in FIG. The management table 18 manages message paths to be transmitted by the messaging service 15, in other words, various message destinations handled by the messaging service 15. As shown in FIG. 4, the management table 18 includes a type, a computer for each of all computer systems (clients 11 and 13, other messaging services 15, and framework services 16) connected to the messaging service 15. ID, IP address, P to P subject ID, P to M subject ID, processing flag, etc. are registered.

  “Type” indicates a type of the computer system, for example, a framework service (F), a messaging service (M), and a client terminal terminal (T).

  “Computer ID” and “IP address” indicate a unique identification code and IP address of the computer system.

  “P to P subject ID” indicates a subject ID (destination subject ID) of a message for P to P communication that the computer system waits for (that is, the computer system can be a destination of the message). Multiple P to P subject IDs can be registered for each computer system.

  “P to M subject ID” indicates a subject ID (destination subject ID) of a message for P to M communication that the computer system waits for (that is, the computer system can be a destination of the message). Multiple P to M subject IDs can be registered for each computer system.

  The “processing flag” indicates whether the thread 171 for communication with the computer system is processing P to P communication (“1”) or not (“0”).

  The registration content of the management table 18 shown in FIG. 4 is an example in the case of the left messaging service Mes1 in FIG. 3, which includes all computer systems connected to the left messaging service Mes1, that is, 2 Three framework services Frm1, Frm2, right messaging service Mes2, and three client terminals PC1, Pc2, and PC3 are registered. According to this example, the first framework service Frm1 listens for four types of messages with subject IDs "A", "B", "C", and "D" for P to P communication. For P to M communication, four types of messages having subject IDs “O”, “P”, “Q”, and “R” are awaited. In addition, the messaging service Mes2 on the right side of the figure is called “D”, “E”, “F”, “H”, “I”, and “J” as P to P communication messages from the messaging service Mes1 on the left side. Seven types of messages each with a subject ID are awaited, and “P”, “Q”, “R”, “S”, “T” are messages for P to M communication from the messaging service Mes1 on the left side. And 6 types of messages with subject ID “U”.

  Referring to FIG. 3 again, when each messaging service 15 receives a message, it determines whether the message is for P to P communication or P to M communication. When a message for P to P communication is received, the messaging service 15 matches the subject ID of the received message with reference to the management table 18 illustrated in FIG. 4 associated with the messaging service 15. Search for a computer system waiting for a message with a P to P subject ID, select one computer system with a processing flag of “0” from one or more found computer systems, and select one computer Send the received message to the system. When receiving the message of P to M communication, the messaging service 15 refers to the management table 18 as shown in FIG. 4 associated with the messaging service 15 and sets the subject ID of the received message. Select all computer systems waiting for a matching P to M Subject ID message and send the message to all selected computer systems.

  FIG. 5 is a connection configuration diagram between a plurality of RtFA servers. FIG. 6 is a connection configuration diagram of a messaging service and a framework service in a plurality of RtFA servers.

  As shown in the upper or lower part of FIG. 5, each RtFA server 14 is connected to all the other RtFA servers 14 so as to communicate with each other. That is, as shown in FIG. 6, the messaging service 15 of each RtFA server 14 is connected so as to be communicable with the messaging services 15 of all other RtFA servers 14. In this way, each of a plurality of components connected so as to be communicable with all other components is referred to as “mesh connection”. Further, as shown in FIG. 6, it is possible to directly contact each messaging service 15 with a plurality of framework services 16.

  Thus, under the mesh connection of the plurality of messaging services 15, each message service 15 executes the above-described keep alive function at a predetermined time, for example, when it is activated. That is, when each messaging service 15 is activated, it sequentially connects with all of the other messaging services already registered in its own management table 18, and the framework system 16 and the clients 11, 13 connected to itself. Notifies all other messaging services connected to the subject ID of the message that is waiting. The notified subject ID is registered in the management table of the other messaging service as the subject ID of the message that the messaging service 15 waits from the other messaging service. If each messaging service 15 cannot connect when trying to connect to another messaging service, the messaging service 15 retries the connection several times at regular intervals thereafter. When each message service 15 receives a connection request from another messaging service that has not yet been registered in its management table 18, it connects to that unregistered messaging service, and each unregistered messaging service and each Exchange the waiting subject ID and the like, and register the messaging service in its own management table 18. By virtue of such a keep-alive function, when a specific messaging system 15 is not operating normally (for example, when the system is down), each other normally operating messaging service 15 is properly operated. A specific messaging system 15 that is not in operation can be excluded from the message relay route, and another relay route can be automatically selected by referring to its management table 18.

  Next, the types of communication services provided by the messaging service 15 will be described with reference to FIGS. There are two types of data distribution services provided by the messaging service 15: P to M (one-to-many) communication processing and P to P (one-to-one) communication processing.

  In the P to M communication process, as described above, the messaging service 15 receives the P to M received by the messaging service 15 based on the P to M subject ID of each computer system registered in the management table 18 illustrated in FIG. This is a process of delivering a message to all computer systems waiting for it. For example, each time market information is updated, a P to M communication process is performed when an updated market information message is distributed from 1 to n RtFA servers to n clients.

  On the other hand, as described above, the P to P communication process is performed by the messaging service 15 based on the P to P subject ID of each computer system registered in the management table 18 illustrated in FIG. This is the process of sending a to P message to one of the computer systems awaiting it. For example, when a request message for a certain process from a client is sent to one framework service having a business logic for performing the process, a P to P communication process is performed.

  FIG. 7 shows an example of a message relay method for P to M communication processing. A P to M message output from a framework service 16 as a publisher is distributed to all messaging services 15 that wait for the message, and all clients that wait for the message from those messaging services 15. 11 and 13.

  FIG. 8 is a flowchart illustrating an example of the P to M communication process. First, the client T1, which is one of the subscribers, establishes a socket connection with a predetermined messaging service Mes1. Also, the subject ID “X” of the P to M message that the client T1 waits for the messaging service Mes1 is registered. The messaging service Mes1 adds the P to M subject ID “X” of the client T1 to the management table 18 associated with the messaging service Mes1. On the other hand, the client T1 waits for delivery of a message from the messaging service Mes1. Thereafter, when the other messaging services Mes2 and Mes3 connected to the messaging service Mes1 are activated, the P to M subject ID “X” of the client T1 already registered in the management table 18 of the messaging service Mes1 is the other messaging service Mes2. And “Me” is also notified, and “X” is added to the management table 18 as the P to M subject ID of the messaging service Mes1.

  Here, when the P to M message having the subject ID “X” is delivered from the framework service Frm3 as a publisher, the messaging service Mes3 that has received the message refers to the management table 18 associated with itself and refers to the subject. Pick up all messaging services Mes1 and Mes2 waiting for ID “X” and deliver the message to them.

  When the messaging service Mes1 connected to the client T1 receives the message, the messaging service Mes1 picks up the client T1 waiting for the subject ID “X” from the management table 18 associated with the client T1, and distributes the message to the client T1.

  Although not shown, each framework service also notifies the subject ID of the P to M message that the framework service awaits to the messaging service that can directly communicate with the framework service. Thereby, the P to M subject ID that the framework service waits for is registered in the management table of the messaging service. Thereafter, the messaging service notifies all other messaging services of the P to M subject ID of the framework service registered in the management table as the P to M subject ID that the messaging service waits on. As a result, the P to M subject ID that the framework service waits on is also registered in the management tables of all other messaging services. As a result, the framework service can receive a message with a P to M subject ID from any messaging service.

  Next, FIG. 9 is a flowchart showing the P to P communication process.

  Similar to the registration of the P to M communication subject ID in the management table described above, each messaging service management table includes a P to P subject ID on which a client and a framework service that the messaging service can directly contact, In addition, P to P subject IDs on which all other messaging services are awaited are automatically registered in advance.

  In such a state, as shown in FIG. 9, first, a certain client PC1 establishes a connection with a predetermined messaging service Mes1.

  Subsequently, when a P to P request message having a certain subject ID “A” is transmitted from the client PC 1, the messaging service Mes 1 receiving this message refers to its own management table 18 and refers to the subject ID. One of the computer systems waiting for “A”, for example, the framework service Frm1 is selected and the request message is delivered to it (arrow (1)). The framework service Frm1 calls the business logic corresponding to the subject ID “A” of the accepted request message, executes the processing of the message, and returns a reply message indicating the execution result to the messaging service Mes1 (arrow (3 )). Then, the messaging service Mes1 returns the reply message to the client PC1. The client PC 1 that acquired the reply message releases the connection with the messaging service Mes1.

  Alternatively, the messaging service Mes1 sends the request message of the subject ID “A” received from the client PC1 to the other messaging service Mes2 that waits for the subject ID “A” instead of sending the request message to the framework service Frm1 as in the above example. You can also send (arrow (2)). For example, this occurs when the framework service Frm1 is processing but the messaging service Mes2 is not processing. In that case, when the messaging service Mes2 receives the request message, the messaging service Mes2 selects one computer system that waits for the subject ID “A”, for example, the framework system Frm2 by referring to its own management table 18 and requests it. Send a message for processing (arrow (4)). When the reply message of the processing result is returned from the framework system Frm2 (arrow (5)), the messaging service Mes2 returns the reply message to the messaging service Mes1 (arrow (6)), and the messaging service Mes1 A reply message is returned to the client PC 1.

  As described above, the messaging service 15 can send messages to other framework services via other messaging services as well as send messages to the framework service 16 that can directly contact itself. . Thereby, load balancing (load balancing) between a plurality of RtFA servers 14 is possible.

  FIG. 10 is an explanatory diagram of the load balancing function of the messaging service.

  As shown in FIG. 10, in each RtFA server 14, each framework service 16 processes a plurality of threads 19 that communicate with the messaging service 15 in parallel. Each messaging service 15 includes a message queue 15a that temporarily holds a message received from a client.

  Each message stored in the queue 15a of each messaging service 15 is delivered to any framework service 16 corresponding to the subject ID of the message according to the management table associated with the messaging service 15. In that case, the messaging service 15 can deliver the message to a particular framework service 16 that can contact itself directly and awaits its subject ID. However, at that time, if the thread 19 of the specific framework service 16 is not empty (that is, processing is in progress), the messaging service 15 waits for the subject ID instead of the framework service 16 being processed. The message is delivered to the messaging service 15. The other messaging service 15 that received the message delivers the message to a particular framework service 16 that the other messaging service 16 can contact directly and awaits its subject ID. In order to enable such message relaying, each messaging service 15 constantly monitors its message queue 15a, and if there are messages waiting to be processed in the message queue 15a, messages are immediately sent from the queue. The message is taken out, the destination of the message is determined with reference to its own management table, and the message is sent out. Thereby, the load balance of a plurality of RtFA servers is optimized. As a result, every message is processed as early as possible, so that back office work that was traditionally done in batch processing at night can be performed early in a near real-time manner.

  Next, the configuration of the framework service 16 will be described.

  FIG. 11 shows the configuration of the framework service 16.

  The entity of the framework service 16 is configured by parallel processing by a plurality of framework threads 25. Each framework thread 25 accesses a group of business logics 20 prepared in advance, and loads and executes specific business logic 22 corresponding to the subject ID of the message delivered from the messaging service 15. Here, the business logic is a process programmed with, for example, a JAVA code, and executes unique message processing. Most of the main business logic requests a predetermined operation corresponding to the content of the message from the database 21 managed by the database server 17.

  FIG. 12 is an operation explanatory diagram of the framework service 16.

  There are roughly two types of operation methods of the business logic of the framework service 16: a synchronous method and an asynchronous method. The framework service 16 may execute only one business logic in response to a certain request message from the client. In addition, the framework service 16 may execute one business logic in response to a request message directly, and may execute one or more subsequent business logics in conjunction with it. In FIG. 12, the business logic of the purchase process is executed directly in response to the message of the purchase registration request from the clients 11 and 13, and in conjunction with this, two subsequent processes of inventory process and accounting process are executed. An example where business logic is executed is shown.

  When only one business logic is executed in direct response to a request message from the client, the framework service 16 executes the only business logic, usually in a synchronous manner, and indicates the execution result. Return reply message to client.

  On the other hand, when one business logic is executed directly in response to a request message from the client and then one or more subsequent business logics are executed in conjunction with this, the framework service 16 performs the first one. One business logic is usually executed in a synchronous manner, but the second and subsequent business logics can be executed in a synchronous manner or can be executed in an asynchronous manner. FIG. 12 shows an example in which only the business logic of the first purchase process is executed in a synchronous manner, and the business logic of subsequent inventory processing and accounting processing is executed in an asynchronous manner. When a plurality of business logics are executed as in the example of FIG. 12, the framework service 16 returns a reply message indicating the execution result to the client when all of the business logics executed in a synchronous manner are completed. Business logic that is to be executed asynchronously is executed in the background separate from the client (ie, offline from the client).

  As shown in FIG. 12, the framework service 16 has a flow definition file 23, in which a business logic execution schedule by the framework service 16 (name of one business logic to be executed first, If there is one or more subsequent business logics to be linked, the message subject ID and linkage method (synchronous or asynchronous) passed to the subsequent business logic are defined for each subject ID of various messages. Has been. When the framework service 16 receives one message, the framework service 16 refers to the flow definition file 23, selects a business logic execution schedule corresponding to the subject ID of the received message, and one or more businesses according to the selected schedule. Execute logic. Since the selected schedule describes at least one business logic to be executed directly in response to the message, the framework service first loads the one business logic. Execute. If the selected schedule further describes one or more subsequent businesses and linkage methods to be linked, the framework service will execute the subsequent business logic after executing the first business logic. It is executed in the linkage system (that is, synchronously or asynchronously). The preceding business logic and the subsequent business logic may be executed by the same framework service, or may be executed by another framework service by the load balancing described above.

  FIG. 13 shows a simple example of the flow definition file 23.

  As illustrated in FIG. 13, the flow definition file 23 includes a plurality of sentences 231, 232, 233, and 234 that describe a business logic execution schedule for each subject ID. The flow definition file 23 is, for example, a text file. Therefore, editing such as addition, deletion, and change of the definition sentences 231, 232, 233, and 234 can be easily performed using a text editor or the like.

  As described in the definition sentence 231 at the top of FIG. 13, each definition sentence is composed of a plurality of sub-sentences separated by semicolons “;”. The first sub-sentence includes the input subject ID, log queue name, execution business logic name, and the like. Each of the second and subsequent sub-sentences includes a message conversion business logic name, an output subject ID, a linkage mode, and the like. The first sub-sentence relates to one business logic that is to be executed directly in response to the message, which is always described in all definition sentences. The second and subsequent sub-sentences relate to one or more subsequent business logics that are executed in conjunction with the first business logic, and are thus described only when there is subsequent businessness logic.

  The meaning of the first sub-sentence item is as follows.

  Here, the “input subject ID” is the subject ID of the message received by the framework system.

  “Log queue name” is the name of the log queue used when the received message is written in the log. For example, "@DEF" means use the default log queue, and "@NONE" means that it will not be written to the log.

  The “execution business logic name” is the name of the business logic to be executed in direct response to the message. In the example of the definition sentences 232 to 234 shown in the figure, the same code as the input subject ID is used.

  The meaning of each sub-sentence item after the second is as follows.

  The “message conversion business logic name” is the name of the message conversion business logic executed to convert the processing result data of the preceding business logic into a message passed to the subsequent business logic. If message conversion is not required, "@NONE" is written here.

  The “output subject ID” is the subject ID of the message passed to the subsequent business logic.

  “Linkage mode” indicates whether the subsequent business logic is executed in a synchronous manner or in an asynchronous manner. For example, “SYNC” means a synchronous method, and “ASYNC” means an asynchronous method.

  The second definition sentence 232 in FIG. 13 illustrates the next schedule (1).

  (1) In response to a message with a subject ID “BuySelBuy” (for example, purchase search request), a business logic named “BuySelBuy” (for example, purchase search processing) is executed.

  The third definition sentence 233 exemplifies the following schedules (1) to (3).

  (1) In response to a message with a subject ID “BuyUpdBuy” (for example, a purchase update request), first, a business logic named “BuyUpdBuy” (for example, a purchase update process) is executed.

  (2) Next, using the conversion business logic named “CnvBuyUpdBuy”, the format of the output data of the preceding “BuyUpdBuy” business logic is converted, and the message with the subject ID “InvUpdInv” (for example, inventory Update request) and output it to the message service.

  (3) Subsequent business logic (for example, inventory update processing) that will process the output “InvUpdInv” message is executed synchronously.

  Further, the fourth definition sentence 234 exemplifies the following schedules (1) to (5).

  (1) In response to a message with a subject ID “BuyInsBuy” (for example, purchase inspection update request), first, a business logic named “BuyInsBuy” (for example, purchase inspection update processing) is executed.

  (2) Next, the conversion business logic named “CnvBuyInsBuy1” is used to convert the output data format of the preceding “BuyInsBuy” business logic, and a message with a subject ID of “InvUpdInv” (for example, inventory Update request) and output it to the message service.

  (3) Subsequent business logic (for example, inventory update processing) that will process the output “InvUpdInv” message is executed asynchronously.

  (4) In addition, using the conversion business logic named “CnvBuyInsBuy2”, the format of the output data of the preceding “BuyInsBuy” business logic is converted, and the message with the subject ID “AccDbtBuy” (for example, accounts payable) Create (registration request) and output it to the message service.

  (5) Subsequent business logic that receives the output “AccDbtBuy” message (for example, accounts payable registration processing) is executed asynchronously.

  Refer to FIG. 12 again. Each framework service 16 can select and execute the business logic 22 corresponding to the message to be processed by referring to the flow definition file 23 associated therewith, and can determine the necessity of subsequent processing. If necessary, a request message for subsequent processing can be created and returned to the messaging service 15.

  Here, as a subsequent process of the process by one framework thread, when the process by another framework thread is performed asynchronously, the framework service 16 results in the process by the business logic in the preceding framework thread ( A request message for subsequent processing is once input to the queue 15a of the messaging service 15, and then another framework thread obtains the request message from the queue 15a of the messaging service 15 to perform subsequent processing. Here, the framework system 16 that performs the preceding process and the framework system 16 that performs the subsequent process may be the same or different. Which framework system 16 is assigned various processes is controlled by the load balancing function of the messaging service described above.

  Each framework service 16 has a message-driven configuration. In other words, business logic loading and business logic processing are executed with the delivery of a message from the messaging service 15 as a trigger.

  According to this embodiment described above, the synchronization method and the asynchronous method are prepared for the linkage method of the business logic of the framework service, and the execution schedule of the business logic can be controlled by the description of the flow definition file that can be easily rewritten at any time. It is easy to define complex business logic flow and modify as needed.

  Further, in the above embodiment, the messaging services are mesh-connected, and the keep alive function allows statuses (waiting) between the messaging services, between the messaging service and the client, and between the messaging service and the framework service. Message subject ID, whether processing is in progress, etc.). Each messaging service then stores the current status of surrounding clients, framework services and other messaging services in a management table. As a result, even if any RtFA server goes down, each messaging service can automatically select a message relay route that can be used normally and transmit the message to the correct system. As a result, fault tolerance is improved, reliability of system operation is improved, system expansion is facilitated, and system maintenance can be easily performed.

  In addition, the messaging service has multiple types of data distribution methods such as P to P communication and PtoM communication, and sends which message to which computer system by which data distribution method according to the status registered in the management table. The messaging schedule can be automatically selected. As a result, a flexible messaging service can be provided.

  In addition, the load balancing function of the messaging service can automatically adjust the load balance of multiple RtFA servers, providing high performance.

  Here, the scope of the present invention is not limited to this embodiment. For example, an equivalent system can be realized by using a platform other than the JAVA base. Further, the above-described features of the messaging service and the above-described features of the framework service are not necessarily combined as in the above-described embodiment.

  Hereinafter, some detailed functions provided in the embodiment will be described.

  FIG. 14 is a block diagram showing an update system for the flow definition file 23.

  The framework service 16 includes a definition file update module 101 that is a program module for updating the definition file 23. When the update module 101 receives a reload command 111 from the outside, the update service module 101 in the main memory 103 of the framework service 16 The definition file 23 currently in use loaded in the disk is updated by overwriting a new definition file 109 stored in the external storage device (for example, the disk storage 107 as indicated by an arrow 113). The new definition file 109 in the storage 107 can be easily edited using the text editor 105 etc. When desired, the definition file 23 in the main memory 103 can be changed by inputting the reload command 111 described above. Edited The contents are updated to the same contents as the new definition file 109. Thereby, even when the framework service 16 is in operation, the contents of the definition file 23 are rewritten at a desired time, and the contents of the definition file 23 are updated. Therefore, it is possible to reflect the change in the type of business logic 22 to be executed, whether to perform subsequent processing, whether to perform a linked operation of a plurality of business logics synchronously, or asynchronously. It is possible to change the processing schedule such as whether to perform the operation while the system is operating.

  FIG. 15 shows the message conversion processing function of the framework service.

  The computer program for the framework service 16 is constructed in, for example, the JAVA language. As shown in FIG. 15, the framework service 16 includes an input conversion function 102 for converting the format of an input message and an output conversion function 103 for converting the format of an output message. The input conversion function 102 converts, for example, an input message in the form of an XML file from the messaging service 15 into a JAVA object format. The output conversion function 103 converts a message in the JAVA object format to be output to the messaging service 15 into an XML format. The input conversion function 102 acquires a JAVA class member variable based on the description of the XML DTD (document type definition) and instantiates it to obtain a Java object message. Further, the output conversion function 103 forms an XML DTD based on the JAVA class member variable, and obtains an XML message.

  FIG. 16 shows the structure of the message queue of the messaging service.

  In the above description, the message queue 15a is described as if it is a single queue. However, actually, as shown in FIG. 16, the message queue 15a includes three types of queues, that is, a memory queue 153, a ring buffer 154, and a DB (database) queue 155. The memory queue 153 and the ring buffer 154 are provided in a storage device such as the RAM 151 that can be accessed at high speed. The DB queue 155 is provided in a nonvolatile large-capacity storage device such as a hard disk (HDD).

  The memory queue 153 temporarily waits for a message indicating that there is a partner who receives the result of processing the message, such as a P to P request message received from the client by the messaging service, and the guarantee of the message is unnecessary. Used to make. On the other hand, the DB queue 155 is used to temporarily wait for a message that requires message guarantee, such as a request message for asynchronous subsequent processing received by the messaging service from the framework service. Whether or not the message needs to be guaranteed is determined by the “guarantee mode” in the configuration of the message 10 shown in FIG.

  The ring buffer 154 is used to temporarily wait for a message of P to M communication. Each computer system can find the message it awaits from the ring buffer 154 and go through the link buffer 154 and take it. In FIG. 16, the ring buffer 154 is shown as a single buffer. However, in reality, three ring buffers corresponding to the three types of priority “H”, “N”, and “L” are used. Is a set.

  The DB queue 155 is used to temporarily wait for a message that requires message guarantee, such as a request message for subsequent processing received by the messaging service from the framework service.

  The messaging service has a message queue management function 104 that controls writing and reading of messages to and from the queues 153, 154, and 155 described above. The message queue management function 104 checks the memory queue 153 in preference to the DB queue 155, and if there is a P to P message in the memory queue 153, takes out the message from the memory queue 153 and waits for it. Send the message to If there is no P to P message in the memory queue 153, the message queue management function 104 checks the DB queue 155. If there is a P to P message in the DB queue 155, the message is stored in the DB queue 155. And send the message to one computer system that listens to it.

  As shown in FIG. 16, the message queue management function 104 adds status information S indicating the processing state of the message to the message M in the DB queue 155, and if the message is processed, the status information S Is changed from “unprocessed” to “processed”. If an error occurs in processing the message, the status information S is set to “error”. Causes of errors include data inconsistencies and program logic mistakes. A message once placed in the DB queue 155 is stored in the DB queue 155 without being deleted even if a problem such as a system down or an error occurs.

  The message queue management function 104 has a function of rewriting the “error” status information S to “unprocessed”. If a problem such as a system failure or an error occurs, the message queue management function 104 later reads out and retransmits a message whose status information S is “unprocessed”. Thereby, reliable processing of the message is guaranteed. Further, by following the status information S of the error message, it is possible to investigate the cause of the error.

  The message queue management function 104 also has a function of rewriting the “error” status information S to “processed” in accordance with an external command. For example, depending on the state of the system, it may not be appropriate to change the error status message to the unprocessed status and re-output. Also, depending on the degree of error that has occurred in the message, it may be more appropriate to modify the message by inputting a command than to output it to the framework service for processing. In such a case, a function of rewriting status information S of “error” to “processed” is used. The function of rewriting the “error” status information S described above to “unprocessed” and the function of rewriting to “processed” can be arbitrarily selected.

  Further, the message queue management function 104 has a read address pointer for the ring buffer 155 for each of all computer systems registered in the management table 18 (FIG. 4), and a read address pointer for each computer system. The P to M message that the computer system awaits is found from the ring buffer 155 while circulating through the ring buffer 155, and the found P to M message is read and sent to the computer system.

  17 and 18 show an operation flow in which the message queue management function 104 stores a message in the message queue.

  As shown in FIG. 17, when the message queue management function 104 receives a message from the client (161), the message queue management function 104 first determines whether the message is in non-transaction mode (NON-TRAN mode) or transaction mode (TRAN mode). Is determined (163). Here, when the NON-TRAN mode is designated, the message queue management function 104 stores the message in the message queue as soon as the message is received (that is, advances the processing of the message). On the other hand, when the TRAN mode is specified, even if the message queue management function 104 receives a message, the message queue management function 104 does not immediately store the message in the message queue, but stores it in another temporary queue, and the COMMIT from the client. When an (execute) command is sent, the message is only stored in the message queue (that is, the message is processed). When a client issues a request message with the TRAN mode specified, the request message can be withdrawn or modified later unless a COMMIT command is issued.

  When the result of the determination in step 163 in FIG. 17 is the NON-TRAN mode, the message queue management function 104 determines whether the received message is for P to P communication or P to M communication (165). . If the result of the determination is P to P communication, the message queue management function 104 puts the received message into the queue (167). The queued message is immediately read and sent to the framework service where it is processed. If a request message for subsequent processing is returned from the framework service as a result of the processing, the message queue management function 104 places the request message for subsequent processing in the DB queue (169). Then, the message queue management function 104 returns a success message indicating the processing result of the received message to the client (171).

  If the result of determination in step 165 is P to M communication, the message queue management function 104 determines whether the priority (FIG. 2) of the received message is “H”, “N”, or “L”. The received message is stored in a ring buffer corresponding to the determined priority (175, 177 or 179). Any P to M message placed in the ring buffer will be sent to the computer system waiting for it. Then, the message queue management function 104 returns a success message for the received message to the client (181).

  If the determination result in step 163 is the NON-TRAN mode, the process proceeds to step 181 shown in FIG. In step 181, the message queue management function 104 stores the received message in a temporary queue different from the message queue described above. Thereafter, when receiving a COMMIT command regarding the received message from the client, the message queue management function 104 extracts the message from the temporary queue, and performs the processing from step 185 on the message. The processing after step 185 is the same as the processing after step 165 in FIG.

  FIG. 19 shows the message reading function of the message queue management function 104.

  As shown in FIG. 19, the message queue management function 104 of the messaging service 15 stores the messages received from the client and the framework service 16 in the message queue 15a having the above-described configuration. The message queue management function 104 has two types of functions, that is, a priority mode 104a and a sequence guarantee mode 104b with respect to the operation of extracting a message from the memory queue 153 and the DB queue 155 shown in FIG. . The priority mode 104a controls the extraction order of messages from the message queue based on the priority order of messages. On the other hand, the sequence guarantee mode 104b prohibits the extraction of subsequent messages stored in the message queue until the processing of the message previously extracted from the message queue is completed in the framework service, thereby Guarantee a certain processing order. Whether to execute the priority mode 104a or the sequence guarantee mode 104b for each message queue is selected according to the subject ID) of each message or according to the preset mode setting of each message queue. . In the sequence guarantee mode 104b, for example, when a sales processing request message is received from each of a plurality of clients, a certain sales processing request is executed after the previously requested sales processing is completed. Applied when you want to guarantee the processing order.

  FIG. 20 shows the configuration of the storage area for the priority mode 104a. FIG. 21 shows an operation flow of the priority mode 104a.

  As shown in FIG. 20, the priority mode 104a includes, for example, three stack memories corresponding to two stack memories, ie, a stackable stack 211 and a simple tack 213, and three priority orders “H”, “N”, and “L”. Entries 215H, 215N and 215L are used. Note that the number of entries can be increased. For example, in addition to the three entries shown in the figure, another entry corresponding to “H” is added.

  Initially, numerical values such as “5”, “3”, and “1” as shown in the figure are set in the entries 215H, 215N, and 215L, respectively. The larger the initial value of the index, the higher the priority level.

  Initially, all entries 215H, 215N and 215L are stacked on the sortable stack 211 as shown, while the simple stack 213 is empty.

  Sortable stack 211 has an array of a plurality of indexes stacked therein, in order of increasing index, the entry with the largest index is at the top, and the entry with the smallest index is at the bottom. To sort automatically. Accordingly, from the sortable stack 211, an entry with a larger index is extracted earlier.

  The simple stack 213 simply stacks the entry entered later on the entry entered earlier. Therefore, from the simple stack 213, the later entry is taken out earlier.

  The priority mode 104a moves a message queue (memory queue 153 or DB queue 155) by moving an entry between the sortable stack 211 and the simple stack 213 and manipulating the entry index according to the flow shown in FIG. ) To control the order in which messages are retrieved.

  Hereinafter, the flow shown in FIG. 21 will be described. First, the priority mode 104a takes out the top entry (that is, index is the largest) from the sortable stack 211 (221), and puts the entry on the simple stack 213 (223). Next, the priority mode 104a checks whether there is a message in the message queue that matches the priority order of the top entry in the simple stack 213 (225). As a result, if there is no matching message, the process proceeds to step 221. If there is a matching message as a result of the check, the priority mode 104a extracts the matched message from the message queue (227). The retrieved message is processed by any framework system. Thereafter, the priority mode 104a checks whether the number of entries in the simple stack 213 is 1 (229). As a result, if the number of entries in the simple stack 213 is two or more, all entries are sequentially extracted from the simple stack 213 and stacked on the sortable stack 211 (237). Then, the priority mode 104a returns a reply message indicating the processing result from the framework system to the client for the message extracted from the message queue in step 227 (239).

  If the number of entries in the simple stack 213 is one as a result of the check in step 229, the priority mode 104a reduces the index of the entry in the simple stack 213 by 1 (231). Then, the priority mode 104a checks whether the reduced index is “−1” (233). If it is not “−1”, the process proceeds to step 237, while if it is “−1”. If the index is returned to the initial value (235), the process proceeds to step 237.

  With the above operation, messages are taken out from the message queue in the order in which the order of the messages in the message queue is corrected in consideration of the priority of those messages. That is, the order of the messages in the message queue is, for example, “H”, “H”, “L”, “H”, “H”, “H”, “N” as shown in FIG. In the case of “,” the order of messages taken out from the message queue is “H”, “H”, “N”, “H”, “H”, “H”, “L” in the priority order. .

  FIG. 22 shows a flow of operations in the sequence guarantee mode 104b.

  As shown in FIG. 22, in the sequence guarantee mode 104b, when a message retrieval request occurs (241), first, the message queue is locked (243, 245, 257), and another message retrieval from the message queue is prohibited. To do. Next, the sequence guarantee mode 104b reads one message from the message queue (247, 249). The read message is processed in one of the framework systems (251), and an appropriate database update commit (or rollback in the case of processing failure) is performed by the processing (253). Thereafter, the sequence guarantee mode 104b releases the lock of the message queue (255).

  By the above operation, the processing of the next message is executed after the processing of the preceding message is completed, so that a certain processing order of the messages is guaranteed.

  FIG. 23 shows the message discrimination function of the framework service 16.

  As shown in FIG. 23, the framework service 16 has a message determination business logic 106. When a message is received from the messaging service 15, the framework service 16 executes the message determination business logic 106. The message discrimination business logic 106 searches the flow definition file 23 associated with the framework system 16 for a definition sentence in which a subject ID matching the subject ID of the received message is written. If a matching definition sentence is found, next, the execution business logic 22 described in the definition sentence is executed. However, if a matching definition sentence is not found, the message determination business logic 106 returns an error reply message indicating that it cannot be processed to the messaging service 15, and the reply message is sent to the client. As already explained, the messaging service 15 sends each message only to the computer system that listens for that message, based on the management table 18 (FIG. 4), so that in principle, a message is a false framework. Never sent to the system. However, even if a message from the client is sent to the wrong framework service, the client can receive an error reply message indicating that it cannot be processed immediately. You can move on to the next action.

  Further, the framework service 16 includes a service stop mode that permits processing in the framework service only for messages having identification information registered in advance, and is not registered in advance when the mode is set. When a message having identification information is received from the client, a message not accepting the message is returned to the client.

  FIG. 24 shows the message conversion business logic of the framework service.

  As shown in FIG. 24, the framework service 16 has one or more message conversion business logics 105. These message conversion business logics 105 are, for example, “CnvBuyUpdBuy”, “CnvBuyInsBuy1” and “CnvBuyInsBuy2” described in the definition sentences 233 and 234 of the flow definition file 23 shown in FIG. Each message conversion business logic 105 may correspond to one predetermined business logic BL1. When a certain business logic BL1 is executed according to a certain definition sentence, a message conversion business logic 105 corresponding to the business logic BL1 is subsequently executed. The message conversion business logic 105 includes a format conversion function for adapting the format of the processing result message output from the preceding business logic BL1 to the format of the input message to the subsequent business logic BL2, and the output from the preceding business logic BL1. A message filtering function for determining whether or not to input this message to the subsequent business logic BL2 according to the parameter of the received message. For example, when the parameter arrangement of the message handled by the preceding business logic BL1 is different from the parameter arrangement of the message handled by the subsequent business logic BL2, the message conversion business logic 105 converts the former parameter arrangement into the latter parameter arrangement. Further, the content of the output message of the preceding business logic BL1 is special (for example, request rejection, database update failure, transaction rollback, etc.), and therefore, the execution of the subsequent business logic BL2 is meaningless. There is a case. In such a case, the message conversion business logic 105 omits generation of an input message to the subsequent business model BL2 by the message filtering function. Here, a message queue that temporarily holds a message may be interposed between the preceding business logic BL1 and the message conversion business logic 105, or between the message conversion business logic 105 and the subsequent business logic BL2.

  The above description is merely an example for explaining the present invention. The present invention is not limited to the above-described embodiments, and can be implemented in many other system configuration variations.

It is a whole block diagram of this embodiment. It is a block diagram which shows the structure of the message which the RtFA server 14 handles. 2 is a configuration diagram of an RtFA server 14. FIG. An example of a management table 18 associated with the messaging service 15 is shown. It is a connection block diagram between several RtFA servers. It is a connection block diagram between several messaging services. It is explanatory drawing which shows the message relay method of P to M (one to many) communication processing. It is a flowchart which shows an example of a P to M communication process. It is a flowchart which shows P to P (one to one) communication processing. It is explanatory drawing of the load balancing function of a messaging service. It is a block diagram which shows the structure of a framework service. It is operation | movement explanatory drawing of a framework service. Here is a simple example of a flow definition file. It is a block diagram which shows the update system of a flow definition file. It is a block diagram which shows the message conversion processing function of a framework service. It is a block diagram which shows the structure of the message queue of a messaging service. It is a flowchart which shows the operation | movement which a message queue management function stores a message in a message queue. FIG. 18 is a continuation of the flowchart of FIG. 17. It is a block diagram which shows the message reading function of a message queue management function. The storage configuration for the priority mode is shown. The flow of the priority mode operation is shown. The flow of operation in sequence guarantee mode is shown. It is a block diagram which shows the message discrimination | determination function of a framework service. It is a block diagram which shows the message conversion business logic of a framework service.

Claims (4)

In a framework system that is communicatively connected to a client:
A framework service that is a computer system that processes a request message from the client and outputs a reply message to the client;
A messaging service that is a computer system that is interposed between the client and the framework service and relays messages between the client and the framework service;
The messaging service relays not only a P to P communication message including the request message and the reply message, but also a P to M communication message between the client and the framework service;
Each messaging service has its own management table;
In the unique management table of each messaging service, a subject ID of a P to P communication message and a subject ID of a P to M communication message that a computer system connected to each messaging service respectively waits are registered;
Each of the messaging services is
(A) When a P to P communication message is received, the subject of the P to P communication message received from the computer system connected to each messaging service with reference to the unique management table of each messaging service Looking for a computer system waiting for a subject ID matching the ID and sending the received message to the found computer system;
(B) When a P to M communication message is received, the subject of the received P to M communication message is referred to from among the computer systems connected to each messaging service by referring to the unique management table of each messaging service. Find all computer systems waiting for a subject ID that matches the ID and send the received message to all found computer systems;
Framework system. The framework system according to claim 1,
The messaging service has a ring buffer for temporarily waiting for the message of the P to M communication;
Framework system. The framework system according to claim 1,
Each P to P communication message includes a guarantee mode regarding whether or not message guarantee is required;
A first message queue for temporarily waiting for a message of P to P communication that does not require message guarantee; and a message service for temporarily waiting for a message of P to P communication that requires message guarantee. A non-volatile second message queue;
Framework system. A framework system that is communicably connected to a client,
A framework service that is a computer system that processes a request message from the client and outputs a reply message to the client;
A messaging service that is a computer system that is interposed between the client and the framework service and relays messages between the client and the framework service;
Each messaging service has its own management table, and each messaging service's own management table includes the subject ID and P to M communication of the P to P communication message that the computer system connected to each messaging service waits for. The subject ID of the message is registered,
In the method of controlling P to P communication and P to M communication in the framework system:
Each messaging service receives a P to P communication message and refers to a unique management table of each messaging service, and receives the received P to P communication from a computer system connected to each messaging service. Looking for a computer system waiting for a subject ID that matches the subject ID of the message and sending the received message to the found computer system;
Each of the messaging services receives the P to M communication message and refers to the unique management table of each of the messaging services, and receives the received P to M communication from the computer system connected to each of the messaging services. Searching for all computer systems waiting for a subject ID that matches the subject ID of the message and sending the received message to all found computer systems;
With a method.

Images