HP BL680c XenEnterprise Management API - Page 8

Note on References vs UUIDs, Return Values/Status Codes

Page 8 highlights

1.3. WIRE PROTOCOL FOR REMOTE API CALLS CHAPTER 1. INTRODUCTION John 1.2 • our Void type is transmitted as an empty string. 1.3.1 Note on References vs UUIDs References are opaque types - encoded as XML-RPC strings on the wire - understood only by the particular server which generated them. Servers are free to choose any concrete representation they find convenient; clients should not make any assumptions or attempt to parse the string contents. References are not guaranteed to be permanent identifiers for objects; clients should not assume that references generated during one session are valid for any future session. References do not allow objects to be compared for equality. Two references to the same object are not guaranteed to be textually identical. UUIDs are intended to be permanent names for objects. They are guaranteed to be in the OSF DCE UUID presentation format (as output by uuidgen. Clients may store UUIDs on disk and use them to lookup objects in subsequent sessions with the server. Clients may also test equality on objects by comparing UUID strings. The API provides mechanisms for translating between UUIDs and opaque references. Each class that contains a UUID field provides: • A "get by uuid" method that takes a UUID, u, and returns an opaque reference to the server-side object that has UUID=u; • A get uuid function (a regular "field getter" RPC) that takes an opaque reference, r, and returns the UUID of the server-side object that is referenced by r. 1.3.2 Return Values/Status Codes The return value of an RPC call is an XML-RPC Struct. • The first element of the struct is named Status; it contains a string value indicating whether the result of the call was a "Success" or a "Failure". If Status was set to Success then the Struct contains a second element named Value: • The element of the struct named Value contains the function's return value. In the case where Status is set to Failure then the struct contains a second element named ErrorDescription: • The element of the struct named ErrorDescription contains an array of string values. The first element of the array is an error code; the remainder of the array are strings representing error parameters relating to that code. For example, an XML-RPC return value from the host.get resident VMs function above may look like this: Status Success 8

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302
  • 303
  • 304
  • 305
  • 306
  • 307
  • 308
  • 309
  • 310
  • 311
  • 312
  • 313

1.3. WIRE PROTOCOL FOR REMOTE API CALLS
CHAPTER 1. INTRODUCTION
<name>John</name>
<value><double>1.2</double></value>
</member>
</struct>
</value>
our
Void
type is transmitted as an empty string.
1.3.1
Note on References vs UUIDs
References are opaque types — encoded as XML-RPC strings on the wire — understood only by
the particular server which generated them. Servers are free to choose any concrete representation
they find convenient; clients should not make any assumptions or attempt to parse the string
contents. References are not guaranteed to be permanent identifiers for objects; clients should not
assume that references generated during one session are valid for any future session. References
do not allow objects to be compared for equality.
Two references to the same object are not
guaranteed to be textually identical.
UUIDs are intended to be permanent names for objects. They are guaranteed to be in the OSF
DCE UUID presentation format (as output by
uuidgen
. Clients may store UUIDs on disk and
use them to lookup objects in subsequent sessions with the server. Clients may also test equality
on objects by comparing UUID strings.
The API provides mechanisms for translating between UUIDs and opaque references. Each class
that contains a UUID field provides:
A“
get
by
uuid
” method that takes a UUID,
u
, and returns an opaque reference to the
server-side object that has UUID=
u
;
A
get
uuid
function (a regular “field getter” RPC) that takes an opaque reference,
r
, and
returns the UUID of the server-side object that is referenced by
r
.
1.3.2
Return Values/Status Codes
The return value of an RPC call is an XML-RPC
Struct
.
The first element of the struct is named
Status
; it contains a string value indicating whether
the result of the call was a “
Success
” or a “
Failure
”.
If
Status
was set to
Success
then the Struct contains a second element named
Value
:
The element of the struct named
Value
contains the function’s return value.
In the case where
Status
is set to
Failure
then the struct contains a second element named
ErrorDescription
:
The element of the struct named
ErrorDescription
contains an array of string values. The
first element of the array is an error code; the remainder of the array are strings representing
error parameters relating to that code.
For example, an XML-RPC return value from the
host.get
resident
VMs
function above may
look like this:
<struct>
<member>
<name>Status</name>
<value>Success</value>
</member>
8