WO2010044066A1

WO2010044066A1 - Method and apparatus for operating a computer system

Info

Publication number: WO2010044066A1
Application number: PCT/IB2009/054517
Authority: WO
Inventors: Francesco Lodolo; Richard Collin; Brian Evans; Michal Zurowski; Aleksandar Antonic; Simo Petteri Kangaslampi; Zemariam Kinfu
Original assignee: Nokia Corporation
Priority date: 2008-10-16
Filing date: 2009-10-14
Publication date: 2010-04-22
Also published as: GB0818999D0

Abstract

A method and apparatus wherein an interface to a software component providing functionality to another component is selected and presented to the other component in dependence on a characteristic of the component requesting the functionality is described. In one embodiment, the characteristics may be the capabilities of the requesting component i.e. what capabilities the requesting component is permitted to perform, or request, from a security point of view. In another embodiment, the characteristic may be for example the version of the component performing the request. In this latter embodiment, by selecting and adapting the interface in dependence upon the version of the component, then binary compatibility between the interface presented to the requesting software component and the requesting software component can be maintained.

Description

Method and apparatus for operating a computer system

Technical Field

The present invention relates to a method and system for operating a computer system.

Background to the Invention

Application Programming Interfaces are used to provide an interface into functionality provided by one software component to other software components. The software component providing the functionality may be part of an operating system or a library component, and the API into that component will define how the other components can access and make use of the functionality.

Summary of the Invention

Various aspects of the invention will be apparent from the appended claims.

According to a first aspect of the invention, there is provided a method, comprising: operating a computer system having one or more service components that provide functions to one or more other client components via interfaces to the or each service components, the method further comprising, upon a service component being required to provide its function(s) to a client component, the following: determining at least one characteristic of the client component; adapting the interface of the service component in dependence on the determined client component characteristics; and using the adapted interface for interaction between the client component and the service component.

According to a second aspect of the invention there is also provided an apparatus, comprising: at least one processor; and at least one memory including computer program code, the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to perform at least the following: determine at least one characteristic of a client component; adapt an interface of a service component in dependence on the determined client component characteristics, the service component being arranged to provide one or more functions to the client component via the interface of the service component; and use the adapted interface for interaction between the client component and the service component. According to a third aspect of the invention there is provided an apparatus, comprising: one or more service components that provide functions to one or more other client components via interfaces to the or each service components; a client component characteristic checker arranged in use to determine at least one characteristic of a client component; a service interface selector arranged in use to adapt the interface of a service component in dependence on the determined client component characteristics; the checker and selector being operable upon a service component being required to provide its function(s) to a client component, whereby an adapted interface is provided for interaction between the client component and the service component.

Brief Description of the Drawings

For a more complete understanding of example embodiments of the present invention, reference is now made to the following descriptions taken in connection with the accompanying drawings in which: -

Figure 1 is a block diagram of a service component interface;

Figure 2 is a block diagram illustrating the interface segregation principle;

Figure 3 is a block diagram illustrating a security arrangement;

Figure 4 is another block diagram illustrating a security arrangement Figure 5 is a block diagram illustrating another security arrangement;

Figure 6 is another block diagram illustrating a security arrangement;

Figure 7 is a further block diagram illustrating a security arrangement;

Figure 8 is a further block diagram illustrating a security arrangement

Figure 9 is a block diagram illustrating a first embodiment of the present invention; Figure 10 is a block diagram illustrating a second embodiment of the present invention;

Figure 11 is a flow diagram illustrating the operation of the first embodiment of the present invention;

Figure 12 is a flow diagram illustrating the operation of the second embodiment of the present invention; and Figure 13 is a block diagram of a computer system that provides the operational environment for the first and second embodiments of the invention.

Description of the Embodiments Within almost any software system one software component has to rely on another software component to perform some functions. To accomplish this, the software component which requires the function to be performed uses a set of standardised requests, called an application program interface (API) that has been defined for the software component being called upon. Almost every software component depends on the APIs of the underlying operating system to perform such basic functions as accessing a file system on the host. Other APIs to software components which are not part of the operating system but which are otherwise installed on the host are also available, and provide the functionality of the software component providing the API to other software components. Typically, a software component may provide an API to provide its functionality to several different other software components installed on the host.

Figure 1 illustrates a first software component 10 providing a first service to client software components client A (12), client B (14), and client C (16). In this case, each of the clients A, B and C require the software component 10 to provide a different function from that required by the other clients. Hence, the software component 10 contains functionality relating to client A, functionality relating to client B, and functionality relating to client C. However, in Figure 1, the software component 10 provides a common interface to all of the clients 12 to 16, such that all of the clients 12 to 16 can see the functionality provided for the other clients. That is, the API into software component 10 is the same for each of clients A to C, such that, at least in theory, and in the absence of any other capability check, client A could, for example, request a function reserved for clients B and/or C.

There are obvious drawbacks to such a situation. In particular, there are security implications, in that each of the client software components can see the functions provided by the service component 10 to the other clients. Therefore, if one of the client programs was in fact a malicious program, it may try to use the common interface to request the service component 10 to perform a function which that client is not authorised to ask the service component to perform. In addition, whenever a change is made to one of the functions that one of the clients calls, with the common interface the other client programs may be affected (or, more precisely, the functions provided to the other client programs may be affected). It may then become necessary to recompile and redeploy the entire service component 10.

In order to avoid the above problems, a principle referred to herein as "interface segregation" may be used. The essence of the principle is straightforward, in that if one has a software component 10 that has several client components, rather than loading the software component 10 with all of the functions that the clients need, then instead it should be possible to create specific interfaces for each client program, or each type of client program. The interface segregation principle is shown in Figure 2. Here, the service component 10 still performs functions for clients A, B and C, but instead of providing a common interface, instead the service component 10 provides separate interfaces 22, 24 and 26 to each of clients A (12), B (14) and C (16). The advantage of such a technique is that if an interface for one of the clients needs to change, then the interfaces for the other clients will remain unaffected.

It should be noted that the interface segregation principle does not mean that every client program that uses the service must have its own special interface. Rather, preferably client programs should be categorised by their type, and interfaces for each type of client should be created. If two or more different client types need the same function, then the function should be added to both of their interfaces.

Such an interface segregation principle can be difficult to apply in practice, as it either needs to be designed in from the start, in which case all of the client programs which use a service component must be known, or else it is very difficult to implement. For example, within a particular system architecture there may simply be no possibility to expose one interface to a client and a different interface to another client..

In addition, interface segregation raises issues for the management of binary compatibility (i.e. ensuring that an appropriate version of an interface is presented to a particular software component, dependent on the component's version). Binary compatibility may be solved with a strict control of interface changes, but this places a large management burden on developers and handset manufacturers alike. There is no mechanism to enforce binary compatibility automatically, which would offer the right interface version to a client program. As a consequence of all of the above, the interface segregation principle, although it is recognised as providing benefits, has not heretofore been applied.

Embodiments of the invention (to be described further below) address the above problem by providing a method and system wherein an interface to a software component providing functionality to another component is selected and presented to the other component in dependence on a characteristic of the component requesting the functionality. In a first embodiment, the characteristics may be the capabilities of the requesting component i.e. what actions the requesting component is permitted to perform, or request, from a security point of view. In a second embodiment, the characteristic may be for example the version of the component performing the request. In this latter embodiment, by selecting or adapting the interface in dependence upon the version of the component, then binary compatibility between the interface presented to the requesting software component and the requesting software component can be maintained.

In either embodiment the characteristic of the requesting software component in which the interface is selected or adapted in dependence thereon is checked by a third software component, which has a high degree of reliability. For example, the third software component may be part of the operating system, which implicitly has a large degree of trust that it is reliable. For example, in one embodiment where the requesting process accesses the software component providing the functionality using a client server model i.e. through the interprocess communication module of the operating system, then the IPC module can check the characteristic of the client process, to determine which interface the service component 10 should present.

In another embodiment, where the functionality of the service component is provided by linking either statically or dynamically into the calling process, then the loader component of the operating system can check the characteristics of the calling component, to determine which interface should be presented to the calling component by the service component.

With the above, the interface segregation principle can be practically provided in an operating system, even where such a principle has not been used previously. In particular the embodiments of the invention to be described allow a specific interface to be provided to each client, or each type of client component, in accordance with the interface segregation principle. However, the embodiments of the invention to be described allow the interface segregation principle to be provided in an adaptive fashion, in that a characteristic of the client component is determined, and an appropriate interface provided in dependent thereon. In such a case, different interfaces can be provided more dynamically and flexibly than has heretofore been possible, in that client components are not pre-categorised with a specific interface which is then always applied. Instead, by looking at the characteristics of the component at the time the component wishes to use a service component, then the most appropriate interface for that client at that time can be determined and used. Preferably, as noted earlier, in one embodiment the characteristics of the client component comprise a set of client component capabilities, being security capabilities relating to functions that the client component is trusted to perform in the computer system. This allows information already available in a security system which will already be present on the computer system to be applied to determine interface adaptation. In addition, by looking at such security information then the most appropriate interface given the level of trust in the client component can be provided, and in particular to make sure that the client is not presented with an interface which gives the client access to functions which the client is not trusted by the security system to perform.

As also noted above in the second embodiment to be described the characteristics of the client component comprise version information relating to the client component, whereby the interface of the service component is adapted to maintain binary compatibility with the client component. In this case, it is often possible that a service component interface may have been updated when the service component is updated. For example, service components forming part of a computer system operating system will typically be used very often, and hence may also be updated often. However, a client component, and particularly one which is part of legacy software may not be updated to match updates to the service component, and hence may require an old version of the software component interface in order to maintain binary compatibility.

In one embodiment a set of available interfaces can be provided, and an appropriate interface is selected for the requesting client component. In this regard, preferably the available interfaces are associated with one or more client component characteristics, and an interface is selected which is associated with the determined client component characteristic. With such an arrangement several interfaces are provided in advance, and the most appropriate is selected and matched to a client component depending on the determined characteristics. This helps there to be a much smaller number of interfaces from which selection is made than the number of client components, as each interface can be associated with a large number of client components. Moreover, the association may be as loose as is necessary. For example, it may be that the available interfaces are indexed by only a subset of the determinable characteristics, and that as a consequence more than one interface is selectable. In such a case, the interface is selected that matches most closely the client characteristics, but preferably without exceeding any security constraints. For example, out of two suitable interfaces, if the more closely matching interface also provides access to functions which the client component is not trusted to use, then the other interface would be selected. In one embodiment, in the case the client component links to the service software component whereby to access its functions, then the determination of a client component characteristic is performed by the computer operating system loader module, and the adaptation of the service software component interface is performed by loading said service software component with an interface selected to be adapted to said client component. Moreover, in the case the client component sends a service request message (for example an inter-process communication (IPC) message) to said service component whereby to access its functions, then the determination is performed by the computer operating system service request (e.g. IPC) module, and the determined characteristics are appended to the service request message for receipt by the service component. Such arrangements allow this embodiment of the present invention to be readily adaptable for use with existing operating systems, such as Symbian OS.

Another embodiment of the invention provides a computer program or suite of computer programs arranged such that when executed by a computer system it/they cause the computer system to operate in accordance with any of the embodiments described. The embodiment also provides a computer readable storage medium, which may be any medium known in the art, that stores the computer program or at least one of the suite of computer programs. In the context of this document, a "computer-readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted in figures 9, 10, or 11. A computer-readable medium may comprise a computer-readable storage medium that may be any media or means that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

It should be noted that embodiments of the present invention may find applicability in any type of computer system, whether it be a general purpose or embedded computer system. For example, embodiments of the invention may comprise any general purpose computer system such as laptop, desktop, or netbook personal computer, of any size or form factor. Similarly the embodiments of the invention may be used in larger computers, such as mainframes, or servers. Embodiments of the invention are also particularly suitable for use in embedded computers, and particularly those found in smartphones. Other applications where computer systems can be employed can also be found for embodiments. The following constitutes a non-limiting list: audio-visual equipment such as set top boxes (decoders); televisions; disk (e.g. DVD, HD-DVD, Blu-Ray) players and recorders; video games consoles (handheld or otherwise); portable audio and video players; audio signal processing equipment such as surround sound amplifiers; digital cameras; domestic appliances such as fridges, freezers, washing machines, cookers, ovens, dishwashers, microwave ovens;, kettles, toasters, etc; telecommunications equipment such as routers, terminals, switches etc.; vehicles, such as cars, trucks, trains, and aircraft. Many further applications of embedded computer systems which may use embodiments of the invention will be apparent to those skilled in the art.

There follows below a description of two specific embodiments of the invention that each make use of interface segregation. Before describing the specific embodiments in detail, a brief overview of the operation of each embodiment will be given.

More particularly, a first specific embodiment of the invention allows a software component which is providing a service or functionality to another component to adapt or select its interfaces that are presented to the other component in dependence on the capabilities of the requesting component. In this respect, in this embodiment a "capability" is an authorisation token that indicates that its owner has been trusted to not abuse resources protected by the token. This authorisation token can grant access to sensitive APIs such as device driver APIs, or system data such as system settings. For example, one capability may be "read user data", whereas another capability may be "write user data". Such capabilities grant the application access to APIs that access and modify the user's private data, such as contacts in a smartphone. Where a software component has a capability then that allows the software component to access the API which services that capability, notwithstanding that the API may also provide other capabilities, which are not supported. This is because, historically, access to interfaces by components based on component capability has not been enforced.

The concept of "capabilities" is used in particular in the context of platform security ("PlatSec") in the Symbian operating system. Platform security in Symbian is described in further detail in chapter 8 of Sales, "Symbian OS internals", John Wiley and Sons Ltd., 2005, but the basic concepts will be described next with respect to Figures 2 to 8. It should be noted that these basic concepts are described here as they form the background for and are a part of the present embodiment.

More particularly, in the present embodiment an executable component that wishes to make use of interface segregation in accordance with the present embodiment will have a set of capabilities, which define the actions that that component may take, and the functions that it may request other components to perform for it. These capabilities will never change during the lifetime of the component. In terms of a software component having particular capabilities accessing functionality provided by another component, there are essentially two main routes. The first is based upon the client-server model, in that the requesting component can be treated as a client process of a server component. In this case, a request is sent from the client process to the server process via the interprocess communication (IPC) module of the operating system, which allows the IPC module to then check the capability of the client process, and append the client process capabilities to the IPC message which is passed to the server process. In this way, the requesting client process cannot lie about its capabilities, to the server process.

Figure 3 illustrates this technique in more detail. Here, the client process 34 has capabilities {cap 1, cap 2, cap 3}. It requests, via an IPC message, the server process 36 to perform a function in accordance with cap 1. The IPC module 32 in the operating system appends the client process capabilities to the IPC message, such that the server process, when it receives the IPC message is able to see that the requesting client process has the capability to perform the requested function. In the present case, the client process 34 is requesting the server process to perform cap 1. In this case, the client process has cap 1, and hence the server process is able to perform the requested function.

Figure 4 illustrates the procedure where the capability check results in the server process being unable to perform the requested function. Here, the client process 34 has requested the server process 36 to perform a function relating to "cap 4". However, the client process only has the same capabilities as previously i.e. {cap 1, cap 2, cap 3 }. Hence, the server process 36 is able to detect that the client process 34 is not endowed with the capability to perform the function relating to "cap 4", and hence does not serve the request.

Another way of linking functionality from one software component to another is by linking from libraries of common functions, such as dynamic link libraries. Here, there are two types of linking, static linking, wherein code is placed into an executable when it is built, and dynamic linking, wherein code is linked into an executable at run time. In terms of static linking, in the present embodiment, a process cannot load a DLL that has a smaller set of capabilities than it has itself, and neither can a DLL statically link to a DLL that has a smaller set of capabilities than it has itself. Such rules of operation prevent malicious or untrusted code being loaded into sensitive processes, for example a plug-in into a system server. The rules also encourage the encapsulation of sensitive code inside well known processes. The loader (part of the operating system) provides a security mechanism, and checks when a static or dynamic link has been performed as to the capabilities of the linking process. Examples of the application of these rules are given next in respect to Figures 5 to 8.

More particularly, Figure 5 illustrates the situation where linking process 52, having capabilities {cap 1, cap 2} tries to statically link to linked process_l 54, having capabilities {cap 1, cap 2, cap 3 }. Such a link is permitted, because the linked process_l 54 has greater capabilities than the linking process 52. However, assume further that the linked process_l 54 is further trying to statically link in functionality from linked process_2 56, which has capabilities {cap 1, cap2}. Here, the load fails, because linked process_2 56 has fewer capabilities than linked process_l 54.

Figure 6 shows the opposite of this. Here, the two static links are fine, and are loaded successfully, because in each case the process which is linked to has greater capabilities than the linking process. That is, the linking process 52 having capabilities {cap 1 and cap 2} is linking functionality in from linked process_l 54 having capabilities {cap 1, cap 2, cap 3 } which itself links in functionality from linked process_3 58, having capabilities {cap 1, cap 2, cap 3, cap 4}.

For dynamic linking, the platform security provided by the capability check is different. Figure 7 illustrates the case where linking process 62 having capabilities {cap 1, cap 2} dynamically links in functionality from linked process 64, having capabilities {cap 1, cap 2, cap 3 }. In this case, the link is successful. However, linked process 64 also dynamically links in functionality from linked process 66, having capabilities {cap ,1 cap 2}. Here the capabilities of link process_2 are less than those of link process_l, and hence if this was a static link the link would fail. However, for dynamic linking the list of capabilities is compared against the original linking process, i.e. in this case linking process 62. In this case, linked process_2 having capabilities {cap 1, cap 2} has the same capabilities as linking process_l, 62, and hence the link succeeds. The same also applies in Figure 8, even though in this case linking process_l 64 and linked process_3, 68 both have greater capabilities than the linking process 62.

The above details of various platform security techniques are relevant to the first embodiment of the invention because in the first embodiment the capability checks provided by the platform security techniques are used to determine the capability of a software component which is requesting functionality from another component, and to determine which interface the requested component should present to the requesting component, in dependence on the capabilities of the requesting component. In such a way, any existing platform security capability checking can be employed for a secondary use i.e. that of enforcing the interface segregation principle. As described previously, the interface segregation principle has not heretofore been used, even though it presents significant technical advantages. Therefore, in the first embodiment, described in detail later, the capability checking procedures used in platform security can also be used for the second purpose of enabling the interface segregation principle, by allowing the capabilities of a process to be checked, and to then present the correct API of a server process to the requesting process.

In addition, in a second specific embodiment, in order to ensure binary compatibility between a requesting process and a serving process the API can be selected or adapted in dependence on the version of the requesting process. Again, this can be performed by the same modules of the operating system that enforce platform security i.e. the loader in the case of a dynamic or static link, or the IPC module, in the case of a client server request. In this case, the OS module responsible checks the version of the requesting process, and then loads the server process with the appropriate interface, or informs the server process of the version, so that it can present the appropriate interface to the requesting process. Such ensures binary compatibility between the requesting process, and the server process, meaning that where a server process has been updated to provide additional functionality, with a new API, then it can still retain the old API which had previously been presented to existing processes, for use with existing processes which have not been updated to accommodate the new API.

The first specific embodiment of the present invention will now be described in more detail with reference to Figures 9, 11, and 13.

More particularly, Figure 9 illustrates two processes, PROCESS_X (90) having capabilities {cap 1, cap 2, cap 4 ,..., cap_n}. PROCESS_X requires functionality from server process 942, which provides one of a number of APIs: API_1, API_2, API_3, ..., API_N (944). Both PROCESS_X (90) and server process 942 are running on a computer system 91 having an operating system with a kernel, which, as described previously, may be any of a general-purpose computer system or an embedded computer system. The API presented to a process which wishes to make use of the server process 942 depends, in the first embodiment, on the capabilities of the requesting process 90. These are checked via a capability checker module 92, in the operating system. The capability checker module 92 may, for example, be the IPC module, in the case of a client server request, or the loader, in the case of a dynamic or static link between PROCESS_X (90), and linked-to process 942.

Figure 13 shows the computer system 91 in more detail, as well as a computer readable medium 138 storing the software components that are used in the present embodiment. The computer system 91 comprises a processor 134, and at least one input/output interface 136, that allows user inputs to be made to control the computer, and allows the output of the computer system to be provided, via one or more output devices (screen, speaker, etc.), to a user. The computer system 91 also includes computer readable medium 138, which may be disk based, such as a hard disk, solid state, such as a Flash memory, or any other computer readable medium. The computer readable medium stores software code which when run by the processor 134 forms PROCESS_X 90, server process 942, and APIs 944. Additionally provided is operating system code 132, to enable the computer system to operate. A suitable O/S may, for example, be the Symbian OS, as is used in many smartphones, although another OS may be used.

Focusing on the APIs 944, as mentioned, the server process 942 has several APIs 944, which collectively provide the software component 94 with interfaces to different clients. As noted previously, the interface segregation principle does not enforce a separate API per client PROCESS_X, but instead recommends categorising calling processes into types, and providing an individual API for each type. Therefore, several APIs may be provided, dependent upon sets of capabilities, common to different processes. However, a different API does not need to be provided for each combination of different capabilities that a calling process may have. Thus, for example there may be key capabilities upon which APIs are selected in dependence thereon. For example, if a process has a particular capability, say cap 4, then a particular API e.g. API_3, may be presented to that process. Therefore, for each API, there will be an associated set of capabilities which a calling process must have one or more thereof, in order to be presented with that API. Where more than one API may be appropriate dependent on the calling process's capabilities then the API selected is the API relating to a list of capabilities which are included in the list of capabilities belonging to the process. If there is an API which has in its list of capabilities a capability which the process does not possess, then that API should not be presented to the calling process.

For example, imagine PROCESS_Y has capabilities {cap 1, cap 2, cap 3 }. Next, imagine that there are five APIs: AP_1, API_2, ... API_5. Each API has the following capabilities: API_l - {cap l } API_2 - {cap I, cap 3 } API_3 - {cap 1, cap 2, cap 3, cap 4} API_4 - {cap 1, cap 2, cap 5, cap 6} API_5 - {cap l, cap 5}

In this case, it would appear that API_3 most closely matches the capabilities of the process, as API 3 has all of cap 1, cap 2 and cap 3, as does PROCESS_Y. However, API_3 also relates to processes which have cap 4, which PROCESS_Y does not have. Therefore, by presenting API_3 to PROCESS_Y, it will allow the process to access functions relating to cap 4, even though the process is not permitted to do such functions.

Likewise, the same applies to API_4 and API_5. Although API_4 contains cap 1 and cap 2, which PROCESS_Y possesses, it also contains cap 5 and cap 6. Likewise, API_5, although having cap 1, which is possessed by PROCESS_Y, also relates to cap 5. Therefore, both API_4 and API_5 would be unsuitable for presentation, as they would allow access to capabilities which the process does not possess.

The appropriate APIs are, therefore, those of which the calling process possesses all of the capabilities, with reference to the APIs' lists of capabilities. In the above example, these are API_1 and API_2. To select between the two, preferably that API which meets most of the capabilities is given. In this case, this is API_2, as this is intended for two capabilities i.e. cap 1 and cap 3, rather than API_1, which merely relates to cap 1.

In such a way, a process is not presented with an API which is intended for a capability which the calling process does not possess. Had there been a further API, API_6, having capabilities cap 1 and cap 2, then such an API would have been equally as applicable as API_2, and either may have been presented.

In terms of how the software component 924 presents the selected API this will depend on how the function is accessed by the calling process. For example, where the software component 94 is in a dynamic link library (DLL) which is either statically or dynamically linked to, then the capability checker 92 will be the loader in the operating system. Here, the loader may load the software component 94 with the appropriate API, dependent on the capabilities of the calling process 90. Alternatively, in a client server model, here the IPC module merely appends the client capabilities to IPC messages, and the server program is already running. In such a case, the server program, being component 94, then adapts its interfaces in dependence on the IPC message received, to select and present the interface it desires in dependence on the above. Therefore, the controlling logic to select the API will depend upon how the software component 94 is being linked to, i.e. whether it needs to be in an operating system module, or in the component itself.

Figure 11 summarises the above operation. Here, at block 11.2 the APIs are arranged per process capability. That is, as discussed above, each API is associated with a particular set of capabilities, and the appropriate API is then selected and presented dependent on the capabilities. When the functionality provided by the software component 94 is to be accessed by a calling process, then at block 11.4 the capability checker, being either the IPC module, or the loader in the OS, checks the calling process capabilities. Then at block 11.6, as mentioned the server software component 94 is either loaded with the appropriate API, or the component itself selects the appropriate API, dependent on the access technique to the functionality provided by the component.

Further details of the second specific embodiment will now be given. Within the second embodiment, binary compatibility between a calling process and a called process is maintained, by presenting to the calling process an interface dependent upon the version of the calling process.

More particularly, as shown in Figure 10 here a calling process 100, being PROCESS_X, and having version number 1.1, calls functionality from software component 104, comprising a server process 1042, and having a plurality of APIs. Both PROCESS_X (100) and software component 104 are running on a computer system 101 having an operating system with a kernel, which, as described previously, may be any of a general-purpose computer system or an embedded computer system. Each API may relate to a particular version, or, more preferably, to prevent a proliferation of APIs, a range of version numbers of calling PROCESS_X. Moreover, each API may in fact relate to different processes, and cover a range of different versions of those different processes. Therefore, for each API there will be attendant meta-data specifying the process names to which the API relates, as well as the range of process versions relating to the named processes.

Figure 13 shows the computer system 101 in more detail, as well as a computer readable medium 138 storing the software components that are used in the present embodiment. As described previously, the computer system 101 comprises a processor 134, and at least one input/output interface 136, that allows user inputs to be made to control the computer, and allows the output of the computer system to be provided, via one or more output devices (screen, speaker, etc.), to a user. The computer system 101 also includes computer readable medium 138, which may be disk based, such as a hard disk, solid state, such as a Flash memory, or any other computer readable medium. The computer readable medium stores software code which when run by the processor 134 forms PROCESS_X 100, server process 1042, and APIs 1044. Additionally provided is operating system code 132, to enable the computer system to operate. A suitable O/S may, for example, be the Symbian OS, as is used in many smartphones, although another OS may be used.

In operation, when PROCESS_X (100) attempts to access the functionality provided by component 104, then a version checker module 102 in the operating system determines the version of PROCESS_X, and either loads the server process 1042 with the appropriate API 1044 (in the case of a library function which is being linked to), or passes the version number of PROCESS_X to the linked-to process (in the case of a client server request using IPC). Figure 12 summarises the procedure. That is, at block 12.2 the APIs are arranged per version, as described above. When the PROCESS_X (100) attempts to access the functionality provided by software component 104, then at block 12.4 the version checker, being either the IPC module, or the loader in the operating system, as appropriate, checks the version, and then at block 12.6 the API relating to the version is presented to the calling process. In this way, binary compatibility between the API presented to the process, and the process version, can be guaranteed.

The embodiments of the invention therefore provide, as described, mechanisms to adapt the interface of a software component dependent on characteristics of another software component which wishes to access the functionality of the first component. This enables the interface segregation principle mentioned previously to be implemented. The interface segregation principle brings benefits, in that should the functions accessed by one interface need to be altered or updated, then this does not affect other functions, which are accessed through the other interfaces. Thus, software updates can be managed more easily.

Additionally, interface segregation as used in the first and second embodiments allows a component provider to control an interface offered to the client, rather than letting a client achieve any interface that it likes. Security is therefore increased, as a client is presented only with an interface relating to the functions which the client has the capability to do, and is not presented with an interface which allows it to perform functions or request functions which the requested client does not have the capability to do. Although the platform security procedures in place may in any event prevent such a client module requesting such a function, by preventing the client from even seeing an interface which allows such functions to be accessed, security is enhanced.

Additionally, the second embodiment allows binary compatibility to be maintained between a client process, and a server process. This allows a single server component, provided with different interfaces dependent on different client process versions, to provide functionality to newer processes, of higher versions, as well as legacy processes, of lower versions. This gets rid of the need to have different server components for different client processes, or different versions of client processes.

Finally, it should be noted that the concepts embodied by the first and second embodiments are examples of reflective and introspective software design techniques. In this respect, introspection in the field of computer programming refers to the ability to examine something to determine what it is, what it knows, and what it is capable of doing. In this respect, in the present embodiments, the version checker or capability checker is an example of an introspective module, as it is able to examine the calling processes, to determine their capabilities of versions. Additionally, the ability to present a different interface in dependence on the information obtained from the introspection is an example of reflective software design. In this respect, reflection is the process by which a computer program can observe and modify its own structure and behaviour. That is, in this case, the reflective aspect of the presently described embodiments is that an API is presented to a process, in dependence on what has been determined (through introspection) about a characteristic of the process.

If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the above-described functions may be optional or may be combined.

Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims. It is also noted herein that while the above describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.

Claims

1. A method, comprising: operating a computer system having one or more service components that provide functions to one or more other client components via interfaces to the or each service components, the method further comprising, upon a service component being required to provide its function(s) to a client component, the following: determining at least one characteristic of the client component; adapting the interface of the service component in dependence on the determined client component characteristics ; and using the adapted interface for interaction between the client component and the service component.

2. A method according to claim 1, wherein the characteristics of the client component comprise a set of client component capabilities, being security capabilities relating to functions that the client component is trusted to perform in the computer system.

3. A method according to claim 2, wherein the adapting comprises selecting or modifying the interface such that the interface does not possess security capabilities that the client component does not possess.

4. A method according to any of the preceding claims, wherein the characteristics of the client component comprise version information relating to the client component, whereby the interface of the service component is adapted to maintain binary compatibility with the client component.

5. A method according to any of the preceding claims, wherein the adapting comprises selecting an interface from a set of available interfaces, the available interfaces being associated with one or more client component characteristics, and an interface being selected which is associated with the determined client component characteristics.

6. A method according to any of the preceding claims, wherein in the case the client component links to the service software component whereby to access its functions then the determining is performed by the computer operating system loader module, and said adapting comprises loading said service software component with an interface selected to be adapted to said client component.

7. A method according to any of the preceding claims, wherein in the case the client component sends a service request message to said service component whereby to access its functions, then the determining is performed by the computer operating system service request module, and said at least one determined characteristic are appended to the service request message for receipt by the service component.

8. An apparatus, comprising: at least one processor; and at least one memory including computer program code the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus to perform at least the following: determine at least one characteristic of a client component; adapt an interface of a service component in dependence on the determined client component characteristics, the service component being arranged to provide one or more functions to the client component via the interface of the service component; and use the adapted interface for interaction between the client component and the service component.

9. An apparatus according to claim 8, wherein the characteristics of the client component comprise a set of client component capabilities, being security capabilities relating to functions that the client component is trusted to perform in the computer system.

10. An apparatus according to claim 9, wherein the adapting comprises selecting or modifying the interface such that the interface does not possess security capabilities that the client component does not possess.

11. An apparatus according to any of claims 8 to 10, wherein the characteristics of the client component comprise version information relating to the client component, whereby the interface of the service component is adapted to maintain binary compatibility with the client component.

12. An apparatus according to any of claims 8 to 11, wherein the adapting comprises selecting an interface from a set of available interfaces, the available interfaces being associated with one or more client component characteristics, and an interface being selected which is associated with the determined client component characteristics.

13. An apparatus according to any of claims 8 to 12, wherein in the case the client component links to the service software component whereby to access its functions then the determining is performed by the computer operating system loader module, and said adapting comprises loading said service software component with an interface selected to be adapted to said client component.

14. An apparatus according to any of claims 8 to 13, wherein in the case the client component sends a service request message to said service component whereby to access its functions, then the determining is performed by the computer operating system service request module, and said at least one determined characteristics are appended to the service request message for receipt by the service component.

15. An apparatus, comprising: one or more service components that provide functions to one or more other client components via interfaces to the or each service components; a client component characteristic checker arranged in use to determine at least one characteristic of a client component; a service interface selector arranged in use to adapt the interface of a service component in dependence on the determined client component characteristics; the checker and selector being operable upon a service component being required to provide its function(s) to a client component, whereby an adapted interface is provided for interaction between the client component and the service component.

16. An apparatus according to claim 15, wherein the characteristics of the client component comprise a set of client component capabilities, being security capabilities relating to functions that the client component is trusted to perform in the computer system.

17. An apparatus according to claim 16, wherein the service interface selector selects or modifies the interface such that the interface does not possess security capabilities that the client component does not possess.

18. An apparatus according to any of claims 15 to 17, wherein the characteristics of the client component comprise version information relating to the client component, whereby the interface of the service component is adapted to maintain binary compatibility with the client component.

19. An apparatus according to any of claims 15 to 18, wherein the service interface selector is arranged to select an interface from a set of available interfaces whereby to adapt said interface, the available interfaces being associated with one or more client component characteristics, and an interface being selected which is associated with the determined client component characteristics.

20. An apparatus according to any of claims 15 to 19, wherein in the case the client component links to the service software component whereby to access its functions then the client component characteristic checker and service interface selector are both provided by the computer operating system loader module, wherein said adapting of said interface comprises loading said service software component with an interface selected to be adapted to said client component.

21. An apparatus according to any of claims 15 to 20, wherein in the case the client component sends a service request message (for example an inter-process communication (IPC) message) to said service component whereby to access its functions, then the client component characteristic checker is provided by the computer operating system service request (e.g. IPC) module, and said determined characteristics are appended to the service request message for receipt by the service component.

22. A computer program or suite of computer programs arranged such that when executed by a computer system it/they cause the computer system to operate in accordance with any of claims 1 to

7.

23. A computer readable storage medium storing a computer program or at least one of the suite of computer programs according to claim 22.