Abstract:
The present invention describes a dynamic managing method, system and extended naming service framework for enabling service availability in a computer system comprising at least one or more client applications, one or more server applications for providing one or more services, and wherein the client applications use one or more services. The system further comprises one or more entities or pieces of physical equipment for providing one or more server applications and a management entity for supervising and recovering the entities or physical equipment. The framework provides a solution to the problem of locating and managing services within a system. The framework provides a centralised storage of information about all the services within a system, although it can also be a distributed solution as well. Source of information about the services are the service providers themselves or mapped information from HA notifications concerning physical equipment, e.g. a LAN port etc.

Description:
[0001]     This is a Continuation of International Application No. PCT/FI03/00235 filed Mar. 27, 2003, which designated the U.S. and was published under PCT Article 21(2) in English.  
       FIELD OF THE INVENTION  
       [0002]     The present invention relates to mobile telecommunication systems. In particular, the present invention relates to a novel and improved method, system and extended naming service framework for guaranteeing service availability.  
       BACKGROUND OF THE INVENTION  
       [0003]     Data communication and computer networks provide different kinds of services to parties requesting services. Service here refers to any instance, for example software or hardware components that are capable of offering some kind of useful information for other entities, users or clients.  
         [0004]     An important property for a service is that it is available as much as possible. Some services are more important than others, and therefore the down time or fault time of the most important services should be minimised. Also an important aspect is that the state information (e.g. failure, down, etc.) should be available to the instances that might need the information, e.g. other service users that might send a service request to the service. In some occasions, a process provides only one service. However, there may be situations where a single process is offering one or more services.  
         [0005]     It can be said that most of the computer and data communication systems have some kind of management system. The task of the management system is to monitor the functions of the system, report failures and manage possible recovery processes. The object to be monitored can be, e.g. a hardware component, e.g. a Computer Processing Unit (CPU) or a software component, service or process. Mobile networks comprise different kinds of Network Management Systems (NMS).  
         [0006]     Conventional problem handling systems are often rule based solutions. This means that there are beforehand generated rules, and when a failure occurs, some information is acquired about the failure, and based on the rules affects of the failure are concluded. What is even more problematic is that the rules are often customer-specific. The main problem with the predetermined rules is that someone has generated the rules, and they are more or less based on before experienced situations. The weakness of the rule based solutions is that they are static by nature.  
         [0007]     When a failure occurs, according to rule based solution, the predetermined rules are gone through, and it is tried to be decided what effects the failure causes. Imagine a situation where a certain failure has not occured ever, so there will not be any proper rule to apply. Therefore, we have a failure situation, and we do not any specific information what are the affects of the failure.  
         [0008]     There exists high-availability carrier-grade server platforms. The use of mainstream hardware technologies and open-interface software components facilitate fast product creation. These network servers will eventually supersede, e.g. current mobile switches, enabling mobile networks to provide rich-call capabilities far beyond present voice and messaging-centric services.  
         [0009]     Currently some systems use so called High Availability Services (HAS). The HAS provides services to build a system that is highly available i.e. provides good service. Clients are interested of service access points called Integration Reference Points (IRP). A client refers to an entity, e.g. a software process, which is able to use different services. A process can include many services, and thus many service access points.  
         [0010]     A problem arises when the High Availability Services (HAS) finds that e.g. some process or physical equipment, e.g. a disk is broken. The problem is to determine which services are affected. Prior art solutions do not provide unambiguous answers to this important question. In current circuit switched based world the architecture was based on processes and communication between them. There the client knew their counterpart processes, and thus affect of some process failure was predictable, and it was possible to recover from the situation just with the HAS concept.  
         [0011]     However, in the present architecture model the main points are services and their access points. The clients are not interested in the physical items like processes providing the services. Clients are only interested in the service access points (IRP) and their run-time references. This gives freedom to pack services in many ways, and thus provides very flexible architecture to support different kind of physical entities of the services.  
       SUMMARY OF THE INVENTION  
       [0012]     The present invention describes a dynamic managing method, system and extended naming service framework for enabling service availability in a computer system. The computer system comprises at least one or more client applications, one or more server applications for providing one or more services, wherein the client applications use one or more services. The system further comprises one or more entities or physical components for providing one or more server applications and a management entity comprising information about the entities or pieces of physical equipment.  
         [0013]     The extended naming service framework described in the present invention provides a solution to the problem of locating and managing services within a system. The framework provides in a preferred embodiment a centralised storage of information about all the services within a system. However, the extended naming service framework can also be a distributed solution as well. Source of information about the services are the service providers themselves or mapped information from the HA notifications concerning physical components, e.g. a LAN port etc.  
         [0014]     Service availability must be transparent to service users. Service providers, even if they aid in service availability must not implement service availability themselves. The present invention provides a generic solution for implementing service availability.  
         [0015]     The High Availability Services receive information e.g. of failures of physical component (Central Processing Units (CPU), Local Area Networks (LAN)), processes etc. Service users (client applications) are not interested in processes but in the service access points. Service providers can provide the “physical” details (e.g. process info) of their services to the extended naming service framework. By listening to the HAS notifications regarding physical components, the extended naming service framework can map the status of a service to the status of the physical component which provides the actual service.  
         [0016]     The present invention has several advantages over the prior art solutions. The present invention provides a generic and dynamic solution for service availability. With the present invention it is possible to map processes or physical equipment to services provided by them. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0017]     The accompanying drawings, which are included to provide a further understanding of the invention and constitute a part of this specification, illustrate embodiments of the invention and together with the description help to explain the principles of the invention. In the drawings:  
         [0018]      FIG. 1  is a block diagram illustrating of the functioning entities in accordance with the present invention,  
         [0019]      FIG. 2  illustrates an example of service registration and service subscription,  
         [0020]      FIG. 3  illustrates an example of a graceful shutdown procedure of a service provider,  
         [0021]      FIG. 4  illustrates an example of service provider switchover, and  
         [0022]      FIG. 5  illustrates an example of retrieving a service interface address from the extended naming service framework. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0023]     Reference will now be made in detail to the embodiments of the present invention, examples of which are illustrated in the accompanying drawings.  
         [0024]      FIG. 1  describes an embodiment of a system in accordance with the present invention. The system comprises two client applications (CU 1 , CU 2 ) and two service providers (SP 1 , SP 2 ). A client application is a service user which uses services provided by server applications. A server application is a service provider providing one or more services.  
         [0025]     High Availability Services HAS receive information e.g. of failures of physical components, e.g. Central Processing Units (CPU), Local Area Networks (LAN), processes etc. The HAS manages the Recovery Units (RU), which include the processes. The recovery unit is usually responsible for a service but in practice it can include multiple service access interfaces or Integrated Reference Points (IRP).  
         [0026]     Broken lines represent possible messaging routes. The main idea of the present invention is that the extended naming service framework ENS stores detailed information concerning client applications (CU 1 , CU 2 ) and server applications (SP 1 , SP 2 ). When a failure situation occurs the extended naming service framework ENS comprise all the needed information to conclude which services will suffer due to the failure.  
         [0027]     The system in accordance with the present invention may also comprise Alarm Services AS (as in  FIG. 1 ) which reports alarm situations. The present invention provides a powerful tool to be used with alarm reporting. Typically an AS reduce the number of alarm reports (or events) sent further, e.g. to Network Management System (NMS). In many cases, problems with physical entities are found out but it is not possible to know which services are effected, if any. Therefore it would ease the NMS operator corrective actions if it would get a better alarm report when alarm is raised based on the hardware supervision. The present invention enables that each alarm based on hardware supervision can be linked to the corresponding service by using extended naming service framework ENS. In a situation of this kind, the AS, when receiving an (hardware related) alarm, asks corresponding impact to services from the ENS, and controls alarm report based on that. Previously this problem has been solved by using alarm correlation rules, but they are static by nature and are based on system study and prediction, and not in real operative bindings as the present invention describes.  
         [0028]     The HAS will start the processes, and in the startup of a process the HAS will give the process physical location information and state of the process (active or standby) . So when the process is started, the current physical location will be told to it (like cluster-node-Recovery Unit) as well as the process state. After the process is started by the HAS, the process will register all service access points to the ENS. In these registration messages (or one big registration message) to the ENS, the process will add also the physical location of the service access point or integration reference point (IRP) and the state. Process can also give some other keys that could be used to subscribe the service later by the clients. After registering the ENS will have information like “IRP, IRP state (=process state), physical location, other search keys”.  
         [0029]     Now, if something goes wrong with some CPU node or with some process, the HAS will send this information to the ENS. The ENS is now able to bind this information concerning the physical component to the real service access points. The ENS is able to change the statuses of the IRPs according to the physical component states.  
         [0030]     The system represented in  FIG. 1  solves the problem of managing Service Availability. Service Availability must be transparent to service users. Service Availability is a common requirement for many services. The usage of the ENS is also flexible. Service users and providers can decide to use all the features provided by the framework, or only a limited set of features. For example, depending on the configuration, the framework can act as a simple the Common Object Request Broker Architecture (CORBA) naming service for some providers and users.  
         [0031]     In  FIG. 1 , server application SP 1  is provided by entity or physical equipment EQ 1  and server application SP 2  by entity or physical equipment EQ 2 . The entity or physical equipment (EQ 1 , EQ 2 ) refer e.g. to servers or processes.  
         [0032]     In one embodiment of  FIG. 1 , the extended naming service framework ENS comprises one or more of the following means: 
        an interface IF for receiving from the management entity HAS a notification that an entity or a piece of physical equipment EQ is malfunctioning     means for updating UM status information of services SE which are provided by the malfunctioning entity or piece of equipment EQ;     means for notifying NM the changed status information to client applications SU that are registered to use the services SE provided by the malfunctioning entity or piece of equipment EQ,     an interface for receiving IF a service subscription from a client application SU,     means for notifying NM a client application SU when a status of a service SE of which the client application SU is aware of, changes.     an interface for receiving IF a service search request from a client application SU;     means for providing NM the client application SU the requested service information if a service SE matches search criteria,     one or more distribution rules DR to be applied when a service SE registered in the extended naming service framework ENS comprises two or more instances of a service SE,     an interface for receiving IF a request for services SE that are linked to the failed one or more entities or physical components EQ,     means for checking CM the information of the services SE, and     means for sending NM information about those services SE linked to the failed one or more entities or physical components (EQ).        
 
         [0044]     The above mentioned means are in one embodiment implemented by using hardware and/or software components.  
         [0045]     In one embodiment of  FIG. 1 , the extended naming service framework ENS supports service access protocols other than the CORBA as well. The messaging path can be any protocol, and not necessarily the CORBA.  
         [0046]     In one embodiment of  FIG. 1 , service users are able to search for services from the extended naming service framework ENS based on flexible service hunting policies. For example, a service user can ask for a service which is serving a particular database fragment. It must be possible for service users to find the address of an interface executing a particular instance of a service from the extended naming service framework ENS. The search criterion in such a case can be e.g. the exact instance identifier of the particular service instance in question.  
         [0047]     In one embodiment of  FIG. 1 , the extended naming service framework ENS supports service pool functionality. Different instances of the same service can constitute a service pool. The ENS is able to create and manage such a service pool. The ENS is able to apply distribution policies to the different service instances within the pool. The distribution policies comprise, e.g. least loaded server, least recently used (LRU) server, round robin (RR) etc.  
         [0048]     In one embodiment of  FIG. 1 , the ENS comprises service provider load management functionality. Service providers inform the ENS when they are under heavy load. This decision can be on the basis of collecting some system data or statistics. In such a case, the ENS must not update any new service users with information about the particular service instance in question. It can also inform existing service users, aware of the service instance, with the status of the service (under heavy load).  
         [0049]     In one embodiment of  FIG. 1 , the ENS provides standard CORBA name service functionality to service providers and users. However, the additional name service can also be other naming service than CORBA as well. The framework provides also a CosNaming interface. The ENS can act as a delegate between the commercial CORBA naming service implementation and the application using the naming service. Service providers can advertise their services using either the CosNaming interface or the additional mechanisms provided by the extended naming service framework. However, service users must be aware of which services are to be retrieved from the CORBA naming service, and which services are to be retrieved using the additional mechanisms provided by the ENS. In this way all Name Service related functionality is concentrated in one place.  
         [0050]     In another embodiment of  FIG. 1 , the system comprises standard CORBA name service and the ENS in separate places.  
         [0051]      FIG. 2  represents a service registration example in accordance with the present invention. Registration may happen, e.g. during system start up, or when the service provider is started/restarted.  
         [0052]     The service provider SP registers its services to the extended naming service framework ENS ( 20 ), e.g. using CORBA communication. In a preferred embodiment, the registration includes the following information: 
        Service name.     Service access point point to which the service belongs.     Interface address of the service.     Physical information about the service (node information, process information etc.).     Service status (e.g. active or standby)        
 
         [0058]     After registration, the service is successfully registered to the ENS and is identified by a unique identity.  
         [0059]      FIG. 2  represents also service subscription procedure where a service user SU subscribes to services from the extended naming service framework ENS. This may happen, e.g. during system start-up, or when the service user is started or restarted.  
         [0060]     The service user SU subscribes to services from the framework ENS ( 22 ), using e.g. a CORBA call. In a preferred embodiment, the subscription includes the following information: 
        Service name.     Service access point to which the service belongs.     Required physical and other properties of the service.     Service status (e.g. active or standby).     Number of instances of the service if the user is interested to know.     The reference of the callback interface for the service user. This is the interface that the framework uses for updating the service user.        
 
         [0067]     The service user SU has now successfully subscribed to services from the framework. If there are services available, which match the subscription, the service user is updated immediately ( 24 ). This update information has all the information about the service, including the service identifier, the service name, the IRP, the interface address of the service, physical information about the service as well as the service status. When a service registers, service users whose subscription matches to the registered service, are updated. In other words, a service user automatically receives service information with which it is involved with. To manage service subscription, the extended naming service framework ENS can build dynamic table concerning the relationship between clients and the services. By using this table the ENS is able to push information concerning the service status changes only to the clients that are interested of the IRPs in question.  
         [0068]      FIG. 3  represents an example of a graceful shutdown procedure. Graceful shutdown means degradation of a system in such a manner that it continues to operate, but provides a reduced level of service rather than failing completely. Graceful shutdown may happen, e.g. during system shut down or during service provider upgrade.  
         [0069]     The extended naming service framework ENS is up and running. The HAS initiates ( 30 ) the shutdown sequence of the service provider. Initiating a shutdown sequence means that new requests are not accepted any more. The service provider indicates (deregistration message) to the framework that it is gracefully shutting down ( 32 ). The extended naming service framework ENS removes the service information from its list of available services. It also updates all the users who are aware of this particular service instance with the new status of the service. Further, the extended naming service framework ENS informs the service provider SP that all service users being aware of the service have been updated ( 34 ). Finally, the service provider SP informs the HAS that the shutdown sequence has been completed and shuts down itself ( 36 ). Because all service users which were aware of this particular service instance are updated, the service users do not initiate any new transactions with the service instance.  
         [0070]      FIG. 4  represents an example of service switchover. In  FIG. 4 , a recovery unit on which a particular service instance is running switches over.  
         [0071]     The initial state of  FIG. 4  is that the service user is aware of both active and standby instance of a service which serves, e.g. some database fragment. The extended naming service framework ENS is up and running and is registered as a consumer for notifications regarding recovery unit switchovers from the CORBA Notification service.  
         [0072]     The extended naming service framework is listening to HAS notifications regarding status change (active or standby etc.) of recovery units. It receives a notification that the status of a particular recovery unit has gone to standby mode ( 40 ). It maps this switchover information to the information regarding to the physical properties of the service instances as provided by the service providers themselves. In other words, the extended naming service framework ENS finds out which services were running on this particular recovery unit. As said before, the service user is assumed to be aware of both the active and standby instance of a particular service. The recovery unit which hosted the active instance of the service has switched over and gone to standby. Therefore, the extended naming service framework ENS updates the service user SU with the changed status of the service instance (active to standby) ( 42 ).  
         [0073]     The extended naming service framework ENS now receives a notification that a particular recovery unit has switched to active state which can be mapped to the status of the services that are running on this recovery unit ( 44 ). The ENS then updates all the service users SU, which are subscribed to information about the service instances under question ( 46 ). The service users SU have now been informed of the new status of the services.  
         [0074]      FIG. 5  represents an example of retrieving the interface address for a particular service instance. The service user SU requests the interface address of a particular service by providing the service name and the service instance identifier to the extended naming service framework ENS ( 50 ). If the requested service is already registered to the extended naming service framework ENS, the ENS returns the interface address (e.g. CORBA IOR) of the requested service to the service user SU ( 52 ). If the interface address is not available, the extended naming service framework ENS generates an exception. Request for a particular interface address occurs whenever the service user needs to invoke the particular service instance and the address of the instance is not available.  
         [0075]     It is obvious to a person skilled in the art that with the advancement of technology, the basic idea of the invention may be implemented in various ways. The invention and its embodiments are thus not limited to the examples described above, instead they may vary within the scope of the claims.