Abstract:
An interface module for a telecommunications network service entity, the interface module being operable to communicate with an application provided on the telecommunications network service entity and a session layer of the telecommunications network service entity, the interface module comprising a generic container to communicate with the application and a protocol connector operable to communicate with an API of the session layer and the generic container, wherein the protocol connector is operable to receive a message from the protocol stack API in accordance with a corresponding protocol, and pass the message to the generic container, which passes the message to the application.

Description:
FIELD OF THE INVENTION 
       [0001]    This invention relates to an interface module particularly but not exclusively for supporting services on a telecommunication network service entity. 
       BACKGROUND OF THE INVENTION 
       [0002]    The provision of a service execution platform for providing multi-media and IP based services requires the control of network resources through a number of complex protocols. The protocols can include legacy protocols based on SS7 and other SIGTRAN protocols, and also IP based protocols such as HTTP, SIP, Radius, Diameter, MSRP, MRCP, RTSP and so on. Application servers such as HttpServlet, SIP Servlet and so on provide an environment for applications which use a particular protocol, but it is difficult to adapt such servers to new protocols. 
         [0003]    To provide for portable service applications, it is known to provide a further API which can sit on top of a protocol stack to provide a network layer independent API, but again such API&#39;s are proliferating, such as the JAIN family of protocol API&#39;s. The growing numbers of possible interfaces and protocols can hinder the development and provision of new services and protocols. 
       SUMMARY OF THE INVENTION 
       [0004]    According to a first aspect of the invention, we provide an interface module for a telecommunications network service entity, the interface module being operable to communicate with an application provided on the telecommunications network service entity and a protocol stack of the telecommunications network service entity, the interface module comprising a generic container to communicate with the application and a protocol connector operable to communicate with an API of the protocol stack and with the generic container, wherein the protocol connector may be operable to receive a message from the protocol stack API in accordance with a corresponding protocol, and pass the message to the generic container, which passes the message to the application. 
         [0005]    The protocol connector may be operable to act as a listener to receive the message from the protocol stack API. 
         [0006]    The generic container may be operable to deploy one of a plurality of protocol connectors corresponding to the required protocol stack. 
         [0007]    The generic container receives protocol information from the protocol connector when the protocol connector may be deployed. 
         [0008]    The protocol connector may be operable to instantiate the required protocol resources. 
         [0009]    The generic container may be operable to permit deployment of the application when the protocol connector confirms that the required protocol resources are available. 
         [0010]    The generic container may have a generic container API to communicate with the application. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]    An embodiment of the present invention will now be described by way of example only with reference to the accompanying drawings wherein: 
           [0012]      FIG. 1  is a diagrammatic illustration of a telecommunication service platform embodying the present invention, 
           [0013]      FIG. 2  is a diagrammatic illustration of an interface module embodying the present invention, 
           [0014]      FIG. 3  is a diagrammatic illustration of a protocol connector archive, 
           [0015]      FIG. 4  is a diagram of a method of operating an interface module, and 
           [0016]      FIG. 5  is a diagram of a method of passing a message. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0017]    Referring to  FIG. 1 , an appropriate computer system for providing a plurality of services, hereinafter referred to as a telecommunication network service entity, is shown generally at  10 . Starting at the top, a service layer is generally shown at  11 . The service layer  11  includes all the programs or service applications which provide services running on the platform  10 , including interpreters and service wrappers where appropriate. The service layer  11  overlies a communication layer  12  which gives access to network, media and system resources, and this includes a plurality of protocol stacks generally shown at  13 . At  14 , a hardware layer is shown, including the physical components necessary to provide data connection channels  14   a  and signalling channels  14   b  generally to establish and receive calls over a telecommunication network. Each protocol stack  13  is provided with an appropriate interface  15 , in the form of an application programming interface (“API”). The API  15  provides a set of functions which may be called by a service application and through which the protocol stack may be accessed. An application to provide a service is shown at  16  running in the service layer  11 . To provide for inter-operability between the application  16  and a protocol stack  13 , an interface module  19  comprising a generic container  17  and a protocol connector  18  is provided between the application  16  and the protocol stack API  15  as will be discussed in more detail below. The protocol corrector  18  communicates with the protocol stack API  15 . The generic container  17  provides a generic container application programming interface  17   a  which communicates with the application  16 , and a service provider interface  17   b  which communicates with the protocol corrector  18 . 
         [0018]    To provide communication with different protocol stacks with varying APIs, the interface module  19  is provided with access to one or more protocol connector files generally shown at  20 . Each of the protocol connector files comprises an archive file requiring the necessary information to instantiate a protocol resource, particularly a desired protocol stack  13 , and provide the necessary information to the generic container  17  to facilitate deployment of the stack. As illustrated in  FIG. 3 , a protocol connector file  20  comprises a connector deployment descriptor  21  which defines the major information required by the protocol connector such as the root classes, the factory classes and other information as desired. At  22 , the protocol connector bytecode is shown, and at step  23  the protocol-specific rules required for the generic container  17 . The protocol-specific rules enable the generic container  17  to interact with the application  16  through the generic container  17   b  in an appropriate manner connected with the protocol and perform protocol-specific actions as needed. Although  FIG. 3  shows the protocol connector file as being associated with interface module  19 , the protocol connector could instead packaged the corresponding protocol stack. 
         [0019]    When it is desired to provide a new protocol stack for a new application  16 , the interface module  19  is operable as shown in  FIG. 4 . At step  30 , the generic container  17  reads the archive  20  corresponding to the protocol connector, for example by unzipping a zip file containing the archive, or otherwise. At step  31 , the general container reads the connector deployment descriptor  21 , and at step  32  loads the byte code for the protocol connector  18 . At step  33 , the generic container  17  reads the protocol-specific rules description  23  and at step  34 , instructs the protocol connector  18  to instantiate the required protocol resources. The protocol connector  18  instantiates the resources as shown at step  35 , and at step  36  reports to the generic container the list of protocol resources it has instantiated, for example one or more protocol stacks  13 , and provides a unique identifier for each resource. At step  37 , the generic container  17  receives confirmation of the instantiated protocol resources, and providing the application can be provided with the necessary protocol resources, loads the application  16  at step  38 . When a connector/protocol stack is deployed by the generic container  17 , it registers to the container and provides a factory: A factory is a mechanism that can be invoked to instantiate the objects of the connector and protocol stack, even though the container has no knowledge of the classes provided by the connector/stack. This permits the container to remain protocol agnostic. 
         [0020]    As shown in  FIG. 5  the protocol connector  19  appears as a listener to the API  15  and so when there is a signalling event, the event is duly received via the protocol connector  18 , as shown at step  39 . At step  40 , the protocol connector packages the protocol-specific message in a generic format, and sends the event to the generic container SPI  17   b.  The generic container  17  then processes the message at step  41  and forwards the messages or events to the application  16  in a protocol-agnostic manner through the generic container API  17   a  at step  42 . The generic container  17  cannot process protocol-specific events, so by encapsulating events in a generic manner the events can be passed to the application  16  without requiring any protocol-specific action from the generic container  17 . 
         [0021]    Accordingly, it will be apparent that the interface module  19  as described herein provides complete independence between the generic container, the application  16  and the protocol stacks  13  used by the application  16 . The protocol stacks  13 , the interface module  19  and the application  16  can be packaged and deployed separately. The generic container  17  is run first, the appropriate protocol connector  18  is instantiated, the appropriate protocol resources are activated, and the application  16  is then only deployed when all the protocol resources which it requires is available. The generic container is completely protocol-independent, and all the protocol-specific information required is packaged in the protocol-specific rules description  23  in the archive. Consequently, a new protocol stack may be provided simply by providing an appropriate archive  20  without needing to modify the generic container. Accordingly, it will be apparent that new protocols may be provided and new applications  16  provided in the application layer  11  without needing to perform recompilation or reinstallation of the platform  10  or the applications. In the present specification “comprise” means “includes or consists of” and “comprising” means “including or consisting of”. 
         [0022]    The features disclosed in the foregoing description, or the following claims, or the accompanying drawings, expressed in their specific forms or in terms of a means for performing the disclosed function, or a method or process for attaining the disclosed result, as appropriate, may, separately, or in any combination of such features, be utilised for realising the invention in diverse forms thereof.