Changeset 2dafa0c
- Timestamp:
- Nov 6, 2008 9:18:37 PM (16 years ago)
- Branches:
- axis_example, compt_changes, info-ops, master, version-1.30, version-2.00, version-3.01, version-3.02
- Children:
- 4ed10ae
- Parents:
- 9c166cf
- Location:
- fedd
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
fedd/fedd_internal_messages.wsdl
r9c166cf r2dafa0c 7 7 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 8 8 xmlns="http://schemas.xmlsoap.org/wsdl/"> 9 10 <!-- 11 The message definitions are all simple embeddings of one of the types 12 from fedd_types.xsd 13 --> 9 14 10 15 <message name="FaultMessage"> … … 31 36 <portType name="feddInternalPortType"> 32 37 <operation name="AllocateProject"> 38 <documentation> 39 This internal interface allows the part of a fedd running on a machine 40 other than the boss node of the emulab in question to request creation 41 of a dynamic project on the boss node. 42 </documentation> 33 43 <input message="tns:AllocateProjectRequestMessage"/> 34 44 <output message="tns:AllocateProjectResponseMessage"/> … … 36 46 </operation> 37 47 <operation name="Ns2Split"> 48 <documentation> 49 This allows a fedd that does not have direct access to the modified ns 50 parser that splits a CEDL description into federation data to access 51 that functionality remotely. 52 </documentation> 38 53 <input message="tns:Ns2SplitRequestMessage"/> 39 54 <output message="tns:Ns2SplitResponseMessage"/> -
fedd/fedd_messages.wsdl
r9c166cf r2dafa0c 7 7 xmlns="http://schemas.xmlsoap.org/wsdl/"> 8 8 9 <!-- 10 The message definitions are all simple embeddings of one of the types 11 from fedd_types.xsd 12 --> 9 13 <message name="RequestAccessRequestMessage"> 10 14 <part name="RequestAccessRequestBody" type="xsd1:requestType"/> … … 63 67 <operation name="RequestAccess"> 64 68 <documentation> 65 Fill this in 69 Request access to a testbed. The request includes the various 70 resources needed (loosely), the identity of the requester, access 71 credentials andscheduling information. A successful response includes 72 enough information for the federation system to access the testbed and 73 actually request resources. 66 74 </documentation> 67 75 <input message="tns:RequestAccessRequestMessage"/> … … 71 79 <operation name="Create"> 72 80 <documentation> 73 Fill this in 81 A request to create a federated experiment from the included 82 description. Credentials and access information is also provided. On 83 success a logical description of the experiment is returned as well as 84 the information about federated testbeds needed to access local 85 services. 74 86 </documentation> 75 87 <input message="tns:CreateRequestMessage"/> … … 79 91 <operation name="Vtopo"> 80 92 <documentation> 81 Fill this in 93 A request for the virtual topology of the experiment. Requesters with 94 different access rights may receive different information. 82 95 </documentation> 83 96 <input message="tns:VtopoRequestMessage"/> … … 87 100 <operation name="Vis"> 88 101 <documentation> 89 Fill this in 102 A request for the visualization of the experiment. This is really a 103 legacy interface for visual tools that cannot generate their own 104 visualization. Requesters with different access rights may receive 105 different information. 90 106 </documentation> 91 107 <input message="tns:VisRequestMessage"/> … … 95 111 <operation name="Info"> 96 112 <documentation> 97 Fill this in 113 A one-stop request for meta-data on the experiment. Includes all the 114 info from a Vtopo and a Vis request. 98 115 </documentation> 99 116 <input message="tns:InfoRequestMessage"/> … … 103 120 <operation name="Terminate"> 104 121 <documentation> 105 Fill this in122 Stop this experiment and deallocate its resources. 106 123 </documentation> 107 124 <input message="tns:TerminateRequestMessage"/> -
fedd/fedd_types.xsd
r9c166cf r2dafa0c 8 8 <xsd:annotation> 9 9 <xsd:documentation> 10 The types of user IDs 10 An ID is an identifier for a principal, service, or object. This type 11 is currently polymorphic o allow different implementations of type, 12 though running code primarily uses localnames and fedids. 11 13 </xsd:documentation> 12 14 </xsd:annotation> … … 23 25 <xsd:annotation> 24 26 <xsd:documentation> 25 Nodes are described in terms of their images or hardware requirements. 26 This description may be empty 27 A node from an Emulab. It may have 0 or more images or hardware 28 types associated with it. As this description is used for 29 acquiring access to the testbed in question, multiple images or 30 types are considered options. Specifying multiple image names 31 indicates that the requester is looking for support for any of 32 them. 27 33 </xsd:documentation> 28 34 </xsd:annotation> … … 37 43 38 44 <xsd:simpleType name="kindType"> 45 <xsd:annotation> 46 <xsd:documentation> 47 An indication of how requested networking capacity is measured. 48 This will undoubtably expand. 49 </xsd:documentation> 50 </xsd:annotation> 39 51 <xsd:restriction base="xsd:string"> 40 52 <xsd:enumeration value="max"/> … … 46 58 <xsd:annotation> 47 59 <xsd:documentation> 48 Capacity value and type of cut 60 A strawman network capacity description for access negotiation. 61 This will come to include more and more interesting parameters. 49 62 </xsd:documentation> 50 63 </xsd:annotation> … … 58 71 <xsd:annotation> 59 72 <xsd:documentation> 60 The types of credentails used for remote project access 73 This captures an access credential that will be used to access 74 resources. These are certificates or public keys. The type is 75 used to designate the key to which access should be bound, or on 76 a reply has been bound. Dynamic credentials where new keys have 77 been created may also be passed in this kind of field. 61 78 </xsd:documentation> 62 79 </xsd:annotation> … … 71 88 <xsd:annotation> 72 89 <xsd:documentation> 73 Purpose of this user - service access or experiment creation 90 This defines the role the user/account is playing in the 91 federated experiment. An account being accessed by the 92 federation system to create the experiment is in the 93 experimentCreation role and the accounts that experimenters will 94 use to access local testbed services (e.g., rebooting a local 95 node) are serviceAccess roles. 74 96 </xsd:documentation> 75 97 </xsd:annotation> … … 84 106 <xsd:annotation> 85 107 <xsd:documentation> 86 A user consists of one or both of an identifier and an access 87 credential. 108 The definition of a user principal. It includes the 109 identification of the user as an ID type, the access credential(s) 110 that the user will use, and the role of the user, if any. 111 Multiple access keys may be used, and it is also possible for 112 the user to be anonymous. Though it is possible to specify a 113 user without ID, access, or role, it is difficult to imagine 114 such a user being useful. 88 115 </xsd:documentation> 89 116 </xsd:annotation> … … 100 127 <xsd:annotation> 101 128 <xsd:documentation> 102 A general attribute value pair for passing federation parameters and 103 preferences 129 A general attribute/value pair for passing federation parameters and 130 preferences. Anything encodable in XML is allowed. This is a 131 point for customization and extension. 104 132 </xsd:documentation> 105 133 </xsd:annotation> … … 114 142 <xsd:annotation> 115 143 <xsd:documentation> 116 An estimate of the resources than a federated experiment may require 144 The estimate of resources a requester is looking for, or the 145 response of a testbed indicating what it can provide. This is 146 something of a placeholder for a full resource specification, 147 and alternative encodings are likely to be imported. 117 148 </xsd:documentation> 118 149 </xsd:annotation> … … 129 160 <xsd:documentation> 130 161 Explicit translation of testbed attribute in a federated experiment 131 description. Used in a creation request. 162 description to the URI at which the controlling federation 163 system can be reached. Used in a creation request. 164 165 This type allows tools to encode experiments in familiar local 166 names for experimenters while providing remote federation 167 systems the information to map the local name into a service 168 location. 132 169 </xsd:documentation> 133 170 </xsd:annotation> … … 142 179 <xsd:annotation> 143 180 <xsd:documentation> 144 A project name and access user 181 A description of the project used to access a testbed. Includes 182 the testbed being accessed, the project name (often a local 183 name, scoped by the testbed), and any users who have been 184 granted access or for whom access is being requested. 145 185 </xsd:documentation> 146 186 </xsd:annotation> … … 157 197 <xsd:annotation> 158 198 <xsd:documentation> 159 The information needed to swap an emulab experiment in 199 A description of an Emulab sufficient for the federation system 200 to create a sub experiment on it. Note that fedAttrs provide an 201 extension mechanism by which testbeds may communicate additional 202 information and preferences to federation systems that 203 understand it. 160 204 </xsd:documentation> 161 205 </xsd:annotation> … … 175 219 <xsd:annotation> 176 220 <xsd:documentation> 177 The information about a federated sub-experiment 221 Naming and Emulab instantiation information about a federant. 222 This is returned by various informational requests and as part 223 of a successful creation message. 178 224 </xsd:documentation> 179 225 </xsd:annotation> … … 190 236 <xsd:annotation> 191 237 <xsd:documentation> 192 Node in the virtual topology of a federated experiment (emulab legacy) 238 Node in the virtual topology of a federated experiment (Emulab 239 legacy). The fields are the local hostname and the IP addresses 240 of the experimental interfaces(colon-separated). 193 241 </xsd:documentation> 194 242 </xsd:annotation> … … 202 250 <xsd:annotation> 203 251 <xsd:documentation> 204 LAN in the virtual topology of a federated experiment (emulab legacy) 252 LAN in the virtual topology of a federated experiment (Emulab legacy). 253 The fields are the name of the LAN/link (vname) the node that 254 this description applies to (vnode), the IP of the connection, 255 and performance information. 205 256 </xsd:documentation> 206 257 </xsd:annotation> … … 218 269 <xsd:annotation> 219 270 <xsd:documentation> 220 The virtual topology of a federated experiment ( emulab legacy)271 The virtual topology of a federated experiment (Emulab legacy). 221 272 </xsd:documentation> 222 273 </xsd:annotation> … … 232 283 <xsd:annotation> 233 284 <xsd:documentation> 234 Node in the visualization of a federated experiment (emulab legacy) 285 Node in the visualization of a federated experiment (Emulab 286 legacy). Fields include the local hostname of the node, x,y 287 coordinates in a 2-dimensional representation, and whether the 288 node in the visualization is a host or a LAN. 235 289 </xsd:documentation> 236 290 </xsd:annotation> … … 246 300 <xsd:annotation> 247 301 <xsd:documentation> 248 The visualization of a federated experiment ( emulab legacy)302 The visualization of a federated experiment (Emulab legacy) 249 303 </xsd:documentation> 250 304 </xsd:annotation> … … 258 312 <xsd:annotation> 259 313 <xsd:documentation> 260 The information needed to create a dynamic project 314 The information needed to create a dynamic project, specifically 315 a project description and the resources in needs access to. 316 This is used by an internal fedd interface. 261 317 </xsd:documentation> 262 318 </xsd:annotation> … … 271 327 <xsd:annotation> 272 328 <xsd:documentation> 273 The information needed to create a dynamic project 329 The description of a dynamically created project, used by an 330 internal fedd interface. 274 331 </xsd:documentation> 275 332 </xsd:annotation> … … 282 339 <xsd:annotation> 283 340 <xsd:documentation> 284 The description of the federated experiment 341 The description of the federated experiment, in extended ns2. 285 342 </xsd:documentation> 286 343 </xsd:annotation> … … 293 350 <xsd:annotation> 294 351 <xsd:documentation> 295 The full on request type. 352 Request for access to a testbed. It includes the testbed from 353 which resources are being requested (a single service may 354 provide access to many), the user or project requesting access 355 (a testbed making the request will leave both empty), the 356 resources needed, the access keys to be used in the subsequent 357 instantiation and service use, an allocation ID to identify this 358 access in later requests, and scheduling information. 296 359 </xsd:documentation> 297 360 </xsd:annotation> … … 321 384 <xsd:annotation> 322 385 <xsd:documentation> 323 The full on response type. 386 Response to an access request. Includes the allocation, the 387 information needed to access creation and experiment services 388 and scheduling information. 324 389 </xsd:documentation> 325 390 </xsd:annotation> … … 336 401 <xsd:annotation> 337 402 <xsd:documentation> 338 A request to embed a federated experiment across testbeds 403 A request to embed a federated experiment across testbeds. Non- 404 standard local names for testbeds are included in the 405 testbedmap, the user making the request, the experiment 406 description, master testbed, and a suggested experiment name are 407 included. More than one name can be suggested, either as 408 synonyms (a fedid and a localname) or as choices (multiple 409 localnames). 339 410 </xsd:documentation> 340 411 </xsd:annotation> … … 355 426 <xsd:annotation> 356 427 <xsd:documentation> 357 A request to embed a federated experiment across testbeds 428 The reply to a successful creation request. Includes the 429 information about federants hosting sub-experiments for service 430 access as well as virtual topology and visualization 431 information. All that information is relative to the requester. 432 ExperimentAccess includes credentials with which one can access 433 the experiment. These may include a public key necessary to 434 prove possession of the credential and should be treated with 435 care. 358 436 </xsd:documentation> 359 437 </xsd:annotation> … … 375 453 <xsd:annotation> 376 454 <xsd:documentation> 377 Request for an existing experiment's topology 455 Request for an existing experiment's virtual topology. 456 Different information may be returned based on the user's rights 457 to see the topology. 378 458 </xsd:documentation> 379 459 </xsd:annotation> … … 386 466 <xsd:annotation> 387 467 <xsd:documentation> 388 Request for an existing experiment's topology 468 The response to a topology request. Different information may 469 be returned based on the user's rights to see the topology. 389 470 </xsd:documentation> 390 471 </xsd:annotation> … … 399 480 <xsd:annotation> 400 481 <xsd:documentation> 401 Request for an existing experiment's topology 482 Request for an existing experiment's visualization. This is 483 largely a compatibility service. Different information may be 484 returned based on the user's rights to see the topology. 402 485 </xsd:documentation> 403 486 </xsd:annotation> … … 410 493 <xsd:annotation> 411 494 <xsd:documentation> 412 Request for an existing experiment's topology 495 An existing experiment's visualization. This is largely a 496 compatibility service. Different information may be returned 497 based on the user's rights to see the topology. 413 498 </xsd:documentation> 414 499 </xsd:annotation> … … 422 507 <xsd:annotation> 423 508 <xsd:documentation> 424 Request for an existing experiment's topology 425 </xsd:documentation> 509 A combined topology, visualalization, and federant request. 510 Different information may be returned based on the user's rights 511 to see the topology. </xsd:documentation> 426 512 </xsd:annotation> 427 513 <xsd:sequence> … … 433 519 <xsd:annotation> 434 520 <xsd:documentation> 435 Information on an instantiated experiment. The createResponse without 436 the secret information 521 Information on an instantiated experiment. A createResponse 522 without the secret information. Different information may be 523 returned based on the user's rights to see the topology. 437 524 </xsd:documentation> 438 525 </xsd:annotation> … … 452 539 <xsd:annotation> 453 540 <xsd:documentation> 454 Request to terminate an experiment 541 Request to terminate an experiment. 455 542 </xsd:documentation> 456 543 </xsd:annotation> … … 463 550 <xsd:annotation> 464 551 <xsd:documentation> 465 Request to terminate an experiment552 Indication that the experiment has been terminated. 466 553 </xsd:documentation> 467 554 </xsd:annotation> … … 474 561 <xsd:annotation> 475 562 <xsd:documentation> 476 Request to run splitter remotely 563 Request to run the CEDL splitter remotely. This is primarily an 564 internal interface. 477 565 </xsd:documentation> 478 566 </xsd:annotation> … … 487 575 <xsd:annotation> 488 576 <xsd:documentation> 489 Remote splitter output 577 Remote splitter output. Also an internal interface 490 578 </xsd:documentation> 491 579 </xsd:annotation> … … 497 585 498 586 <xsd:complexType name="faultType"> 587 <xsd:annotation> 588 <xsd:documentation> 589 Indication that a service has failed. The code values are 590 591 1 access denied 592 2 proxy error 593 3 badly formed request 594 4 server configuration error 595 5 internal error 596 6 partial instantiation 597 7 federant error 598 599 Errstr contains the text above corresponding to the code. Code 600 is always present. Desc provides additional human-readable data 601 about the error. 602 </xsd:documentation> 603 </xsd:annotation> 499 604 <xsd:sequence> 500 605 <xsd:element name="code" type="xsd:int">
Note: See TracChangeset
for help on using the changeset viewer.