Changes between Version 3 and Version 4 of FeddPluginCalls

Timestamp:

Jun 29, 2010 7:00:02 AM (14 years ago)

Author:

faber

Comment:

--

FeddPluginCalls

@@ -4 +4 @@
 
 The interfaces are all described in xsd and SOAP, and these are easy enough to convert into python data structures [SoapToPython once you know how].  Below we describe the semantics of each call, and the tools available to plug-in writers to assist in implementation.  These tools are available when plug-ins derive from [source:fedd/trunk/federation/access.py federation.access], as [source:fedd/trunk/federation/skeleton_access.py federation.skeleton_access] is.
+
+Each python method in the plug-in that corresponds to a plug-in interface is called with the same parameters:
+
+ * the request: a python dict representing the parameters to the call as encoded in SOAP
+ * the calling fid: a [source:fedd/trunk/federation/fedid.py fedid object] holding the caller's identity
+
+Each method should return the python dict encoding the response or raise a [source:fedd/trunk/federation/service_error.py service_error] containing information about the error.  The service_error class contains error codes (in either the [source:wsdl/trunk/fedd_types.xsd XSD] or [source:fedd/trunk/federation/service_error.py python] definitions.
 
 == Initialization ==
@@ -35 +42 @@
 
 Finally, the default initializer allocates a Lock to be acquired when accessing persistent state and reads that state from {{{self.state_file}}}.
+
+The plug-in initializer is largely plug-in depenent, but must also set the methods to be called for each interface call in the {{{self.soap_services}}} and {{{self.xmlrpcservices}}} dicts.  
+
+== !RequestAccess ===
+
+The !RequestAccess command asks the testbed to map the [FeddAbout#GlobalIdentifiers:Three-levelNames three-level name] on the call into local permissions and to do any bookkeeping associated with later attachment of resources to that allocation.  Specifically, a [http://fedd.isi.deterlab.net/trac/wiki/FeddAbout#GlobalIdentifiers:Fedids fedid] must be created.  Requests from this allocation back to the central experiment controller will be made under that principal/fedid.  Such requests gather configuration information or parameters passed between sub-experiments during creation.  The per-allocation fedid allows fine-grained control of access to thie information at the experiment controller, as well as the ability to name (and therefore request operation on) the various allocations made on this plug-in.
+
+