GB2449882A

GB2449882A - Determining the Compatibility of a Client Application Program with a Server Interface

Info

Publication number: GB2449882A
Application number: GB0710839A
Authority: GB
Inventors: Niels Erik Joergensen; Soren Sorensen
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 2007-06-06
Filing date: 2007-06-06
Publication date: 2008-12-10
Also published as: GB0710839D0

Abstract

The invention relates to a method for determining the compatibility between a client application program and an interface on a server application program in a client-server system. The client application sends a request to the interface of the server application comprising a hash value (preferably using the MD5 algorithm). This hash value is derived from information relating to the anticipated characteristics of the server interface. When the request is received at the server interface, the hash value is used to determine if the client application is compatible with the interface of the server application.

Description

ELECTRONIC DEVICE AND METHOD FOR DETERMINING

COMPATIBILITY OF A CLIENT APPLICATION PROGRAMME WITH AN

INTERFACE

TECHNICAL FIELD

The technical field relates generally to an

electronic device and method for determining compatibility of a client application programme with an interface.

BACKGROUND

It is well known in the art for software application programmes to interact through interfaces. It is also known for such interfaces to comprise version numbers, which uniquely define the particular version of interface being used, and thereby identify a configuration and structure of that interface.

In this manner, a first client application is able to determine the particular configuration and structure of an interface being offered by a second, server application, and thereby allowing the client application to determine whether it is compatible with that interface.

Alternatively, the client application may provide the interface version number(s) of the interface(s) with which it is compatible to the server application. In this manner, the server application is able to determine if it supports such an interface.

This approach to determining interface compatibility is suitable where, for example, a client application requires a complete interface being offered by the server application, since any incompatibility will result in incorrect interaction via the interface.

Consequently, it is often sufficient for a client application to simply know whether it is fully compatible, or not, with the available interface.

However, the inventor has recognised that it is not S always the case that a client application will require use of a complete interface, but rather use only a part of the interface. Nevertheless, for the known approach, the client application is only able to determine from the interface version, whether or not it is fully compatible.

Thus, where the interface version indicates that the client application is not fully compatible, the client application is unable to determine whether the incompatibility is for required or non-required parts of the interface. Consequently, the client application is not able to use the interface, even if, in fact, it is compatible with all required features of the interface.

Furthermore, a client application generally comprises a table or list of interface version numbers with which it is compatible. In this manner, when the client application identifies an interface version number that is not identified within the table or list, it is assumed that it is incompatible with that interface.

However, it may simply be that the server application providing the interface was released after the release of the client application, and comprises an interface version that was known at the time of the release of the client application. Therefore, even if the client application is compatible with the interface, since it is not within its table or list, it is assumed that it is incompatible.

This problem is further compounded where multiple releases of a server application, comprising different interface versions, significantly increases a complexity of keeping track of interface versions with which a client application is compatible.

Thus, there exists a need for an electronic device and method for determining compatibility of a client application programme with an interface, which addresses at least some of the shortcomings of past and present methods for determining compatibility of a client application programme with an interface.

BRIEF DESCRIPTION OF THE FIGURES

The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, which together with the detailed description below are incorporated in and form part of the specification and serve to further illustrate various embodiments of concepts that include the claimed invention, and to explain various principles and advantages of those embodiments.

FIG. 1 is an illustration of a client application programme and a server application programme in accordance with some embodiments of the invention.

FIG. 2 illustrates an example of a scenario in which logical entities comprise groups of tables.

FIG. 3 illustrates a flow chart of a first part of a method for determining a compatibility of a client application programme with an interface of a server application programme in accordance with some embodiments of the invention.

FIG. 4 illustrates a flow chart of a second part of a method for determining a compatibility of a client application programme with an interface of a server application programme in accordance with some embodiments of the invention.

Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, dimensions of some of the elements in the figures may be exaggerated relative to other elements to help improve understanding of various embodiments. In addition, the description and drawings do not necessarily require the order illustrated. Apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the various embodiments so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein. Thus, it will be appreciated that for simplicity and clarity of illustration, common and well-understood elements that are useful or necessary in a commercially feasible embodiment may not be depicted in order to facilitate a less obstructed view of these various embodiments.

DETAILED DESCRIPTION

Generally speaking, pursuant to the various embodiments, there is provided an electronic device and method for determining compatibility of a client application programme with an interface of a server application programme. Those skilled in the art will realize that the above recognized advantages and other advantages described herein are merely illustrative and are not meant to be a complete rendering of all of the advantages of the various embodiments.

In accordance with embodiments of the invention, the electronic device hereinafter described may encompass any electronic device comprising a server or application programme, and is envisaged as comprising, but not being limited to, any of the following: a computer comprising a server application offering an interface that can be accessed as a whole or in smaller subsets; a computer comprising a client application arranged to access an interface and/or subsets of that interface; or any device comprising data that may be accessed via an interface and/or subsets of that interface, for example a credit card or the like comprising a microchip that is activated by a card reader, etc. Referring now to the drawings, and in particular FIG. 1, server and client applications in accordance with some embodiments of the invention are shown and indicated generally at 110 and 120 respectively. Those skilled in the art, however, will recognize and appreciate that the specifics of this example are merely illustrative of some embodiments and that the teachings set forth herein are applicable in a variety of alternative settings. For example, since the teachings described do not depend on specific relationships between applications, they can be applied to any type of interaction via an interface or the like, although a client/server relationship is shown in this embodiment.

In particular, it will be appreciated that the terms client' and server' used herein are intended for the purpose of clarity in relation to the roles of the individual applications within the specific embodiment illustrated, and are described as being non-limiting.

Turning now to FIG. 1, a first, server application is shown and generally indicated at 110, comprising an interface 130 via which a second, client application 120 is able to interact with the server application 110. The interface 130 is adapted to enable a client application, for example client application 120, to utilise one or more feature(s) and/or functional operation or logical structure of the server application 110.

For the illustrated embodiment, the server application 110, comprises or is operatively coupled to a memory element 140 as shown, and in particular is adapted to retrieve data stored within the memory element 140.

The data may be stored in any suitable format, for example within a database structure comprising logical entities, such as look-up tables.

Accordingly, the interface 130 comprises a configuration and structure corresponding to the one or more feature(s) and/or functional operation or logical structure of the server application 110, e.g. it is configured to support retrieval of data stored within the memory element 140. Furthermore, the configuration and structure of the interface 130 is arranged to correspond to the structure of the data stored within the memory element 140, e.g. a form and/or structure of the logical entities and any sub-units thereof.

The client application 120 is able to utilise one or more feature(s) and/or logical or functional operation of the server application 110 by sending requests to the server application 110 via the interface 130. Thus, when the client application 120 requires data stored in the memory element 140, the client application 120 sends a request for the required data to the interface 130. The server application 110 receives the request, retrieves the data from the memory element 140 and forwards the data to the client application 120 via the interface 130.

As will be appreciated by a skilled artisan, in order for data to be correctly requested and/or received by the client application 120, it is necessary for the client application 120 and interface 130 to be compatible, at least with respect to that part of the interface relating to the requested data.

In accordance with embodiments of the invention, a request from the client application 120 to the interface comprises a hash' value. The hash' value identifies a form or structure of logical entities within memory and is derived from information relating to an interface characteristic, as anticipated by the client application, of the interface 130. In the context of the invention, as hereinafter described, the expression interface characteristic is envisaged as encompassing, at least, one or more feature, logic or functional operation and/or one or more structural aspect of the relevant part of the interface 130.

By way of example, it is known for BluetoothTM clients to register with a Bluetooth server. The Bluetooth server may have stored thereon a picture in a variety of formats, for example in a bitmap (bmp) format, a Graphics Interchange Format (gif), or a Joint Photographic experts Group (jpg) format. Different Bluetooth clients may support different formats. In this manner, hash values may be computed for each combination of formats: hash("bmp"); hash("gif"); hash("jpg"); hash("bmp,gif") ; hash("bmp,jpg") ; hash("gif,jpg") hash("bmp,gif,jpg") In the case where a Bluetooth client supports bmp and gif formats, the Bluetooth client may request the picture with the following hash value hash("bmp;gif").

With this hash value the Bluetooth server is able to determine if the Bluetooth client is compatible (e.g. supports an appropriate format), and can then send the picture with the most suitable format, for example the smallest size (measured in bytes) of the supported formats (bmp or gif) back to the client.

For the illustrated embodiment, the client application 120 comprises hash determining logic 150, arranged to compute, or otherwise obtain, the hash value to be provided within a request.

For the illustrated embodiment, the data is stored within a database structure comprising logical entities, such as look-up tables. Therefore, when the client application 120 sends a request for data relating to logical entities stored within the memory element 140, the hash value may be derived from information relating to such logical entities, such as a form and/or structure of the logical entities and any sub-units thereof.

Upon receipt of the request by the interface 130, the interface 130 is then able to determine from the hash value whether the interface 130 and client application are compatible. That is to say, the interface 130 is able to determine from the hash value whether the logical entities within the memory element 140 comprise, for example, a compatible form and/or structure to that expected by the client element 120.

In one embodiment of the invention, the interface determines whether the received hash value is valid by identifying those logical units requested for access by the client application 120, and generating a hash value derived from information relating to the actual relevant interface characteristic. The interface 130 is then able to compare the hash value generated by itself with the hash value received with the request. If the hash values match, then the interface 130 assumes the client application 120 is compatible therewith.

The provision of such a hash value to the interface enables a compatibility to be determined between a S client application and an interface by the interface on a substantially ad hoc basis. Thus, a client application is no longer required to maintain information relating to compatible interfaces. Moreover, even when a client application comprises an earlier release date than that of an interface, the compatibility between the client application and the interface is not assumed to be false.

Furthermore, any complexity associated with keeping track associated with interface versions with which a client application is compatible is substantially alleviated.

In one embodiment, the hash value is derived from information relating to only those parts of the interface that are required for that particular request, for example those logical entities requested by the client application 120. Thus, the interface 130 is able to determine from the hash value whether the client application 120 and interface 130 are compatible, in relation to the required part of the interface 130. For example, the interface 130 is able to determine whether the logical entities stored within the memory element 140, and requested by the client application 120, comprise a compatible form and/or structure to that expected by the client element 120.

Upon determination that the client application 120 is compatible in relation to the required part of the interface 130, for example with respect the requested logical entities, the interface 130 provides the requested interface characteristic, for example the interface 130 returns the requested data, even when the client application 120 may be incompatible with other elements of the interface 130.

In this manner, a client application is only required to be compatible with relevant parts of an interface in order to be able to interact with a server application. Consequently, even if certain parts of an interface are modified or updated, a client application will not lose the ability to interact with the interface in relation to those parts with which the client application remains compatible.

In one embodiment of the invention, the hash value may be derived by way of a hash function such as a Message-Digest algorithm 5 (MD5) . The MD5 is a widely used cryptographic hash function, comprising a 128-bit hash value, and is defined in Internet standard RFC 1321.

As previously mentioned, for the example illustrated in FIG. 1, data is stored within a database structure comprising tables, each table making up a single logical entity. Each table may be defined by a descriptor, examples of which are provided below: tblnamel: fldnamel: datatypel: fldname2: datatype2:...: fldnamei: datatype_i [Descriptor 1] tblname2:fldnamel:datatypel:fldname2:datatype2:...: fldname_ j:datatype j [Descriptor 2] The first example describes a first table, tblnamel, comprising i fields, labelled fidnamel to

fldnamei. For each field a data type is defined,

datatypel to datatypei respectively.

The second example describes a second table, tblname2, comprising j fields, labelled fidnamel to

fidname j. For each field a data type is defined,

datatypel to datatype j respectively.

When the client application 120 requests data from the interface 130, the hash value is derived from the descriptor of the logical entities, namely the tables within the database structure.

In particular, the hash value is derived from the descriptor of those logical entities for which data is requested. By way of example, if the client application 120 requests data relating to the first table in the example above, the hash value is derived from Descriptor 1. Conversely, if the client application 120 requests data relating to the second table in the example above, the hash value is derived from Descriptor 2.

Thus, in the case where the hash value is derived using the MD5 hash function, the MD5 hash function is applied to the descriptor to generate a 128-bit hash value.

As will be appreciated, the client application 120 may request data relating to more than one logical entity. Thus, for the example above, if the client application 120 requests data relating to both tables, the hash value is derived from a combined descriptor, for example Descriptor 3 below: (tblnamel: fldnamel: datatypel: fldname2: datatype_2: fldnamei: datatypei; tblname2: fldnamel: datatypel: fldname2: datatype2:...: fld name_ j:datatype_ j) (Descriptor 3] As will be appreciated, the same two tables may alternatively be defined by, for example, Descriptor 4 below: (tblname2: fidnamel: datatype_l: fldname2: datatype2: :fldname j:datatype_ j; tblname2: fidname 1: datatype_l: fldname2: datatype_2 fid namei:datatypei) [Descriptor 4] As the number of logical entities increases, the number of permutations for the order in which a descriptor may define the logical entities increases. By way of example, in a case where a client application requests data relating to three logical entities, A, B, and C, there are six possible combinations in which the logical entities may be defined within a descriptor, namely: [A, B, C] , [A, C, B] , [B, A, C] , [B, C, A] , [C, A, B] and [C, B, A] Thus, in one embodiment of the invention, it is envisaged that logical entities are ordered, for example alphanumerically, within the descriptor from which the hash value is derived. In this manner, where a plurality of logical entities is requested, the specific descriptor from which the hash value is derived, and thereby the hash value itself, is predictable. Thus, for the example above, the descriptor from which a hash value is to be defined would be [A, B, C] Without any ordering of the logical entities, the interface would be required to compute each possible permutation, in order to determine whether the hash value received related to a valid descriptor. As illustrated below, this may require a prohibitive amount of processing in order to accomplish. Consequently, the ordering of the logical entities within descriptors greatly reduces the number of hash values that would be required to be maintained within the table.

It is envisaged that in one embodiment of the invention, the client application and/or the interface may compute hash values each time the client application sends a request to the interface.

Furthermore, in an alternative embodiment of the invention, the client application and/or the interface may maintain a table, or the like, of valid hash values of descriptors for all possible combinations or logical entities.

By way of example, without ordering of the logical entities, the total number of permutations for all combinations of logical entities, and thereby the number of valid hash values, may be expressed using Equation 1 below: P=P(n,i) [1] Where P(n,i) = n(n-1) (n-2)...(n-i) = ri!/(n-i) !; n is the total number of logical entities; and I is the number of logical entities within a descriptor.

In the case where there are ten logical entities, the number of permutations would still equal 9,864,100.

Maintaining a list of so many hash values is clearly prohibitive, even for such a relatively small number of logical entities.

Conversely, where the logical entities are ordered such that for each combination of logical entities a single descriptor may be predicted, the number of valid hash values will be reduced to the number of combinations. This can be expressed by Equation 2 below: K=K(n,i) [2] Where K(n,i)=P(n,i)/i!.

Now, in the case when there are ten logical entities, the number of valid hash values is 1,023, a significant reduction in comparison to where no ordering is applied.

As will be appreciated by a skilled artisan a database structure may comprise a large number of tables.

Consequently, it is anticipated that for alternative embodiments of the invention a logical entity may comprise a group of tables, as opposed to a single table, in order for the number of logical entities to be reduced. FIG. 2 illustrates a scenario in which logical entities may comprise groups of tables.

A database structure comprises tables A to G 205.

Tables A, B, C and D are used by a first client type, client type X 210. Tables D and E are used by a second client type, client type Y 215. Tables E, F and G are used by a third client type, client type Z 220.

In this scenario, client type X and client type Y 210, 215 are static client types, that is to say clients of type X always access table A, B and C and clients of type Y always access D and E. It is worth noting that the structure of table A-G might not be static. Conversely, clients of type Z 220 are likely to change, however clients of type Z are unlikely, if ever, to access tables A, B and C. Notably, tables A, B, C and D are only used by static client types X and Y 210, 215, and more specifically tables A, B and C are only ever used by client type X 210. Thus, instead of defining seven logical entities, each comprising one table, tables A, B and C may be grouped together to make up a single logical entity, whilst tables D, E, F and G each make up a single logical entity. In this manner, the number of logical entities is reduced to five.

Although table D is also used by client type X 210, it is kept as a separate logical entity so that it can more easily be accessed by client type Y 215.

Furthermore, should table D change, for example due to changes in client type Y, although client type X 210 will become incompatible with that part of the interface relating to table D, it will remain compatible with, and therefore still be able to access, that part of the interface relating to tables A, B and C. Consequently, although client type X 210 will lose a part of its ability to interact with the server application of which the interface forms a part, it will not lose all of its ability to interact therewith.

Similarly, table F forms a separate logical entity as it is used by both client type Y 215 and client type Z 220.

In an alternative embodiment of the invention, tables F and G may be grouped together to form a single logical entity, since they are both only used by client type Z 220. However, because client type Z 220 is likely to change, and thereby tables F and G are likely to change, by keeping tables F and G as separate logical entities, any changes to one will not affect the other.

As previously mentioned, by using a hash value representing only those parts of an interface that are required, a client application is not required to be compatible with the entire interface, only with certain required parts of the interface. Thus, for the example illustrated in FIG. 2, and described above, client type X 210 is only required to be compatible with that the part of the interface relating to tables A, B, C and D, and as such any request from client type X 210 will relate to the logical entity comprising grouped tables A, B and C and/or the logical entity comprising table D. In this manner, by using a hash value derived from that part of the interface relating to these two logical entities, so long as these logical entities within the interface do not change, client type X 210 will advantageously remain compatible with the interface, irrespective of whether any changes occur in relation to

tables E, F or G.

Referring now to FIG. 3 there is illustrated a flow chart 300 of a first part of a method for determining a compatibility of a client application programme with an interface of a server application programme in accordance with one embodiment of the invention. For the embodiment illustrated in FIG. 3, a hash value is computed each time a request is to be sent to the server application programme. Thus, the method starts at step 310, and proceeds to step 320, where the logical entities relating to the request are determined.

For the example illustrated in FIG. 2, client type X 210 may require data relating to Tables A, B, C and D. Accordingly, the logical entities that would be determined are table group (ABC) and table D. Next, in step 330, the logical entities are ordered alphanumerically, which for this example would be table group (ABC) followed by table D. A descriptor of the ordered logical entities is then created, in step 340, followed by a hash value being computed from the descriptor in step 350, for example using an ND5 hash function as previously described.

The request, comprising the hash value, is then sent, in step 360, and the method ends at step 370.

Referring now to FIG. 4 there is illustrated a flow chart 400 of a second part of the method for determining a compatibility of a client application programme with an interface of a server application programme, in accordance with one embodiment of the invention.

The method starts at step 410, with the receipt of a request from a client application. Next, in step 420, a hash value is extracted, or otherwise retrieved, from the received request. Having retrieved the hash value, the next step, step 430, comprises determining whether the hash value is valid, and thereby whether the client application is compatible with the interface.

As previously mentioned, the hash value has been derived from information relating to the interface characteristic (for example one or more feature logical or functional operation and/or a structure), as anticipated by the client application, of the interface.

Consequently, the interface is able to determine from the hash value whether the actual interface characteristic matches those anticipated by the client application, and if so, it can be assumed that the client application and interface are compatible.

If the hash value is valid in step 430, the method moves to step 440, where the interface performs the necessary actions to fulfil the request, or forwards the request on to the server application for the server application to fulfil the request. For the illustrated embodiment this comprises retrieving data relating to requested logical entities from a database, or the like.

Next, in step 450, a response is sent back to the client application. For the illustrated embodiment, the response comprises the data relating to the requested logical entities. The method then ends at step 460.

Referring back to step 430, if the hash value is not valid, and therefore the client application and interface are assumed not to be compatible, the method moves on to step 470, where an incompatibility message is sent back to the client application. The method then ends at step 460.

For the embodiments described herein, and illustrated in the accompanying drawings, a server/client relationship has been described comprising an interface for allowing access to data stored within a database.

However, it will be appreciated by a skilled artisan that the inventive concept may be applied to alternative forms of interfaces, such asapplication programmer interfaces (APIs), etc. As will be appreciated by a skilled artisan, the, or each, client application interacting with a server application may be executed on the same processing device as the server application. Alternatively, one or more client applications may be executed on a different processing device to that of the server application, where the client application and server application may be coupled by way of, for example, a local area network (LAN), or other networking or connecting medium.

In the foregoing specification, specific embodiments have been described. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below.

Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential features or elements of any or all the claims. The invention is defined solely by the appended claims including any amendments made during the pendency of this application and all equivalents of those claims as issued.

Moreover in this document, relational terms such as first' and second', top' and bottom', and the like' may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.

The terms comprises,' comprising,' has', having,' includes', including,' contains', containing' or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by comprises...a', has...a', includes...a', contains...a' does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element.

The terms a' and an' are defined as one or more unless explicitly stated otherwise herein. The terms substantially', essentially', approximately', about' or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art.

The term coupled' as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is configured' in a certain way is configured in at least that way, but may also be configured in ways that are not listed.

Moreover, an embodiment can be implemented as a computer-readable storage element having computer readable code stored thereon for programming a computer (e.g., comprising a processing device) to perform a method as described and claimed herein. Examples of such computer-readable storage elements include, but are not limited to, a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a ROM (Read Only Memory), a PROM (Programmable Read Only Memory), an EPROM (Erasable Programmable Read Only Memory), an EEPROM (Electrically Erasable Programmable Read Only Memory) and a Flash memory. Further, it is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation.

The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the

technical disclosure. It is submitted with the

understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the

disclosure. This method of disclosure is not to be

interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.

Claims

What is claimed is: 1. An electronic device comprising a client application programme arranged to interact with a server application programme by sending a request to an interface of the server application programme; wherein the electronic device is characterised in that the request comprises a hash value, the hash value being derived from information relating to an anticipated interface characteristic of the interface.
2. The electronic device of Claim 1 further characterised in that the hash value is derived from information relating to only those parts of the interface required for the request.
3. The electronic device of Claim 1 or Claim 2 further characterised in that the hash value is derived from information relating to logical entities of the interface.
4. The electronic device of Claim 3 further characterised in that the hash value is derived from a descriptor of one or more logical entities of the interface.
5. The electronic device of Claim 4 further characterised in that where at least two logical entities are defined by the descriptor, ordering is applied to the logical entities within the descriptor.
6. The electronic device of Claim 5 further characterised in that the ordering of logical entities is arranged alphanumerically.
7. The electronic device of any preceding Claim further characterised in that the hash value is derived using a MD5 hash function.
8. The electronic device of any preceding Claim further characterised in that the client application computes a hash value each time a request is to be sent to the interface.
9. The electronic device of any preceding Claim further characterised in that the client application comprises a table of hash values.
10. The electronic device of any preceding Claim further characterised in that the client application comprises hash logic adapted to compute, or otherwise obtain a hash value for a request.
11. An electronic device comprising a server application programme comprising an interface arranged to receive a request from at least one client application programme; wherein the electronic device is characterised in that interface is arranged to receive a request comprising at least one hash value, and upon receipt of such a request from a client application programme to determine, based on the hash value within the request, a compatibility of the client application programme with the interface.
12. The electronic device of Claim 11 further characterised by the hash value having been derived from information relating to an interface characteristic of the interface by the client application programme.
13. The electronic device of Claim 12 further characterised by the hash value having been derived from information relating to only those parts of the interface required for the request. I0
14. The electronic device of Claim 13 further characterised by the hash value having been derived from information relating to at least one logical entity of the interface.
15. The electronic device of Claim 14 further characterised by the hash value having been derived from a descriptor of the at least one logical entity of the interface.
16. The electronic device of Claim 15 further characterised in that, where at least two logical entities are defined by the descriptor, ordering is applied to the logical entities within the descriptor.
17. The electronic device of Claim 16 further characterised in that the ordering of the at least two logical entities is arranged alphanumerically.
18. The electronic device of any of Claims 11 to 17 further characterised in that the hash value is derived using a MD5 hash function.
19. The electronic device of any of Claims 11 to 18 further characterised by the interface determining whether the received hash value is valid by comparing a hash value derived from information relating to an actual interface characteristic of the interface with the hash value received with the request.
20. The electronic device of Claim 19 further characterised in that the server application programme computes a hash value to compare with a received hash value each time a request is received.
21. The electronic device of Claim 19 further characterised in that the server application programme comprises a table of valid hash values.
22. The electronic device of any of Claims 11 to 21 further characterised in that when it is determined that a hash value is invalid, the interface sends an incompatibility message to the client application programme.
23. A method for determining compatibility of a client application programme with an interface of a server application programme, wherein the method comprises: the client application programme sending a request to the interface comprising a hash value, the hash value being derived from information relating to at least one interface characteristic of the interface; and the interface receiving the request and determining whether the client application programme is compatible therewith based on the hash value within the request.
24. The method of Claim 23 further characterised in that the hash value is derived from information relating to only those parts of the interface required for the request.

S
25. The method of Claim 23 or Claim 24 further characterised in that the hash value is derived from information relating to at least one logical entity of the interface.
26. The method of Claim 25 further characterised in that the hash value is derived from a descriptor of at least one logical entity of the interface.
27. The method of Claim 26 further characterised by defining, where at least two logical entities by the descriptor, ordering the at least two logical entities within the descriptor.
28. The method of Claim 27 further characterised by ordering the at least two logical entities alphanumerically.
29. The method of any of Claims 23 to 28 further characterised by deriving the hash value using a MD5 hash function.
30. The method of any of Claims 23 to 29 further characterised by determining by the interface whether the received hash value is valid by comparing a hash value derived from information relating to an actual interface characteristic of the interface with the hash value received with the request.
31. The method of any of Claims 23 to 30 further characterised by one of: the client application programme, the server application programme, computing a hash value for each request.
32. The method of any of Claims 23 to 31 further characterised by one of: the client application programme the server application programme comprising a table of hash values.
33. The method of any of Claims 23 to 32 further characterised by, determining that the hash value is invalid, and in response thereto sending by the interface an incompatibility message to the client application programme.
34. A computer-readable storage element having computer readable code stored thereon for programming a computer to perform at least one function of the client application programme of the electronic device of any of Claims 1 to 10.
35. A computer-readable storage element having computer readable code stored thereon for programming a computer to perform at least one function of the server application programme of the electronic device of any of Claims 11 to 22.