WO1999057620A2

WO1999057620A2 - Distribution of a service request in a client-server architecture

Info

Publication number: WO1999057620A2
Application number: PCT/FI1999/000374
Authority: WO
Inventors: Harri TÖHÖNEN
Original assignee: Sonera Oyj
Priority date: 1998-05-04
Filing date: 1999-05-04
Publication date: 1999-11-11
Also published as: WO1999057620A3; FI980985A0; AU3828899A; FI980985A

Abstract

The present invention relates to a system and a procedure for distribution of a service request in a computer system based on a client-server architecture and comprising at least one client (1), which sends service requests to servers (21, 22, ..., 2n); one or more servers (21, 22, ..., 2n), which provide callable services for the client (1); and middleware means (3). According to the invention, the system comprises a multiplexing server (4), by means of which the client's (1) service request is copied and distributed to the servers (21, 22, ..., 2n) for parallel execution; a queue system (51, 52, ..., 5n) for storing service requests not yet executed; and queue handling means (61, 62, ..., 6n), by means of which the service requests placed in the queue system (51, 52, ..., 5n) are passed on for re-execution. The invention allows transparent distribution of the service request, guarantees improved reliability of operation in failure situations and consistency of resources.

Description

DISTRIBUTION OF A SERVICE REQUEST

BACKGROUND OF THE INVENTION

The present invention relates to a system as defined in the preamble of claim 1 for distribution of a service request in a computer system based on a client-server architecture and to a procedure as defined in the preamble of claim 8 for distribution of a service request in a computer system based on a client- server architecture.

In a three-level client-server architecture, the server/servers produces/produce services requested by the client/clients. An agent acting between these is middleware, which is used to take care of e.g. the routing of service requests to the appropriate server, equalisation of load and management of transactions.

A typical area of application is telecommunication network management. In this case, the client application is e.g. a customer management system and the server application represents e.g. an SCP intelligent network component (Service Control Point, SCP). When the operation of the SCP intelligent network component, i.e. the node to be managed, is to be rendered as reliable as possible, the node is physically dou- bled, so that both nodes contain the same service data. The duplication must not be visible to the client process, but changes made by the client in the service data must be copied to both nodes . In other words, when the client sends a management data update request, the update request must be transmitted to all the servers and the management data must be updated in all the nodes to be managed, but the client must perceive the entire transaction as if it were only dealing with a single server/node. In prior-art systems, a service request can be distributed in a client application separately to each identical resource. Thus, the distribution architecture is visible to the client application. Further, if an update operation in one of the nodes to be managed is unsuccessful e.g. due to a telecommunication problem, the result is that the nodes are in a non- consistent state because the update cannot be cancelled automatically from the middleware level.

In middleware environments, a two- stage commitment procedure is previously known. In such a pro- cedure, the changes caused by a service request are first saved temporarily, whereupon a transaction monitor sends a preliminary commitment command (pre- commit) to each server. If the transaction monitor receives a confirmation from each server, then it sends the servers an actual commitment command (commit) , and the changes caused by the service request are updated simultaneously. If no confirmation is received from one of the servers, then no commitment command is sent and the changes are not updated, thus preserving the consistency of resources.

Two-stage commitment is in itself a workable procedure. The problem is that not all of the nodes to be managed are capable of it. In other words, a service request can only be cancelled if the cancellation decision is made from the client application. As a result, however, the distribution is visible to the client .

SUMMARY OF THE INVENTION The object of the present invention is to disclose a new type of procedure and system for eliminating the above-mentioned drawbacks.

A specific object of the present invention is to disclose a solution for achieving transparent dis- tribution of a service request and consistency of resources . As for the features characteristic of the present invention, reference is made to the claims.

The system of the invention for distribution of a service request in a computer system based on a client-server architecture comprises at least one client application/client process which sends service requests to servers; one or more server applications/server processes providing services which can be called by the client; and middleware means; further- more, the system comprises a multiplexing server, a queue system and queue handling means, which are implemented e.g. as software components. For each server, preferably a separate queue system and queue handling means are provided. This ensures maximal re- liability in failure situations. The multiplexing server provides the same service interface as the actual servers, and the names of the services of the actual servers are changed, causing the clients' service calls to be directed to the multiplexing server. According to the invention, by means of the multiplexing server, the client's service request is copied and distributed to the servers for execution. By means of the multiplexing server, responses are obtained from the servers and a single response for the calling client is composed from them. If any one of the servers returns a successful response, then a successful response is returned to the client. Thus, the duplication is hidden from the client. For those servers which return an unsuccessful response due e.g. to a telecommunication failure preventing communication with the resource to be managed, the service request is placed in the queue system for the server in question. The multiplexing server does not take care of service requests placed in a queue system but is ready to serve subsequent service requests of the client/clients . Further, according to the invention, service requests not fulfilled are stored in server-specific queue systems, which comprise a separate queue for each service provided by the server. The queues are based on prioritisation of requests, i.e. a service request entered in a queue with the highest priority is the first one to be served and removed from the queue. The queue system is implemented e.g. in the form of a file. Further, according to the invention, the queue handling means are used to pass on the service requests placed in the queue system to the servers at predetermined time intervals for re-execution. For example, a list of the queues to be monitored is main- tained. A service request is taken from the queue, and the server service corresponding to the queue is called.

As compared with prior art, the present invention has the advantage that it allows transparent distribution of a service request, in other words, a client's service request can be copied to a plurality of servers without the copying being visible to the client. Furthermore, according to the invention, instead of cancellation of a transaction, a queue mecha- nism is used whereby attempts to execute the transaction are repeated until the fault has been corrected and the transaction is successfully carried out or until a time limit is exceeded. This makes it possible to achieve a greater reliability in failure situations than before. Moreover, the invention requires only minimal changes in the existing middleware architecture as regards the client and server processes, so it can be easily implemented and taken into use.

In an embodiment of the invention, the multi- plexing server, the queue system and the queue handling means are logically disposed in conjunction with the existing middleware means between the client and the servers. Each server communicates with a given telecommunication network component, which network components are managed by a management application communicating with the client. The servers provide identical services to the client, with the difference that different servers communicate with different manifestations of the network components to be managed.

In an embodiment of the invention, a table of the servers to which the service request is to be duplicated is maintained in the multiplexing server. The services of the servers in the table are preferably called asynchronically by the multiplexing server, in other words, having transmitted a service request to one server, the multiplexing server starts transmitting the service request to the next server without waiting for a response from the first server. This allows parallel execution without delays.

In an embodiment of the invention, before calling a service, a check is carried out on each server by the multiplexing server to determine whether there are already any service requests in the queues corresponding to the service in question. If the queue concerned already contains service requests, then the new service request is placed directly in the appropriate queue and assigned the lowest priority at the moment .

In an embodiment of the invention, a cycle counter and/or a time stamp are/is attached to service requests transferred into a queue system to allow control of the length of time each service request is retained in the queue system.

In an embodiment of the invention, to retrieve a service request from a queue by using queue handling means, the server service corresponding to the queue is called synchronically, in other words, a response to the call is awaited. If a message indicat- ing successful execution of the service request is received from the server, then the service request has been successfully executed. If the server is still unable to execute the service request, then the service request is again placed in the queue and the cycle counter for the service is incremented. However, if the time stamp and/or cycle counter of the service request exceed certain predetermined values, then the service request is deleted from the queue and the situation is logged.

In an embodiment of the invention, the middleware means consist of Tuxedo middleware.

BRIEF DESCRIPTION OF THE DRAWINGS In the following, the invention will be described by the aid of a few examples of its embodiments by referring to the attached drawing, wherein

Fig. 1 presents an embodiment of the system of the invention, and Fig. 2 presents a functional diagram of a system according to the invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Fig. 1 presents an embodiment of the system of the invention for implementing telecommunication network management in which a management application 8 is used to manage components 7¹,7²,7³ of the telecommunication network. In this example, the network components are SCP nodes in an intelligent network, nodes 7² and 7³ being backup copies of node 7¹. Nodes 7² and 7³ thus contain the same intelligent network service data as node 7¹. A notable feature is that the SCP nodes 7¹,7²,7³ are incapable of two-stage commitment to data updates. A management application 8 communicates with a client process 1, and the SCP nodes 7¹,7²,7³ communicate with server processes 2¹,2²,2³. Functioning be- tween the client process 1 and the server processes 2¹,2²,2³ is Tuxedo middleware application management software 3, which takes care of e.g. routing of the service requests to the appropriate server, load equalisation and transaction management. Implemented as logical software components disposed between the client process 1 and the server processes 2¹,2²,2³ are a multiplexing server 4, queue handling means 6¹ , β² , β³ and queue systems δ¹^²^³. For each server, there is one queue handling means and one queue system.

Fig. 2 presents a functional diagram of a system according to the invention in a Tuxedo environment. By means of a client application (not shown), a call for service y is issued, which service is actu- ally implemented as service y' in server A 2¹ and server B 2². First, configuration information is read from a run-time management information base (MIB) in Tuxedo 3. The configuration information comprises e.g. server groups, routing data for the groups, queue pa- rameters and queue space data. When the service request y is received by the multiplexing server 4, a check is carried out to establish whether the queue systems 5¹ and 5² (not shown) for servers 2¹ and 2² already contain any messages. In this way, the order of the service requests is maintained. The name of the service is changed to y' . A routing field is added to the message.

Next, a call for service y' is sent asynchronically to each application server 2¹ and 2². Be- fore the call, the routing field is assigned a value which is obtained from a table maintained by the multiplexing server 4, said table containing routing field values for the servers 2¹ and 2². The values were obtained from the Tuxedo 3 configuration information when the multiplexing server 4 was started up. Thus, the service requests are routed to different application servers. Next, responses are obtained from the application servers 2¹ and 2². It is to be noted that Tuxedo automatically collects the responses to asynchronous calls. The title part of the message is checked for errors, and the results are added to a re- suits table which contains table locations for each application server 2¹ and 2². Based on the results table, a response message for the client application is composed.

The results table is analysed. If errors are detected e.g. in the response of application server 2¹, then a time stamp and a cycle counter are attached to the message concerned. Further, the lowest priority in the queue system 5¹ corresponding to the application server 2¹ is found out and the message is assigned the next priority level below it. After this, the message is placed in the queue system 5¹ for the application server 2¹.

The queues are polled using the queue handling means 6¹ and 6² (not shown) . For each service, there are specified queues in the queue systems 5¹ and

5². For each application server 2¹, 2² there is one queue system 5¹, 5² and one set of queue handling means β¹, 6². Using queue handling means 6¹, a call for service y' is issued synchronously. Before the call, the time stamp and cycle counter are checked. If the time stamp is too old and the cycle counter has a sufficient value, then the message is deleted from the queue system 5¹, and the situation is logged. If an erroneous response is still obtained from the applica- tion server 2¹, then the message is placed back into the queue and the cycle counter value for the message is incremented.

The invention is not restricted to the examples of its embodiments described above, but instead many variations are possible within the scope of the inventive idea defined in the claims.

Claims

1. System for distribution of a service request in a data system based on a client-server architecture and comprising at least one client (1) , which sends service requests to servers (2¹, 2², ... , 2ⁿ) ; one or more servers (2¹,2², ... , 2ⁿ) , which provide callable services for the client (1) ; and middleware means (3) , characterised in that the system comprises

- a multiplexing server (4) , by means of which the client's (1) service request is copied and distributed to the servers (2¹, 2², ... , 2ⁿ) for parallel execution, the client (1) is notified of successful/unsuccessful execution of the service request, and if one of the servers (2¹, 2², ... , 2ⁿ) is unable to exe- cute the service request, then the service request is transferred into the queue system (5¹, 5², ... , 5ⁿ) for the server concerned;

- a queue system (5¹, 5², ... , 5ⁿ) for each server (2¹, 2², ... , 2ⁿ) for storing service requests not yet executed; and

- queue handling means (6¹, 6², ... , 6ⁿ) for each server (2¹,2², ... , 2ⁿ) , said means being used to pass on service requests placed in the queue system (5¹, 5², ... , 5ⁿ) for re-execution at certain time inter- vals.

2. System as defined in claim 1, characterised in that

- the multiplexing server (4) , the queue system (51,52, ... ,5n) and the queue handling means (61, 62 , ... , 6n) are disposed in conjunction with the middleware means (3) between the client (1) and the servers (21, 22 , ... , 2n) ;

- each server (21, 22 , ... , 2n) is connected to a telecommunication network component (71,72, ... , 7n) , which network components (71, 72 , ... , 7n) are managed using a management application (8) communicating with the client (1) ; and - the servers (21, 22 , ... , 2n) provide identical services for the client (1) .

3. System as defined in claim 1 or 2, characterised in that - a table of the servers (2¹, 2², ... , 2ⁿ) to which the service request is to be copied is maintained in the multiplexing server (4) ; and

- the services of the servers (2¹, 2², ... , 2ⁿ) are called asynchronically by the multiplexing server (4) .

4. System as defined in any one of the preceding claims 1 - 3, characterised in that

- before issuing a call for a service, a check is carried out on each server by the multiplexing server

(4) to determine whether there are any service re- quests in the queue systems (5¹, 5², ... , 5ⁿ) ; and

- if there are already service requests in the queue system ( ¹ , ² , ... , 5^╧Ç) , then the service request is placed in the queue system (5¹, 5², ... , 5ⁿ) by the multiplexing server (4) and assigned the lowest prior- ity at the moment.

5. System as defined in any one of the preceding claims 1 - 4, characterised in that a cycle counter and/or a time stamp are/is attached to the service requests transferred into a queue system (╬┤¹^², ... , 5ⁿ) by the multiplexing server (4) .

6. System as defined in any one of the preceding claims 1 - 5, characterised in that

- using the queue handling means (6¹, 6², ... , 6ⁿ) , the services of the server (2¹, 2², ... , 2ⁿ) are called synchronically;

- if the server (2¹, 2², ... , 2ⁿ) is unable to carry out the service, then the service request is returned to the queue system (5¹, 5², ... , 5^╧Ç) by the queue handling means (6¹, 6², ... , 6ⁿ) and the cycle counter for the service request is incremented; and

- if the time stamp and/or cycle counter of the service request exceed certain predetermined values, then the service request is deleted by the queue handling means (6¹, 6², ... , 6ⁿ) .

7. System as defined in any one of claims 1 - 6, characterised in that the middleware means (3) consist of Tuxedo middleware.

8. Procedure for distribution of a service request in a data system based on a client-server architecture and comprising at least one client (1) ; one or more servers (2^X,2², ... , 2ⁿ) ; and middleware means (3) , in which procedure service requests are sent from the client (1) to the servers (2¹, 2², ... , 2") , and services called are provided for the clients (1) by the servers (2¹, 2², ... , 2ⁿ) , characterised in that

- by means of a multiplexing server (4), the cli- ent ' s (1) service request is copied and distributed to the servers (2¹, 2², ... , 2ⁿ) for parallel execution, the client (1) is informed about successful/unsuccessful execution of the service request, and if one of the servers (2¹, 2², ... , 2ⁿ) is unable to carry out the serv- ice request, then the service request is transferred into a queue system (5¹, 5², ... , 5ⁿ) for the server concerned;

- service requests not yet executed are stored in server-specific queue systems (5¹, 5², ... , 5ⁿ) ; and - using server-specific queue handling means (6¹, 6², ... , 6ⁿ) , service requests placed in the queue system (5¹, 5², ... , 5ⁿ) are passed on for re-execution at certain time intervals.

9. Procedure as defined in claim 9, char- acterised in that

- the multiplexing server (4) , the queue system (╬┤^╬┤², ... ,5") and the queue handling means (6) are disposed in conjunction with the middleware means (3) between the client (1) and the servers (2¹, 2², ... , 2ⁿ) ; - each server (2¹, 2², ... , 2ⁿ) is connected to a telecommunication network component (7¹,7², ... , 7ⁿ) , which network components (7¹, 7², ... , 7ⁿ) are managed by a management application (8) communicating with the client (1) ; and

- identical services are provided for the client (1) by the servers (2¹, 2², ... , 2ⁿ) .

10. Procedure as defined in claim 8 or 9, characterised in that

- a table of the servers (2¹, 2², ... , 2ⁿ) to which the service request is to be copied is maintained in the multiplexing server (4) ; and - the services of the servers (2¹, 2², ... , 2ⁿ) are called asynchronically by the multiplexing server (4) .

11. Procedure as defined in any one of the preceding claims 8 - 10, characterised in that

(4) to determine whether there are any service requests in the queue systems (5¹, 5², ... , 5ⁿ) ; and

- if there are already service requests in the queue system (5¹, 5², ... , 5") , then the service request is placed in the queue system (5¹, 5², ... , 5ⁿ) by the multiplexing server (4) and assigned the lowest priority at the moment .

12. Procedure as defined in any one of the preceding claims 8 - 11, characterised in that a cycle counter and/or a time stamp are/is attached to service requests transferred into a queue system (5¹, 5², ... , 5^╧Ç) by the multiplexing server (4).

13. Procedure as defined in any one of the preceding claims 8 - 12, characterised in that - using the queue handling means ( 6¹ , ╬▓² , ... , 6ⁿ) , the services of the server (2¹, 2², ... , 2^╧Ç) are called synchronically;

- if the server (2¹, 2², ... , 2ⁿ) is unable to carry out the service, then the service request is returned to the queue system (5¹, 5², ... , 5ⁿ) by the queue handling means (6¹, 6², ... , 6ⁿ) and the cycle counter for the service request is incremented; and - if the time stamp and/or cycle counter of the service request exceed certain predetermined values, then the service request is deleted by the queue handling means (╬▓¹, 6², ... , 6ⁿ) .

14. Procedure as defined in any one of the preceding claims 8 - 13, characterised in that the middleware means (3) consist of Tuxedo middleware.