Enabling Client Systems to Discover Services Accessible by Remote Procedure Calls (RPC) on Server Systems
Information representing the RPC servers, on which each RPC service is currently being provided, is maintained on a directory server. A client may query the directory server and determine a specific one of the RPC servers on which to cause execution of a desired RPC service. Each RPC server may also register the service interface using which the corresponding RPC services can be accessed. As a result, the same RPC service may potentially be accessed with a different service interface on different RPC servers. Another aspect of the present invention provides a schema using which procedure interface definition (i.e., the name of the procedure, the parameters, and their attributes) can be represented. Such a feature is used to store the procedure definitions on the directory server, thereby enabling a client system to determine the procedure definition prior to sending an RPC request to execute the procedure.
Latest Oracle Patents:
- User discussion environment interaction and curation via system-generated responses
- Model-based upgrade recommendations using software dependencies
- Providing local variable copies of global state for explicit computer executable instructions depending whether the global state is modified
- Efficient space usage cache on a database cluster
- Biometric based access control for DaaS
The present application is a continuation of and claims priority from co-pending U.S. application Ser. No. 10/905,298, entitled, “Enabling Client Systems to Discover Services Accessible by Remote Procedure Calls (RPC) On Server Systems”, filed on Dec. 25, 2004, and is incorporated in its entirety herewith.
BACKGROUND OF THE INVENTION1. Field of the Invention
The present invention relates to client-server technologies, and more specifically to a method and apparatus for enabling client systems to discover services accessible by remote procedure calls (RPC) on server systems.
2. Related Art
Remote procedure calls (RPCs) generally enable a client system to request services provided on server systems (“RPC server system”). In a common scenario, a RPC server system is implemented to execute a service upon receiving an RPC request, and a client system causes execution of the service by sending the RPC request. The results of execution of the service are then generally provided to the client system sending the RPC request.
In one prior embodiment, the RPC services are provided on pre-specified RPC server systems according to pre-specified RPC interfaces (e.g., TCP or UDP port number at which to send the request). Thus, any client system requiring execution of a service sends the corresponding RPC request to a RPC server system (on which the service is provided) according to the pre-specified interface.
The approach of above may have several limitations. For example, it may be desirable to provide the same service on different (or additional) RPC servers (e.g., to scale), and the clients systems may not be able to automatically (i.e., without additional configuration which specifically indicates the RPC servers on which each RPC service is accessible) discover the availability of the services on the different RPC servers.
Accordingly what is needed is a method and apparatus which enables client systems to discover services accessible by remote procedure calls (RPC) on server systems.
The present invention will be described with reference to the accompanying drawings briefly described below.
In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 1. OverviewAccording to an aspect of the present invention, information representing the RPC servers on which each RPC service is accessible is registered on a directory server. A client system may query the directory server to determine the specific RPC servers on which a desired service is accessible, and cause execution of the desired service by sending an appropriate RPC request to any of the determined RPC servers.
As a client system may dynamically determine the specific RPC server on which a desired service is available, the services accessible by RPC may be provided on any server.
According to another aspect of the present invention, each RPC server providing the service also registers (on a directory server) a corresponding interface definition, using which the RPC service can be accessed. Accordingly, different interface definitions (e.g., different TCP port numbers) may be associated with different RPC servers for execution of the same service.
One more aspect of the present invention provides a schema (which allows specification of what each data element is and any relationship with other data elements according to a pre-specific convention/language), using which a procedure interface definition can also be specified. Such a feature may be used associated with procedures, which can be caused to be executed as a part of accessing a desired service. In an embodiment, the parameters (arguments) and their attributes are specified in the form of objects hierarchically.
Several aspects of the invention are described below with reference to examples for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. One skilled in the relevant art, however, will readily recognize that the invention can be practiced without one or more of the specific details, or with other methods, etc. In other instances, well-known structures or operations are not shown in detail to avoid obscuring the features of the invention.
2. Example EnvironmentNetwork 150 provides connectivity between all the remaining systems of
RPC servers 180-A and 180-B are implemented to execute RPC services upon receipt of corresponding requests from client systems 110-A and 110-B. In general, each RPC server executes processes to receive RPC requests according to a pre-specified interface, and to provide the services specified in the RPC requests. RPC servers can be implemented on enterprise level operating systems such as Solaris, Windows XP, Linux, HP Unix etc.
Each client system 110-A and 110-B sends RPC requests to the specific RPC servers providing the corresponding services. An aspect of the present invention enables client systems to discover services accessible by remote procedure calls (RPC) on server systems using directory server 160, as described below with reference to
In step 210, RPC server 180-A registers with directory server 160 and RPC service accessible to client systems. Such registration may be performed when RPC server 180-A is initialized, for example, as a part of booting-up RPC server 180-A. In general, the registration can be according to any pre-specified convention.
In step 215, RPC server 180-A receives a RPC request to execute the registered RPC service. The request needs to be received according to pre-specified interface conventions. In step 220, RPC server 180-A executes the requested service.
In step 230, RPC server 180-A determined whether to process more RPC requests for the registered service. A determination not to process more requests can be made, for example, before shutting down RPC server 180-A. Control passes to step 215 if more RPC requests are to be processed.
In step 235, RPC server 180-A indicates in the directory server that the RPC service is no longer accessible to client systems. Such indication may be provided either by removing the registration information, or alternatively by merely setting an appropriate flag in directory server 160. In step 240, RPC server 180-A terminates providing the service and the method ends in step 249.
The manner in which client systems 110-A and 110-B can operate to discover the RPCs servers on which a desired RPC service is accessible, is described below with respect to
In step 255, client system 110-A sends a directory query to directory server 160, requesting information on the RPC servers on which a desired RPC service is available. In step 260, client system 110-A receives from directory server 160 a response indicating the RPC servers on which the desired RPC service is accessible. The query and response can be according to any pre-specified protocol. In an embodiment, lightweight directory access protocol (LDAP) version V.3 is used for the query and response.
In step 270, client system 110-A sends an RPC request to an indicated RPC server to cause execution of the desired RPC service. The RPC request can be sent using known interfaces. The flowchart ends in step 299.
Thus, using the approaches described above, client systems can determine the specific RPC server systems on which desired RPC services are accessible, and can cause the service to be executed on one of the determined RPC servers. However, it may be appreciated that typical systems need to be implemented with various enhancements. The description is continued with respect to some desired example enhancements, and then the manner in which various aspects of the present invention provide such desired enhancements.
5. EnhancementsIt is often desirable that different RPC servers be accessed with different interface parameters for the same service. For example, the TCP port number at which a service is accessible can be different in different RPC servers, thereby facilitating avoidance of conflict for the same port number (for different services).
In addition, in environments in which a client system can cause execution of specific one of procedures provided as a part of the RPC service, it may be desirable to register the procedure identifiers (as illustrated with reference to examples in below sections) and the details of various parameters (“procedure interface”) using which the procedures can be executed. Furthermore, different RPC servers may wish to restrict access (of different RPC services) to different sets of client systems.
Various aspects of the present invention enable such features described below with various examples.
6. Interface Definition Language (IDL) FileVarious aspects of the present invention enable the information in the IDL file to be represented on directory server 160 such that client systems can generate corresponding queries without having to access the IDL file (or compiled version thereof), as described below. Thus, the content of the IDL file of
Lines 301?315 contain attributes for a corresponding RPC service. Line 303 indicates the unique identifier for the RPC service using the key-word UUID. The name for the service is indicated in line 315. Line 305 indicates that the present version of the RPC service is 1. Line 307 indicates the transport or session level protocol using which the communication between the RPC client and server is allowed to happen. Line 309 indicates the machine name (with an IP address), the port number of the RPC server, at which the RPC service is accessible (service-endpoint). It may thus be appreciated that different servers can specify different service end points (port numbers) while providing the same service. Line 313 specifies the identifier for the directory server with which the service is registered (svcreg(server-ldap)).
Lines 318-324 define a structure aggegate1_t (containing ub4 or a basic C language type of size 4 bytes variable), and line 326 defines another variable ubig_ora (C language unsigned long variable of maxlength type).
Line 328 defines a procedure remoteproc1 (within the service myService), which could be executed by a client system. The procedure remoteproc1 is shown with parameter1 of type aggregate1_t as an input parameter, and parameter2 as pointer to ub4 as both an input variable and an output variable (an example of pass by reference).
It may be appreciated that information such as that contained in lines 316-330 may also need to be stored in directory server 160 such that client system 110-A can cause execution of the specific procedures (remoteproc1, in the above example) of interest. As aspect of the present invention provides a schema template, using which the procedure definition can be represented as described below in further detail.
7. Schema Template to Specify Procedure DefinitionBroadly, a procedure definition is specified using (1) object definitions; (2) attribute definitions; (3) relationship among objects; and (4) relationship among objects and attributes. (1), (3) and (4) are illustrated with reference to
With respect to
Thus, when a search request related to a procedure name is received from client system 110-A, directory server 160 uses the properties defined above in determining matching procedure names. On the other hand, a top level search could be performed on the directory server for all the RPC interfaces available and their arguments specific details. The result obtained could be used by client system 110-A to determine which of these procedures is to be executed.
Lines 410-418 define the properties for attribute ‘FunctionPrototype’ (i.e., how client system 110-A can access the procedure). The properties of lines 414, 416 and 418 are respectively the same as in lines 405, 407 and 409.
Lines 419-427 define the properties for attribute ‘ArgumentName’ (i.e., the names of input and output parameters used by the procedure). The properties of lines 423, 425 and 427 are respectively the same as in lines 405, 407 and 409.
Lines 428-436 define the properties for attribute ‘ArgumentType’ (i.e., the type of the parameters). The properties of lines 432, 434 and 436 are respectively the same as in lines 405, 407 and 409.
Lines 437-445 define the properties for attribute ‘MemberOf’ (i.e., specifies whether the attribute is a part of another attribute for example, if an C language basic type int is a member of a C language aggregate (structure or union), and enables hierarchical definition of attributes). The properties of lines 441, 443 and 445 are respectively the same as in lines 405, 407 and 409.
Lines 446-454 define the properties for attribute ‘ReturnType’ (i.e., the type of return parameters of a procedure. Depending on the third generation high level language, this could be null). The properties of lines 450, 452 and 454 are respectively the same as in lines 405, 407 and 409.
The attributes thus defined can be used to complete the procedure definition in terms of objects, as described below.
8. Object DefinitionsWith respect to
Lines 464 to 472 indicate the properties of the object class ‘FunctionArgumentObject’. The comment of line 466 indicates that the object is an argument (input parameter) to the procedure. Line 468 indicates that the present object is a child of the FunctionObject. Line 470 indicates that the attribute that must be present is an ArgumentName (defined above in lines 419-427 of
Line 474-480 indicates the properties of object class ‘TypeObject’. The comment of line 475 indicates that the object is for the input parameter or a ReturnType (output parameter). Line 477 indicates the present argument is a child of the FunctionArgumentObject, and line 478 indicates that the attribute used by the TypeObject is ArgumentType (definied above in lines 428-436). A parameter could also be a member of an aggregate. In such a case, the MemberOf attribute species the nesting of the parameter. For instance, if a member name “mem1” is a member of an aggregate “aggr1”, the MemberOf parameter for the TypeObject specific to “mem1” would contain the aggregate name specific to “aggr1”. It may be noted that “aggr1” would have a TypeObject specific to itself.
The Schema data of Appendix A contains schema representation for IDL file of
Continuing now with combined reference to Appendix A, the IDL file of
Lines 1 and 2 specify the particular node in the object tree in the directory server below which all the RPC specific entries shall reside. This could be modified across implementations. Lines 3-49 contain various attributes with corresponding properties, which are used in the object definition (described below with reference to lines 122-147 of Appendix A) of an RPC service stored in directory server 160. Each attribute is referenced through the value of the property ‘NAME’. Thus, starting in lines 4, 9, 15, 21, 27, 33, 39, and 45, the properties of attributes ‘orclNetROInterfaceName’, ‘orclNetROInterfaceBinaryAttribute’, ‘orclNetROSvcReg’, ‘orclNetROInterfaceAttributeName’, ‘ orclNetROInterfaceAttributeParameterName’, ‘orclNetROInterfaceAttributeParameterArgument’, orclNetROInterfaceAttributeParameterType’, ‘orclNetROInterfaceAttributeParameterValue’) are respectively defined. As may be appreciated properties DESC, EQUALITY, SUBSTR, SYNTAX for each corresponding Attribute is shown in 4 distinct lines below the NAME property for the attribute, consistent with the conventions of
Lines 51-85 are shown containing properties of corresponding attributes used in definition of object classes for structures of data-types stored in directory server 160. Thus, starting at lines 51, 57, 63, 69, 75, and 81, the properties of attributes with NAMEs ‘orclNetROTypeName’, ‘orclNetROTypeKind’, ‘orclNetROTypeMemberOf’, ‘orclNetROTypeAggregateSize2’, ‘orclNetROTypeAttributeName’, and orclNetROTypeAttributeParameter are respectively defined, also consistent with the conventions of
Lines 87-120 are shown containing attributes and corresponding properties used in definition of object classes for Procedures within a Service. Thus, starting at lines 87, 92, 98, 104, 110, and 116, the properties of attributes ‘orclNetROProcedureName’, ‘orclNetROPrototype’, ‘orclNetROParameterName’, ‘orclNetROParameterType’, ‘orclNetROParameterAttributeName’, and ‘orclNetROParameterAttributeArgument’ are respectively defined, also consistent with the conventions of
Lines 122-177 of Appendix A are shown containing procedure definitions in terms of objects (according to the template of
Lines 122-147 contain definitions of object classes corresponding to an RPC service. Lines 122-127 of Appendix A indicate the root object class associated with an RPC service. Client systems generally request execution of procedures of an RPC service by accessing an RPC service using attributes which indicate the RPC service name/interface name registered (orclNetROInterfaceName attribute) with directory server 160. Thus, line 126 indicates that object class ‘orclNetROInterfaceObject’ use properties of attribute orclNetROInterfaceName (of Lines 4-8) and orclNetROSvcReg (Lines 15-19) while performing a search in directory server 160 to process a request from client system.
Line 132 indicates that the previously defined (in line 9) attribute orclNetROInterfaceBinaryAttribute is used by the object class orclNetROInterfaceBinaryObject defined starting from line 129. The attribute is used by directory server 160 while storing and further while processing a query from client systems for object class definitions of an RPC service. Similar relationship exists between attribute orclNetROInterfaceAttributeName (line 138) with object class orclNetROInterfaceAttributeObject (defined starting at line 135), as well as attributes orclNetROInterfaceAttributeParameterName (line 144), orclNetROInterfaceParameterArgument (line 145), orclNetROInterfaceAttributeParameterType (line 146), and orclNetROInterfaceAttributeParameterValue (line 146) with orclNetROInterfaceAttributeParameterObject (Line 141).
Similarly, lines 149-159 specify object classes for representing structure of data types using corresponding attributes (lines 153-153, 158-159). Object class orclNetROTypeObject (of line 149) is defined using attributes orclNetROTypeName (Line 152), orclNetROTypeKind (152), orclNetROTypeMemberOf (Line 153) and orclNetROTypeAggregateSize. Similarly, object class orclNetROTypeAttributeObject (of line 155) is defined using orclNetROTypeAttributeName (Lines 158) and orclNetROTypeAttributeParameter (Line 159).
Lines 161-177 are shown containing object classes for representing a procedure in a service with corresponding relation to the attributes. The object classes orclNetROProcedureObject (lines 161), orclNetROProcedureParameterObject (line 167) and orclNetROProcedureParameterAttributeObject (line 173) used for representing a procedure as an object are shown using corresponding attributes orclNetROProcedureName and orclNetROPrototype (line 164), orclNetROParameterName and orclNetROParameterType (line 170), orclNetROParameterAttributeName (176) and orclNetROParameterAttributeArgument (Line 177).
The schema definition specifies a logical language in which the entries for any RPC interface could be stored in the directory server. The schema definition is loaded into the directory server before any entry specific to any RPC service could be stored in the directory server. The loading of the schema of Appendix A into the directory server is done using several known (e.g., ldapadd, ldapmodify etc provided by Oracle Corporation, Redwood shores, Calif., USA) tools. According to one approach, the interchange format file is manually generated (in a format suitable for loading onto directory server 160) for the schema. In the case of LDAP directory server, the interchange format file is referred to as LDIF file (LDAP Interchange Format File). The content of LDIF file specifying the schema is contained in Appendix A. This schema is an extension from the schema templates of
Appendix B depicts the contents or entries in the LDIF file for the object class definitions of Appendix A, and the IDL file of
Lines 1-8 of Appendix B indicate the name space hierarchy under which the object classes are defined. Such hierarchy provides a unique universal resource locater which the information in the object classes can be queried and accessed. Thus, client systems use the unique locators in accessing the procedures in the service.
Lines 10-20 are shown representing objects used in defining a RPC service. The orclNetROInterfaceName (of line 16) attribute for the Object class ‘orclNetROInterfaceObject’ (line 15) indicates that service defined using LDIF file of Appendix B corresponds to myService (Line 315 of
Lines 21-24 contain representation of an attribure (UUID of line 303), associated with the RPC service (myService). The object class orclNetROInterfaceAttributeObject (line 22) contains a value ‘UUID’ for the associated attribute orclNetROInterfaceAttributeName in line 23 according to definition of this object class (lines 135-139 of Appendix A).
Lines 25-28 contain representation of a parameter value for the attribure UUID (values enclosed within brackets following UUID of line 303) indicating an unique identifier for the RPC service (myService), which is stored in directory server 160. The object class orclNetROInterfaceAttributeParameterObject (line 26) contains a value ‘807B9154B46E—1F65_E034—0800208AB384’ for the associated attribute orclNetROInterfaceAttributeParameterName in line 27 according to definition of this object class (lines 141-147 of Appendix A).
Lines 29-32 contain representation of a parameter value for the attribute ‘version’ (line 305) indicating the present version of the service (myService) on RPC server. The object class orclNetROInterfaceAttributeObject (line 30) contains a value ‘version’ for the associated attribute orclNetROInterfaceAttributeName in line 31 according to definition of this object class (lines 135-139 of Appendix A).
Lines 33-36 contain representation of a parameter value for the attribure version (values enclosed within brackets following UUID of line 305) indicating that the present version of the service ‘myService’ available on RPC server is 1. The object class orclNetROInterfaceAttributeParameterObject (line 34) contains a value ‘1’ for the associated attribute orclNetROInterfaceAttributeParameterName in line 35 according to definition of this object class (lines 141-147 of Appendix A).
Lines 37-40 and 41-45 contain representation of attributes (endpoint of line 307) and the corresponding parameter value (RSLV of line 307), which are based on object class definitions for orclNetROInterfaceAttributeObject (lines 135-139 of Appendix A) and orclNetROInterfaceAttributeParameterObject (lines 141-147 of Appendix A).
Lines 46-49 and 50-54 contain representation of an attribute (address_desc of line 309) and the parameter value (service_endpoint of line 309), which are based on object class definitions for orclNetROInterfaceAttributeObject (lines 135-139 of Appendix A) and orclNetROInterfaceAttributeParameterObject (lines 141-147 of Appendix A).
Lines 55-58 and 59-63 contain representation of an attribute (rslv_server of line 309) and the parameter value (ANSWER of line 309), which are based on object class definitions for orclNetROInterfaceAttributeObject (lines 135-139 of Appendix A) and orclNetROInterfaceAttributeParameterObject (lines 141-147 of Appendix A).
Lines 64-68 contain representation of a data structure used by myService (aggregate1_t of line 324). As may be observed from line 65, representation of such a structure is based on object class definition of the object orclNetROTypeObject (Lines 149-153 of Appendix A). Attributes orclNetROTypeName and orclNetROTypeKind has corresponding values as ‘aggregate—1’ and ‘typedef structure’ as indicated in lines 66 and 67.
Lines 69-75 contain representation of a member of the data structure aggregate1_t (member1_aggregate1 as in line 320 of IDL definition of
Lines 76-85 contain definition of an attribute (size_in of line 320) according to the definition of the object class orclNetROTypeAttributeObject (lines 155-159 of Appendix A). Lines 92-97 contain represenation of yet another data structure (‘maxlength’ in line 326) according to object class definition of orclNetROTypeObject (lines 149-153 of Appendix A).
Lines 98-102 contain representation of a procedure (remoteproc1 in line 328) which can be accessed in the service (myService). The procedure is represented according to object class definition (line 161-165) for a corresponding object (orclNetROProcedure in line 99). The attributes associated with the object class are contained in lines 100-102.
Lines 103-108 contain representation of a type of the parameter resulting from the execution of the procedure remoteproc1 (sb4 of line 328) according to the definition of object class orclNetROPrcoedureParameterObject (lines 167-171 of Appendix A).
Lines 109-113 contain representation of an attribute for the parameters received from the client system for execution of procedure remoteproc1 and resulting after the execution of the procedure. Such a representation is based on definition of an object class ‘orclNetROProcedureParameterAttributeObject’ (lines 173-177 of Appendix A).
Lines 114-119 and 125-130 contain representation of parameters (parameter1 and parameter2 respectively of line 328) according to the object definition of orclNetROProcedureParameterObject (lines 167-171 of Appendix A).
An attribute associated with the parameter (parameter1 of line 328) is represented in lines 120-124 according to object definition of ‘orclNetROProcedureParameterAttributeObject’ (lines 173-177 of Appendix A). Similarly, attributes (in, out of line 328) of another parameter parameter2′ (line 328) are represented in corresponding lines 131-134 and 135-139 according to definition of object class ‘orclNetROProcedureParameterAttributeObject’ (lines 173-177 of Appendix A).
These string entries are dynamically constructed by implementing RPC library interfaces. RPC library interfaces are written on top of the LDAP protocol, known way (application programmers interface set for interaction with the LDAP server). Using these interfaces these entries are loaded onto directory server 160, and client systems 110-A and 110-B may discover the servers (and corresponding interfaces) on which a desired service can be accessed, as described below with example transactions.
11. Interaction Between Client System and Directory ServerIn general, client system 110-A generates directory queries to determine the service interface and the procedure interface. Client system 110-A can potentially query for all the services registered with directory server 160 (if that information is not already known), or only the specific service of interest. As noted above, in an embodiment, directory server 160 is implemented according to LDAP, and the manner in which the queries can be generated is described below with examples.
In general, an LDAP query needs to specify (a) base distinguished name (an entry where to start searching); (b) scope (the scope of the search); (c) filter (what to search for); and (d) attributes and attributes_only (the type of information/attributes which are to be returned).
Thus, for example, assuming that client system 110-A need to generate a directory query for “remoteproc1” in line 98 of appendix B, the LDAP query may be formed as follows:
(a) the base distinguished name:
dn:orclNetROProcedureName=remoteproc1,orclNetROInterfaceName=myService,cn=orclnetRemoteOpsInterfaceRegistration,cn=OracleNetRemoteOps,cn=OracleNet,cn=Products,cn=OracleContext,% s_SubscriberDN %
(b) scope: LDAP_SCOPE_BASE (only the attributes of the base entry)
(c) filter: “orclNetROProcedureName: remoteproc1”
(d) to get only the prototype: the attributes argument is: {“orclNetROPrototype”, NULL}
In response, directory server 160 returns the procedure interface for remoteproc1 in the IDL file.
As another example, with reference to appendix B line 7, to query all the service interfaces which are currently loaded into the directory server, an LDAP query may be formed as follows:
(a) the base distinguished name:
cn=orclnetRemoteOpsInterfaceRegistration,cn=OracleNetRemoteOps,cn=OracleNet, cn=Products,cn=OracleContext,% s_SubscriberDN %
(b) scope: LDAP_SCOPE_ONELEVEL (indicating that only one level below the base entry, line number 13 in appendix B; as shown in the Appendix A and B for the Oracle IDL reference implementation, all the remote interface entries lie one level below the base entry in the directory tree for remote interface registration)
(c) filter: “orclNetROInterfaceName=*”
(d) to get only the interface name, the attributes argument is: {“orclNetROInterfaceName”, NULL}
Thus, by generating queries such as those above, client system 110-A may retrieve all the required information from directory server 160, and generate the RPC requests. The overall operation is summarized below.
12. Overall Operation SummaryThe schema (
Each RPC server system 180-A and 180-B generates entries as described in Appendix B and stores these entries on directory server 160 in a known way (to make the corresponding RPC service information accessible to client systems 110-A and 110-B). As noted above, each RPC server system 180-A can provide different/custom service interface as well as access controls for the same service.
If the service definition changes in between, RPC server 180-A may regenerate the entries to reflect the change, and modify the entry with the new content again on directory server 160. As a result, change of information is dynamically reflected at least in RPC queries received thereafter. In addition, each service is defined in a corresponding object sub-tree stored in the directory server. The storing is performed in a known way.
Client systems 110-A and 110-B can query directory server 160 to retrieve the information related to each service of interest, for example, as described above. Once the information on the service of interest (and the procedure interface) is available, client system 110-A can generate an RPC request (similar to in a prior art situation in which RPC requests are generated based on information in the IDL files provided to the client system), and send the generated request to RPC server 180-A in a known way. The response may also be sent/received in a known way.
Due to the features described above client systems can dynamically discover the RPC services accessible on different RPC servers, and cause execution of desired services. The description is continued with respect to an embodiment in which various features of the present invention are operative by execution of appropriate software instructions.
13. Software ImplementationProcessing unit 510 may execute instructions stored in RAM 520 to provide several features of the present invention. Processing unit 510 may contain multiple processors, with each processor potentially being designed for a specific task. Alternatively, processing unit 510 may contain only a single processor. RAM 520 may receive instructions and data from secondary memory 530 and network interface 580 using communication path 550.
Graphics controller 560 generates display signals (e.g., in RGB format) to display unit 570 based on data/instructions received from processing unit 510. Display unit 570 contains a display screen to display the images defined by the display signals. Input interface 590 may correspond to a keyboard and/or mouse, and generally enables a user to provide various inputs (e.g., request/query). Network interface 580 enables some of the inputs (and outputs) to be provided on a network and also to interface with other systems over network 150. Display unit 570, input interface 590 and network interface 580 may be implemented in a known way.
Secondary memory 530 may contain hard drive 535, flash memory 536, and removable storage drive 537. Secondary memory 230 may store the data and software instructions which cause digital processing system 500 to provide several features in accordance with the present invention. Some or all of the data and instructions may be provided on removable storage unit 540, and the data and instructions may be read and provided by removable storage drive 537 to processing unit 510. Floppy drive, magnetic tape drive, CD?ROM drive, DVD Drive, Flash memory, removable memory chip (PCMCIA Card, EPROM) are examples of such removable storage drive 537.
Removable storage unit 540 may be implemented using medium and storage format compatible with removable storage drive 537 such that removable storage drive 537 can read the data and instructions. Thus, removable storage unit 540 includes a computer readable storage medium having stored therein computer software and/or data.
In this document, the term “computer program product” is used to generally refer to removable storage unit 540 or hard disk installed in hard drive 535. These computer program products are means for providing software to digital processing system 500. Processing unit 510 may retrieve the software instructions, and execute the instructions to provide various features of the present invention as described herein.
Thus, various features of the present invention enable client systems to discover services accessible by remote procedure calls (RPC) on server systems.
14. CONCLUSIONWhile various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
APPENDIX A
- 1. dn: cn=subschemasubentry
- 2. changetype: modify
- 3. add: attributetypes
- 4. attributetypes: (<oid_prefix>.1 NAME ‘orclNetROInterfaceName’
- 5. DESC ‘the name of the Remote Operations based interface’
- 6. EQUALITY caseExactMatch
- 7. SUBSTR caseExactSubstringsMatch
- 8. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 9. attributetypes: (<oid_prefix>.2 NAME ‘orclNetROInterfaceBinaryAttribute’
- 10. DESC ‘object descriptor of an interface instance is stored as binary’
- 11. EQUALITY caseExactMatch
- 12. SUBSTR caseExactSubstringsMatch
- 13. SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE_VALUE)
- 15. attributetypes: (<oid_prefix>.3 NAME ‘orclNetROSvcReg’
- 16. DESC ‘the name under which the interface is registered’
- 17. EQUALITY caseExactMatch
- 18. SUBSTR caseExactSubstringsMatch
- 19. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 21. attributetypes: (<oid_prefix>.4 NAME ‘orclNetROInterfaceAttributeName’
- 22. DESC ‘the name of the interface attribute’
- 23. EQUALITY caseExactMatch
- 24. SUBSTR caseExactSubstringsMatch
- 25. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 27. attributetypes: (<oid_prefix>.5 NAME ‘orclNetROInterfaceAttributeParameterName’
- 28. DESC ‘the name of the parameter to interface attribute’
- 29. EQUALITY caseExactMatch
- 30. SUBSTR caseExactSubstringsMatch
- 31. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 33. attributetypes: (<oid_prefix>.6 NAME ‘orclNetROInterfaceAttributeParameterArgument’
- 34. DESC ‘the argument to the interface attribute parameter’
- 35. EQUALITY caseExactMatch
- 36. SUBSTR caseExactSubstringsMatch
- 37. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 MULTI_VALUE)
- 39. attributetypes: (<oid_prefix>.7 NAME ‘orclNetROInterfaceAttributeParameterType’
- 40. DESC ‘the type of the interface attribute parameter’
- 41. EQUALITY caseExactMatch
- 42. SUBSTR caseExactSubstringsMatch
- 43. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 45. attributetypes: (<oid_prefix>.8 NAME ‘orclNetROInterfaceAttributeParameterValue’
- 46. DESC ‘the value of the interface attribute parameter’
- 47. EQUALITY caseExactMatch
- 48. SUBSTR caseExactSubstringsMatch
- 49. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 51. attributetypes: (<oid_prefix>.9 NAME ‘orclNetROTypeName’
- 52. DESC ‘the name of the scalar or aggregate data type’
- 53. EQUALITY caseExactMatch
- 54. SUBSTR caseExactSubstringsMatch
- 55. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 57. attributetypes: (<oid_prefix>.10 NAME ‘orclNetROTypeKind’
- 58. DESC ‘the type for instance int or typedef struct’
- 59. EQUALITY caseExactMatch
- 60. SUBSTR caseExactSubstringsMatch
- 61. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 63. attributetypes: (<oid_prefix>.11 NAME ‘orclNetROTypeMemberOf’
- 64. DESC ‘the member of which aggregate’
- 65. EQUALITY caseExactMatch
- 66. SUBSTR caseExactSubstringsMatch
- 67. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 69. attributetypes: (<oid_prefix>.12 NAME ‘orclNetROTypeAggregateSize’
- 70. DESC ‘the size of the aggregate’
- 71. EQUALITY caseExactMatch
- 72. SUBSTR caseExactSubstringsMatch
- 73. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 75. attributetypes: (<oid_prefix>.13 NAME ‘orclNetROTypeAttributeName’
- 76. DESC ‘the name of the attribute for this type’
- 77. EQUALITY caseExactMatch
- 78. SUBSTR caseExactSubstringsMatch
- 79. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 81. attributetypes: (<oid_prefix>.14 NAME ‘orclNetROTypeAttributeParameter’
- 82. DESC ‘the parameter for the attribute of this type’
- 83. EQUALITY caseExactMatch
- 84. SUBSTR caseExactSubstringsMatch
- 85. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 87. attributetypes: (<oid_prefix>.15 NAME ‘orclNetROProcedureName’
- 88. DESC ‘the name of the procedure’
- 89. EQUALITY caseExactMatch
- 90. SUBSTR caseExactSubstringsMatch
- 91. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 92. attributetypes: (<oid_prefix>.16 NAME ‘orclNetROPrototype’
- 93. DESC ‘the prototype declaration for the procedure’
- 94. EQUALITY caseExactMatch
- 95. SUBSTR caseExactSubstringsMatch
- 96. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 98. attributetypes: (<oid_prefix>.17 NAME ‘orclNetROParameterName’
- 99. DESC ‘the parameter to this procedure’
- 100. EQUALITY caseExactMatch
- 101. SUBSTR caseExactSubstringsMatch
- 102. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 104. attributetypes: (<oid_prefix>.18 NAME ‘orclNetROParameterType’
- 105. DESC ‘the type of the parameter’
- 106. EQUALITY caseExactMatch
- 107. SUBSTR caseExactSubstringsMatch
- 108. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 110. attributetypes: (<oid_prefix>.19 NAME ‘orclNetROParameterAttributeName’
- 111. DESC ‘the attribute for the parameter of the procedure’
- 112. EQUALITY caseExactMatch
- 113. SUBSTR caseExactSubstringsMatch
- 114. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE_VALUE)
- 116. attributetypes: (<oid_prefix>.20 NAME ‘orclNetROParameterAttributeArgument’
- 117. DESC ‘the arguments to the attribute for the parameter of the procedure’
- 118. EQUALITY caseExactMatch
- 119. SUBSTR caseExactSubstringsMatch
- 120. SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 MULTI_VALUE)
- 121. —
- 122. add: objectclasses
- 123. objectclasses: (<oid_prefix>.23 NAME ‘orclNetROInterfaceObject’
- 124. DESC ‘the root of the entire object tree specific to this interface’
- 125. SUP orclContainer
- 126. AUXILIARY MUST (orclNetROInterfaceName $ orclNetROSvcReg $ orclaci)
- 127. MAY (description))
- 129. objectclasses: (<oid_prefix>.24 NAME ‘orclNetROInterfaceBinaryObject’
- 130. DESC ‘object descriptor associated with a interface is stored in binary form’
- 131. SUP orclNetROInterfaceObject
- 132. AUXILIARY MUST (orclNetROInterfaceBinaryAttribute)
- 133. MAY (description))
- 135. objectclasses: (<oid_prefix>.25 NAME ‘orclNetROInterfaceAttributeObject’
- 136. DESC ‘the attribute of the interface’
- 137. SUP orclNetROInterfaceObject
- 138. AUXILIARY MUST orclNetROInterfaceAttributeName
- 139. MAY (description))
- 141. objectclasses: (<oid_prefix>.26 NAME ‘orclNetROInterfaceAttributeParameterObject’
- 142. DESC ‘the parameter for the attribute of the interface’
- 143. SUP orclNetROInterfaceAttributeObject
- 144. AUXILIARY MUST orclNetROInterfaceAttributeParameterName
- 145. MAY (orclNetROInterfaceAttributeParameterArgument $
- 146. orclNetROInterfaceAttributeParameterType $ orclNetROInterfaceAttributeParameterValue $ 147.description))
- 149. objectclasses: (<oid_prefix>.27 NAME ‘orclNetROTypeObject’
- 150. DESC ‘the scalar or aggregate type defined in the interface’
- 151. SUP orclNetROInterfaceObject
- 152. AUXILIARY MUST (orclNetROTypeName $ orclNetROTypeKind)
- 153. MAY (orclNetROTypeMemberOf $ orclNetROTypeAggregateSize $ description))
- 155. objectclasses: (<oid_prefix>.28 NAME ‘orclNetROTypeAttributeObject’
- 156. DESC ‘the attribute of the scalar or aggregate type’
- 157. SUP orclNetROTypeObject
- 158. AUXILIARY MUST orclNetROTypeAttributeName
- 159. MAY (orclNetROTypeAttributeParameter $ description))
- 161. objectclasses: (<oid_prefix>.29 NAME ‘orclNetROProcedureObject’
- 162. DESC ‘the procedure within the interface’
- 163. SUP orclNetROInterfaceObject
- 164. AUXILIARY MUST (orclNetROProcedureName $ orclNetROPrototype)
- 165. MAY (description))
- 167. objectclasses: (<oid_prefix>.30 NAME ‘orclNetROProcedureParameterObject’
- 168. DESC ‘all the parameters including return type of the procedure’
- 169. SUP orclNetROProcedureObject
- 170. AUXILIARY MUST (orclNetROParameterName $ orclNetROParameterType)
- 171. MAY (description))
- 173. objectclasses: (<oid_prefix>.31 NAME ‘orclNetROProcedureParameterAttributeObject’
- 174. DESC ‘the attribute for all the parameters including return types of the procedure’
- 175. SUP orclNetROProcedureParameterObject
- 176. AUXILIARY MUST (orclNetROParameterAttributeName)
- 177. MAY (orclNetROParameterAttributeArgument $ description))
- 178. —
- 179. dn: cn=catalogs
- 180. changetype: modify
- 181. add: orclindexedattribute
- 182. orclindexedattribute: orclNetROInterfaceName
- 184. dn: cn=catalogs
- 185. changetype: modify
- 186. add: orclindexedattribute
- 187. orclindexedattribute: orclNetROSvcReg
- 189. dn: cn=catalogs
- 190. changetype: modify
- 191. add: orclindexedattribute
- 192. orclindexedattribute: orclNetROInterfaceBinaryAttribute
- 1. dn:
- 2. cn=OracleNetRemoteOps,cn=OracleNet,cn=Products, cn=OracleContext,% s_SubscriberDN %
- 3. objectclass: top
- 4. objectclass: orclContainer
- 5. cn: orclnetRemoteOps
- 6. description: An Oracle Net Remote Operations Services system
- 7. dn:
- 8. cn=orclnetRemoteOpsInterfaceRegistration,cn=OracleNetRemoteOps,cn=OracleNet, cn=Products,cn=OracleContext,% s_SubscriberDN %
- 9. objectclass: top
- 10. objectclass: orclContainer
- 11. cn: orclnetRemoteOpsInterfaceRegistration
- 12. description: An Oracle Net Remote Operations Interface Registration sub-system
- 13. dn: orcNetROInterfaceName=myService,cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,
- 14. cn=OracleNet,cn=Products,cn=OracleContext,% s_SubscriberDN %
- 15. objectclass: orclNetROInterfaceObject
- 16. orclNetROInterfaceName: myService
- 17. orclNetROSvcReg: server_ldap
- 18. orclaci: access to attr=(*) by dn=“cn=orcladmin, cn=Users, % SUBSCRIBER_DN %”
- (search, read, write, compare)
- 19. by * (search, read, nowrite, nocompare)
- 20. description: The Interface Name for this Oracle Net Remote Operations Interface object
- 21. dn: orclNetROInterfaceAttributeName=uuid,orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNet,cn=Products, cn=OracleNetRemoteOps,cn=OracleContext,% s_SubscriberDN %
- 22. objectclass: orclNetROInterfaceAttributeObject
- 23. orclNetROInterfaceAttributeName: uuid
- 24. description: The Interface Attribute for this Oracle Net Remote Operations Interface Attribute object
- 25. dn: orclNetROInterfaceAttributeParameterName-=807B9154B46E—1F65_E034—0800208AB384, orclNetROInterfaceAttributeName=uuid, orclNetROInterfaceName=myService,cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet,cn=Products, cn=OracleContext,% s_SubscriberDN %
- 26. objectclass: orclNetROInterfaceAttributeParameterObject
- 27. orclNetROInterfaceAttributeParameterName: 807B9154B46E—1F65_E034—0800208AB384
- 28. description: The Interface Attribute Parameter for this Oracle Net Remote Operations Interface Attribute object
- 29. dn: orclNetROInterfaceAttributeName=version,orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet, cn=Products,cn=OracleContext,% s_SubscriberDN %
- 30. objectclass: orclNetROInterfaceAttributeObject
- 31. orclNetROInterfaceAttributeName: version
- 32. description: The Interface Attribute for this Oracle Net Remote Operations Interface Attribute object
- 33. dn: orclNetROInterfaceAttributeParameterName=1, orclNetROInterfaceAttributeName=version,orclNetROInterfaceName=myService, cn=OracleNetRemoteOps,cn=orclnetRemoteOpsInterfaceRegistration,cn=OracleNet, cn=Products,cn=OracleContext,% s_SubscriberDN %
- 34. objectclass: orclNetROInterfaceAttributeParameterObject
- 35. orclNetROInterfaceAttributeParameterName: 1
- 36. description: The Interface Attribute Parameter for this Oracle Net Remote Operations Interface Attribute object
- 37. dn: orclNetROInterfaceAttributeName=endpoint,orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet, cn=Products,cn=OracleContext,% s_SubscriberDN %
- 38. objectclass: orclNetROInterfaceAttributeObject
- 39. orclNetROInterfaceAttributeName: endpoint
- 40. description: The Interface Attribute for this Oracle Net Remote Operations Interface Attribute object
- 41. dn: orclNetROInterfaceAttributeParameterName=RSLV, orclNetROInterfaceAttributeName=endpoint, orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration,cn=OracleNetRemoteOps, cn=OracleNet,cn=Products,
- 42. cn=OracleContext,% s_SubscriberDN %
- 43. objectclass: orclNetROInterfaceAttributeParameterObject
- 44. orclNetROInterfaceAttributeParameterName: RSLV
- 45. description: The Interface Attribute Parameter for this Oracle Net Remote Operations Interface Attribute object
- 46. dn: orclNetROInterfaceAttributeName=address_desc, orclNetROInterfaceName=myService,cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet,cn=Products, cn=OracleContext,% s_SubscriberDN %
- 47. objectclass: orclNetROInterfaceAttributeObject
- 48. orclNetROInterfaceAttributeName: address_desc
- 49. description: The Interface Attribute for this Oracle Net Remote Operations Interface Attribute object
- 50. dn: orclNetROInterfaceAttributeParameterName=service_endpoint, orclNetROInterfaceAttributeName=addres s_desc, orclNetROInterfaceName=myService,cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet,cn=Products,
- 51. cn=OracleContext,% s_SubscriberDN %
- 52. objectclass: orclNetROInterfaceAttributeParameter
- 53. orclNetROInterfaceAttributeParameterName: service_endpoint
- 54. description: The Interface Attribute Parameter for this Oracle Net Remote Operations Interface Attribute object
- 55. dn: orclNetROInterfaceAttributeName=rslv_server, orclNetROInterfaceName=myService,cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet,cn=Products, cn=OracleContext,% s_SubscriberDN %
- 56. objectclass: orclNetROInterfaceAttributeObject
- 57. orclNetROInterfaceAttributeName: rslv_server
- 58. description: The Interface Attribute for this Oracle Net Remote Operations Interface Attribute object
- 59. dn: orclNetROInterfaceAttributeParameterName=ANSWER, orclNetROInterfaceAttributeName=rslv_server, orclNetROInterfaceName=myService,cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet,cn=Products,
- 60. cn=OracleContext,% s_SubscriberDN %
- 61. objectclass: orclNetROInterfaceAttributeParameterObject
- 62. orclNetROInterfaceAttributeParameterName: ANSWER
- 63. description: The Interface Attribute Parameter for this Oracle Net Remote Operations Interface Attribute object
- 64. dn: orclNetROTypeName=aggregate1_t, orclNetROTypeKind=typedef struct,orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration,cn=OracleNetRemoteOps,cn=OracleNet, cn=Products,cn=OracleContext,% s_SubscriberDN %
- 65. objectclass: orclNetROTypeObject
- 66. orclNetROTypeName: aggregate1_t
- 67. orclNetROTypeKind: typedef struct
- 68. description: The Type for this Oracle Net Remote Operations Interface object
- 69. dn: orclNetROTypeName=member1_aggregate1, orclNetROTypeMemberOf=aggregate1_t,orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration,cn=OracleNetRemoteOps,cn=OracleNet, cn=Products,cn=OracleContext,% s_SubscriberDN %
- 70. objectclass: orclNetROTypeObject
- 71. orclNetROTypeName: member1_aggregate1
- 72. orclNetROTypeKind: ub4
- 73. orclNetROTypeMemberOf: aggregate1_t
- 74. orclNetROTypeAggregateSize: 2
- 75. description: The Type for this Oracle Net Remote Operations Interface object
- 76. dn: orclNetROTypeAttributeName=size_in, orclNetROTypeName=member1_aggregate1,orclNetROTypeMemberOf=aggregate1_t, orclNetROInterfaceName=myService,cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet,cn=Products,
- 77. cn=OracleContext, % s_SubscriberDN %
- 78. objectclass: orclNetROTypeAttributeObject
- 79. orclNetROTypeAttributeName: size_in
- 80. orclNetROTypeName: member1_aggregate1
- 81. orclNetROTypeKind: ub4
- 82. orclNetROTypeMemberOf: aggregate1_t
- 83. orclNetROTypeAggregateSize: 2
- 84. orclNetROTypeAttributeParameter: 1
- 85. description: The Attribute for Oracle Net Remote Operations Interface Type object
- 86. dn: orclNetROTypeName=member2_aggregate1, orclNetROTypeMemberOf=aggregate1_t,orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration,cn=OracleNetRemoteOps,cn=OracleNet, cn=Products,cn=OracleContext, % s_SubscriberDN %
- 87. objectclass: orclNetROTypeObject
- 88. orclNetROTypeName: member2_aggregate1
- 89. orclNetROTypeKind: oratext*
- 90. orclNetROTypeMemberOf: aggregate1_t
- 91. description: The Type for this Oracle Net Remote Operations Interface object
- 92. dn:orclNetROTypeName=maxlength,orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration,
- 93. cn=OracleNetRemoteOps,cn=OracleNet,cn=Products, cn=OracleContext,% s_SubscriberDN %
- 94. objectclass: orclNetROTypeObject
- 95. orclNetROTypeName: maxlength
- 96. orclNetROTypeKind: typedef ubig_ora
- 97. description: The Type for this Oracle Net Remote Operations Interface object
- 98. dn: orclNetROProcedureName=remoteproc1,orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet, cn=Products,cn=OracleContext,% s_SubscriberDN %
- 99. objectclass: orclNetROProcedureObject
- 100. orclNetROProcedureName: remoteproc1
- 101. orclNetROPrototype: [size_is(maxlength)] sb4 [ptrmemory]remoteproc1([in] aggregate1_t parameter1[in, out]ub4*parameter2)
- 102. description: The Procedure for this Oracle Net Remote Operations Interface object
- 103. dn: orclNetROParameterName=returntype, orclNetROProcedureName=remoteproc1,orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration,cn=OracleNetRemoteOps,cn=OracleNet, cn=Products,cn=OracleContext, % s_SubscriberDN %
- 104. objectclass: orclNetROProcedureParameterObject
- 105. orclNetROParameterName: returntype
- 106. orclNetROParameterType: sb4
- 107. orclNetROProcedureName: remoteproc1
- 108. description: The Procedure Parameter for this Oracle Net Remote Operations Interface Procedure object
- 109. dn: orclNetROParameterAttributeName=size_is, orclNetROParameterName=retumtype,orclNetROParameterType=sb4, orclNetROProcedureName=remoteproc1,orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps, cn=OracleNet,cn=Products,cn=OracleContext,% s_SubscriberDN %
- 110. objectclass: orclNetROProcedureParameterAttributeObject
- 111. orclNetROParameterAttributeName: size_is
- 112. orclNetROParameterAttributeArgument: maxlength
- 113. description: The Procedure Parameter Attribute for this Oracle Net Remote Operations Interface Procedure object
- 114. dn: orclNetROParameterName=parameter1,orclNetROProcedureName=remoteproc1, orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet,cn=Products, cn=OracleContext, % s_SubscriberDN %
- 115. objectclass: orclNetROProcedureParameterObject
- 116. orclNetROParameterName: parameter1
- 117. orclNetROParameterType: aggregate1_t
- 118. orclNetROProcedureName: remoteproc1
- 119. description: The Procedure Parameter for this Oracle Net Remote Operations Interface Procedure object
- 120. dn: orclNetROParameterAttributeName=in, orclNetROParameterName=parameter1,orclNetROProcedureName=remoteproc1, orclNetROInterfaceName=myService,cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet,cn=Products,
- 121. cn=OracleContext, % s_SubscriberDN %
- 122. objectclass: orclNetROProcedureParameterAttributeObject
- 123. orclNetROParameterAttributeName: in
- 124. description: The Procedure Parameter Attribute for this Oracle Net Remote Operations Interface Procedure object
- 125. dn: orclNetROParameterName=parameter2,orclNetROProcedureName=remoteproc1, orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet,cn=Products, cn=OracleContext,% s_SubscriberDN %
- 126. objectclass: orclNetROProcedureParameterObject
- 127. orclNetROParameterName: parameter2
- 128. orclNetROParameterType: ub4*
- 129. orclNetROProcedureName: remoteproc1
- 130. description: The Procedure Parameter for this Oracle Net Remote Operations Interface Procedure object
- 131. dn: orclNetROParameterAttributeName=in, orclNetROParameterName=parameter2,orclNetROParameterType=ub4*, orclNetROProcedureName=remoteproc1,orclNetROInterfaceName=myService, cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet, cn=Products,cn=OracleContext,% s_SubscriberDN %
- 132. objectclass: orclNetROProcedureParameterAttributeObject
- 133. orclNetROParameterAttributeName: in
- 134. description: The Procedure Parameter Attribute for this Oracle Net Remote Operations Interface Procedure object
- 135. dn:
- 136. orclNetROParameterAttributeName=out,orclNetROParameterName=parameter2, orclNetROParameterType=ub4*, orclNetROProcedureName=remoteproc1, orclNetROInterfaceName=myService,cn=orclnetRemoteOpsInterfaceRegistration, cn=OracleNetRemoteOps,cn=OracleNet,cn=Products, cn=OracleContext,% s_SubscriberDN %
- 137. objectclass: orclNetROProcedureParameterAttributeObject
- 138. orclNetROParameterAttributeName: out
- 139. description: The Procedure Parameter Attribute for this Oracle Net Remote Operations Interface Procedure object
Claims
1. A method of enabling client systems to cause execution of remote procedure call (RPC) services on a plurality of RPC servers, said method comprising:
- registering on a directory server a first set of RPC servers on which a first service is accessible, wherein said first set of RPC servers is comprised in said plurality of RPC servers;
- sending a query request from a first client system to said directory server, said query request specifying said first service as a desired RPC service;
- receiving a query response in said first client system, wherein said query response indicates that said first set of RPC servers provide said first service; and
- sending an RPC request to one of said first set of RPC servers to cause execution of said first service on said one of said first set of RPC servers.
2. The method of claim 1, wherein said query response further indicates a service interface using which said first service can be accessed on said one of said first set of RPC servers, and wherein said RPC request is sent according to said service interface from said first client system to said one of said first set of RPC servers.
3. The method of claim 2, wherein said service interface contains a port number at which said first service is accessible on said one of said first set of RPC servers.
4. The method of claim 2, wherein said service interface stored on said directory server further contains access control restrictions in accessing said first service provided on each of said first set of RPC servers.
5. The method of claim 4, wherein said service interface is represented as an object according to a schema.
6. The method of claim 1, wherein each of said plurality of RPC servers registers with said directory server a corresponding set of services accessible on the RPC server.
7. The method of claim 6, wherein said plurality of RPC servers perform said registration at a time of corresponding initialization.
8. A method of causing execution of a service accessible by a remote procedure call (RPC), said method comprising:
- sending a directory query to a directory server requesting a RPC server on which said service is accessible;
- receiving a response from said directory server indicating said RPC server on which said service is accessible; and
- sending an RPC request to said RPC server to cause execution of said service.
9. The method of claim 8, further comprising:
- requesting said directory server to specify a service interface on said RPC server using which said service is accessible; and
- receiving said service interface from said directory server, wherein said RPC request is sent according to said service interface.
10. The method of claim 9, wherein said service interface contains a port number at which said service is accessible on said RPC server.
11. The method of claim 10, wherein said service interface further contains access control restrictions in accessing said service provided on each of said first set of RPC servers.
12. A computer readable medium carrying one or more sequences of instructions for causing a system to cause execution of a service accessible by a remote procedure call (RPC), wherein execution of said one or more sequences of instructions by one or more processors contained in said system causes said system to perform the actions of:
- sending a directory query to a directory server requesting a RPC server on which said service is accessible;
- receiving a response from said directory server indicating said RPC server on which said service is accessible; and
- sending an RPC request to said RPC server to cause execution of said service.
13. The computer readable medium of claim 12, further comprising one or more instructions for:
- requesting said directory server to specify a service interface on said RPC server using which said service is accessible; and
- receiving said service interface from said directory server, wherein said RPC request is sent according to said service interface.
14. The computer readable medium of claim 13, wherein said service interface contains a port number at which said service is accessible on said RPC server.
15. The computer readable medium of claim 14, wherein said service interface further contains access control restrictions in accessing said service provided on each of said first set of RPC servers.
16. The computer readable medium of claim 15, wherein said service contains a procedure, further comprising one or more instructions for:
- requesting said directory server to provide a procedure interface using which said procedure can be executed; and
- receiving data representing said procedure interface, wherein said RPC request is sent to cause said procedure to be executed.
17. The computer readable medium of claim 16, wherein said procedure interface contains a set of parameters, corresponding attributes, and whether each of said set of parameters is of input type, output type or both, and said data representing said procedure interface containing said set of parameters, corresponding attributes and indication of whether each of said set of parameters is of input type, output type or both.
18. A computer readable medium carrying one or more sequences of instructions for causing a directory server to enable client systems to cause execution of remote procedure call (RPC) services on a plurality of RPC servers, wherein execution of said one or more sequences of instructions by one or more processors contained in said directory server causes said directory server to perform the actions of:
- storing a data representing a first set of RPC servers on which a first service is accessible, wherein said first set of RPC servers is comprised in said plurality of RPC servers;
- receiving a query request from a first client system to said directory server, said query request specifying said first service as a desired RPC service; and
- sending a query response to said first client system, wherein said query response indicates that said first set of RPC servers provide said first service,
- whereby said first client system is enabled to send an RPC request to one of said first set of RPC servers to cause execution of said first service on said one of said first set of RPC servers.
19. The computer readable medium of claim 18, wherein said query response further indicates a service interface using which said first service can be accessed on said one of said first set of RPC servers, and wherein said RPC request is sent according to said service interface from said first client system to said one of said first set of RPC servers.
20. The computer readable medium of claim 19, wherein said service interface contains a port number at which said first service is accessible on said one of said first set of RPC servers.
21. The computer readable medium of claim 20, wherein said service interface stored on said directory server further contains access control restrictions in accessing said first service provided on each of said first set of RPC servers.
Type: Application
Filed: Mar 19, 2008
Publication Date: Jul 3, 2008
Applicant: Oracle International Corporation (Redwood Shores, CA)
Inventor: Gaurab Paul (Bangalore)
Application Number: 12/050,942