text: in overview the method described herein can be understood with reference to fig3 to 5 . referring firstly to fig3 an interaction between two exemplary objects is shown where object 1 is named “ stocktake ” and object 2 is named “ inventory ”. the stocktake object 300 , includes as an attribute 302 , stock and as a method 304 , calculate . the inventory object 306 includes as an attribute 308 item 1 to item n and as methods get items ( 1 ), get items ( abc ) 310 . for the purposes of illustration it will be noted that two methods with the common name get items are included in the object . this is because in some implementations it is possible to “ overload ” a method name such that two different methods may have the same name , for example . in such implementations the methods are distinguished by an associated argument which may be a string or integer . for example in the case of the overloaded method name get items , get items ( i ) has an integer argument which could be distinguished from other integer arguments or any string argument whereas get items ( abc ) has a string argument distinguishable from other string arguments or any integer argument . in addition each object lists its interface / acl pairs . for example the inventory object 306 may list , at 314 , the interface / acl pairs that it implements , for example an interface a may have an associated acla , interface b has aclb and interface c has aclc . accordingly in order for the stocktake object to perform the operation calculate stock it needs to call , say , the method get items ( 1 ) as shown by arrow 312 from the inventory object which then invokes the method applying the policy corresponding to the appropriate interface according to the interface / acl pair as discussed in more detail below . the inventory object then returns the information to the stocktake object which can then populate the attribute stock with the returned data . in the present example it is assumed that each acl or policy associated with the relevant interface dictates that the method is only useable by a pre - determined group for example executives , managers , warehouse operatives and so forth . fig4 shows conceptually one manner in which the relationship between objects and multiple interfaces can be expressed . it will be seen that protection or resolution of conflicts between policies is required in some cases , for example , when a method is called from multiple interfaces by an object itself where each interface may have a different policy associated with it and its methods and may itself inherit methods from one or more “ parent ” interfaces . for example the stock - take object 400 may call method 1 402 , for example the get items ( 1 ) method from the inventory object 404 which then invokes the method . it can be seen that a complex hierarchical interface structure may be encountered including interfaces a , b , c , reference numerals 412 , 406 , 408 , directly invocable by the inventory object . in addition one or more of the directly invocable interfaces may themselves inherit the method from further interfaces . for example interface b 406 may inherit from parent interface a , reference numeral 412 . in the present example , where interface b 406 inherits method get items ( 1 ) 402 from interface a 412 as shown by arrows y and z , and interface c also describes get items ( i ) conflicts can arise where different policies are associated with each of the interfaces a , b or c . because the acl &# 39 ; s are typically associated with the object as it is created , whereas the methods and interfaces it implements are determined by the class , it can be seen therefore that conflicting policies for the same method can arise if the acls are inconsistent . for example the inventory object may specify by its interface acl packages 314 in fig3 that interface a has a policy acla that only executives may perform the get items method whereas interface b has a policy aclb that only managers can perform the get items method . the process described herein deals with the added complexity resulting from describing groups of methods via interfaces and in particular ensures that conflicting policies are not introduced by using different interfaces that have , or inherit , common methods , by detecting such conflicts . in particular because the specific interface used to invoke the method by the remote client is not known or at least not necessarily trusted , the problems that would otherwise arise with correct enforcement of conflicting policies do not occur and the actual method invoked can be relied on instead . the specific examples described herein are expressed in terms of the java language although it will be appreciated that the steps involved can be implemented in any appropriate manner in relation to any appropriate language where multiple inheritance is supported and a one - to - one mapping to actual methods is not required such that a method can be described in multiple interfaces or none , as in all of these cases it is vital to ensure that a consistent security policy is available when different policies are associated to different interfaces . conflict detection can be understood , in overview , referring to fig5 . at step 500 all interfaces associated with the target object together with their corresponding policies are obtained and at step 502 , all of the methods implemented by each of the interfaces and / or any of its super - interfaces are discovered . at step 504 it can be established whether more than one policy is associated with the same method by checking against a look - up table which can be dynamically populated during execution of the process as discussed in more detail below . in addition appropriate steps can be taken to allow differentiation between methods that have common names but differ in static parameter types , i . e . arguments , again as described in more detail below . as a result conflicting policies are not enforced for object method invocation policies as specified at the level of interfaces . this is because the interface selected by the client for the invocation is irrelevant and security decisions in the server are based on the actual method implemented by the class of which the object is an instance and not on the interface . it will be appreciated that the processes described as follows can be implemented at any appropriate time for example during development and either statically or dynamically as appropriate . for example when it is desired to deploy a new object appropriate checks can be carried out to ensure that there are no conflicts arising from multiple interfaces associated with the object and this can be carried out off - line or on - line as an object is created or as a method is called . the process described herein can be understood in more detail with reference to fig6 and the following exemplary code : listing 1 // detects whether there is a conflict in the proposed set of access control // policies applied to groups of methods described herein by interfaces conflictdetection ( object in , list_of_ { interface intf , acl acl } req , hashtable results ) { for every entry x in req { checkimplementsintf ( in , x . intf ); set m = fmdmethods ( x . intf , new set ( )); for every entry meth in m { methname = hashname ( meth ); old = results . get ( methname ); if (( old equals null ) or ( x . acl equals old )) { results . set ( methname , x . acl ); } else { raise “ conflicted detected ” exception ; } } } } in particular , at step 600 the inputs to the process are a list of interface / acl pairs and an object that it is desired to protect with those policies . the interface / acl pairs are , for example , defined in the programmatic description setting out how to create the object as an instance of a class , or may be read from a file or obtained in any appropriate manner . at step 602 in the “ checklmplementslntf ” step a check is carried out to ensure that , for every interface / acl pair associated with a target object , the object implements that interface for example as follows : listing 2 // ensure that the object implements the interface we want to protect . checkimplementsintf ( object in , interface intf ) { if in is not an instance of intf { raise “ conflict detected : incompatible interface ”; } } at step 603 first interface / acl pair , is selected and at step 604 all methods implemented by the interface ( or any of its parent interfaces ) are found for example , by introspecting the interfaces at run - time by using java reflection mechanisms — which are well known to the skilled reader as a method of traversing the hierarchical structure shown in fig4 to obtain information about the classes / methods / interface supported by a particular object such that detailed description is not requested here . this can be achieved for example as follows : listing 3 // recursively finds all the methods implemented by an interface or any // inherited by its superinterfaces set findmethods ( interface intf , set results ) { for all methods m in intf { results . add ( m ); } for all superinterfaces superintf of intf { results = findmethods ( superintf , results ); } return results } in step 606 , a method signature ( methname ) is computed as a function of the method name itself e . g . get items and the arguments attached to the method eg ( 1 ) or ( abc ). the combination step can be carried out by any appropriate operator , for example the method name and argument types can be concatenated to return a unique string as the hash name ( hashname ) value using any appropriate hash function as will be well known to the skilled reader : listing 4 // return a unique string for that method name and all its arguments // static types . string hashname ( method meth ) { return hash ( meth . name , “-”, classof ( meth . arg1 ), “-”, classof ( meth . arg2 ) ....) } ensuring that a unique string is obtained in each case avoids problems that could otherwise arise with overloaded methods where methods with similar or the same names but different arguments can be added for example to a sub - class . instead conflict detection is carried out in relation to a “ signature ” associated with the method that does not include interface information but contains a description of argument types so that we can allow duplicated method names . it will be appreciated that this step is only required in languages where the possibility of overloading is allowed . at step 608 a datastructure such as the table shown in fig7 is populated with entries comprising each of the discovered methods , identified by method signature , together with the acl associated with the interface in relation to which they were discovered . for example where a single method having method signature ms 1 is discovered for interface / acl pair x / aclx , then aclx is entered against ms 1 in the table . in step 609 for each of the remaining interface / acl pairs steps 604 to 608 are repeated to obtain all of the method signatures associated with each respective interface . for each iteration the method signatures returned are checked against the existing table and the table is dynamically updated during the process . in particular , at step 610 a check is carried out to see whether an acl already exists against a method signature . for example in the case of fig7 if a method signature discovered for interface z / aclz is ms 2 it will be seen that no acl is entered in the table of fig7 against it . accordingly at step 612 the table is populated for ms 2 and with the new aclz and at step 614 a “ no conflict ” output is provided against that method . if , however , an acl already exists against the method signature then at step 616 a check is carried out to establish whether it is a compatible acl with the new acl . for example , ms 1 is discovered but aclz is compatible with aclx at step 616 then an output of “ no conflict ” is provided at 614 . if , however , the acl in the table is not compatible with the new derived acl then at step 618 an output “ conflict detected ” is provided . at this stage the process can be stopped and the conflict resolved manually . alternatively , at step 620 the conflict can be resolved automatically according to any appropriate policy . for example the most specific policy amongst the acl &# 39 ; s can be adopted or the first policy found can be adopted or indeed any other approach can be pursued as appropriate . it will be noted that the table shown in fig7 can be of any appropriate type such as a look - up table and created in any appropriate manner . for example if the system is tested in a single run then the table can be populated dynamically as the process proceeds . alternatively if the system is tested incrementally then the table can be maintained and updated through each incremental run . reverting to the example discussed above with reference to fig3 and 4 , application of the process described herein can be further understood . assuming that three interfaces a , b and c can be expressed : listing 5 public interface a { getitems ( 1 ); } public interface b extends a { // also includes method get item from a getitems ( abc ); } public interface c { getitems ( 1 ); } a class can then be created that implements interfaces a , b and c : listing 6 public class inventory implements b , c { public inventory ( ) { ... } public getitems ( 1 ) { ... } public getitems ( abc ) { ... } } an object inventory is now created as an instance of the class inventory which can be expressed : if , for the previous object instance “ inventory ”, acl b is associated with interface b and acl c is associated with interface c such that only managers satisfy acl b and only executives satisfy acl c it will be seen that conflict will appear when evaluating the acl associated with the method “ getitems ( 1 )”. since the method is defined in both interface b ( via interface a ) and also in interface c , both acl b and acl c are relevant but are inconsistent with one another . then applying the process described herein , the input to the flow shown in fig6 the object “ inventory ”, the interface / acl pairs interface b / acl b , interface c / acl c are derived and , inter alia , the methods “ getitems ( 1 )” would be returned as implemented by the interfaces . the method signature would then be computed and from the table populated with the method / acl pairs the conflict would be detected and then resolved in any appropriate manner . it will be noted that the method getitems ( abc ) results in the hash value hash [“ getitems_string ”], different from the previous one , and therefore , no conflicts are found for that method . it will be appreciated that the process described herein can be implemented in any appropriate manner and in any appropriate language . furthermore the platform on which the process is implemented can be selected as required as will be apparent to the skilled reader . for example the process can be implemented in the smart frog distributed computing environment as described at http :// www . smartfrog . org . for example a plurality of remote entities 800 , 802 , 804 may implement the process including a data processors 800 a , 802 a , 804 a , a memory 800 b , 802 b , 804 b and an input / output interface for sending and receiving communications between the entities 800 c , 802 c , 804 c . each of the entities may process method calls by objects calling those methods internally to themselves or from other entities as appropriate and dynamically or statically as required to arrive at the process described herein . for example each of the entities may comprise a java virtual machine ( jvm ) residing on one or more common platforms . as a result of the approaches described herein , conflicts between policies can be avoided whilst still making use of interfaces . using interfaces to specify policy has the benefit that in statically typed languages , like java , checks at compile time ensure that extra methods are not added unintentionally and the expected abstraction provided by an interface remains unchanged . furthermore , this does not limit flexibility in choosing the right granularity of policy since many interfaces can be provided describing the same methods , policies being associated with the interfaces in different objects or implementations of the interface , without conflict arising . it will further be appreciated that the approaches described herein can be implemented in the case of any multiple interface configurations or other statically defined multiple groupings of methods where a policy conflict may arise and in relation to any language , remote method invocation system and computer system as appropriate . the specific form and nomenclature applied to objects , methods and interfaces can be adopted as appropriate and it will be recognized that the terms used herein can be replaced by appropriate equivalent terms where required in implementation of other computer languages .