KR100728745B1 - A pos system using unification meddle ware based on peer to peer - Google Patents

Abstract

The present invention relates to a point-of-sale (POS) system using peer-to-peer-based integrated middleware, wherein all terminals constituting the POS system are regarded as the same peer, and communication of each peer is peer-to-peer. On the other hand, each peer has a server area and a client area, so that various functions such as the distribution of resources to and use of distributed resources, free event / message transmission, remote monitoring and updating, and database handling are available. It is related to a distribution system for unified management of orders, inventory, and order flexibly.

POS SYSTEM, P2P, Integrated Middleware, Components, Applications, Database Handling, Updates, Remote, Mobile Devices

Description

POS system using integrated middleware based on peer-to-peer {A POS SYSTEM USING UNIFICATION MEDDLE WARE BASED ON PEER TO PEER}

1 is a diagram showing the basic configuration of a data packet format based on the X-Talk protocol of the present invention.

2 is a diagram schematically showing a packet structure of communication between X-Talk clients (applications with X-Talk components embedded) of the present invention.

3 is a diagram illustrating a schematic configuration for mapping an X-Talk Peer ID and a peer code of the present invention.

4 is a diagram schematically showing a bit structure of a Peer ID code of the present invention.

5 is a schematic structural diagram of an X-Talk component of the present invention.

6 is a view schematically showing the interface structure of the present invention.

7 is a flowchart illustrating a basic Service Request and Reply process in X-Talk as an embodiment of the present invention.

8 is a schematic flow diagram of a process for transmitting Return Event / Return Data from a destination peer B to a source peer A in accordance with an embodiment of the present invention.

FIG. 9 is a flowchart illustrating a schematic process of transmitting an Event / Message from an application of a source peer A to an application of a destination peer B. Referring to FIG.

FIG. 10 is a diagram illustrating a schematic meaning of file transfer according to the present invention when there are three peers.

FIG. 11 is a diagram showing another embodiment of FIG. 10.

FIG. 12 is a flowchart illustrating the overall overall process when the peer A of FIG. 10 wants to instruct the peer B to transfer the file of the peer B to the peer C.

13 is a flow diagram illustrating a schematic process for free database handling between peers.

14 is a configuration diagram showing a schematic configuration of a B-Server of the present invention.

15 is a schematic system configuration view of the present invention from the perspective of a B-Server.

16 is a view showing a schematic configuration of a force system consisting of a force terminal with a built-in X-Talk component according to the present invention.

FIG. 17 is a diagram illustrating an embodiment of FIG. 16 viewed from the perspective of a force terminal.

18 is a diagram illustrating the concept of an extended force system.

19 shows another embodiment of an extended force system.

The present invention relates to a point-of-sale management system using a peer-to-peer based integrated middleware, that is, a point of sale (POS) system. More specifically, all terminals constituting the POS system are regarded as the same peer. Allow peers to communicate on a peer-to-peer basis, while each peer has a server domain and a client domain, so that resources can be distributed to and used by peers, free event / message transmission, The present invention relates to a distribution system that flexibly manages orders, inventory, and orders by unifying various functions such as remote monitoring and updating and database handling.

In order to better understand the technical idea of the present invention, a general approach to basic network configuration and a consideration thereof are required.

In general, networks may be classified as having a client-server (C / S) structure or a peer-to-peer (P2P) structure. In a P2P-based network, one device or network node is considered a peer, and each peer may communicate directly with each other, requiring no central network structure, and these peers also cooperate with each other to provide services and services. Since resources are shared with each other, so-called peer-groups are formed. In addition, peers can be connected to or disconnected from the network at any time, can arbitrarily join and leave the system, or can form a dynamic network because peer-groups have the property of being separated or merged. . On the other hand, the network structure of the client-server has the advantage of managing and coordinating the network in an integrated manner, which is useful not only in terms of technology but also in terms of business.

However, in the configuration of these networks, if each server and client has a different communication system or different heterogeneous devices, there is a problem in that a solution for creating a unified communication system is needed. In the case of mobile devices, it is difficult to design integrated middleware to form a sophisticated network.

POS system can be understood as a system that manages point of sale and inventory management, and manages and plans all information related to distribution by computer, minimizing the purchase of products and loss of stock, smoothing distribution and time. And cost-saving system.

However, although such a POS system itself is a dynamic network, flexibility and scalability must be considered very important, the conventional system is a client-server network between the central management system and the POS terminal, the database of each store through a central server Although it is controlled and the central server manages the clients of each store efficiently, there is a technical inefficiency in managing the clients of each store autonomously and actively. Furthermore, in today's world, the distribution network is not limited to a single item group, but the items handled are diversified. Although there is a need to expand to a network, conventional systems have been difficult to respond to such environmental changes by quickly implementing applications at low cost.

In the meantime, the present inventors have attempted to associate a client / server network model and a peer-to-peer model for a more efficient network configuration in a POS system construction. It was confirmed that the information exchange programming or solution of client / server application and peer-to-peer application is needed. At this time, the problem of re-developing a solution optimized for the required service according to the operation purpose and characteristics of each POS system has emerged. .

Furthermore, for the efficiency of the network, each peer in the network should be configured to handle the database between peers remotely. The interface between the background application and the front-end application must be implemented. There was a problem in developing a new DB Handling application.

Moreover, when each peer's device is a mobile device such as a PDA or a mobile phone, the implementation of the basic P2P concept itself was difficult, and not only the human resources required for sophisticated coding were enormously required, but also the OS in which each peer's device was operated. Because of the difficulty in standardizing the behavior of a client, it is pointed out that combining a client / server network with a P2P based POS system in a mobile environment is very difficult.

In order to solve the above problems, an object of the present invention, the communication between each component constituting the POS system, that is, the device (peer) of each store is not simply through the management server, but the device of each store has By providing the basic networking technology that various functions such as sharing or distributing existing database and free handling of database can be made between devices of each store, it implements active and flexible POS system. In this case, the central management server is configured as an equal peer. .

Through this technical purpose, a device, such as a PDA or a mobile phone, which is practically connected to a POS system, can immediately check whether the product is in stock and the amount of stock, and immediately from an inventory management PDA terminal without going through a central management server. It is intended to contribute to increasing the productivity of POS systems by reading and receiving information.

In order to achieve the above objectives, first, the need for middleware that can be independently or flexibly combined with the slim legacy solution to the large legacy solution, and secondly, most mobile devices are limited to their role as thin clients. On the other hand, given the anticipated high performance of mobile devices, the complexity and diversity of applications that are foreseen in the future require a more sophisticated development environment. Therefore, developers can easily adapt to such rapid development environment changes while adapting to the market demand level. The middleware should be developed to serve as a tool to help. Third, it is essential that the middleware is not burdened in terms of development cost in order to be applied to various applications of an independent software vendor (ISV) or system integration (SI) partner. dog The middleware has been considered that it consists of a compact structure, have a price advantage compared to the other systems having a plurality of composite structures.

Further objects of the present invention will be described below, which are intended to be in a broader scope by the means described in the claims of the present invention and the disclosure of the embodiments thereof, as well as means and combinations within the range that can be easily contemplated therefrom. It is to be noted that it will be subsumed and will correspond to the unique effects of the present invention.

In order to achieve the above object, the present invention is a peer-to-peer-based force system between the force terminal and the force server equipped with a force system application:

N (N is an integer greater than 1) peer terminals including the force terminal and the force server;

An integrated middleware component configured as a component in each peer terminal and divided into a server area including integrated service resources related to ordering / stocking / order management of a POS system and a client area performing a network connection and service request process. "X-Talk Component"); And

And a bridging server (B-Server) for assigning a unique peer ID code when the peer terminal connects to a network, and a protocol between each peer terminal is formed in an application layer.

The integrated middleware component in the POS system using the peer-to-peer based integrated middleware of the present invention is connected to the POS system application through an interface,

X-Talk P2P Connector module for transmitting and receiving data packets as a connection module between peer terminals;

A Packet Parser module for receiving a data packet through the X-Talk P2P Connector module, classifying the data packet and determining a process according to the classification;

Sync for determining the command transmission and data processing method according to the result data of the data packet classified by the Packet Parser module. Coordinator module;

An X-Talk Server module executing a request service of a peer peer terminal transmitted from the Packet Parser;

An integrated service library module including contents necessary for executing a request service of a peer peer terminal and connected to resources of the peer terminal; And

And a naming module for retrieving information of the other peer terminal through the B-Server and assigning a peer ID.

The Sync. Coordinator module decides whether to send Sync or Async.

In the case of a sync transmission, the second peer terminal waits until a response is received until a predetermined waiting time of the first peer terminal. In the case of an Async transmission, the control right is immediately transmitted without waiting after transmitting a command to the second peer terminal. It is preferable to return to the force system application of the first peer terminal.

Meanwhile, the B-Server (the first B-Server) performs authentication and management of all peers of the first force system, and the second B-Server is all peers belonging to the second force system or a heterogeneous third network. To perform authentication and management of the

Each of the B-Servers serves as a gateway to the network of the other B-Server, which represents another feature of the present invention.

In addition, in the present invention, each peer terminal of the POS system including the POS server and the POS terminal is pre-installed with an integrated middleware component having an integrated service library for ordering / stocking / order management of the POS system, and each peer terminal has a peer. A B-Server is provided to perform authentication by assigning an ID code, and the communication between each peer terminal is based on a network system made through an integrated middleware P2P connector module. As a method:

Invoking a specific method of an integrated service through an interface through a force system application of a first peer terminal that is a requesting peer;

Accessing the B-Server to obtain a peer ID of a first peer terminal;

Transmitting a request command of a specific service to a second peer terminal in which the first peer terminal is a destination peer;

The second peer terminal creating a response to the requested service through its integrated service library and transmitting the response to the first peer terminal; And

And checking the response received from the second peer terminal by the first peer terminal and notifying its force system application.

On the other hand, the configuration method of the present invention, determining whether the transmission of the request command of the specific service is a Sync transmission or Async transmission;

In the case of a sync transmission, the second peer terminal waits until a response is received until a predetermined waiting time of the first peer terminal. In the case of an Async transmission, the control right is immediately transmitted without waiting after transmitting a command to the second peer terminal. The method may further include the step of returning to the force system application of the first peer terminal.

In addition, the request command of the specific service, the first peer terminal to set the third peer terminal as the target peer, and requesting the second peer terminal to transmit the resources it has to the third peer terminal. It is considered an important embodiment in the invention.

In addition, the integrated service library is provided with a unified module for the database handling (DB Handling) between peer terminals, access to the files stored in the peers, or database upgrade, event / message transmission, file transfer,

It is preferable that the force system application of the first peer terminal selects one or more of those modularized in the integrated service library to call a specific method.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. However, after presenting a richer description of the integrated middleware of the present invention as a component embedded in all the force terminals in the POS system, the embodiment of the configuration of the force system of the present invention based on the integrated middleware will be described. Will be described. In the following description of the present invention, when it is determined that the subject matter of the present invention may be unnecessarily obscured as a matter already known to those skilled in the art, such as a known function or a known configuration, the detailed description thereof will be omitted.

1. Definition

As an important term used in the present invention, it provides a base for sharing distributed resources among heterogeneous peers including mobile devices, and integrates P2P functions and C / S models by integrating with Backoffice and modularized integrated services in components. The unique middleware of the present invention that implements the functions of the integrated server as well as the client element for each peer using libraries and integrated resources is defined as "X-Talk".

2. X-Talk Protocol

Unlike the Client-Server (C / S) system model, which secures critical resources on the server and transmits information and resources according to the client's needs, the peer-to-peer system model is basically any peer computer or device. This is a model to build in an environment where resources are distributed among the fields. Therefore, each peer device must include both client and server components. In addition, each application or service must respond and respond in real time. To this end, we established a new networking infrastructure that facilitates peer-to-peer system building on top of primitive networking.

1 shows the basic configuration of a data packet format based on the X-Talk protocol among peers. The OSI 7 Layer to Transport Layer is TCP / IP based and the actual X-Talk protocol belongs to the application layer. Basically, C / S, P2P or low-level networks are the same. However, it is appropriate to configure a basic communication channel dedicated to X-Talk separately at the application level because it is entirely application related to which model to configure the system based on.

Fig. 2 shows a packet structure of communication between X-Talk clients (applications with X-Talk components), where "Receiver" is a Peer ID for receiving data packets, "Sender" is a Peer ID for sending data packets, "Command" is a service request command, "Check Code for Command-Reply Pair" is a code for checking which command a specific packet received is a response. "Date_NuM" is the number of bytes of sub data, and "Data" is a command. Refers to the actual data involved.

X-Talk Name System, Peer ID, Peer Name

3 shows a schematic configuration for mapping X-Talk Peer ID and peer code. When an X-Talk client connects to a bridging server (hereinafter referred to as "B-Server"), a unique peer ID code mapped one-to-one to a peer ID of a unique string value is obtained from the B-Server. The mapping between Peer ID Code and Peer ID is managed by X-Talk Name System. It is used as a unique Peer ID Code in the application and the Peer ID is used inside the X-Talk client. This is similar to the domain name that can be read when transmitting data in the existing Internet application is translated into the actual IP address through this DNS.

The Peer ID Code is composed of 32 bits and each bit has the same meaning as in FIG. 4. "User Code", "Group Code", and "Class Code" are used to group multiple peer groups, and the maximum number of peers that can be expressed as "User Code" is 256, which means one Group. This group has a maximum of 4096. In addition, a group having a group code as one cell is expressed in "Class Code" and a maximum of 4096 can be used. "User Code", "Group Code", and "Class Code" may be appropriately allocated according to the size of peer group and assigned to computers and wired and wireless devices on the Internet.

2. X-Talk Component

5 shows a schematic configuration of an X-Talk component.

The X-Talk component is connected to the application (1) via the interface (2), Sync. Coordinator (3), Packet Parser (4), X-Talk Server (5), Service Library (6), Resources (7), Peer Connection Monitor (8), X-Talk Local Name System (10) and X-Talk P2P Connector (9), which is divided into a server area and a client area to perform a function, the functions in the divided areas are shown in Figure 5 "C + serial number", " S + serial number " On the other hand, the application 1 may be understood as a force system application such as a sales processing application or an ordering application that is programmed based on the characteristics of a product managed systematically and sales or inventory management.

Packet Parser (4)

All data packets coming through the X-Talk P2P Connector 9 enter the Packet Parser 4. The classification of packets determines the process to be processed and gives the process data and control. Each packet classification and an embodiment thereof is as follows.

Case 1: Data that comes as a response when a user sends a command to another peer:

When peer A sends a service request command to peer B, peer B sends the processing back to peer A. The result data enters the Packet Parser (4), and upon confirmation as Case 1, Sync. Sent to the Coordinator (3). Sync. Coordinator (3) memorizes all the commands sent by peer A, checks whether the result data from Packet Parser (4) is the result of any previously sent command, and notifies Application (1) of the result. Notify).

# Case 2: Data coming from other peers unilaterally pushed or streamed

This is the voice steaming function of X-Talk. Compressed voice data is transmitted from peer B to peer A at regular intervals. In this case, there is no specific command corresponding to the received packet. In other words, because it plays packet received by peer A unilaterally, voice is played in X-Talk Server immediately.

Case 3: data requesting a specific service from another peer

This is the case when peer B requests a specific service from peer A. This includes file transfers, event transfers, message transfers, and DB Handling. The data classified as case 3 is sent to the X-Talk Server (5), and X-Talk finds and calls the specific service requested in the Integrated Services Library (6) to separate threads within the X-Talk Server (5). Thread).

Sync. Coordinator (3)

Sync. Coordinate (3) is a part of Sync / Async processing of X-Talk command. When the command performs Sync or Async operation, it means that the application 1 is notified of the counterpart's processing result, which directly affects the application design.

In X-Talk, there are basically two types of service request commands to the peer. One is to send a command and wait for a response from the other peer (the peer that sent the command is in Block state, and you can set a time limit, so if the response does not come for a specified time, the Block state is released and Fail Notify And the other is the case of returning to the application 1 directly without waiting for the result data after transmission. The former is Sync. Called Command and the latter Async. Called Command. The former use is mainly used when there is no reason to proceed with Application (1) without receiving the result. The latter is mainly used when the application 1 waits more than necessary if the service requested by the partner peer takes a long time to complete.

The detailed process from command transmission to result data processing is as follows.

-Sync. Command

Peer A syncs service request data. Send to Coordinator (3). Coordinator (3) assigns a unique key to the command and stores it in memory. After transmitting the command packet, it waits for the result data to be classified from the packet parser 4. When the result data comes from the Packet Parser 4, it is checked whether the Key included therein exists among the keys stored before the command transmission, and then the control right is returned to the application 1. If data does not come from the Packet Parser 4 within a predetermined time, it declares time out and notifies the application 1 of fail.

Async. Command

When Peer A requests service request data, the Sync. Send to Coordinator (3). Sync. The coordinator (3) also stores the key unique to the command and the event code sent from the application (1) in memory. After sending to the peer, it returns immediately to the application 1 without waiting. After that, when the result data comes from the packet parser 4, it is checked whether the key included therein is present among the keys stored before the command transmission, and the application 1 is notified of the stored event code.

 X-Talk Server (5)

This is a process to execute the service requested by the peer. A separate processing thread is created for each service, and the result data is also returned to the request peer through the individually created channel. X-Talk Server (5) itself is an execution environment and the code corresponding to the actual service is taken from the integrated service library (6) and executed.

Service Library (6)

The integrated service library 6 of the present invention is a place that contains contents necessary when a peer serves as a server, that is, when a peer performs a service requested. This includes routines such as file information service, file transfer service, peer management service, audio / video processing, DB transaction, resources management service, message and event processing, etc. In a conventional network, each peer performs only one of the routines. In contrast, the integrated service library 6 of the present invention unifies the various services by enhancing the function as a server of each peer by integrating necessary contents, and does not require individual programming for individual services.

Resources (7)

The integrated resource 7 is all the resources that the peer can manage / control. This includes computers running peers, mobile phones, PDAs, embedded system files, databases, multimedia content, I / O peripherals, and so on.

 X-Talk Local Name System (10)

Receive peer information belonging to one B-Server from B-Server and keep it on its own. When checking the information of the other peer, search for peer information corresponding to Peer ID before checking from B-Server. to be.

X-Talk Component Interface (2)

X-Talk is implemented to have different components and interfaces according to the platform, and FIG. 6 schematically illustrates this. X-Talk components are implemented in the form of COM (Component Object Model) for Microsoft's Win 98 / NT / 2000 / XP and Pocket PC / Win CE.Net platforms. In the case of a system with resources, components were configured based on the Java 2 Platform Micro Edition (J2ME) to construct a Java Virtual Machine (Java VM) environment. The Mobile Information Device Profile (MIDP) / Connected Limited Device Configuration (CLDC) is a core element of J2ME and provides the core application functions required by mobile applications in the same form as the standard Java runtime environment.

Date Communication & Collaboration between two X-Talk peers

Describes Date Communication and Collaboration with Peer B based on Peer A. Regardless of the platform on which X-Talk runs, data communication and collaboration between peers is the same.

The basic Service Request and Reply mechanism in X-Talk is:

Referring to FIG. 7, when describing a request for a specific service or sending an event / message to peer B, that is, when peer A operates as a client, first, the method of interface (2) is called from applications (1) (S11). ). Next, Sync. Coordinator (3) obtains the Peer ID corresponding to the Peer Name designated by the application (1) by requesting the X-Talk Name System (S12), Sync. When the coordinator 3 transmits the information to the X-Talk P2P Connector 9, the X-Talk P2P Connector 9 creates an X-Talk Packet and transmits it to the designated destination Peer ID (S13). The contents of the service requested by peer A to peer B are in the command of the X-Talk Data Packet, and the related information is in the data.

Sync. Coordinator (3) has a different operation depending on whether the application (1) wants to send a sync or Async (S14). If it is a Sync transmission, it waits without ending the routine until a response is received from the destination peer. In other words, Application (1) will not be able to perform other actions until a response is received. However, if there is no response from the destination peer for a specified period of time, for example t> t _o (t _o is a predetermined wait time), control is returned to the application (1) with an error code. This Sync transfer process is used when it is necessary to check in real time whether a Message / Event transmission or a specific service request is delivered to the destination peer. On the other hand, the Asyn transmission process sends an Event / Message / Service Request to the destination peer immediately after Sync. Coordinator (3) returns control to the application (1) of the source peer A. In other words, the application 1 of the peer A can return to the control right after the call to the interface 2, and thus can perform other tasks.

8 schematically illustrates a flow of transmitting Return Event / Return Data from a destination peer B to a source peer A. FIG. After the transmitted Event / Message / Service Request arrives at the destination peer B (S21), the destination peer B transmits Return Event / Return Data to the source peer A again (S22). When peer A receives Return Event / Return Data, it checks with Check Code for Command-Reply Pair to see which Event / Message / Service Request is Return Event / Return Data (S23), and then the corresponding Application (1). A notification is made to (S24).

All of the functionalities provided by X-Talk above operate according to the flow described above, and this operating system is closely coupled with the X-Talk protocol. Hereinafter, a detailed process performed under the X-Talk protocol will be described in detail.

① Event / Message transmission

FIG. 9 shows a process for transmitting an Event / Message from the application 1 of the source peer A to the application 1 of the destination peer B. FIG.

First, the interface 2 and Sync. The process of arriving at the packet parser (4) via the coordinator (3) via the peer A's X-talk P2P connector (9) and peer B's X-talk P2P connector (9) starts from step S31 and proceeds to step S38. Is done through. Next, in the packet parser 4 of peer B, data transmission is performed in two directions. One is to notify the application of the Event / Message through the interface of the peer B (S38, S39), the other is to send a return signal that the Event / Message has arrived to the peer A (S40). Meanwhile, the return signal transmission process is finally notified to the application 1 of the peer A through S40 (S41 to S43). By using the above functions, real-time text and events can be exchanged between mobile phone, PDA, PC, and Embedded System. It is an application program that adopts them, and it can monitor and remotely monitor the status of messenger and control devices between real-time devices.

② File transfer

In order to disclose the preferred embodiment of file transfer in X-Talk, we assume three peers involved. In other words, you specify that Peer A sends specific files on Peer B to Peer C. This gives you more flexibility than FTP, which means you can only transfer files from your peer to the peer. For example, a peer device in a network with a small network bandwidth, such as a cell phone or a PDA, can control large file transfers between two other peers.

FIG. 10 illustrates a case where three peers are divided into an order peer, a source peer, and a target peer, respectively. When a peer A, an order peer, instructs peer B, a source peer, to transmit a specific file with peer C as a target, FIG. In this case, peer B actually transmits the specific file to peer C, the target peer. FIG. 11 illustrates a case in which the order peer and the source peer are the same peer, unlike the mechanism, and peer A, which commands file transfer, transfers its file to peer C, which is a target peer.

FIG. 12 illustrates the flow in which peer A in FIG. 10 instructs peer B to transfer a file of peer B to peer C in more detail (peer A: order peer, peer B: source peer, peer). C: target Peer)

In the application A of peer A, the file transfer method of interface 2 is called (S101). Interface (2) receives the file transfer call command of the Application (1) and sync it. Coordinator (3) to pass (S102), Sync. The coordinator 3 inquires of the X-Talk Name System 10 to obtain the actual Peer ID of the peer B name received from the application 1 (S103). Next, it transmits to the X-talk P2P Connector (9). The transmission method is Peer B as the source peer, requesting the file transfer service to Peer C as the target peer, and then receiving control again. Since there is a need to perform the Asyn transmission method will be (S104). When the transmission command is completed, the application 1 is notified of the completion (S105 to S105 ″).

Next, the process from peer A to peer B is initiated by transmitting a command packet (S106) to peer B's X-talk P2P connector 9 via peer A's X-talk P2P connector 9. The peer B's X-talk P2P connector 9 forwards the command packet to the Packet Parser 4 (S107), and the Packet Parser 4 checks the command included in the Packet and the X-Talk Server (5). Transfer to (S108). X-talk Server (5) calls the corresponding Service Library (6) to respond to the requested service, and Service Library (6) uses the resource (7) of its own to perform the requested work from peer A (S109). In this case, since the specific file of peer B is transmitted to peer C, peer B's X-Talk Server (5) creates a new process and enters a state to respond to another service request. In other words, the file transfer takes time until the task itself completes the transfer, so create a new process for the task and leave it there and the X-Talk Server (5) itself goes to a waiting state for service requests from other peers. . This is a method of efficiently using the peer B CPU. The newly created file transfer process transfers the file segment to peer C in the background (a file segment is file data that is broken up into large units of specific size).

In order to prepare for transmission to peer C, the peer B's X-Talk Server (5) is the Sync. Coordinator 3 is requested to transmit the file segment (S110), the Sync. Coordinator (3) will deliver the file segment to the X-Talk P2P Connector (9) (S111).

Next, the file segment enters the peer C's X-Talk P2P connector 9 via peer B's X-Talk P2P connector 9 (S112). After arriving at the Packet Parser 4 (S113), the command sent by the peer B is interpreted and sent to the X-Talk Server 5 (S114). Peer C's X-Talk Server (5) recognizes that the service request sent by Peer B should store the data sent with the command as a file in its specific directory, and calls SaveFileData from its Service Library (6). To store (S115). Peer B's X-Talk Server (5) and Peer C's X-Talk Server (5) both receive service requests from Peer A and Peer B, but their contents are different. Peer B's X-Talk Server (5) breaks the files in Peer B's directory into peer C segments sent by Peer A to Peer C. Peer C's X-Talk Server (5) sends files sent by Peer B The segment is stored in the directory specified by peer B.

If all of the file segments have been transmitted, the X-Talk Server 5 requests the Packet Parser 4 to transmit a storage completion signal to the peer B (S116), and the Packet Parser 4 receives the segment storage completion signal. To the X-Talk P2P Connector 9 (S117).

In this way, when all files are sent, Peer B sends a completion signal to Peer A. To this end, the X-Talk P2P Connector 9 of peer C first transmits the return data of the storage completion signal to the X-Talk P2P Connector 9 of peer B (S118), and the X-Talk P2P Connector of peer B ( 9) transmits it to the packet parser 4 of peer B (S119), and the packet parser 4 parses the received return data and then transmits it to its Sync. If the transfer to the Coordinator (3) (S120), Sync. Coordinator (3) checks whether the return data and the transmission command code match and transmits to the X-Talk Server (5) (S121).

Since the file is currently transmitted in segments, it is necessary to calculate whether the entire file has been transferred to peer C. Therefore, the X-Talk Server 5 returns the return data and the transfer command code through S121. After checking whether or not the match is completed, calculate whether the transfer of the corresponding file to peer C of peer B made by peer A transfer command is completed (S122). If completed, the file transfer completion signal is transmitted as return data to the X-Talk P2P Connector 9 of the peer A via the Packet Parser 4 and the X-Talk P2P Connector 9 (S123, S124, S125). Peer A's X-Talk P2P Connector 9 sends the received return data to its Sync. Transfer to Coordinator (3) (S126), Sync. The coordinator (3) checks whether the return data of the file transfer completion and the transfer command code match, acquires a Notify event code, and notifies the application 1 of the peer A of the transfer completion (S127, S128). It is over.

When peer A transfers its file to peer B, it is as if peer A tells peer A to transfer peer A's file to peer B. All transfers are the same as above. That is, order peer: A, source peer: A, target peer: B.

③ DB Access

In the area where P2P model is applied, resources are distributed evenly among various computers or devices, so each related device must have both server and client in order to utilize each other's resources. Resource refers to files held by each peer, other physical devices connected to the device, and, above all, a database, so sharing a database is an important part of the function of a peer to peer. Occupies.

Most DB's have large capacity of CPU and hard disk, but in recent years, CPU and storage devices of PDAs and mobile phones are rapidly becoming highly functional and large-capacity, so these mobile devices have their own DB. The DB Access described here means that the peers must not only be free in accessing the peer peer's DB, but also be able to provide services without affecting the work of the peer. This means that even mobile devices must implement a background service (demon process).

In Fig. 13, the functions of freely accessing and reading / modifying / inserting a database between peers are shown. Although the flow from step S131 to step S148 is not significantly different from the above embodiments of ① and ②, unlike the transmission of the file in the resource 7 of the peer of the peer, the flow is stored in the resource of the peer B through S140 and S141. Accesses and reads or modifies the database. That is, the embodiment of FIG. 13 is a flow when peer A reads data of peer B's DB or adds / delete / modifies specific data to peer B's DB. It also describes the processing of data to be processed in units of work (transaction units) rather than in units of records.

In other words, the ExecuteSQL method of Interface (2) is called from Application (1) of peer A. Sync. Coordinator (3) requests X-Talk Name System (10) to get Peer B ID. Next, the command packet is transmitted to the X-Talk P2P connector (9), and is delivered to the packet parser (4) via the peer B's X-Talk P2P connector (9), and the packet parser (4) receives the received packet. Confirm that it is a service request and pass it to the X-Talk Server (5). The X-Talk Server (5) recognizes that the request service is a SQL statement execution, and calls and executes an appropriate function among the Service Library of the Service Library (6). The execution result is the result data of the requested records and returns it to peer A.

On the other hand, in case of transaction unit data update, Application (1) bundles several SQL statements into one packet. This is because multiple SQL statements to be processed must not be processed individually, but must all be executed one-time. In other words, multiple sql statements are processed in one command of X-Talk to ensure data integrity.

3. Bridging Server

Fig. 14 shows a schematic configuration of the B-Server of the present invention, and the main configuration thereof is the Common Service Library (10), the X-Talk Gateway (20), the Manager of Peer Session Resources (40), and the Authentication Process (70). It includes.

X-Talk Gateway (20)

The B-Server forms an X-Talk Network with its peers. In order to connect to the X-Talk Network formed by another B-Server, the related B-Servers must act as a gateway to each other. In addition to the common service for its peers, the B-Server also acts as a gateway.

Manager of Peer Session Resources (40)

This element includes Shared Resources and Locking Resources. Shared resources correspond to both resources managed by the B-Server and resources belonging to each peer. When multiple peers try to use a resource belonging to a specific peer at the same time, this resource is called Shared Resources (50). At this time, it is necessary to provide a control system in order to control the peer without using polluting the shared resources in a normal procedure, which is achieved through the Locking Resources (60) included in the Manager of Peer Session Resources (40).

Common Service Library (10)

In addition to the services that can be established between peers among X-Talk services, there are services that must be composed of 1: N (N is an integer greater than 1) or N: 1. In this case, the B-server has no choice but to participate in the service. The library related to processing is the Common Service Library. This is usually the case when a particular peer is a service that sends messages or events to multiple peers at the same time.

Authentication Process (70)

To participate in X-Talk, a peer must first authenticate and connect to a B-Server. In addition to authentication, B-Server performs basic services for peers such as registering new peers and setting permission levels.

FIG. 15 schematically illustrates a structure in which heterogeneous device peers form a network via a B-Server in a network in which a C / S scheme and a P2P scheme are converged. In this structure, the B-Server performs interaction with the X-Talk Component described above.

Interaction between B-Server and X-Talk Component

All X-Talk components can be used after connecting to the B-Server. The main functions of B-Server in X-Talk network are shown in Table 1 below.

TABLE 1

1. Registration and Information Management of New X-Talk Client 2. Authentication for X-Talk connection 3. Monitor and control the status of the connected X-Talk 4. Ability to share / control resources of connected X-Talks 5. Gateway function to connect from one X-Talk network to another X-Talk network

① Registration and information management of new X-Talk client

Before using X-Talk, you must create and use an account for a new X-Talk client on the B-Server. When an account is created, detailed information related to network and accessor such as hostname, IP, OS type (platform type), shared directory, and alias is stored in the database of B-Server. It also stores information about peer groups, account permissions, and friend settings between X-Talk parties.

② Authentication for X-Talk Connection

Every X-Talk has only one X-Talk network session assigned to one X-Talk ID. That is, if an X-Talk is using a specific ID, no other X-Talk can use the same ID.

③ Monitoring and control status of connected X-Talk

B-Server can forcibly terminate the connection of X-Talk currently connected and can also restrict the use.

④ Ability to share / control resources of connected X-Talks

X-Talk network with multiple peers provides the ability to obtain the exclusive right of resource use in sharing resources with each other and release the right after use to other X-Talk. For example, if Peer A is transferring a file to Peer B, when another Peer C tries to create a file of the same name as Peer B, it needs to give Peer A permission to use it safely until the end of the transfer to Peer B. Do. As another example, when peer A is sending a sequential control signal to peer B's I / O device, peer s should be sent to peer A if the sequential control signal should not be interrupted by another peer. There must be a function to give monopoly rights to I / O, and this function is performed by the B-Server.

Peer A may register a string representing the exclusive authority with the B-Server in real time. If another peer, peer B, wants to use the resources currently used by peer A, first ask the B-Server if the resources specified by peer A are currently available. If the result of the inquiry is OK (in fact, the result of the inquiry will be sent by locking for the inquiring peer at the same time as the OK signal). If the result is not OK, it means that another peer is currently in use. do. If configured in this way, participating applications (applications including X-Talk Component) can use each peer resource securely by mutual promise, and B-Server manages this process.

⑤ Gateway function to connect from one X-Talk network to another X-Talk network

One B-Server composes one X-Talk network. Therefore, when there are multiple B-Servers, that is, when there are multiple X-Talk networks, it serves as a gateway to connect peers belonging to different X-Talk networks.

Hereinafter, embodiments of the POS system configuration based on the X-Talk network will be described.

16 shows a schematic embodiment of a POS system.

POS, the basic system of the retail business, has to deal with the work that takes place at various sites such as ordering, inventory, and order management. Sometimes it is necessary to access data from a computer or other terminal that performs a particular task. In the existing C / S environment, only one-way processing of transmitting data from the workplace to the server is possible, but on the X-Talk basis of the present invention described above, all terminals and servers are regarded as the same peer (each peer X-Talk components are built-in), which allows the server to modify or read the client's information without disrupting client tasks. This provides the opportunity to flexibly handle the work that takes place at the distribution site. For example, when a product price of a POS is to be changed immediately, the data of a server designated as one peer may be transmitted to another peer POS terminal without disturbing the work of the cashier. That means you can sell your products at new prices quickly, regardless of the cashier. In addition, orders from mobile-enabled PDAs are immediately reflected wirelessly in the POS, extending the ability to perform a wide range of jobs.

As such, the PDA or mobile phone connected to the inventory management system can immediately check the availability and inventory of the product, and can immediately read the information from the inventory management PDA terminal without going through the inventory management server, thereby improving productivity. Can be.

FIG. 17 shows an example in which the sixteenth embodiment is described in more detail from the viewpoint of one force terminal.

Devices equipped with X-Talk components all handle or exchange events / messages / files / databases desired by applications under the same conditions in real time. Details of this method are the same as those of the embodiments of FIGS. 7, 8, 9, and 12 described above. For example, retrieval of sales information, input and retrieval of inventory information, change of emergency sales, It consists of wireless ordering data, two-way voice communication, emergency message transmission, file transmission, and database replication, and the PDA (with wireless LAN or with peer) is another peer of POS system service. It is made by requesting a wireless MODEM, a merchant PC, etc., and a web server performing a function of a B-Server assigns a peer ID of the POS system and is in charge of authentication and management.

18 shows an example of a force system scenario based on X-Talk.

An embodiment of processing real-time messages / events / voice data / file data between peers, for example, when all applications need to know the table occupancy status in real time, a peer having all X-Talk components embedded after order processing in a PDA POS terminal. Sends an order occurrence event of "SendAllUserEventWithMsg (1000," Table is occupied "...)" to the X-Talk component of the peer that received the event and notifies the corresponding application, and monitors the terminal running the application. The table occupancy status is displayed on the screen. Recognizing this, the user of the peer transmits a real-time message / event corresponding to the order to the corresponding PDA POS terminal requesting the order according to a predetermined application procedure to create a real-time communication.

As an embodiment for urgently determining the selling price of the current terminal, a specific database command for urgently changing the selling price from the terminal (Peer A) of the headquarters manager of the POS system to the database server (Peer B) is transmitted to all terminals (Peer) in the Background Process. Command to send to the database of X-Talk component of C), "ExecuteCommand2_Ex1 (" My-DB "," My POS1 ", ...), ExecuteCommand2_Ex1 (" My-DB "," My MOS1 ", ... ), ... ", When the transfer is completed, the order peer is notified of the transfer completion event, and the source peer is notified of the database change completion event. The detailed procedure is as described in the X-Talk process of FIG.

In order to send a remotely upgraded POS system application or to examine the status of a particular peer, the peer is accessed remotely. For example, each peer terminal in the application of the headquarters manager peer, "My Pos1, My Pos2, ..., DBs of applications such as My Mos (Mobile Ordering System) 1, My Mos 2, ..., "can be accessed, which is the same as the procedure described in the embodiment of FIG.

On the other hand, the network between each peer of each of the above POS systems gives a peer ID as an authentication procedure for peer connection in the B-Server, and the B-Server monitors or controls the status of X-Talk of the connected POS system. Done.

19 shows a schematic configuration of an embodiment in which another force system is connected and extended.

B-Server 1, which performs authentication and management of POS System for distribution network A, and B-Server 2, which performs authentication and management of POS System for distribution network B, are interconnected. The peer to peer network has the configuration of FIGS. 16 to 18. At this time, B-Server 1 and B-Server 2 form an X-Talk network with peers belonging to it, and serve as a gateway for each network, thereby expanding the network of the POS system. This network is easy to expand because the X-Talk component, which is the underlying integrated middleware, is installed on all peers forming the network even though the POS system applications are different from each other, forming the same X-Talk protocol.

The above embodiments are merely for illustrating the present invention, and the protection scope of the present invention is not limited by these embodiments.

As described in detail above, according to the present invention, each POS terminal or server of the store constituting the POS system is configured as the same peer, by embedding the same integrated middleware component in each peer to form the same protocol The sharing of resources owned by each peer is smooth, and free handling of each resource (database) is possible, making it possible to construct a more flexible and effective force system.

For example, a message chat is possible between each POS terminal, and communication of inventory information can be actively performed between stores while sharing real-time store status, while determining emergency selling price in real time and remotely executing POS terminal of another store. Providing a system that can easily upgrade the database remotely has the advantage of increasing the productivity of the POS system.

In addition, even if the application of the force system itself is different, since the integrated middleware formed in the lower layer of the application forms the same protocol, there is a useful effect that can easily implement the expansion of the network between a plurality of force systems.

In addition, the unique effects generated by the peculiar constitution of the present invention can be easily estimated in the range described in the constitution of the present invention, and the effect of the present invention is not only the matters described in the above-described embodiments and claims of the present invention, but these It is noted that it will be encompassed by a wider range of potential effects that may occur within a range that can be easily drafted from, and potential advantages that contribute to industrial development.

Claims (8)

A POS system application for ordering / inventory / order management is installed on a POS terminal and a POS server, and is a peer-to-peer based POS system between a POS terminal and a POS server: N (N is an integer greater than 1) peer terminals including the force terminal and the force server; An integrated middleware component configured as a component in each peer terminal and divided into a server area including an integrated service resource related to ordering / stocking / order management of a POS system and a client area performing a network connection and service request process. ("X-Talk Component"); And Bridging server for assigning a unique peer ID code when the peer terminal is connected to the network; including, a protocol between each peer terminal is formed in the application layer, the POS system using a peer-to-peer-based integrated middleware The method of claim 1, The integrated middleware component is connected to the POS system application through an interface, An X-Talk P2P connector module for transmitting and receiving data packets as a connection module between peer terminals; A Packet Parser module for receiving a data packet through the X-Talk P2P Connector module, classifying the data packet and determining a process according to the classification; Sync for determining the command transmission and data processing method according to the result data of the data packet classified by the Packet Parser module. Coordinator module; An X-Talk Server module executing a request service of a peer peer terminal transmitted from the Packet Parser; An integrated service library module including contents necessary for executing a request service of a peer peer terminal and connected to resources of the peer terminal; And And a naming module for retrieving information of a counterpart peer terminal through the bridging server and assigning a peer ID to the peer system. The method of claim 2, Sync. Coordinator module decides whether to send Sync or Async. In the case of a sync transmission, the second peer terminal waits until a response is received until a predetermined waiting time of the first peer terminal. In the case of an Async transmission, the control right is immediately transmitted without waiting after transmitting a command to the second peer terminal. Force system using peer-to-peer based integrated middleware to return to the force system application of the first peer terminal. The method of claim 1, The bridging server performs authentication and management of all peers of the first force system as a first bridging server, and another bridging server belongs to a second force system or a heterogeneous third network as a second bridging server. If all peers are authenticated and managed, and if they are connected to each other, The bridging servers each act as a gateway to a network of the other bridging server, a force system using peer-to-peer based integrated middleware. Each peer terminal of the POS system including a POS server and a POS terminal is pre-installed with an integrated middleware component having an integrated service library, and is provided with a bridging server for assigning a peer ID code to each peer terminal and performing authentication. As a method for configuring a POS system on a peer-to-peer basis, based on a network system where peer-to-peer communication is performed through an integrated middleware P2P connector module: Invoking a specific method of an integrated service relating to ordering / stocking / order management of the POS system via an interface through a POS system application of a first peer terminal that is the requesting peer; Accessing the bridging server to obtain a peer ID of a first peer terminal; Transmitting a request command of a specific service to a second peer terminal in which the first peer terminal is a destination peer; The second peer terminal creating a response to the requested service through its integrated service library and transmitting the response to the first peer terminal; And And checking, by the first peer terminal, a response received from the second peer terminal, and notifying its force system application of the peer system to peer-to-peer based integrated middleware. The method of claim 5, Determining whether the transmission of the request command of the specific service is a Sync transmission or an Async transmission; And In the case of a sync transmission, the second peer terminal waits until a response is received until a predetermined waiting time of the first peer terminal. In the case of an Async transmission, the control right is immediately transmitted without waiting after transmitting a command to the second peer terminal. Returning to the force system application of the first peer terminal, further comprising the step of configuring a force system using peer-to-peer based integrated middleware. The method of claim 5, The request command for the specific service is that the first peer terminal sets the third peer terminal as the target peer, and requests the second peer terminal to transmit its own resources to the third peer terminal. A method of configuring POS system using two peer-based integrated middleware. The method according to any one of claims 5 to 7, The integrated service library is provided with unified modules for database handling (DB Handling) between peer terminals, access to files stored in peers, or database upgrade, event / message transfer, and file transfer. A method for configuring a POS system using peer-to-peer-based integrated middleware, wherein the POS system application of the first peer terminal selects one or more modules modularized in the integrated service library and calls a specific method.

Images