TW201617866A - Method for providing fault-tolerant software as service platform - Google Patents

Abstract

The present invention relates to a development method of a software system, more particularly to a method for providing a fault-tolerant software as a service platform. Through this method, the message transmission pathway is independent of its messaging route, and can be dynamically determined on the basis of the availability of network and nodes of the paths. When a connection to a software service node is temporarily unavailable, the routing manager of message broadcast can immediately determine alternate pathways for messaging to the next node until it finds an available route. Therefore, messages can be passed through different paths, and transmitted via any combination of existing service nodes or software service nodes. This invention has two main benefits: the first one is to reduce the loss of business opportunities due to unexpected software system failures and lower the cost of hardware equipment used for the prevention of software system failure; the second one is to increase the code sharing cooperation between organizations, which can shorten the system development cycle so as to allow software product designers to focus on the software system development process that meets business needs.

Description

Provide a way to use fault tolerant software as a service platform

The present invention provides a method for a fault tolerant software as a service platform, a service node or a plurality of service nodes connecting or receiving connections from a software service node. A service node is a software that provides the ability to interact with multiple software service nodes; a software service node is a software that processes a series of computer code to complete the service request service; based on the characteristics of the design software service node, the software The service node has all or part of the service request; a few software service nodes complete the service request of the service node according to the design features of the plurality of software service nodes; one software service node or multiple software service nodes, or one service node or multiple service nodes, may be composed Service node group; a service node group or a service node group s can provide load balancing and fault tolerance in multiple software service nodes by grouping multiple software service nodes; one domain or multiple domains complete knowledge by name Identification. A domain consists of multiple service nodes, multiple software service nodes, and multiple service node groups; Each service node in a domain has a unique name; each software service node within a domain has a unique name; each service node group within a domain has a unique name; each domain has a unique name A unique name; an in-domain software service node universal unique name is associated with a functional variable name, a service node group name and a software service node name have a corresponding order; a domain service node universal unique name is associated with a functional variable name, Service node names have a corresponding order.

The software system platform is the basis for the development of software solutions. Traditionally, the system is designed to perform system file analysis based on module functionality through modular computer code. Modern technologies developed by the system include not only function-based modular computer code, but also classes that encapsulate computer code into business code writing and behavior definitions. In the future, users can form a computer object from the class and from the class for personal application. Under the large-scale system deployment, it usually requires a larger hardware investment than the traditional system development method. This is because the data and computer code are mixed in the computer object. This is the same thing that needs to be deployed to execute on the same platform or server system. Related objects usually need to be deployed on the same platform or server system to work together.

In addition, systems under modern system development technology usually implement software fault tolerance through hardware redundancy and backup mechanisms. For mission-critical enterprises Owners of the industry, such as ISPs or telecom operators, can experience a million to one billion business losses in the event of a single point of failure, whether it is a software system or a hardware system. While hardware fault tolerance can be achieved by hardware hardware and data mirroring to replicate hardware devices and data, fault tolerant software systems need to fulfill the needs of mission-critical enterprises. Therefore, there is a need for a way to provide fault-tolerant software system development that allows for a single point of failure in a software system. There is also a need for a way to make fault-tolerant software systems accessible from domestic or international networks over local or wide-area networks.

Often, software systems under modern system development techniques Development requires customers to install a set of features on the customer's computer system, ignoring other additional features of the user's use of such software. This will further enhance the ongoing operations, maintenance and support costs passed on to customers. In addition, during the implementation of the system, the software system developed according to modern technology needs to develop and deploy software for a long time, and the realization of the customized system is caused by the standardization process in the business world. Time and effort.

Therefore, to solve the previous problems, we need to enable users to A method of installing the functionality required by a software system on a computer system that allows the client to further access the software system for further enhancement.

The present invention provides a fault tolerant software as a service platform. In the described example, the fault tolerant software serves as a service platform, including multiple nodes and functional requirements interfaces, and includes seven types of elements: - service node; - software service node; - service node group; - connection; - domain; - database; - service plan

Operationally, a service node can issue a service request to a node of a software service. Each service request consists of a series of service flow form processing steps, which are defined in the service plan. The service plan defines a set of interrelated software service node processing steps to complete the service request type. Multiple software service nodes can be grouped by one service node group, and one service node group can include multiple software service nodes. The connection between the nodes is controlled by an access control device, for example, an account record. Once access is granted, a connection can be established between the software service node, the service node, the service node group, and the repository.

The messaging route is a messaging route that is independent of it and can be dynamically determined based on the availability of the network and the nodes on the path. For example, when a connection to a software service node is temporarily unavailable, the routing manager issuing the message can immediately determine the alternate route for message delivery to the next node until an available route is discovered. Therefore, messages can be passed through different paths, through any combination of existing service nodes or software service nodes. Such an architecture as an advantage of the present invention is capable of eliminating faults by enabling software fault tolerant software Customer concerns.

The first benefit of the present invention is to reduce the opportunity for business loss due to an unexpected software system failure and the cost of hardware devices for preventing software system failure.

A second benefit of the present invention is the increased code sharing cooperation between organizations. An additional benefit from the second point is the shortened system development cycle, which allows software product designers to focus on the development of software systems for business needs.

30‧‧‧ The method of the present invention provides a functional architecture diagram of a fault tolerant software as a service platform

31‧‧‧ Domain A

32‧‧‧ Domain B

33‧‧‧ Domain C

53‧‧‧Connection Administrator

54‧‧‧Route Manager

55‧‧‧Access Control Manager

56‧‧‧Interface Manager

57‧‧‧Error Recovery Manager

Figure 1 is a typical sequence of service processes, such as a service flow diagram of a software being processed as a service platform.

Figure 2 is a functional architecture diagram showing the provision of fault tolerant software as a service platform in accordance with the method of the present invention.

Figure 3 is a block diagram showing the method of connecting a set of software service nodes from a software service node outside the group through a comprehensive connection path in the domain using the method of Figure 2.

Figure 4 is a block diagram showing the method of connecting a set of software service nodes from an out-of-group service through a comprehensive connection path in the domain using the method of Figure 2.

Figure 5 is a block diagram showing the components included in the service node in accordance with the present invention.

Figure 6 and Figure 7 show the method of Figure 2, through the full connection in the domain A method block diagram that connects a set of software service nodes from another set of software service nodes.

Figure 8 and Figure 9 show a block diagram of a method for connecting a group of software service nodes of a domain from another set of software service nodes through a comprehensive connection path in the domain using the method of Figure 2.

Figure 10 is a block diagram showing the method of monitoring the service of a software service node connected from one domain to another using the method of Figure 2.

Figure 11 is a block diagram showing the method of using the protocol of the connection and the software as a service platform by the method of Fig. 2.

Figure 12 is a block diagram showing a fault tolerant filing method in accordance with the present invention.

Figure 13 is a block diagram showing the method of using fault tolerant software as a service platform in a managed service environment in accordance with the present invention.

Figure 14 is a block diagram showing the method of using fault tolerant software as a service platform in a call center environment in accordance with the present invention.

Embodiments of the present invention will be described below in conjunction with the drawings.

Figure 1 is a diagram of a service flow, by way of example, a typical service process sequence 20, as a processing software, a service platform. According to each service request 21, the service request will first be classified by the service type and dispatched to the software service node according to the business scenario 22. The requested service can be routed to the target software service node through a plurality of software service nodes when the service request satisfies 23 before. When the service request is satisfied, the service request will be terminated through a series of steps in the service completion 24 including the necessary logs for the service request and a series of termination steps.

Figure 2 is an example showing the system architecture 30 for Fault-tolerant software as a block diagram of the service platform. A service node 37 is a piece of software that provides the ability for multiple software service nodes 44 and 45 to interact. A service can issue a request or receive a result from a software service node or software service node 44. Software service node 44 is a piece of software that provides the ability to connect to other software service nodes or nodes of software services. The software service node 44 has a connection manager 53, a routing manager 54, an access control manager 55, a configuration manager 56, and an error recovery manager. The software service node can route the service request to the appropriate node through the routing manager 54 through the service manager 53, and verify the access authority of the service request. The access control allows connection or rejection through the access control manager 55. connection. The service request is provided by the configuration manager 56, an error is detected, and an instant is recovered from the error by the error recovery manager 57.

Each service and software service node has in the domain it is in The only name. The A field 31 is a combination of an individual or a service name and/or a name of a software service node and/or a node group name of a service. Each domain has a unique name. One or more software service nodes can be grouped into one service node group 34. The names within a domain must be unique. Although the function variable name is unique, a software service node name and the connected service node group name and Functional variable names are universally unique.

Thus, a domain can have any combination of service nodes or service nodes, multiple nodes of a software service node or software service, a service node group or multiple service node groups and domains or multiple domains. Examples of combinations in a domain are listed below. The elements within the domain may be a combination of any of the following or a combination of more or lesser complexity. For example: d1: {S1, S2, D3}; d2: {S1, SSN1}; d3: {S1}; d4: {S1, SSN1, SNG1}; d5: {SNG1}; d6: {SNG1, SNG2, SSN1 }.

d represents the field, with a number next to it representing the name of the unique function variable. S represents the service node with a digit on the side that represents the unique service node name. Represents a field with a number next to it that represents the unique function variable name. The SSN represents a software service node with a digit on the side that represents the name of the unique software node. SNG represents a service node group with a digit on the side that represents the name of the unique software node group. Software service nodes or software service nodes 46, 47, 48 may reside in a service node group 34. The software service node can connect to other service node groups in which the software service node is located in the same domain, as shown in Figure 3. The software service node 51, 52 resident service node group 36 can be connected to the software service node 49 and the service node 50, the service node group 35 of the domain B33. Software service node 51, 52 station The staying service node group 36 can be connected to the software service node 49, and the service node 50, the service node group 35 of the domain B33.

Software service nodes can also be connected to other areas of software Service node, as shown in Figure 3. The software service node 49, 50 resides 35 domain B33 can be connected to the software service node 46, 47, 48 resident 34 domain A35. A service node can be a message transmission between two or more software service nodes. As shown in Figure 3. The service node 42 is a message transmission of the software service nodes 51 and 52 and the service node 36 group of the domain B 33. Once the appropriate access rights are granted and verified during access, the accessibility of the cross-domain software service nodes is taken for granted. Service node 41 can simply pass the results or send a message between the software service nodes. A service node group can contain as many software service nodes as possible. The software service node resides in a group of service nodes that are interconnected. Therefore, the software service node can back up other software service nodes that reside in the same service node group. Under this system structure, load balancing and redundancy of software service nodes are realized.

Figure 3 is an example showing that they are not combined into a service node. A block diagram of the connection between a group and a software service node that resides in a service domain group software service node in the same domain. Once the access rights are verified and authorized by the connection requester of the software service node, the connection between the software service nodes is automatically established. Access to a software service node is based on a pre-defined script that is stored in one or more databases. Each connection request made by the node of the service node and/or the software service is granted access to authenticate the account ID. Before the patent. In FIG. 3, the software service node 44 is connected to a service node group 34 and is automatically connected to the service node group 35 where each software service node 46, 47, 48 is located. If the connection between the software service node 45 and the service node group 34 is established, the software service node 45 can also be connected to the group of service nodes 34 where each of the software service nodes 46, 47, 48 is located. Therefore, once the connection is authorized, a software service node allows access from the software service node or software service node.

Figure 4 is an example showing a block diagram of the connection between a service node or a service node and an in-domain software service node or software service node. Once the access rights are granted and granted and verified, the connection between the software service node service node or the service node and the software service node or software service node is automatically established. Access rights are based on a predefined script that is stored in one or more repositories. Each access request made by the service node and the software service node is authenticated before the access to the account ID is granted. In Figure 4, the service node 39 is connected to a service node group 34, which is automatically connected to the service node group 34 where each software service node 46, 47, 48 is located. If a connection is established between the service node 40 and the service node 34 group, the service node 40 can also be connected to the service node group 34 where each of the software service nodes 46, 47, 48 is located. Therefore, once the connection is authorized, a software service node allows access from the software service node or software service node.

Figure 5 is a block, Figure 6, Figure 0, showing that the component resides on a service node. A service node is a piece of software that provides multiples as shown in Figure 2. The ability of software service nodes to interact. A service node consists of three component business rule elements 61 implemented in the computer code business rules; a connection manager component 62 responsible for connecting the software service nodes; and a routing manager component 63 responsible for determining the destined nodes and routing paths.

Figure 6 and Figure 7 show examples of those belonging to different suits A connection between software client nodes in the same domain. The software service node can connect to other service node groups where the software service nodes reside in the same domain. For example, in FIG. 6, the software service node 51 in the service node group 36 can connect all the service node groups S and S35 of the software service nodes 49 and 50 in the same domain B33. In FIG. 7, the software service node 52 resident service node group 36 can be connected to all of the software service nodes 49 and 50 service node groups SNG 235 in the same domain B33.

Diagrams of Figures 8 and 9 showing those belonging to different domains The connection between the different service node group software service nodes. For example, in Figure 8, the software service node 49 resides in the domain B33. The service node group SNG 235 can be connected to all of the software service nodes 46, 47, 48 to host the service node group 34 of the domain A31. For example, in Figure 9, the software service node 50 resides in the service node group 35. The domain B33 can be connected to all of the software service nodes 46, 47, 48 to host the service node group 34 of the domain A31.

For example, Figure 1, Figure 0, shows a software service node that can be accessed from a monitoring service node in one domain to another. For example, once the connection between the monitoring service node 43 and the service node group 35 is established, for example, the monitoring service 43 The software service nodes 49 and 50 accessible by the domain C32 reside in the service node group 35 domain B33. Once the access rights are verified and authorized by the connection recipient of the software service node, the remote service node or the remote service node and the remote software service node or the remote software service node automatically establish a connection. Access rights are based on a predefined script that is stored in one or more repositories. Each connection request is made by the remote service node before the access to verify the account ID is granted a patent.

Fig. 1 shows a fault tolerant software used in the connection protocol 71 as a service platform in accordance with the present invention. For example, the connection between the service node and the software service node, and the connection between the software service nodes 72, is the basis of the computer network. The network communication protocol includes: the communication network communication protocol for service to service in the present invention is UDP, RTP, TCP and/or SIP. The network protocols used to communicate information are IP, TCP, UDP, and/or SCTP. The network protocol used to control messaging is TCP, SIP streaming or message based, and/or vendor specific.

In Figure 1, the message transfer between the service node and the software service node is based on the above network protocol. By way of example, a service plan completion service request is defined as primarily through 5 steps. The steps in the example of FIG. 1 include: S11 73, a service node capable of issuing a service request to the software service node SSN11 77; SSN11 77, a software service node, can complete part of the service request, and then pass the processing service request to the software service node SSN12 78; SSN12 78, a software service node, can complete part of the service request, and then pass The service request is processed to the software service node SSN13 79. Meanwhile, the SSN 12 78 can receive a service request from S13 74; SSN 13 79, a software service node, can complete the last part of the service request and display the processing result S12 76 of the service node. Meanwhile, the SSN 13 79 can receive the service request from S15 77 and issue The service request is sent to the service node S14 75.S12 76, and the result of the service request is displayed on the display. Service request close

The service request is completed by sending the data to S12 76. The service S11 73 issues a service request to the SSN 11 77, and the SSN 11 77 processes the service request, but since the SSN 11 77 only completes part of the service request, the SSN 11 77 is then passed to the SSN 12 78 for further processing via the computer network according to a pre-defined scheme. Request for service. The service request from the SSN 11 77 is first verified, and the access rights to the original service request account are subsequently verified. In this example, the S11 73.SSN 12 78 receives the service request from the SSN 11 77. The service manager of SSN 12 78 satisfies a portion of the service request, and the connection manager of SSN 12 78 connects to SSN 13 79 via an instruction issued by Route Manager SSN12 78. The routing manager determines the route based on a predefined service plan. Service node S13 74 can be connected to SSN 12 78 for service. SSN 13 79 receives the service request from SSN 12 78 and completes the service request. The service request result is passed to S12 76 for display according to a predefined service plan. SSN13 79 can receive a service request live transmission from S15 77 Request to S14 74. The service request was sent, transmitted and completed on the computer network.

Figure 1 and Figure 2 show how to use the system architecture of the present invention 80 It is now fault tolerant. For example, service node S16 81 connects each of software service nodes SSN 14 84, SSN 15 85, and SSN 16 86 to camp service node group SNG 4 83. Each software service node resident service node group SNG4 83 is internally connected. For example, service node S16 81 issues a service request and a service request will be completed through cooperation between the steps of a series of software service nodes. The system architecture of the fault tolerant software as a service allows the service node or multiple service nodes and/or software service nodes or multiple software service nodes to connect to the service node group based on appropriate access control. Once the connection between the service node and the service node group is established and/or the connection between the software service node and the service node group is established. A service node or a plurality of service nodes or software service nodes or a plurality of software service nodes may automatically connect to a service node group where each software service node resides. Therefore, once the connection of the service node S16 81 and the service node group SNG4 83 is established, the service node S16 81 can be connected to each software service node SSN14 84, and SSN 15 85 and SSN 16 86 are individually connected by 87, 89 and 91. Similarly, once the software service node SSN17 82 and the service node group SNG4 83 are connected, the software service node SSN17 82 can connect to each software service node SSN14 84, the SSN 15 85 and the SSN 16 86 resident service node group SNG4 83 through 88, 90, and 92 separate connections.

Through the example in the first 2nd figure, how to describe in detail Fault tolerance is achieved in the invention. The service node S16 81 issues a service request to the service according to a predefined service plan, which will be completed by the software service node SSN17 82 through different routing paths: Route A: After the service request is sent at S16 81, the service The request can be made to connect to the software service node SSN 14 84 via connection 87 and then to the software service node SSN 17 82 from the software service node SSN 14 84 by connection; route B: after the service request is sent at S16 81, the service request can be connected via connection 89 The software service node SSN 15 85 is satisfied and then connected from the software service node SSN 15 85 to the software service node SSN 17 82 via the connection 90; Route C: After the service request is sent in S16 81, the service request can be connected to the software service node SSN 16 via the connection 91. 86 is satisfied and then connected from the software service node SSN16 86 to the software service node SSN17 82 via connection 92; the routing manager S16 81 determines the target node for the service request according to a predefined service plan and decides to adopt route A as the service request.

Assume that connection 87 is the downtime of the next plan and the service node S16 81 is attempting to transmit a service request to the software service node SSN14 84, and the connection manager S16 81 discovers the network downtime and notifies the routing manager. The route manager receives the notification and determines the alternate routing path, in this case routing B as the service request. Service node S16 81 uses route B to send the service request again. After the service request is sent at S16 81, the service request can be satisfied by connecting to service node SSN 15 85 via connection 89, and then connected to SSN 17 82 from software service node SSN 15 85 via connection 90.

If the software service node is between SSN15 85 and SSN17 82 The connection 90 is also temporarily shut down and the SSN 15 85 attempts to deliver the service request and passes the processing result to the SSN 17 82. The error recovery manager SSN 15 85 can find another alternate routing service request and processing result to the SSN 17 82.

In this case, the error recovery manager SSN15 85 may decide to pass The SSN 16 86 passes the service request and the processing result to the SSN 17 82. The error recovery manager looks for the first available node to deliver the message. Therefore, the final routing path for the service request can be as follows: a service request is sent from service node S16 81; connected to software service node SSN15 85 via connection 89; connection 90 is down and thus connected to software service node SSN16 86; software service Node SSN 16 86, connected to software service node SSN 17 82 via connection 92; service is completed at SSN 17 82.

The invention also provides cross-domain messaging for multiple service nodes and/or multiple software service nodes.

Each element of the invention has a globally unique name. The universally unique name of each element allows the routing manager to identify each element in time.

Figure 13 is an illustration of an application that uses fault-tolerant software as a service platform to host a service business. The application explains the benefits of cooperating, operating, and fault-tolerant software-as-a-service platforms implementing managed services. In the first and third figures, there are three companies, X company, bank Y and research institute. X company is an enterprise Industry application development company. It develops a software system and allows bank Y to access the software system remotely through the software service node SSN30 106. The users C10 110, C20 111, and C30 112 of the bank Y 103 are connected to the software service node SSN 30 106 to access the software system located in the X company domain 101. In the X company domain, the software service node SSN20 104 software service node SSN30 79 interfaces and delivers the service request of the bank Y user to the corresponding software service node SSN20 104. For example, the services provided by Company X are real-time quote service for stocks, company briefing consulting services and reporting services. The stock real-time quote service is provided through service node S30 107, which can provide an instant stock quote upon request. The company profile consulting service is provided through the service S40 108, which provides corporate information such as management teams, organizations, production lines and target markets.

Provides reporting services via S50 109, which provides the required information A system within the company's X domain, such as a software system for traffic reports, a system usage report, a system performance report, or an account data report. The Y user of the bank can access the software system by logging in to the system for his/her desktop software, then the account information will be passed to the access control system to provide account verification in the X company's access control system, and the available functions check the authority of the registrant and The account management system performs traffic monitoring. Account information is stored in the customer database 113. The Reporting Service can access the customer database and retrieve the information needed for the analysis based on the user's request.

The Institute 102 provides stock history information to customers. Institute The software development staff learned that Company X provides company profiles and information stocks to customers in real time. Therefore, the software development staff of the institute decided to use the service of company X. To minimize their software development efforts. At the Institute, the software developer wrote a program, the software service node SSN40 105, which interfaces with the company X's software service node SSN20 104. After the connection between the two software service nodes is established, the software development staff of the institute can immediately access the stock real-time quote service, company profile service and report service. After receiving the required information, the Institute's software development staff can store it in its database 114 or consolidate the collected data and provide analytical data to the client. The system infrastructure of the present invention improves system development efficiency between organizations.

Figure 1 is a schematic diagram of a service flow, by way of example, A sequence of service processes 20, as a processing software, ie a service platform. According to each service request 21, the service request will first be classified by the service type and dispatched to the software service node according to the business scenario 22. The requested service can be routed to the target software service node through a plurality of software service nodes before the service request satisfies 23. When the service request is satisfied, the service request will be terminated through a series of steps in the service completion 24 including the necessary logs for the service request and a series of termination steps.

Figure 2 is an example showing the system architecture 30 for Fault-tolerant software as a block diagram of the service platform. A service node 37 is a piece of software that provides the ability for multiple software service nodes 44 and 45 to interact. A service can issue a request or receive a result from a software service node or software service node 44. Software service node 44 is a piece of software that provides the ability to connect to other software service nodes or nodes of software services. Software service node 44 There is a connection manager 53, a routing manager 54, an access control manager 55, a configuration manager 56 and an error recovery manager. The software service node can route the service request to the appropriate node through the routing manager 54 through the service manager 53, and verify the access authority of the service request. The access control allows connection or rejection through the access control manager 55. connection. The service request is provided by the configuration manager 56, an error is detected, and an instant is recovered from the error by the error recovery manager 57.

Each service and software service node has in the domain it is in The only name. The A field 31 is a combination of an individual or a service name and/or a name of a software service node and/or a node group name of a service. Each domain has a unique name. One or more software service nodes can be grouped into one service node group 34. The names within a domain must be unique. Although the function variable name is unique, a software service node name is universally unique with the connected service node group name and function variable name.

Therefore, a domain can have any group of service nodes or service nodes Multiple nodes of a software service node or software service, a service node group or multiple service node groups and domains or multiple domains. Examples of combinations in a domain are listed below. The elements within the domain may be a combination of any of the following or a combination of more or lesser complexity. For example: d1: {S1, S2, D3}; d2: {S1, SSN1}; d3: {S1}; D4: {S1, SSN1, SNG1}; d5: {SNG1}; d6: {SNG1, SNG2, SSN1}.

d represents the field, with a number next to it representing the name of the unique function variable. S represents the service node with a digit on the side that represents the unique service node name. Represents a field with a number next to it that represents the unique function variable name. The SSN represents a software service node with a digit on the side that represents the name of the unique software node. SNG represents a service node group with a digit on the side that represents the name of the unique software node group. Software service nodes or software service nodes 46, 47, 48 may reside in a service node group 34. The software service node can connect to other service node groups in which the software service node is located in the same domain, as shown in Figure 3. The software service node 51, 52 resident service node group 36 can be connected to the software service node 49 and the service node 50, the service node group 35 of the domain B33. The software service node 51, 52 resident service node group 36 can be connected to the software service node 49, and the service node 50, the service node group 35 of the domain B33.

Software service nodes can also connect to software service nodes in other domains, as shown in Figure 3. The software service node 49, 50 resides 35 domain B33 can be connected to the software service node 46, 47, 48 resident 34 domain A35. A service node can be a message transmission between two or more software service nodes. As shown in Figure 3. The service node 42 is a message transmission of the software service nodes 51 and 52 and the service node 36 group of the domain B 33. Once the appropriate access rights are granted and verified during access, the accessibility of the cross-domain software service nodes is taken for granted. clothes The service node 41 can simply pass the results or send a message between the software service nodes. A service node group can contain as many software service nodes as possible. The software service node resides in a group of service nodes that are interconnected. Therefore, the software service node can back up other software service nodes that reside in the same service node group. Under this system structure, load balancing and redundancy of software service nodes are realized.

Figure 3 is an example showing that they are not combined into a service node. A block diagram of the connection between a group and a software service node that resides in a service domain group software service node in the same domain. Once the access rights are verified and authorized by the connection requester of the software service node, the connection between the software service nodes is automatically established. Access to a software service node is based on a pre-defined script that is stored in one or more databases. Each connection request made by the node of the service node and/or the software service is granted before the access to authenticate the account ID is granted. In FIG. 3, the software service node 44 is connected to a service node group 34 and is automatically connected to the service node group 35 where each software service node 46, 47, 48 is located. If the connection between the software service node 45 and the service node group 34 is established, the software service node 45 can also be connected to the group of service nodes 34 where each of the software service nodes 46, 47, 48 is located. Therefore, once the connection is authorized, a software service node allows access from the software service node or software service node.

Figure 4 is an example showing a block diagram of the connection between a service node or a service node and an in-domain software service node or software service node. Once the access rights are granted and granted and verified, the connection between the software service node service node or the service node and the software service node or software service node is automatically established. Access rights are based on a predefined script that is stored in one or more repositories. Each access request made by the service node and the software service node is authenticated before the access to the account ID is granted. In Figure 4, the service node 39 is connected to a service node group 34, which is automatically connected to the service node group 34 where each software service node 46, 47, 48 is located. If a connection is established between the service node 40 and the service node 34 group, the service node 40 can also be connected to the service node group 34 where each of the software service nodes 46, 47, 48 is located. Therefore, once the connection is authorized, a software service node allows access from the software service node or software service node.

Figure 5 is a box, Figure 6, Figure 0, showing that the component resides in a Service nodes. A service node is a piece of software that provides the ability to interact with multiple software service nodes as shown in Figure 2. A service node contains three components: the business rules component 61 implements the business rules in the computer code; the connection administrator component 62, which is responsible for connecting the software service nodes; and the routing manager component 63, which is responsible for determining the destined nodes and routing paths.

Figure 6 and Figure 7 show examples of those belonging to different suits A connection between software client nodes in the same domain. The software service node can connect to other service node groups where the software service nodes reside in the same domain. For example, in FIG. 6, the software service node 51 in the service node group 36 can connect all the software service nodes 49 and 50 in the same domain B33. Node group SNG335. In FIG. 7, the software service node 52 resident service node group 36 can be connected to all of the software service nodes 49 and 50 service node groups SNG 235 in the same domain B33.

Diagrams of Figures 8 and 9 showing those belonging to different domains The connection between the different service node group software service nodes. For example, in Figure 8, the software service node 49 resides in the domain B33. The service node group SNG 235 can be connected to all of the software service nodes 46, 47, 48 to host the service node group 34 of the domain A31. For example, in Figure 9, the software service node 50 resides in the service node group 35. The domain B33 can be connected to all of the software service nodes 46, 47, 48 to host the service node group 34 of the domain A31.

For example, Figure 1 shows the monitoring service node from a domain. You can access the software service node of another domain. For example, once the connection between the monitoring service node 43 and the service node group 35 is established, for example, the software service nodes 49 and 50 accessible by the domain C32 in which the monitoring service 43 is located resides in the service node group 35 domain B33. Once the access rights are verified and authorized by the connection recipient of the software service node, the remote service node or the remote service node and the remote software service node or the remote software service node automatically establish a connection. Access rights are based on a predefined script that is stored in one or more repositories. Each connection request is made by the remote service node before the access to verify the account ID is granted a patent.

1 shows the capacity used in the connection agreement 71 in accordance with the present invention. Wrong software as a service platform. For example, the service node and the software service node, The connection between the connections between the software service nodes 72 is the basis of the computer network. The network communication protocol includes: the communication network communication protocol for service to service in the present invention is UDP, RTP, TCP and/or SIP. The network protocols used to communicate information are IP, TCP, UDP, and/or SCTP. The network protocol used to control messaging is TCP, SIP streaming or message based, and/or vendor specific.

In Figure 1, the message transfer between the service node and the software service node is based on the above network protocol. By way of example, a service plan completion service request is defined as primarily through 5 steps. The steps in the example of Fig. 1 include: S11 73, a service node capable of issuing a service request to the software service node SSN11 77; SSN11 77, a software service node, which can complete part of the service request, and then deliver the processing service The request is made to the software service node SSN12 78; SSN 12 78, a software service node, can complete part of the service request, and then deliver the processing service request to the software service node SSN13 79. Meanwhile, the SSN 12 78 can receive a service request from S13 74; SSN 13 79, a software service node, can complete the last part of the service request and display the processing result S12 76 of the service node. Meanwhile, the SSN 13 79 can receive the service request from S15 77 and issue The service request is sent to the service node S14 75.S12 76, and the result of the service request is displayed on the display. Service request close

The service request is completed by sending the data to S12 76. The service S11 73 issues a service request to the SSN 11 77, and the SSN 11 77 processes the service request, but since the SSN 11 77 only completes part of the service request, the SSN 11 77 is then passed to the SSN 12 78 for further processing via the computer network according to a pre-defined scheme. Request for service. The service request from the SSN 11 77 is first verified, and the access rights to the original service request account are subsequently verified. In this example, the S11 73.SSN 12 78 receives the service request from the SSN 11 77. The service manager of SSN 12 78 satisfies a portion of the service request, and the connection manager of SSN 12 78 connects to SSN 13 79 via an instruction issued by Route Manager SSN12 78. The routing manager determines the route based on a predefined service plan. Service node S13 74 can be connected to SSN 12 78 for service. SSN 13 79 receives the service request from SSN 12 78 and completes the service request. The service request result is passed to S12 76 for display according to a predefined service plan. The SSN 13 79 can receive a service request from S15 77 to send a request to S14 74. The service request is sent, transmitted and completed on the computer network.

The first and second figures show how to implement fault tolerance using the system architecture of the present invention 80. For example, service node S16 81 connects each of software service nodes SSN 14 84, SSN 15 85, and SSN 16 86 to camp service node group SNG 4 83. Each software service node resident service node group SNG4 83 is internally connected. For example, service node S16 81 issues a service request and a service request will be completed through cooperation between the steps of a series of software service nodes. Fault-tolerant software-as-a-service system architecture allows service nodes or multiple service nodes and/or software services A node or multiple software service nodes are connected to a service node group based on appropriate access control. Once the connection between the service node and the service node group is established and/or the connection between the software service node and the service node group is established. A service node or a plurality of service nodes or software service nodes or a plurality of software service nodes may automatically connect to a service node group where each software service node resides. Therefore, once the connection of the service node S16 81 and the service node group SNG4 83 is established, the service node S16 81 can be connected to each software service node SSN14 84, and SSN 15 85 and SSN 16 86 are individually connected by 87, 89 and 91. Similarly, once the software service node SSN17 82 and the service node group SNG4 83 are connected, the software service node SSN17 82 can connect to each software service node SSN14 84, the SSN 15 85 and the SSN 16 86 resident service node group SNG4 83 through 88, 90, and 92 separate connections.

Through the example in the first 2nd figure, how to describe in detail Fault tolerance is achieved in the invention. The service node S16 81 issues a service request to the service according to a predefined service plan, which will be completed by the software service node SSN17 82 through different routing paths: Route A: After the service request is sent at S16 81, the service The request can be made to connect to the software service node SSN 14 84 via connection 87 and then to the software service node SSN 17 82 from the software service node SSN 14 84 by connection; route B: after the service request is sent at S16 81, the service request can be connected via connection 89 To the software service node SSN15 85 is satisfied, and then connected to the software service node SSN17 82 from the software service node SSN15 85 through the connection 90; Route C: After transmitting the service request at S16 81, the service request can be satisfied by connecting to the software service node SSN16 86 via connection 91, and then from the software service node SSN16 86 to the software service node SSN17 82 via connection 92; routing manager S16 81 The target node is determined for the service request according to the predefined service plan and decides to adopt route A as the service request.

Assume that connection 87 is the downtime of the next plan and the service node S16 81 is attempting to transmit a service request to the software service node SSN14 84, and the connection manager S16 81 discovers the network downtime and notifies the routing manager. The route manager receives the notification and determines the alternate routing path, in this case routing B as the service request. Service node S16 81 uses route B to send the service request again. After the service request is sent at S16 81, the service request can be satisfied by connecting to service node SSN 15 85 via connection 89, and then connected to SSN 17 82 from software service node SSN 15 85 via connection 90.

If the software service node is between SSN15 85 and SSN17 82 The connection 90 is also temporarily shut down and the SSN 15 85 attempts to deliver the service request and passes the processing result to the SSN 17 82. The error recovery manager SSN 15 85 can find another alternate routing service request and processing result to the SSN 17 82. In this example, the error recovery manager SSN 15 85 may decide to pass the service request and processing results to the SSN 17 82 via the SSN 16 86. The error recovery manager looks for the first available node to deliver the message. Therefore, the final routing path of the service request may be as follows: a service request is sent from the service node S16 81; Connected to the software service node SSN 15 85 via connection 89; connection 90 is therefore down to the software service node SSN 16 86; software service node SSN 16 86 is connected via connection 92 to the software service node SSN 17 82. Service completed at SSN17 82.

The invention also provides cross-domain messaging for multiple service nodes and/or multiple software service nodes. Each element of the invention has a globally unique name. The universally unique name of each element allows the routing manager to identify each element in time.

Figure 13 is an illustration of an application that uses fault-tolerant software as a service platform to host a service business. The application explains the benefits of cooperating, operating, and fault-tolerant software-as-a-service platforms implementing managed services. In the first and third figures, there are three companies, X company, bank Y and research institute. Company X is an enterprise application development company. It develops a software system and allows bank Y to access the software system remotely through the software service node SSN30 106. The users C10 110, C20 111, and C30 112 of the bank Y 103 are connected to the software service node SSN 30 106 to access the software system located in the X company domain 101. In the X company domain, the software service node SSN20 104 software service node SSN30 79 interfaces and delivers the service request of the bank Y user to the corresponding software service node SSN20 104. For example, the services provided by Company X are real-time quote service for stocks, company briefing consulting services and reporting services. The stock real-time quote service is provided through service node S30 107, which can provide an instant stock quote upon request. Company Profile Consulting Service It is provided through Service S40 108, which provides corporate information, such as management teams, organizations, production lines and target markets, on demand.

Provides reporting services via S50 109, which provides the required information A system within the company's X domain, such as a software system for traffic reports, a system usage report, a system performance report, or an account data report. The Y user of the bank can access the software system by logging in to the system for his/her desktop software, then the account information will be passed to the access control system to provide account verification in the X company's access control system, and the available functions check the authority of the registrant and The account management system performs traffic monitoring. Account information is stored in the customer database 113. The Reporting Service can access the customer database and retrieve the information needed for the analysis based on the user's request.

The Institute 102 provides stock history information to customers. Institute The software development staff learned that Company X provides company profiles and information stocks to customers in real time. Therefore, the software development staff of the Institute decided to use the services of Company X to minimize their software development work. At the Institute, the software developer wrote a program, the software service node SSN40 105, which interfaces with the company X's software service node SSN20 104. After the connection between the two software service nodes is established, the software development staff of the institute can immediately access the stock real-time quote service, company profile service and report service. After receiving the required information, the Institute's software development staff can store it in its database 114 or consolidate the collected data and provide analytical data to the client. The system infrastructure of the present invention improves system development efficiency between organizations.

30‧‧‧ The method of the present invention provides a functional architecture diagram of a fault tolerant software as a service platform

31‧‧‧ Domain A

32‧‧‧ Domain B

33‧‧‧ Domain C

53‧‧‧Connection Administrator

54‧‧‧Route Manager

55‧‧‧Access Control Manager

56‧‧‧Interface Manager

57‧‧‧Error Recovery Manager

Claims (6)

A method for providing fault tolerant software as a service platform, comprising: (a) a service node or a plurality of service nodes connecting or receiving connections from a software service node. A service node is a piece of software that provides the ability to interact with multiple software service nodes; (b) a software service node is a piece of software that processes a series of computer code to complete a service request service; (c) a design-based software The characteristics of the service node, the software service node service node all or part of the service request; (d) a small number of software service nodes complete the service request of the service node according to the design features of the multiple software service nodes; (e) a software service node or multiple software services A node, or a service node or a plurality of service nodes, may constitute a service node group; (f) a service node group or a service node group s may be grouped in multiple software service nodes by grouping multiple software service nodes Provide load balancing and fault tolerance; (g) one domain or multiple domains complete knowledge identification by name. A domain consists of multiple service nodes, multiple software service nodes and multiple service node groups; (h) each service node within a domain has a unique name; (i) each software service node within a domain Have a unique name (j) Each service node group in a domain has a unique name (k) Each domain has a unique name (l) an intra-domain software service node universal unique name and function variable name Correlation, the service node group name and the software service node name have a corresponding order (m) The service node common unique name in one domain is associated with the function variable name, and the service node name has a corresponding order. For example, the method of claim 1 includes: (a) The four-step service process includes: (i) service request; (ii) service case; (iii) service provisioning; (iv) service completion; (b) service request available through service node and/or software service node The person initiates the operation, both local and/or the domain; (c) the case of the service is a series of steps of the service, wherein the steps of each service are marked with a serial number. (d) a service plan that provides a service flow based on the type of incoming request; (e) a service request by a service requester through a series of computer steps; (f) a service request that meets the service request provided to the service, and Closing the mutually agreed service request of the requester and the service provider; (g) the order in which the service flow defines the steps for incoming service tracking and service completion; (h) the corresponding steps in the service flow defining the request entered by each software service node . The method of claim 1, further comprising: (a) a software service node comprising: (i) a connection manager; (ii) a routing manager; (iii) access control management; (iv) an interface manager; (v) error recovery manager; (b) the connection administrator can accept and connect to the service node and/or the software service node; (c) the route manager can determine the node definition of the service; (d) the route manager can Determining a destination node extending to a service request, and determining a corresponding routing path according to the specified service flow and the plurality of available service nodes of the software; (e) The access control manager can verify the permissions of the received service and determine the connection of the software service node; (f) the interface manager can fully satisfy or satisfy the requested service according to the essential part of the software service node; Once the service is completed in the current software service, the interface manager will notify the connection administrator of the next step; (h) the interface manager can capture data and events through the software service node at any time; (i) The interface manager can log and/or send logs to the specified receiver (j). When a failure is detected, the error recovery manager can find an alternate routing path and determine the connection of a specified routing path through the routing manager. The method of claim 1, further comprising: (a) a service node comprising: (i) a business rule manager; (ii) a connection manager; (iii) a routing manager; (b) a business rule manager comprising Business steps provided by a series of computer steps; (c) connection administrators can accept and connect service nodes and/or software service nodes as needed; (d) a routing manager can be based on specified service flows and multiple availability of software The routing path corresponding to the service node determines the destination node to which a service request is sent; (e) one service node or a service node that resides in one service node group or multiple service node groups can have multiple software services in the same domain. Transferring data or requests in a node; (f) multiple software service nodes in a domain with multiple service nodes and service node groups are interconnected For example, the method of claim 1 includes: (a) a software service node between a service node and a plurality of software service nodes in a domain. Multiple access to the path can be established by granting connection permissions to the access control manager of the point or multiple software service nodes. a service node or a plurality of service nodes are connected; (b) between a plurality of service nodes and a plurality of software service nodes in a domain, once the access control manager of the software service node or the plurality of software service nodes grants connection permission, It is possible to establish multiple path connections. A service node or a plurality of service nodes are connected; (c) a service node and a plurality of software service nodes in a domain reside between software service groups. Once the software service node or the access control manager of the plurality of software service nodes is granted By connecting permissions, you can establish multiple path connections. A service node or a plurality of service nodes are connected; (d) within a domain, a service node establishes a connection to a service node group to automatically connect to each software service node resident service node group; (e) within a domain, Multiple Software Service Nodes Residing Multiple Service Node Groups Once multiple software service nodes host access control managers of these service node groups grant connection permissions, multiple path connections can be established. (f) Multiple Software Service Nodes of Multiple Service Node Groups in Multiple Domains Once multiple software service nodes host access control managers of these service node groups grant connection permissions, multiple path connections can be established. For example, the scope of patent application 2 includes: (a) the service node of the domain in the remote website can establish a channel, and connect one or more paths to one service node group or multiple service nodes through access control mode. group. (b) The service node of the domain in the remote website can access the service node group where multiple software service sections reside through access control and network connection.