Title of Invention

A METHOD AND SERVER FOR PERFORMING SERVICE FOR A CLIENT

Abstract

The invention relates to the structures of servers. The invention comprises the server architecture including at least one thread, which can handle sev¬eral different services at the same time. The thread uses a task manager to schedule the next service to be processed. The operating system handles the execution of the thread or threads. An assignment list contains all ser¬vices assigned to the thread.

Full Text

Server Architecture Field of the Invention This invention relates to servers. Especiafly, the invention relates to the structures of servers, how the server has been constructed, and how the server runs services. Further, the invention especially relates to servers in the field of telecommunications. Background of the Invention Figure 1 shows an example of a client-server environment. The server (1) may contain many services (2). The client (3) invokes a specific service in the server. The interface between the client and the service can, for instance, be based on CORBA. The service is in some state, which is changed by the client. When the service has performed desired tasks, it sends a response back to the client. This is the way, how servers handle re¬quests from clients at present. Servers can be constructed in many ways. All ways have their drawbacks and strong sides. One possible way is to use Java, an object-oriented programming language, to create functions of the server. Basic Java structures should be kept in mind when reading this text, describing the advantages and drawbacks of Java, and the invention. An object is a software component that usually contains executa¬ble codes and data. In an object-oriented language actual objects are not de¬fined, but classes of objects are. A class is a template for multiple objects with similar features. It can be said that a class describes all common fea¬tures for all objects in the class. So, a single object is a concrete representa¬tion of the class, in other words an instance. Methods are functions, i.e. executable codes that operate in a class or an object. A stream is a path of communication between the source of some information and its destination. Java contains several inputstream and outputstream classes for defining different streams. Serializing is a fea¬ture in Java environment that makes it possible to save a state of an in¬stance of the class (the concrete representation of a class) in the form of a byte-line. Serialized instances can be deserialized making it possible to use the saved class representation later. Threads are objects of the Thread-class. Preferably, the threads are used if the application runs several tasks simultaneously. A thread runs a task that is given to it. The task contains commands that the operating sys¬tem accomplishes. Parallel threads run at the same time, i.e. the application can execute parallel commands individually, without waiting for the end of a single command before starting the next command. So, if there are several applications and/or tasks to be run simultaneously. It is useful to use a thread-modeling. To sum up, a Java application comprises classes, which refer to objects. One of the classes is the "route" class, which contains basic meth-ods of the application and makes It possible to get the other classes that be-long to the application. ' ■ A client sends an event to the server, which has threads listening for events coming from the client. These threads pass the events upon re¬ception to the processing threads which do the actual event processing. Each event requires its own, new, processing thread. The cooperation of the two types of threads is synchronized. However, the synchronization is always expensive and tedious to design. The objective of the invention is to avoid these drawbacks and of¬fer better system performance than previous solutions. This is achieved in a way described in the claims. Summary of the Invention The idea of the invention is that the server architecture includes at least one thread, which can handle several different services at the same time. The thread uses a task manager to schedule the next service to be processed. The operating system handles the execution of the thread or threads. An assignment list contains all services assigned to the thread. A service environment comprises a container class, which contains objects that form. an actual service Instance and elements for keeping sen/ice and object specific data, and for controlling the actions of the container. Further, the service environment comprises information of the state and the substate of the container, and queues for different types of events to be processed. The queues can hold events coming from the clients before the events actually are processed. The service environment observes the states of the queues. The task manager asks the service environments in the assignment list if there are any events to be processed. If there are, the manager pulls the events in the order they are going to be processed. The thread pulls the events in or¬der from the manager for executing in the "operating system. The thread fires the event to the right service in the assignment list for starting the execution. After the execution, the state of the service environment has changed. Brief Description of the Drawings In the following the invention is described in more detail by means of Figures 1 - 5 iri the attached drawings where. j Figure 1 illustrates an example of a client-server environment at present, Figure 2 illustrates an example of a client-server environment according to the invention. Figure 3 illustrates an example of a sen/er architecture for handling parallel services according to the invention. Figure 4 illustrates an example of a service environment according to the invention. Figure 5 shows an example of the method according to the invention. Detailed Description of the Invention Figure 3 shows an example of a server architecture for handling parallel services according to the invention-. Threads are very essential when arranging simultaneous processes to be performed. Normally, a thread han¬dles the execution of one service. So, if there, for example, are ten parallel sen/ices, there exist ten parallel threads. However, the services run inde¬pendently from each others, so there exist idle and busy threads in the view of the operating system. The idle threads consume resources of the operat¬ing system. Using the arrangement, such as in Figure 3, according to the in¬vention, one thread (31) can handle several services simultaneously, which saves the resources of the operating system. The server architecture accord¬ing to the invention can include several parallel threads, each of them han¬dling several sen/ices. So, one thread can comprise one to many services (or service instances of the services). The server architecture needs a task manager (32) for handling the scheduling of executions of the services. The sen/ices (33a, 33b, 33c) assigned to the thread (31) form an assignment list (34.). The task manager-uses the list for pulling events from the services In the list, and scheduling the events for the thread, which pulls events for executing them from the task manager. The thread fires the execution of the events in the services. The service environment, i.e. the program environment, is a con¬tainer (Figure 4,41) (a class) in which the service (42) (program) and its in¬stance (a program instance) can be accommodated, and run when it is op¬erational in the service architecture. The program environment comprises the elements as depicted in Figure 4, The service environment compnses one to many queues (47) for stohng messages i.e. events coming from a client. Each event represents a task which the current sen/ice instance processes. The container comprises a common part, wnich in turn comprises a control part (45) and an instance context (44). The container further com¬prises a set of objects (43) that form the actual service. The control part exe¬cutes objects (43) in accordance with events received. The instance context stores data that is specific for the service instance. The service environment comprises information (46) of the state and the substate of the container, and queues (47) for different types of events to be processed. The events are categorized in to three types: Re¬quest, ISC, and Asynchronous events. ISC (Inter-Service Communication) means that an event was sent from another service, and it can be sent either synchronously or asynchronously. A synchronous message (event) is a message that the service is waiting for, i.e. the processing of a service event is in a waiting state and it will continue the processing when the service gets a special (synchronous) message. An asynchronous message is a message that the service is not waiting for. However, the service must be waiting for a synchronous mes¬sage, during which time it may receive unexpected messages, i.e. asynchro¬nous messages, or the synchronous message. Signal messages are special cases of asynchronous messages. The signal handler can handle signal messages at the same time another handler handles a synchronous or asynchronous message. The Request type handles synchronous events coming from inside the service. However, It is possible to use other types and another number of types if desired. The queues can hold events coming from clients before they actually are proc¬essed. The period of how long an event can be held depends on the sen/ice itself. The service environment registers states of the queues. When thinking in terms of sen/ices in a communication system service platform. One service can be implemented as a program that is em¬bedded into the service environment. In other words, the service is imple¬mented such that its program code is implemented as objects within the con¬tainer. A particular instance of the said program in execution within the ser¬vice architecture thus is a service environment instance. The container comprises a common part, whichin turn comprises a control part (45) and an instance context (44). The container further com¬prises a set of objects (43) that form the actual service. The control part exe¬cutes objects (43) in accordance with events received. The instance context stores data that is specific for the sen/ice instance. The service environment can be, for instance, defined as a pro¬gram ioad module, the kind of which is executable in parallel within a thread. The threads are in turn executable in parallel within an execution environ¬ment such as a Java virtual machine. Therefore, there are parallel process entities on three levels: operating system level, virtual machine level and on the thread level. Since the sen/ice architecture is based on an object-oriented model, clients are also modeled as objects. The clients send requests or messages to the sen/ice, which are also objects that contain tasks desired by the clients. Request/message objects are called events. (It should be noted that an event can also mean another type cf object.) Let's examine an example where a sen/ice architecture is con¬structed to have one thread to which three sen/ices have been assigned, as the situation is in Figure 3. Two sen/ices, 33a and 33b, are idle, but the third service 33c has an event from the client. The event is waiting in the relevant queue. The service environment has registered the states of the queues and sen/ices. If one or a number of the services is ready to take an internal event, the sen/ice environment pulls the event for the service from the Re¬quest queue, if there are any event waiting. The task manager examines the assignment list for puiling events. According to the cycle, which the manager uses for checking the states of the services, the manager starts from service 33a. Service 33a is idle and thus doesn't have an event for execution. Also service 33b, which the man¬ager examines next, is idle. The manager finds an event to be pulled for the execution when examining the state of service 33c. The manager pulls the event. Normally, there are many events which have to be scheduled for execution in the task manager (32), but now, in this example, there is only one event,which the manager can schedule to be first for execution. If there are a number of sen/ices in the assignment list with events to be processed, the task manager will go through the services in a round-robin fashion and processes their events in the specified order according to the event priorities. In the service environment asynchronous events are put into an order of the priority of the events. Synchronous messages are put into an order accord¬ing to the incoming order. (It should be noted that the task manager may use other ways for scheduling if other technical solution are used.) The thread pulls (31) the event from the manager, and fires the execution of the event in the sen/ice (33c). The firing means that the same thread can send (and re¬ceive) and execute an event. The execution of the event changes the state of the service environment (46) that the task manager can notice when ex¬amining this service environment. Figure 2 shows an example of a client-server environment accord¬ing to the invention. The client sends an event to server 1. The event is di¬rected to the right service environment (S1). Since.the event can be in the queue, i.e. the service looks idle to the task manager, before the thread fires it, the service environment (S1) can use other service environments for cer¬tain tasks before the event is directed back to the thread for final execution. Due to this, the service can be constructed so that it uses other sen/ices for creating the final service. The service environment can ask another service environment (5) in the same server (1) or in another server (6). It is also pos¬sible to form a chain of service environments to create a final service. The situation is pictured in Figure 2, where the route service environment S1 (4) asks another service environment S4 (7) in another server (6) to do a certain task or tasks, and server environment S4 in turn asks yet another server en¬vironment S5 (8) to do a certain task or tasks. The chain discharges back- wards when sen/ice environment S5 fires the task or tasks responding to sen/ice environment S4, which in turn fires it's task or tasks responding to service environment S1, where finally the event retums to the thread the fir¬ing the service desired by the client. The sen/ice gives the response to the client. The server architecture according to the invention includes a method of performing a service. Figure 5 shows an example of the prefer¬able method. First (61), an event from a client, has to be pulled from the queue in the service environment that handles this sen/ice and its events. As described before, the service environment contains the actual service, at least one queue for the events pushed by clients, and state information of the service and queues. The service environment keeps the event in the queue or allows it to be pulled (62) by the task manager. The choice depends on the state in¬formation of the service and queues. For instance, the service can be busy doing other matters, or one of the queues has another event that has to be performed first. When the task manager has pulled the event, it schedules (63) the event with other events pulled from the other service environments in the order in which the events were pulied. These service environments have been assigned to the thread that handles the processing of the assigned sen/ice environment specific sen/ices. The scheduled events are in the order of performance of the services. The thread pulls (64) the event in order from the task manager for processing the event. The thread fsres (65] the event to the service in the sen/ice environment for performing the service. The firing means that the ac¬tual processing happens in the service, not in the thread. The thread con¬tains the service classes of the services assigned to it, and uses these classes for performing events, it should be. noted that the thread can alternatively post the event to the service. Posting means that different threads handle the execution and sending (to post) of the service. It is worth noting that the service architecture can be constructed other ways than de¬scribed above. For example, the pulling acts can be created by using a pushing technique such as pushing the events from the service environments to the task manager and from the task manager to the thread. However, the use of the pulling technique as described in this text is preferable. Further, it is worth noting that the pulling order in the inventive worth noting that the pulling order in the inventive architecture can be, for example, that first, the thread pulls an event from the task manager, and af¬ter this the task manager pulls an event (events) from the service environ¬ments (the task manager does not pull events independently),- In other embodiments of the invention, for instance, the event queues are not necessarily stored in association with a given sen/ice envi¬ ronment instance, they can be stored elsewhere, however such that events can be retrieved by the program instance when it is notified of an incoming event. Similariy, the container part can be composed of one code module that is not necessarily composed of separate objects. Similarly, there may not be a clear separation of the code part: of the program into a common con¬ trol part; and a service specific part. The invention makes it possible to use the resources of the oper¬ating system more efficiently, thus a huge amount of services can run simul¬taneously. For each service, it looks like the thread runs only for the service itself. The sen/ice architecture according to the invention runs asynchro¬nously, meaning that the period between the acknowledgement of the cli¬ent's request and the response to the client can be anything, due to buffer¬ing. Avoiding synchronicity means cost savings. The invention also makes so-called hot services possible. This means that the state of the service is not changed by the client, but the sen/ice itself can change the state. Espe¬cially worth noting is that the sen/ice can be a client to other services. Although, the invention is described in this text by a few exam¬ples, it is evident that the invention is not restricted to these, but it can be used in other solutions as well, in the scope of the inventive idea. WE CLAIM; 1. A method for performing a service for a client who sends service specific events to the server in a client-server platform that comprises at least one client and at least one server, the server comprising at least one service, the method comprising the steps of; pulling the event that the client sends to a service environment that is comprised of the service, at least one queue for the events sent, and state information of the service and queues, from the queue by the service environment, wherein the events are sent by the client to a server in a client-server platform that comprises at least one client and at least one server, the server comprising at least one service, pulling or pushing the event from/by the service environment by/to a task manager when the state information of the service and queues allows it, scheduling the events irom the service environments, which have been assigned to a thread that handles processing of the events of the assigned service environments, in the task manager, pulling or pushing the scheduled event by/to the thread from/by the task manager for processing the service event, firing the event to the service in the service environment for performing the service. 2. A method as claimed in claim 1, wherein instead of firing the event to the service, the event is posted to the service. 3. A server for executing a service for a client who sends events to the server in a client-server platform that comprises at least one client and at least one server, the server comprising at least one service, the server configured to perform the method as claimed in any of claims 1 and 2.

Documents:

in-pct-2002-1526-che - abstract.jpg

in-pct-2002-1526-che -abstract-duplicate.pdf

in-pct-2002-1526-che -abstract.pdf

in-pct-2002-1526-che -claims-duplicate.pdf

in-pct-2002-1526-che -claims.pdf

in-pct-2002-1526-che -correspondence-others.pdf

in-pct-2002-1526-che -correspondence-po.pdf

in-pct-2002-1526-che -description (complete)-duplicate.pdf

in-pct-2002-1526-che -description (complete).pdf

in-pct-2002-1526-che -drawings.tif

in-pct-2002-1526-che -form-1.pdf

in-pct-2002-1526-che -form-18.pdf

in-pct-2002-1526-che -form-26.pdf

in-pct-2002-1526-che -form-3.pdf

in-pct-2002-1526-che -form-5.pdf

in-pct-2002-1526-che -others.pdf

in-pct-2002-1526-che -pct search report.pdf

in-pct-2002-1526-che -pct.pdf

in-pct-2002-1526-che -petition.pdf